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 <hvier...@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 <s...@ytti.fi> wrote: > > > > On 17 December 2016 at 21:26, Hannes Viertel <hvier...@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@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