Hi Pshem, We have seen the same issue with the 3800x In our case we use the maximum allowed packet number queue-limit 2457 packets
If I'm not mistaken, there are improvements coming to the default queue sizes with the 15.3 train George On Mon, Mar 25, 2013 at 4:25 AM, Pshem Kowalczyk <pshe...@gmail.com> wrote: > Hi, > > We have a couple of ME3600X (24cx) providing MPLS-based L2 services to > anywhere between 20 and 80 customers per chassis. For the last few > weeks we've been chasing a packet loss issue with some of those > customers. It looks like the issue is more likely to happen on > interfaces with multiple service instances then those with just a few. > In most extreme cases we have customers doing 700Mb/s on a single port > with the default queue depth (~ 50KB) and not a single dropped packet > one one hand and a bunch of <10Mb/s on another dropping packets all > the time. > > Initially we used the following QoS (per service instance): > > policy-map PM-CUST-DEFAULT-100M-OUT > class class-default > shape average 100000000 > > This was causing massive drops even for services that were only > transmitting 5-15Mb/s. Since queue-depth couldn't be applied with just > the default class, we ended up with something like this: > > policy-map PM-CUST-DEFAULT-100M-OUT > class CM-DUMMY > class class-default > shape average 100000000 > queue-limit 1536000 bytes > > (where CM-DUMMY matches non-existing qos-group). > > This made things significantly better, but I feel that the queue of > 1.5MB per service is quite excessive (bearing in mind that the device > has only 22MB in total for shared queues on 1G ports). I was told by > the TAC engineer that the memory is allocated dynamically, so it's > save to oversubscribe it. > > At this stage I'm still waiting to learn if its possible to monitor > the utilisation of that RAM. > > But the other question still lingers - what do you use as the > queue-limit? I know it's traffic-dependant but with only 3 profiles > available there is not much room to move (we use one profile for the > core-facing classes, this is the second one) and a fairly universal > depth has to be used. On top of that we don't really know what our > customers use the service for, so the visibility is very limited. > > So if you use the platform - what's your magic number? > > kind regards > Pshem > _______________________________________________ > cisco-nsp mailing list cisco-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/