[c-nsp] can't be -- output discards on 6500 gig-e

[Cheung, Rick]

	I agree, peaks that consume all the interface buffers where packets
eventually get discarded may not show up in the average utilization reported
on the CLI.

	I use STG.exe, a 1 file application that can snmp poll the interface
every 1 second or less, to capture more realtime utilization stats. You'll
need to know the OID.

http://leonidvm.chat.ru/



Rick Cheung


-----Original Message-----
From: Steve Francis [mailto:sfrancis at fastclick.com]
Sent: Thursday, July 29, 2004 3:47 PM
To: Edward Henigin; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] can't be -- output discards on 6500 gig-e


If your 1 minute average is 500Mbps, then your peaks are certainly
higher. I suspect TAC is correct.


Stephen Sprunk once said on this list:

One should note that any utilization up to 59.8% is, on average,
indistinguishable from an empty line.  70% = 1.6x delay, 80% = 3.2x, 90%
= 8.1x, and 95% = 18.05x.  Of course, once you figure in finite
buffering, anything past 59.8% is likely to be dropping packets.

ObMath: Plot r^2/(1-r).  Where the derivative exceeds one (r~0.598),
delay increases faster than traffic rate.  Assumes random arrival times.






> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net 
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Edward Henigin
> Sent: Thursday, July 29, 2004 9:37 AM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] can't be -- output discards on 6500 gig-e
> 
> Hello,
> 
> I've got a 6509/sup720 that's having output discards on a 
> gigabit ethernet interface at peak time.  No biggie, you say, 
> you're running the line too hot.  But what's "too hot?"  
> We're seeing the discards when the interface is doing 500Mbps 
> on a 1 minute average.  I do not believe at all that we 
> should be getting output discards at that traffic level.
> 
> The card is a WS-X6416-GBIC.  It has 10 ports enabled.  We 
> constantly saw discards on the port at a rate of 40 to 70 
> packets/sec over a 3 hour period.  During the same 3 hour 
> period, the port was doing 450Mbps to 650Mbps, 40kpps - 
> 55kpps, on a 5 minute average.
> 
> We opened a case with TAC and all they say is "you're running 
> out of output buffers."  I'm sorry, but that's not helpful at 
> all.  This behavior is unacceptable to me.  At 500Mbps, I 
> should NOT be discarding packets, even at that low rate.
> 
> Send flowcontrol is on, receive flowcontrol is off.  By my 
> reading of http://tinyurl.com/6omgc, that means that we will 
> not process incoming pause packets, and we should not be 
> pausing our output to the other side.
> So I don't believe that flowcontrol has anything to do with it.
> 
> Anyone else have any insight?
> 
> Thanks,
> 
> Ed
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net 
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


This message, including any attachments, contains confidential information intended for a specific
individual and purpose and is protected by law. If you are not the intended recipient, please contact
sender immediately by reply e-mail and destroy all copies. 
You are hereby notified that any disclosure, copying, or distribution of this message, or the taking 
of any action based on it, is strictly prohibited.

WARNING: Computer viruses can be transmitted via email. The recipient should check this email
and any attachments for the presence of viruses. The sender accepts no liability for any damage 
caused by any virus transmitted by this email. E-mail transmission cannot be guaranteed 
to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive 
late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors 
or omissions in the contents of this message, which arise as a result of e-mail transmission.