[j-nsp] Juniper Shaping TC, Odd Spirent Results

[Matt Bentley]

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 <saku at 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>