ET vs The Competition (How We Measure Up)

---

We have new MK5025 Parts for Sale! Contact us with your requirements.

Potential customers regularly ask us how our products measure up against the competition, so we decided to do a little analysis for you. We've tried not to be biased, but it is very difficult. We have done our best to indicate when we're stating an opinion. Our focus here is our high speed synchronous boards for the UNIX router market, as development APIs are clearly a matter of taste and very difficult to compare. We really only have one serious competitor, but if others arise we will try to include them in the analysis.

The Components of Comparison

There are two basic elements for comparing synchronous communications products: hardware and software. The hardware is the vehicle with which you reach the outside world. In some cases it supplies a high level of functionality, and in some cases it simply provides the minimal physical capabilities to interface to a particular medium. The basic requirement for such a product is HDLC framing, which is the scheme utilized by virtually all widely accepted synchronous protocols. HDLC is a link-level protocol and framing technique with many defined "sub-protocols". HDLC protocols continuously transmit "flags", which means that there is always data on the line when a board is enabled (unless you're half duplex, but forget about this for now). Anything that goes onto the line that is NOT a flag is considered data. There's also what's called an FCS, which is an acronym for Frame Check Sequence, or a checksum to us common folks. HDLC protocols are synchronous, which means that they are synchronized to a clock, which is usually provided by a modem or a CSU/DSU. Once the hardware meets these basic requirements, you have an HDLC board capable of running PPP, LAPB, X.25, Frame Relay or any other HDLC based protocol.

Regarding communications boards in general, you'll often see published specifications about a board which are, at best, misleading. For example the "maximum data rate" will often be published, but this is not necessarily meaningful. The max data rate for an HDLC based product defines the rate at which it can pass flags without choking (under or overrunning is the proper term). This is not very useful information because flags aren't data, and the rate that the controller can move data is dependent on a variety of other things. So the data rate doesn't tell you anything about throughput, which is really what you want to know. In the same context, the raw throughput capabilities of a board are important, but are also generally meaningless unless the software drivers associated with the board are included in the testing or analysis. In order for a board to realize its full potential throughput, the software driver must be perfectly efficient, which in real-world cases in not possible. It is not uncommon, for example, for a poorly written software driver to degrade a board's capability by as much as 90%.

The other componant of interest is the bus throughput, which for this discussion is limited to ISA and PCI. Typically the bus throughtput is equal for similar busses, that is most ISA cards are about the same across the bus and most PCI cards are similar as well. At low speeds (56 or 64kbs) the bus speed is practically meaningless because the amount of data moving across the bus is very small. Using a PCI board for a 56kbs connection will produce almost no benefit. Even with one or two T1 you will not see any noticable difference in throughput between ISA and PCI, mainly because the bus is much faster than the transmission speed so maintaining full bandwidth throughput is not difficult. The issue with ISA is bus "capacity", which implies that with multiple cards you will approach a threshold at which system performace will suffer. With 4 T1 ports on ISA card, the throughput potential reaches over 12Mbs (1.536Mbs full duplex) on the bus, which on some bridged busses is half of the bandwidth. While this level is acceptable, more than 4 T1s (assuming of course that they are very busy T1s) can become problematic, and 8 can truly tax a system. 8 or even 16 T1 ports on the PCI bus is no problem.

Hardware Architectures

In the context of high speed synchronous boards, there are basically three standard architectures. One is the dumb serial board, which usually has an SCC (serial communications controller) with a user-accessible bus interface. These boards are very slow and cannot be seriously used at the speeds we're talking about here.

Boards with a second type of architecture are commonly referred to as "intelligent" boards, which is a board with an SCC controller and an on-board CPU of some sort to manage the traffic. Intelligent boards generally run a program which is dedicated to processing interrupts and organizing incoming and outgoing data. The advantage of intelligent boards is that they offload the communications and interrupt overhead and can run complete, custom protocols on the board. The disadvantage is that they almost always have processors that are much slower than the host system (Z80s or 80186s), and that they need some sort of inefficient handshake mechanism so that the two CPUs can exchange information. They tend to be difficult to debug, and have a tendency to be less reliable than other solutions.

The third and increasingly more common approach is the use of a hardware communications processor that incorporates a dedicated processor and SCC controller in a single device. These devices usually have an internal RISC processor, internal transfer FIFOs (needed for high speed activity) and DMA mastering capability. They have all of the advantages of a board with an on-board CPU, but are much faster. Generally speaking, they are fast, compact communications engines that implement a large portion of the communications processing in hardware. An architecture which includes these powerful engines is clearly the best choice to handle today's demanding communications requirements, and this is the hardware architecture that we use for our ET/5025 series communications adapters.

The ET/5025-16 vs The RISCsomething

For internet router products, our main competitor is some company up in New England (I forget their name) with a product called RISCsomething (or something like that). RISC is one of those words that gets a lot of press these days, and they've decided that they want to make it very clear that they're using a RISC processor. They may have a point, given that the communications marketplace isn't as technical as it once was, and that you can't expect potential customers to read a hardware specifications sheet and to understand, for instance, that the MK5025 processor that we use is a RISC processor. But we thought RISC5025 sounded silly, and ET/RISC5025 was too many letters (and still sounded silly), so we left it off.

Anyway, both boards are actually substantially similar in architecture. We use the MK5025 and MK50H25 processors, and they use the Hitachi HD64570 controller. The two devices (or "parts" as they are called) are similar in concept, although there are some differences that made us like the MK5025 better. The only real "advantage" of the Hitachi part is that it has two ports in one part, but we didn't think that it could handle two T1 speed lines under heavy load. So we decided to give you two RISC processors on our dual port card, to guarantee that there was more power than needed to handle any traffic that you could throw at it without degradation. It costs a little more, but we figure that anyone who has an investment in two T1 lines won't mind spending a little extra for a product that is twice as powerful. The MK5025 also has a primitive based interface that allows us to do some very complex things in hardware, it can be tuned more precisely, and we can do neat stuff like address and control field filtering for hardware PPP. The MK5025 can guarantee continuous single or double flag separation at the full clock rate, which means 100% throughput, and we figured our customers would like that. It also has LAPB built into it, so we could run X.25 at very high speeds and get 100% throughput, and we liked that too.

ISA Cards:

The only real physical difference between the their ISA card and ours is that the RISCsomething has high density connectors and both connectors are on the board's backplane. Our board has one DB25 on the back and you need to mount the second port in an available slot or to the PC's chassis. Since you usually have an extra slot or two and many cases have extra DB25 mounts built-in, this is not really a big issue. The advantage of our connectors is that the adapter cables are inexpensive, they're less likely to get damaged, they're easy to build yourself, and if you're using RS-232 or EIA-530 you don't need an adapter cable at all.

PCI Cards

Our PCI card has 4 T1 capable ports, and theirs has 2. If you plan on expanding to 4 port, or even 8, our board is clearly the better choice. All 4 ports are cabled to a single slot in the backplane, meaning that you can have 8 T1 ports and use only 2 slots.

The major function difference between the cards is that theirs is a bus-master and ours is not. Most people read alot of marketing garb and think that bus-mastering is better, but under some conditions its not. The more bus mastering controllers you have to more contention there is for the bus, and the more likely that you will have underruns or overruns on the serial line. With multiple bus-mastering ethernets or a 100Mbs ethernet bus master, you could have trouble with even 2 T1 lines on a bus master card getting the bus enough to fulfill your transmitter and receive requirements. So we decided to buffer the data on the board, which means no interference with higher bandwidth ethernet cards, and much more predictable relability for high density applications. We believe that our design allows for 20 T1 lines in a single PCI machine.

Our PCI card also includes an integrated watchdog timer, which is a nice feature that doesn't cost anything. The watchdog timer wires to the reset pins on your motherboard and can be used to phyisically reboot the PC in case of a failure.

Hardware Summary

Its pretty difficult to explain the differences between two similar hardware products to someone who isn't an engineer; in fact its often difficult to explain it to someone who is an engineer. A simple summary follows:

• Both boards use RISC processor architecture with RAM interface.
• Both boards have 2 ports capable of T1 speeds.
• The ET/5025-16 has 2 RISC processors, the RISCsomething has 1.
• The ET/5025-16 has built-in high level protocol support, the RISCsomething only does framing.
• Both architectures are available for PCI, but our board has 4 ports to their 2 ports

So the hardware summary is basically that the ET/5025-16 is faster than their ISA, but it costs a little more. At least the first one, then the cost is about even. If you need higher densities, our PCI board has 4 ports and we can support more ports in a PC than they can with half the slots. So far, not so bad for us, because our REAL strength is in software.

The Software Challenge

Now for the second piece of the puzzle. As we said before, hardware is a vehicle, and you need good hardware to have a good product. But its not enough by itself. Its like a good fax modem without any software. And we all know about the differences in the capabilities of fax software. The same goes for communications protocols drivers. There are good ones, bad ones and terrible ones. Software is where the real functionality is in this type of product, and its also where most of your latency (processing time) is. As the complexity of the protocols that you are running on your lines increases, the importance of the quality of the software increases.

Emerging Technologies offers feature-rich software subsystems that were written in-house and are maintained internally. This means that we can fix anything that's broken, and we can do it fast.

As for protocol support, we only run software that we wrote on our boards. Frame relay, PPP, Cisco HDLC, and X.25. We do this for several reasons, one so that we can fully support it and another is that we believe that generically implemented products (that is, software products that are written to work on any hardware platform) have to make trade-offs and are not able to take advantage of the features that make one piece of hardware better than another. There's also no logic in thinking that anyone can utilize the capabilities of a board better than the manufacturer, because we know all of the tricks and we designed the board to do what we want it to do. In other words, we don't think that any generic product or driver written by an outside concern can be as good as custom ones written by the manufacturer.

Our software subsystems have features that you won't even think of until you need them. You can mix any of our supported protocols on a board (i.e. run frame relay on one port and PPP on the other). Our drivers support address sharing, so you can put two or more boards at the same memory address. Our event-driven interfaces provide flexible management with any number of lines. We give you utilities to tune the sub-systems easily from the command line. We support dynamic sub-interfaces. We have data compression. We can even route IPX traffic.

Our frame relay interface is implemented with dynamic sub-interfaces, which provide unprecedented flexibility for our products. The allow for the proper interface with GateD when multi-homing, support unnumbered interfaces and reduce system overhead when routing.

Our ET/BWMGR puts us so far ahead of our competition that you can barely consider them competitors. With bandwidth limiting, queue prioritization and "smart" filtering our software subsystems add tremendous value that our competitors simply don't have. Plus, you get our innovative Ethernet Bandwidth Limiter for FREE if you use our 16-bit ISA card or our PCI card.

Our new load balancing and line bundling features add components that are only found in high-end routers. Now you can double your bandwidth capacity by adding a second line (or quadruple it with 3 more lines!), which can be evenly load balanced or you can route specific traffic to one pipe or another. Its one of the most powerful features available on the market, so if you plan on growing then its nice to know we've got it as part of our standard product.

We're not going to say much about our competitor's software, because there's not much to say. They provide basic functionality that works OK, without many bells and whistles. If you read the various reviews, the word is that PPP is flakey, their frame relay works sometimes, but Cisco HDLC works well. Of course, Cisco HDLC is not even really a protocol, so what it really means is that if you're not running any software or protocol on the board, then it works well. Not bad if you're not planning on doing anything with your business to be competitive.

Fault Tolerance

This isn't really the correct term for what I'm about to describe, but it sounds good and fits loosely, so why not use it? Something that is not apparent from the data sheets and marketing literature is how well a product handles diversity. What happens when the link goes down? Does it come back up cleanly? How well does it manage adverse traffic conditions?

Unfortunately, you don't know much about this stuff until its too late. We pay very close attention to these factors when testing our software, because its just as important as speed. We also pay close attention to implementation, making sure that our products meet the software specs for all situations, not just the most common ones.

Low-End Options

Something that we have is a product designed for speeds under 1 Mb/second called the ET/5025. The ET/5025 only has one port, but uses the same RISC processor as the ET/5025-16. The other difference is that it has an 8-bit bus, which is a bit of a bottleneck at very high speeds (the board will run at 2Mbs), but at low speeds (say up to 384kbs) the bus transfers are an insignificant part of the picture. Plus our shared-memory interface is about as fast at 8 bits as a 16 bit DMA interface. What you get is a low-cost product with almost all of the features of our high-end product. Same software, same processor...great low price.

Another Frame Relay Competitor for Linux

We've heard rumors that there's another vendor with a frame relay product for Linux named Sag Harbor or something like that. They're targeting the low end market with a low-speed board that doesn't cost much. The board fits our previously mentioned "intelligent board" hardware architecture and has a Z80 (can you still buy those?) processor. It doesn't sound very fast (I think they quote a maximum speed of 128kbs) but we don't know much about it because last we heard it was in pre-alpha, which I think means that they've started working on it. It costs about the same as our RISC processor outfitted ET/5025, which will run T1 speeds, so we're not too worried about it. Also be aware that much of the functionality of this "intelligent" board is on the board, so although they give you "GPL Source", most of the things that can go wrong are not available to you.

Conclusion

There really is no conclusion, but hopefully you can sort out some of the questions you might have had and make a decision for yourself. If you're only going to buy one board, just want to make a connection and cash is really tight, you might go with our competitor. If you have higher aspirations, you might give us a try.

Go Home