I do agree with the theory that packets should be dropped instead of being buffered. But at 1 GE linerate fiber with <50% utilization and around 100k packets/s this shouldn't happen with this kind of switch.
I tried the buffer-sharing-full command of Jared, but I'm still seeing packets dropped within the first 10 minutes. Cheers, Frederic On Thu, 13 Jan 2011 09:28:28 -0800 "George B." <[email protected]> wrote: > Actually meant for the below to go to the list: > > ---------- Forwarded message ---------- > From: George B. <[email protected]> > Date: Thu, Jan 13, 2011 at 9:27 AM > Subject: Re: [f-nsp] egress queue drops > To: Jared Valentine <[email protected]> > > > Actually, if anyone has been following the "bufferbloat" conversation > on gettys blog, it is probably better to drop packets than increase > buffers. If you are backing up into buffers, there is congestion and > you WANT to drop packets so the flows back off. He has noticed up to > TENS of seconds of traffic buffering end to end along some paths > (that is cumulative buffering in all devices along the path). This > means there is no way that TCP congestion avoidance and tuning > mechanisms can work. You might not find out a packet was dropped for > several seconds after the fact (because of traffic buffered up ahead > of the dropped packet along the path) and at that point all TCP does > is flail. > > Here's the blog: > > https://gettys.wordpress.com/ > > Go back to the beginning of the conversation and read the comments, > too. > > The attitude of "every packet is precious" is causing a huge > performance degradation of end user applications and things would work > a lot more smoothly if buffers were smaller and more packets got > dropped sooner. That would allow congestion avoidance mechanisms to > actually function. > > George > > > On Thu, Jan 13, 2011 at 9:18 AM, Jared Valentine > <[email protected]> wrote: > > If you're not leveraging any QoS (and from the looks of your "show > > int" it doesn't look like it), then you could add > > "buffer-sharing-full" in the global config. That will release the > > buffers that are reserved for queues 1-7 and make them available to > > queue0, which is where all of your traffic currently is today. > > > > If you are leveraging QoS, or plan on doing so in the near-term, > > then you'll probably need to be a little more selective about > > reallocating your buffers using specific "qd" commands instead. > > > > Jared Valentine > > [email protected] > > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] On Behalf Of Frederic > > Jaeckel Sent: Thursday, January 13, 2011 9:18 AM > > To: foundry-nsp > > Subject: [f-nsp] egress queue drops > > > > Hej, > > > > I'm having a few FCX switches which display egress drops in the > > interface statistics. > > > > I'm curious how I can fix that and if I can fix that. The mentioned > > thing happens on every port of the switch and at most on the uplink > > ports. I set the symmetric flow control like that: > > symmetric-flow-control set 1 buffers 320 > > > > and the error still occurs. > > > > Maybe someone has a hunch or knows the problem? Would be nice if I > > could fix that. > > > > > >> #show int e 1/1/1 > >> GigabitEthernet1/1/1 is up, line protocol is up > >> Hardware is GigabitEthernet, address is 0024.3877.9c40 (bia > > 0024.3877.9c40) > >> Configured speed auto, actual 1Gbit, configured duplex fdx, > >> actual fdx Configured mdi mode AUTO, actual none > >> Member of 5 L2 VLANs, port is tagged, port state is FORWARDING > >> BPDU guard is Disabled, ROOT protect is Disabled > >> Link Error Dampening is Disabled > >> STP configured to ON, priority is level0, mac-learning is enabled > >> Flow Control is config enabled, oper enabled, negotiation > >> disabled mirror disabled, monitor disabled > >> Not member of any active trunks > >> Not member of any configured trunks > >> No port name > >> Inter-Packet Gap (IPG) is 96 bit times > >> IP MTU 1500 bytes > >> 300 second input rate: 136526024 bits/sec, 41720 packets/sec, > >> 14.31% > > utilization > >> 300 second output rate: 355122840 bits/sec, 55045 packets/sec, > >> 36.38% > > utilization > >> 7038712 packets input, 2873484976 bytes, 0 no buffer > >> Received 8 broadcasts, 1101 multicasts, 7037603 unicasts > >> 0 input errors, 0 CRC, 0 frame, 0 ignored > >> 0 runts, 0 giants > >> 9327790 packets output, 7548747686 bytes, 0 underruns > >> Transmitted 16 broadcasts, 7630 multicasts, 9320144 unicasts > >> 0 output errors, 0 collisions > >> Relay Agent Information option: Disabled > >> > >> Egress queues: > >> Queue counters Queued packets Dropped Packets > >> 0 9327946 1356 > >> 1 0 0 > >> 2 0 0 > >> 3 0 0 > >> 4 0 0 > >> 5 0 0 > >> 6 0 0 > >> 7 0 0 > > > > best regards, > > Frederic Jaeckel > > > > _______________________________________________ > > foundry-nsp mailing list > > [email protected] > > http://puck.nether.net/mailman/listinfo/foundry-nsp > > > > _______________________________________________ > foundry-nsp mailing list > [email protected] > http://puck.nether.net/mailman/listinfo/foundry-nsp
signature.asc
Description: PGP signature
_______________________________________________ foundry-nsp mailing list [email protected] http://puck.nether.net/mailman/listinfo/foundry-nsp
