Allen,
Ning responds professionally on the WIND-gratis board:
Allen's response is indeed comprehensive. I am not sure if I can cover all the points here. Let me try to cover same major ones.
1) QNX is a bloated general-purpose OS.
I disagree with that. QNX is a very efficient RTOS with some advanced features commonly found on server OSes. Yet, its minimum footprint is about the same as the less capable RTOSes. QNX is technically the envy of the more popular RTOS vendors, and to which other RTOS vendors are trying to match with their new generations of RTOSes.
2) Increasing complexity of network software is, like that of PC software, the evil design of a monopoly.
This is not true. Let's look at a very small segment of network technologies--routing technology. Internet started with a simple network of computers with static routes--no routing protocols. Then came RIP (Routing Information Protocol), which automatically updates routes on all routers. As the network got larger, a more complex routing protocol OSPF was introduced. As Internet grew from a single domain network to a multi-domain one, BGP was added. This is about where the commercial deployments are at today. We already networked the whole world together. Why do we need more complex networking protocols any more than we need more bloated word processors from Microsoft?
Well, one of the problem with OSPF is that it selects the quickest path through a network based on the speeds of individual links that make up the network. Thus traffic tends to gravitate towards the fastest links. This works well when the traffic on the network is light. As the traffic increases, you will have traffic jams on the fastest links in the network. This is analogues to our highway systems where traffic jams often happens on the roads with the highest speed limit and the largest capacity.
One of the solutions to this problem is to select routes not only on the static characteristics of the links but also on the dynamic traffic loads. Other solutions include given preferences to certain traffic based on some policies, which is similar to the car-pool lanes and toll roads in our highway system. As you can see, the network control protocols get even more complex now. But the problems do not end here. How do you prevent people from abusing the system? Now you need to add a security infrastructure to protect this complex traffic engineering system...
The conclusion is that the increasing complexity of network software is driven by market forces, not by an evil empire.
3) The complexity is the main driver for more power hardware (Allen used the PC analogy to make his point that unnecessarily complex software is creating demand for more powerful hardware).
This is not true either. The more complex network control protocols do not demand proportionally more powerful hardware. In the network equipment market, the main driver for more powerful hardware is the speed. The explosive bandwidth demand is forcing equipment vendors to offload more and more packet processing functions from software to hardware. Originally, everything above layer 1 is done in software. Now all of layer 2 packet processing is done in hardware. It is common for layer 3 packet processing to be handled in hardware. Many companies now are pushing layer 4 and above into hardware.
In today's high speed network equipment, you will not find any RTOS directly involved in packet processing in the forwarding path. This is why I don't think the real-time characteristics is important anymore in the network equipment. However, I never claimed that you should drop NT or Solaris into a router. The differences between an embedded OS and a general purpose OS is huge, but there is only one trivial feature that differentiate an embedded OS and a RTOS. A RTOS has a deterministic upper bound in its interrupt latency. This difference is merely the result of thread scheduling policy (RTOS never let a lower priority thread to preempt a higher priority one except in the case of deadlock.) In some ways, RTOS's scheduling policy is undesirable for complex network control protocols.
4) Intel's IXP (which is part of their IXA), IBM's Rainier and other network processors will once again put RTOS in the path of packet processing and forwarding.
Again, this is not true. Intel's IXP has an ARM core that runs some kind of RTOS and 6 packet processing micro-engines with completely different instruction sets. Each micro-engine has 4 threads that are NOT under the control of the RTOS. You can think of IXP as an integration of host CPU and ASIC hardware in one chip. It doesn't change the fact that RTOS and the network control protocols that run on it still play the role of a controller, not the forwarding engine itself.
5) The old RTOS without advanced features can handle all of the foreseeable needs of networking.
This is a tough one because the line between what's possible and what's not with antiquated tools is not clear. Throughout the history, you see many examples of people pushing beyond the limits of primitive tools. Can any of us imagine how the Stonehenge was built almost 5 thousand years ago with the primitive tools they had then? However, I doubt any of us would argue that Caterpillar products are too complex and unnecessary because Stonehenge was built without them.
6) Cisco made an mistake selecting QNX while most companies it acquired are using older generation RTOS.
Well, most companies Cisco bought are venture funded. Their #1 goal is to be acquired in a few years. So there is an overwhelming pressure to come up with products fast. It's not surprising that their decisions are often short-sighted. Cisco and other startups, such as Juniper, are taking longer-term view. This is evident in their decisions.
I would not worry too much that Cisco will be locked in a constant battle of OSes within itself. Most of companies Cisco acquired bought their network software from other network software vendors or from free public code. These software are almost always OS agnostic (i.e..e. they are very portable from OS to OS).
There are many portable network software vendors. Nortel, who bought Bay Networks which bought Phase II before that, is the largest one. It is in their interests to keep their software OS agnostic. This is in contrast to Wind River, who bought a portable network software vendor Routerware last year and is trying to offer OS specific integrated network solutions. This leads to the next point.
7) To be Microsoft or not to be Microsoft.
Matt, and sometimes Allen, made arguments that Wind River is the next Microsoft of embedded market because WRS is offering integrated solutions just like what Microsoft is doing in the PC space. While Allen also berated Microsoft for offering integrated--a.k.a bloated and inflexible--products. So here lies the conundrum for WRS investors like us--is WRS Microsoft or not?
I think comparing WRS to MS, while convenient and emotion provoking, often over simplify the problems and obscure the fact that WRS is in a market with fundamentally different dynamics than the PC market. Furthermore, a competitive market place is a chaotic system. As you know, a chaotic system rarely produces some outcome twice.
We should evaluate the embedded markets and players on their own merits. I know it's more laborious to make points that way and often difficult to make points as crystal clear as "company X is the next Microsoft." But investing is about making predictions of future, which is never simple or clear. For me, understanding the complexities of the market and appreciating the uncertainties of my predictions is what gives me the confidence in my investment decisions. If my investment decisions were based on catchy words of my brokers, market analysts or even my friends that "company X is the next Microsoft", I would have been badly hurt many times.
Ning
|
