I'm also asking JTAC, but have so far gotten the runaround. May need to go to advanced JTAC.
On Thu, Dec 20, 2012 at 1:18 PM, John Neiberger <jneiber...@gmail.com>wrote: > I hope someone tackles this question soon. I'm pretty interested to find > out what the answer is, too. > > John > > > On Wed, Dec 19, 2012 at 11:45 AM, Matt Bentley <mattdbent...@gmail.com>wrote: > >> Hi All: >> >> We have a 200Mbps ethernet service delivered via EoSDH. We have GigE >> handoffs to the carrier on either side. We've been seeing a chronic trace >> amount of packet loss for some time. After a lot of soul-searching, I >> think we've identified that the inbound buffers on the carrier equipment >> are smaller than what our allowable burst is. And, apparently, the >> ability >> to set BC/BE on a Juniper shaper is a brand new feature, not supported in >> our current code. We're using traffic-control profile, and so can't use a >> policer. Although I'm guessing the policer would then just begin dropping >> packets regardless of what class they're in. Has anyone encountered this >> before? Any workarounds? This seems like it should be a very serious >> problem since I can't imagine we're the only person who orders a high >> speed >> circuit over a higher speed interface, like GigE. >> >> I've used a traffic-generator to attempt to identify what the default BC >> value which Juniper doesn't allow someone to set is, and am seeing some >> oddities - or perhaps my testing is inconsistent. >> >> What I do is set my shaping rate to whatever (say 200Mbps), and then pump >> 1250 byte packets through it. 1250 bytes = 10,000 bits, so it makes the >> math easy. Then, my idea is to identify how many 1250 bytes packets I can >> send in a single burst at 1Gbps speeds prior to seeing drop. If I can >> transmit say 900 1250 byte packets, that means a BC of 9Mbps (900x1250x8), >> correct? However, assuming that's correct, I'd expect that if I reduced >> the packet size to 625 bytes (cut in half), I'd be able to send exactly >> double the number of frames (1800). Same number of bits, just double the >> number of frames. However, I've found that not be the case. Correlation >> is not linear. >> >> To make things even more complicated, if I identify 900 frames as the >> threshold at which drop begins, I'd expect that if I sent 1200 frames, I'd >> still only see 900 frames get through. However, this also does not appear >> to be linear. More frames will get through when the number sent is >> bigger. >> I suspect this has something to do with tokens being replenished - but if >> that's correct, then why are my BC values inconsistent, depending on >> packet >> size? >> >> I've opened a JTAC case, but am not getting much of anywhere. >> >> Any suggestions or comments would be greatly appreciated. >> >> Thanks! >> _______________________________________________ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> > > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp