Article Info

Link: Cisco unveils compact new edge router

Cisco unveils compact new edge router

Very interesting new system. Incorporates multiple services into a single supervisory blade. Yet another example of how Cisco is becoming more of a software oriented company. It also uses the new internal NPU, which may explain EZCH -15% in 2 days,

Discussion

Comments are disallowed for this post.

  1. “…his skepticism of NPUs was a conceptual one that the actual evidence refutes. He is letting his conceptual bias prevent him from even looking for countervailing evidence.

    Though interesting he says this in his post “Yet another example of how Cisco is becoming more of a software oriented company.” Exactly Andrew which is why the company will gladly embrace off the shelf processors just as they do off the shelf optical components. Why would Cisco invest years and 10s of millions into replicating the NPU that EZchip is offering. Think about what the NP-4 means… a design win with Cisco cements EZchip in Cisco for many many years and generations. That is why the design spec process with JNPR and CSCO are so important right now.

    On the other hand, no merchant silicon compnay could invent the Quantum Flow… There is no business case for investing $100 million of venture capital money and five years of development (starting in 2003) with a hope that Cisco in 2008 will be pursuing an aggregrated services router strategy but won’t have a processor to use and will therefore buy your chip.”

    Posted by ehud achman | March 4, 2008, 5:19 PM
  2. I’ve been waiting to post a detailed opinion on NPUs until the video from the 2007 Gilder conference is released but last I checked it was currently “under editing” and I am hopeful that my contrarian opinions have not been removed.

    Who/What is being quoted in the above comment?

    Posted by Andrew Schmitt | March 4, 2008, 5:33 PM
  3. Andrew –

    The QFP was not designed for line cards and therefore does not compete with EZchip.

    kindly,

    John

    Posted by JSimmons | March 4, 2008, 6:15 PM
  4. “It also uses the new internal NPU, which may explain EZCH -15% in 2 days,”

    The QuantumFlow is an ASIC not an NPU. And it is my belief that it was designed to process data on the router and not on the line cards, where the NP-3c lies. Additionally, the QuantumFlow uses a second silicon chip for traffic management. With no internal traffic management there is no way it can compete with merchant NPUs.

    Posted by Anonymous | March 4, 2008, 6:59 PM
  5. Heres my take on the NPU technology:

    The QFP whitepaper talks about line card apps. I’d expect to see the 10K replacement have the QFP or son-of-QFP on the line cards. So yeah, you can see this as competitive with Ezchip’s Np-2b/3.

    The TM capabilities of the QFP are similar to Ezchip’s, albeit with 2x the number of queues.

    The CPU architecture is interesting. 4 threads per core, kinda sounds like they used the 34K from MTI, but the power and freq don’t line up, esp. in 90nm – custom SRAM development perhaps?

    PPE performance is not that great. 1200 DMIPS, assuming at 1.2GHz, means the core is a relatively simple single issue. Depending on how the thread scheduling is done, this may translate to 300 DMIPS per thread. Single threaded performance is not going to be too crash hot if this is indeed the case.

    The overall device architecture is also interesting. Throwing the packet into on-chip SRAM and then letting the PPEs crunch on it is classic Cisco. Everyone knows what the limitations of this approach is – the size of the burst buffer bounds the maximum amount of processing you can do before you hit the discard condition.

    The other interesting component is the sw architecture. It appears to be a single image, run to completion model. Each PPE has all the sw it needs for all apps. This definitely simplifies the programming model, but with a 16K L1, I cache pollution may impact performance.

    It is not clear to me whether their new virtualized Linux runs on the PPEs. I’d hope not, because of the single threaded performance quoted above. The whitepaper touts how easy it is to program, because it’s written in C. The language is only part of the issue. It’s obviously easier to write something on top of an OS than on bare metal. With so much hardware assist, the complexity will be in interfacing to the hw, not the algorithmic part. The only way to really improve this is to write the apps on top of an OS which abstracts the hw and provides services to user programs. However, this comes at quite the performance penalty. And this is why I don’t think the PPEs run an OS.

    Posted by Anonymous | March 5, 2008, 10:55 PM
  6. Real world apps would never see a 90nm, 80W power hog QFP on a line card. Not cost competitive.

    Posted by JSimmons | March 7, 2008, 7:15 PM
  7. I agree that 80W is a lot of a power budget to blow. But remember it also integrates the switch fabric TM and line TM. It’s not clear whether this also includes the associated memories – probably not.

    But given most custom chassis thermals try to target for 250-300W per card (gees, even crappy old ATCA coughs up 200W per card), 80W on the packet processing + TM might not be such a non-starter as you indicate.

    As for the cost competitive aspect, given that it’s an ASIC, the majority of the cost has already been sunk. Their BOM cost would be better than buying from an ASSP vendor who has to amortize the NRE. Companies like Cisco have different investment metrics when it comes to developing ASICs versus ASSP vendors who need to do the std ROI calculation.

    Either way you look at it, a company like Cisco doing such a large investment is not good for all the other NEMs who can’t afford do spend the coin on an ASIC.

    Posted by Anonymous | March 14, 2008, 2:00 PM