[j-nsp] Juniper PTX1000

[Tim Jackson]

But I want it all and I don't want to pay for it :(

--
Tim

On Sat, Dec 17, 2016 at 3:51 PM, Hannes Viertel <hviertel at bastelbude.net>
wrote:

> of course you are correct and the HM cubes are off-chip and not on-chip as
> my auto correct stated before.
>
>
> the only point i wanted to make and here i want to close the loop to
> colton’s posting.
>
> In my eyes, there is a significant difference between an barista 7280R and
> a PTX1k, both from the software features and scaling in terms of software
> and hardware.   Jericho+ and derivates (like barefoot’s tofino) will change
> this in the future on the HW side. On the SW side things look different..
> EOS itself has a modern architecture, but the quality of routing code when
> it comes to scaling and features is a different beast.  Even if a lot of
> features became commodity in the past the ability to hold 30m routes in the
> RIB is still a complicated thing to do…
>
> in the end it’s like always in life,
>
> you get what you pay for….
>
>
> /hannes
>
>
>
>
> > On 17 Dec 2016, at 21:42, Saku Ytti <saku at ytti.fi> wrote:
> >
> > 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
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>