Re: partial comments on section 5 of ibif

Hi -

> From: "bill" <[email protected]>
> To: "'Randy Presuhn'" <[email protected]>; <[email protected]>
> Cc: "'Bert Wijnen'" <[email protected]>
> Sent: Wednesday, October 08, 2003 4:20 PM
> Subject: RE: [Ipoverib] partial comments on section 5 of ibif
...
> For the multicast in packets, as I am remembering my IBTA days - IBTA
> doesn't really have multicast - just broadcast, which is subtly
> different.  I do not believe there are IBTA counters to monitor what
> this OID maps into.

OK, so these counters should simply not change because the event
they would count is physically impossible.  It probably wouldn't hurt
to say something like "Since multicast is not defined for InifiniBand,
there is nothing for this counter to count."

> For link packet/octet counters...
>
> IBTA defines a 32 bit counter of 4byte words (in otherwords a 34 bit
> counter) for physical link packets.
>
> So the best you can do is get a 34 bit count of octets/packets out for a
> 8Gbit link (yes, I have been complaining about this for 3 years now)...
>
> Unless you implement a software process that querries the hardware every
> 10 seconds, and keeps a 64 bit counter - there is no way of keeping the
> 64 bit counters (yes they can roll every 16 seconds)
...

The MIB module shouldn't  specify the implementation mechanism, but since
the underlying data clearly *is* available, specifying  that these 64-bit
counters should be zero would be incorrect.  The data rates of this interface
type and the availability of underlying (34-bit) hardware make it pretty
clear to me that the 64-bit counters (properly implemented to actually
*count*  :-) are a MUST.

Thanks for the clarifications, I'll return to grinding through the rest of
of the document.

Randy