Thanks. Unfortunately, a code upgrade isn't going to happen for us - at least for a good while yet. I'm opening the JTAC case to try to determine what the default BC is that they don't let me configure on our existing code. Then at least I know what the limitations I'm forced to deal with pending an upgrade are.
I did some testing myself, and am not seeing consistent results. The burst I can pass varies depending on both the numbers of bits I'm sending at full speed as well as the frame count/frame size ratio. For example, sending 10,000 1250 byte frames does not yield even close to the same dropped bits that 20,000 625 byte frames does. And also, if I send a 10Mb burst, a different number of bits gets through vs a 11Mb burst. The second one I sort of expect, since I'm sending for longer, but it definite doesn't make it easy to calculate the BC. Hopefully this makes sense. On Thu, Dec 20, 2012 at 1:43 PM, Saku Ytti <s...@ytti.fi> wrote: > On (2012-12-19 11:45 -0700), Matt Bentley wrote: > > > 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 > > I think you answered to yourself. If you're running Trio HW upgrade to > release which implements RLI14371, i.e. 11.4R1 or newer, I'd recommend > 11.4R6. > When upgraded configure 'shaping-rate 200m burst-size 1' (128 is actually > what gets programmed, as it's minimum size, but 1 commits, 0 does not) > > > I've opened a JTAC case, but am not getting much of anywhere. > > What is expected outcome? Known issue, addressed in shipping release. > > -- > ++ytti > _______________________________________________ > 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