[j-nsp] Juniper PTX1000

[Saku Ytti]

On 17 December 2016 at 21:26, Hannes Viertel <hviertel at bastelbude.net> wrote:

Hey,

> PTX1k is based on the paradise chipset and uses only LPM. The lookup memory is HMC based and is entirely on-chip. ( that’s at least the fpc3/ptx5k behavior, i’m relatively sure  it’s the same for ptx1k without having checked it explicitly)

The 3*2GB HMC are off-chip memory. Two of them are for packet memory,
3rd one is for lookup tables. Bloom is on-chip. FPC3 is same, except
only 2*2GB HMC, halving packet memory.

> The issue i have is not the black art part…the thing with the current implementation in EOS is that it’s highly dependent on the prefix distribution and  you have to monitor in order to not shoot you in your feet… And given the current capacity limits of Jericho you probably will see issues more in the 700-800k prefix range than in the claimed 1,2m FIB entries.  Assuming the current FIB size in the DFZ, * I  * would want to know the exact limits and have some reasonable margins. Will that change? sure… but today it is like it is and *I* would not bet my job on it…

The actual FIB count you get out of PTX1k will depend also, the HMC
itself is not the bottle neck, you'll run into other problems before
filling 2GB of HMC (Trio LU is 256MB RLDRAM).
So like always, you gotta test on actual demands and either that works
or does not work.

Sure PTX1k scales further because of the off-chip memory, but if
you're near the edge of the scaling limits you gotta test. But in case
of PTX!k or -SE, you can throw money at the problem and avoid testing,
if your requirement is exactly DFZ, then you can safely know there
will be no risk for the foreseeable future.

> but again, your milage may vary...




-- 
  ++ytti