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-j...@lixfeld.ca> wrote: > > Hey Adam, > >> On Jan 24, 2019, at 5:51 AM, <adamv0...@netconsultings.com> >> <adamv0...@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@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@mx1# > > jlixfeld@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@mx2# > _______________________________________________ > 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