|
Malcolm Turnbull wrote:
>
> Alex Davies then explained it to me as (NB. Must have given him a
> different example).:
> --snip--
> Now, we can note that there are 32 (or more) zeros at the end of these
> numbers. In fact, any number that it throws out will have 32 bits of
> zeros after it.
Not true, at least not in the version I'm using, those zeroes are
actually the most significant 32 bits of the 64-bit value. I'm not sure
why it's like that, but you just need to swap the two 32-bit fields
around to get to the real value (which incidentally is the same as
shifting >>32 when they are all zeroes).
Take for example 2670058611031409148 returned by SNMP for 2182G.
In hex (easier to work with than binary) it is 250df429 000001fc,
the real value is 000001fc 250df429 which is 2182465057833 or 2182G.
I just used the rates instead for the time being (just remember to
change from COUNTER to GAUGE so cacti knows how it works).
> I havent tried to get LVS to return a number over 18.4
> quintillion in, but I guess that it would either move to a counter128
> and pad it with 64 zeros (or 96, or 32 - who knows?) or it would just
> work. In any case, I don't think that it is likely that this is a
> number we will ever have to deal with...
|
