Re: Multiplexing and packet loss

On Fri, 24 Apr 2009 22:36:39 -0700, Andrey Tarasov <andyvt@xxxxxxxxx>
wrote:

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.

also check the inbound queues.

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.

you can also get issues on input, since there is buffering needed
between the blade in the switch and the forwarding engine.

i agree the 6724 is a better blade to use, but mainly because it uses
the fabric rather than the shared bus, so it wont contend with other
traffic on the bus.

the fabic tap gives a 20 Gbps channel shared by the 24 GigE ports -
which doesnt sound like much over subscription.

However, the cisco hardware wraps every packet in extra control info
as it crosses the fabric link - so esp with min size packets the
useable bandwidth is only maybe 70 to 75% of that.


Regards,
Andrey.
--
Regards

stephen_hope@xxxxxxxxxxxx - replace xyz with ntl
.