On Thu, 24 Jan 2019 at 12:52, <[email protected]> wrote: > If it shows info cell drops then that means the PFE can't cope with the PPS > rate.
It can't drop cells, as packets are never cellified, as platform does not have FAB side at all. There is only WAN side, so all is local switched. > 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. EAChip (mqss) on fabric platforms has 400Gbps WAN + 400Gbps FAB, MX204 is fabless, so it's 800Gbps WAN. This test should pass with modest luss load. > -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) This is really good proposal, flow-control is on by default. -- ++ytti _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
