On 18 May 2016 at 19:44, Adam Vitkovsky <[email protected]> wrote:
> I'm not that familiar with these small ASICs -or actually FPGAs (as a > crossover between ASIC and NPU). > But since in FPGAs not everything is programed in HW (I'm guessing), wouldn't > the execution time be partly dependent on what features are enabled? So then > higher clock-rate would mean that you can execute more instructions per given > Tc. That is to be able to do more advanced stuff while sustaining the nominal > pps rate? > Just thinking out loud. If I understood you right, you're saying 'maybe we were lookup starved, ended up buffering due to waiting for lookup engine'. But that is not microburst, microburst is egress interface being congested, lookup engine being congested is just box being oversubscribed with traffic. What Cisco is trying to explain on the PDF is that somehow to handle microburst, you need less memory, when you make clock rate higher, which is completely non-sensical (unless it's the clock of the egress interfaces, unfortunately there is only 100ppm room for creativity). Essentially they removed memory and now are trying to make it look like it's not a problem. I don't think they are trying to lie, I think their testing just tested completely wrong things. I'm pretty sure they were pacing packets, instead of bursting. Which of course means you never need buffers to hit egress rate. -- ++ytti _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
