On Mon, 19 Nov 2007, David Miller wrote:
> From: Andi Kleen <[EMAIL PROTECTED]>
> Date: Mon, 19 Nov 2007 16:29:33 +0100
>
> > > > >
> > > > > All of our options suck, we just have to choose the least sucking one
> > > > > and right now to me that's decrementing the counter as much as I
> > > > > empathize with the SNMP application overflow detection issue.
> > > >
> > > > If the SNMP monitor detects an false overflow the error it reports
> > > > will be much worse than a single missing packet. So you would replace
> > > > one error with a worse error.
> > >
> > > This can be fixed, the above cannot.
> >
> > I don't see how, short of breaking the interface
> > (e.g. reporting 64bit or separate overflow counts)
>
> As someone who just spent an entire weekend working on
> cpu performance counter code, I know it's possible.
>
> When you overflow, the new value is "a lot" less than
> the last sampled one. When the value backtracks like
> we're discussing it could here, it only decrease
> a very little bit.
While I agree with your analysis that it could be worked around,
who knows how all the various SNMP monitoring applications out there
would interpret such an unusual event. I liked Stephen's suggestion
of a deferred decrement that would insure the counter didn't ever
run backwards. But the best approach seems to be just not to count
it in the first place until tha application has actually received
the packet, since as Herbert pointed out, that's what the RFC
actually specifies for the meaning of the udpInDatagrams counter.
-Bill
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
