@jon raine wrote:
. . . but just how low should you be looking? is 2.5% going to have a significant impact on traffic and performance? like you said, just upping the threshold to mask the issue is not an answer, but what is?
"Bad" drop rates vary per apps. Traditionally, anything above 1% was considered "bad", as I recall that's about the self regulating drop rate for classical TCP.
However, apps like VoIP or video like a zero drop rate (BTW, a zero drop rate, for those traffic types, is often achievable as they have known max bandwidth needs. [NB: to also guarantee zero drop rates, for such traffic, you may need admission control.])
Lastly, NMS monitoring is often for a multi minute period average, so shorter term drop rates can be much, much higher (and detrimental). Because of the latter, I generally investigate NMS drop rates in excess of 0.1%.
@jon raine wrote:
I have just setup discard monitoring and have errors for values between 2.54% & 93.903%. obviously the higher rates will warrant immediate attention, . . .
Just curious, what you consider a higher rate. Hopefully, your 93.903% would be. ; )
PS:
Above I mention "classical TCP" self regulating. Hopefully, all will understand that TCP will often keep increasing its transmission rate to capitalize on all available bandwidth. Detecting drops was how TCP knew to slow down (and repeats its available bandwidth probing).
The latest TCP variants, besides still using drops for transmission rate management, now might very closely also monitor jumps in RTT. Seeing such, which often is due to queuing, and queuing is due to congestion. So, these variants will slow themselves without dropping packets.
If the forgoing is happening, since much to most traffic uses TCP, you might now need to consider any non-zero drop rate should be investigated.
Also keep in mind a zero drop rate doesn't guarantee all is good on the network, either.
