[j-nsp] Finding drops

[Jason Lixfeld]

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