SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : Wind River going up, up, up!

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: Anthony Ettipio who wrote (7795)5/19/2000 10:23:00 PM
From: Allen Benn  Read Replies (2) of 10309
 
There have been a series of interesting posts about Cisco IOS on this and other threads. I alluded to a conundrum Cisco must be having with respect to acquiring VxWorks with nearly acquisition. Khan questions, indeed disputes, this notion. Meanwhile, from Matt Belkin's board, Ning makes some interesting observations about QNX being used by Cisco.

Ning makes many points consistent with my understanding of what is going on inside Cisco. Cisco's IOS is not much to brag about, and comes in about as many flavors as there are Cisco core products. This is consistent with Ning's description of IOS as a simple dispatching loop. In the past, when I referred to Cisco's IP, I specifically meant the rich library of network protocol, application and management software accumulated over the years. Cisco maintains a sizeable IOS group to maintain the OS and to provide support to core product developers. From what I understand, the development tools for IOS have been archaic, entirely inappropriate for timing-sensitive code. (A reliable Cisco software engineer swears the primary debug technique consists of inserting printf statements.)

A year or two ago, Cisco's IOS group undertook a major upgrade based on QNX. Memory protection was a factor in the choice of QNX, but Ning's contends there are other important reasons for Network Equipment makers to gravitate to general-purpose operating systems. He claims hardware advances and application-complexity have reached the point where full-scale server-type OS's are the preferred choices for network equipment. The traditional, lean RTOS kernel is fast becoming insufficient.

There is a strong argument in favor of Ning's view, the most famous proponent of which is Bill Gates. Bill Gates has made the world's biggest fortune with PCs by NOT scaling down the software, but instead letting Moore's Law drive the hardware up to satisfy software requirements. Windows CE and embedded NT are perfect examples of Bill's thinking in this regard. Deploy bloated generic OS's and let the hardware advance until it is practical. This is visionary stuff that worked for Bill, and makes a lot of sense if you think about it. That is, it makes sense unless you think deeply about it. Notice that Windows CE is a total flop. Embedded NT is more successful, but in limited, high-end situations.

The reality is that the proposition in question is dead wrong. It is so wrong that Cisco's decision to assimilate QNX adds gigantically to the conundrum I contend they have because of Tornado/VxWorks. Now let's see why.

A general-purpose OS comes with a ton of code that is unnecessary in any given embedded application. That is a very bad thing when it comes to reliability, provability of code, efficiency, security and timing. (Bill Gates succeeded because individuals accept unreliable operating systems. Network equipment customers, on the other hand, will not tolerate frequent failure.) The answer for QNX, of course, is that it is a mature OS, meaning that the extra code isn't likely to cause problems. Actually I believe that, as long as you work with a restricted set of microprocessors, in particular the x86 family of processors. Porting a general-purpose OS that lived and matured on a single family of processors cannot be easy, and cannot result quickly in a robust operating system on new and different hardware platforms. Cisco's struggles with QNX add support to that assertion.

So what processors have to be supported in the modern world of network equipment, or embedded systems in general? The answer is shocking if you haven't thought about it. WIND supports about 35 different processors, but they also integrate FPGA's, DSP's, various processor cores, and whatever else will be coming along that often don't look anything like a typical server CPU. And these hybrid devices are all over network equipment. Look back at the stated reason why WIND acquired EST. WIND wants to provide cradle to grave harware/software support, where some of the hooks are built into the logic device (any combination of the list above).

Let's get specific about network equipment. A recent development promises to revolutionize the network equipment space: Intelligent network processors from Intel and a competing one from IBM. These are hugely complex undertakings with micro-coded packet engines communicating to a slower-performing processor core. These devices hold the promise of higher-layered switches and similar devices providing the performance of traditional ASIC-powered network processors. It is inconceivable to me that, in this environment, timing is anything but crucial, certainly in the packet microengines, but also in the microprocessor core as well. As silicon advances through Moore's Law, concerns about timing and execution speed will become more important, not less as believed by Bill Gates and Ning. The reason is that network bandwidth increases at an even faster rate than Moore's Law, which when coupled with increasing complexity and high-layered functionality, translate into the OS and related software being the major bottleneck going forward -- forever.

Bloated, general-purpose operating systems will not be welcomed in the post-desktop era. They don't port quickly and efficiently to evolving hardware. They require excessive time and effort to become stable. They are much more difficult to protect against intrusion than their simpler brethren. Their relative inefficiency makes them struggle with explosive increases in network bandwidth. And, most of all, there is no need for them. The genre of RTOS's like VxWorks comfortably handle complexity through middleware. (You can think of middleware as operating system software that actually is needed for a particular application.) VxWorks scales up nicely through in-house and third-party add-ons to accommodate advanced network equipment features. In my view, scaling up is the fastest, most robust way to address unending growth in complexity.

This is only my opinion. What are the trends? What is happening today?

What we see is that every network processor semiconductor company seems to be deeply involved with WIND. Both of the intelligent network processors, by Intel and IBM, come with reference designs based on VxWorks, not QNX, not Linux, not Windows NT/2000 and certainly not Cisco IOS. All the expensive companies Cisco keeps acquiring build their products using Tornado/VxWorks. These companies aren't laggards; they are technology leaders. Arrowpoint builds an intelligent switch with VxWorks that Cisco is desperate to own.

It is when you put Ning's and Khan's facts together with these observations that you begin to appreciate fully one part of Cisco's conundrum. Think of the organizational warfare that must be occurring inside Cisco, where some would side with IOS-QNS, some with VxWorks, and probably some would be loyal to the old IOS.

But this is only part of the conundrum. A much more weighty problem in this context concerns competitive threats. Only when Cisco comprehends the remaining part of their conundrum will the discontinuities surface that I referred to before.

Allen
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext