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 <[email protected]> wrote: > > On 17 December 2016 at 21:26, Hannes Viertel <[email protected]> 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 [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
