Re: Multiplexing and packet loss

Hoffa wrote:
On 21 Apr, 23:42, Stephen <stephen_h...@xxxxxxxxxxxx> wrote:
On Tue, 21 Apr 2009 05:13:52 -0700 (PDT), Hoffa

<fredrik.hofg...@xxxxxxxxx> wrote:
Hi
I have a 1gbit (1000BaseZX) link between two sites that's, due to
large number of small packets, have alot of buffer related packet loss
in one direction. A solution I'm planning to implement is CWDM on this
link and team at least four interfaces into an etherchannel. I'm
however unsure if this will actually solve any of the packer loss
problems. In theory four interface buffers should be better than one
but I wounder if anyone have any real world data on this. Will a CWDM
etherchannel only move the buffer problems from the interface to the
etherchannel buffer?
you need to understnad the loss mechanism.

If you are running out of bandwidth, then CWDM may help.

if the device driving the link cannot cope with the number of packets,
then giving it more bandwidth to drive is likely to make it worse.

So equipment, traffic profile and details?

Regards
Fredrik
--
Regards

stephen_h...@xxxxxxxxxxxx - replace xyz with ntl

Thank you for the input. I'll give as much technical info as possible.
I've done some packet sniffing on the link and it's easy to see the
number of 64byte packets coming in floods on the interface. The source
of the packets is a server application cluster located at both ends of
the link and they are sending updates back and forth and the out on
the Internet.
Switch: 6513 sup720-3B
Line card: WS-X6516A-GBIC

According to

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/product_data_sheet0900aecd801459a7.html

this line card has only 1MB buffer per port. Recommended replacement - WS-X6748-SFP or WS-X6724-SFP - has 1.77MB on egress, so it's 6 of one, half a dozen of the other.

Question is - are you experiencing tail drops in egress queue or fabric drops? Can you post show interface? Number of output drops and its ration to total traffic is most interesting here.

Thrill5: What kind of buffer tuning might provide a solution? I was
under the impression that one should leave outgoing buffers and queues
alone.

Nothing can be done here - it's hardware based queuing. Thrill5 most likely assumed 7200 or similar platform.

Regards,
Andrey.
.

Quantcast