> I was monitoring bytes in/out on one of my Nevada build 110 hosts, and
> noticed a number of samples similar to this:
>
> bash-3.2# dladm show-link bge0 -s -i 1
> .......
> bge0 54685 83001694 0 9177 655350 0
> bge0 53692 81484360 0 9004 644020 0
> bge0 52153 79153774 0 8741 623334 0
> bge0 47985 18446744069487416862 0 8058 576704 0
> bge0 54690 83015076 0 9174 654468 0
>
> Is this a known issue? I didn't see a bug related to this in bugster,
> so I thought I would ask here.
The RBYTES counter often comes directly from networking hardware, so I'd
suspect that either the hardware provided a bad value or the value was
being changed while it was being read by the driver. It might be worth
DTracing bge_m_stat() to see (a) whether the statistics_type is
BGE_STAT_BLK and (b) what the *val ends up being for MAC_STAT_RBYTES. As
an aside, the driver has a comment stating:
/*
* Transfer the statistics values from the copy that the
* chip updates via DMA to the named-kstat structure.
*
* As above, we don't bother to sync or stop updates to the
* statistics, 'cos it doesn't really matter if they're a few
* microseconds out of date or less than 100% consistent ...
*/
Perhaps not syncing/stopping has a more pathological effect than just
being a little out-of-date. Or perhaps this a bug somewhere else ...
--
meem
_______________________________________________
networking-discuss mailing list
[email protected]
