[j-nsp] Finding drops

[adamv0025 at netconsultings.com]

Hi Jason,
Sorry missed the previous email,

Hmm interesting, so it's capped at the WA block then not on the ASIC, good to know.
On MPC7s we did not run into this issue but rather to the chip overload problem
>From my notes:
MPC7 24x10GE per PFE that is 2x212.773Mpps (425.546Mpps two directions) -> 17.73Mpps per 10GE
MPC7 20x10GE per PFE that is 2x212.773Mpps (425.546Mpps two directions) -> 21.28Mpps per 10GE
Just for reference:
Line-rate 10Gbps at L2(64B)@L1(84B) is 29.761Mpps (two directions

Under NDA you can get what juniper tested internally, some graphs etc..
But it's better to do your own testing (in a specific use case)

See the full linerate performance is not there so that you can send 64b packets at 100G no one would do that -but it's terher to give you some headroom to send packets of normal size and do some processing while maintaining the performance.
So yes with 100GE capable chips you have to be careful nowadays on what features you enable. 
 
adam
> -----Original Message-----
> From: Jason Lixfeld <jason-jnsp at lixfeld.ca>
> Sent: Wednesday, January 30, 2019 5:05 PM
> To: adamv0025 at netconsultings.com
> Cc: Saku Ytti <saku at ytti.fi>; Juniper List <juniper-nsp at puck.nether.net>
> Subject: Re: [j-nsp] Finding drops
> 
> Hi,
> 
> Just to close the loop on this, according to JTAC, the throughput issues
> observed are addressed in KB33477 (basically, wire speed can be achieved on
> > 96 byte packets).
> 
> > On Jan 24, 2019, at 9:43 AM, Jason Lixfeld <jason-jnsp at lixfeld.ca> wrote:
> >
> > Hey Adam,
> >
> >> On Jan 24, 2019, at 5:51 AM, <adamv0025 at netconsultings.com>
> <adamv0025 at netconsultings.com> wrote:
> >>
> >> Is the test stream unidirectional please? -say from left (the mx1 side) to
> right (mx2 side) please? Or bidirectional please?
> >
> > It’s been bi-directional, in that the Rx Tester is set to loopback. More or less
> only so I could see the number of packets received out the far side.  This
> tester won’t count ingress packets unless it’s in loopback mode, or actually
> running some test.
> >
> > In any event, turning the loopback off doesn’t have any effect on the
> results.
> >
> >> Now that you're looking at the right router.
> >> Can you please run the: show pfe statistics traffic fpc 0 | match
> "cell|drops"
> >> on mx1
> >> If it shows info cell drops then that means the PFE can't cope with the PPS
> rate.
> >
> > No matches here.  As Saku eluded to.
> >
> >> Since as Saku confirmed both interfaces et-0/0/2 and et-0/0/0 on mx1 are
> on the same PFE then the packet processing computational load for ingress
> and egress processing is not spread across two PFEs but rather executed on a
> single PFE which has to handle 200Gbps (100in+100out) worth of traffic @
> 64bps, can't be bothered to calculate the pps rate there, but my guess is that
> the PFE can't handle the resulting PPS rate (as it is most likely above the PFE's
> overall (in+out) PPS budget) which is not that high on Gen3 (applies to most
> NPUs out there with 100g ports).
> >>
> >
> >> If the chip is rated for 800G(400in+400out) extrapolating from my notes
> on MPC7 testing the 204PFE then should cope with ~200in+~200out @64bit
> (if your traffic is bidirectional you'd be at the limit.
> >
> > Are there no specs published that provide the max number of pps @ 64
> bytes the MPC7?
> >
> >> -is the flow-control disabled on all interfaces involved with this
> >> test please? (we don't want the mx2 to send pause frames to et-0/0/0
> >> on mx1 when it can't cope with the ingress PPS rate, skewing the
> >> results)
> >
> >
> > It is disabled.
> >
> > jlixfeld at mx1# wildcard range show interfaces et-0/0/[0,2] | display
> > set | match flow set interfaces et-0/0/0 ether-options no-flow-control
> > set interfaces et-0/0/2 ether-options no-flow-control
> >
> > [edit]
> > jlixfeld at mx1#
> >
> > jlixfeld at mx2# wildcard range show interfaces et-0/0/[0,2] | display
> > set | match flow set interfaces et-0/0/0 ether-options no-flow-control
> > set interfaces et-0/0/2 ether-options no-flow-control
> >
> > [edit]
> > jlixfeld at mx2#
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp