Review: Intelligent Multiport Serial Boards
All boards were installed and worked flawlessly following the documentation that was included with the drivers. Each board was used in my system for over a week, supporting my UUCP feed. I also did testing with interactive login sessions, file transfers, and dialup PPP connections with my V.34 modem. No problems were encountered with any of the boards during this usability testing phase. Dumb terminals were simulated by interconnecting cables on the serial boards. Again, no problems were encountered.
Unfortunately, benchmarking is a necessary evil for hardware reviews. You just can't judge hardware by its looks, no matter how pretty it is.
Benchmarking is somewhat of a black art. It is possible to tweak benchmarks to produce very biased test results to highlight particular features of a product. I have no connection to any vendors, so my tests are not biased by personal or professional concerns. Also, some benchmarks (such as the ones I did) don't exactly portray real-world situations, but they do provide some sort of performance measurement.
Because of resource limits, I was simply unable to acquire the massive amount of equipment needed to accurately simulate, for example, 8 dialup PPP connections. This would have required 9 computers, 16 high speed modems, 8 phone lines (or another way of connecting the modems), and^well, you get the idea. So, keep all this in mind while reading these benchmarks, and take them with a grain or two of salt.
The most interesting statistics are:
I/O throughput--how many characters are sent and received;
CPU overhead--how much of the host CPU is consumed doing the I/O. Only system time is counted, not user time, because it is the efficiency of the kernel driver and hardware that is being measured.
The ideal board gives the highest throughput with the lowest CPU usage.
All tests were done on a generic PC, with an Intel 486DX33 CPU and 256K cache, 16MB RAM, and an ISA bus, running Linux 1.2.0. Benchmark tests were done in single user mode, with a minimally configured kernel, to ensure that other program activity would not skew the test results.
The software I used is called tbench. It was developed by engineers at DigiBoard, with enhancements made by engineers at Stallion. I consider the benchmarking software to be reasonably unbiased, due to the fact that it was developed by two competitors, and the fact that it is used by yet other competitors (such as Comtrol) indicates that they concur. Further modifications were made by Stallion engineers for Linux, to adapt the software to use setserial in order to use higher speeds with the serial ports. The tbench software is in the public domain.
You can get the version of tbench I used at ftp://ftp.cc.gatech.edu/pub/people/gregh/review, along with the full test results. The original version of tbench is available at ftp://ftp.digibd.com/pub/tbench.
The tbench output tests write data to combinations of ports ranging from one port to all 8 ports. The data is written to the output port set as fast as possible, without flow control, to provide a steady stream of data. The data consists of six-digit numbers with checksums. 100K of data is written to each port. Each output test was run three times, and the results were averaged to eliminate any inconsistencies.
There are two sets of test results: “raw” (-opost) and “cooked” (opost) I/O results. It's important to distinguish which types of activity uses which type of I/O mode. Interactive login sessions use cooked mode for I/O, while programs such as file transfer programs, SLIP, PPP, and UUCP do raw I/O. Cooked I/O is slower, because each character must be examined to see if it's a special character, such as ^C or ^Z. In addition, some editing of the line is done. Of course, this takes more CPU overhead. In raw I/O mode, there is no need to examine each character, because all 8-bit combinations are considered to be valid data, and no characters are specially processed.
Under ideal conditions, the actual character per second (CPS) output will be the serial port speed divided by ten. Each character transmitted is 8 bits plus a start and stop bit, hence we device the speed by ten. Output tests were done at 9600, 38400, 57600 and 115200 bps, each in both raw and cooked mode. The raw output data was compiled into graphs for each speed, showing the CPS throughput on one to 8 ports and the CPU usage on one to 8 ports (see page 50).
|Android Candy: Copay—the Next-Generation Bitcoin Wallet||Sep 03, 2015|
|The True Internet of Things||Sep 02, 2015|
|September 2015 Issue of Linux Journal: HOW-TOs||Sep 01, 2015|
|September 2015 Video Preview||Sep 01, 2015|
|Using tshark to Watch and Inspect Network Traffic||Aug 31, 2015|
|Where's That Pesky Hidden Word?||Aug 28, 2015|
- The True Internet of Things
- Using tshark to Watch and Inspect Network Traffic
- September 2015 Issue of Linux Journal: HOW-TOs
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- Firefox Security Exploit Targets Linux Users and Web Developers
- Concerning Containers' Connections: on Docker Networking
- Where's That Pesky Hidden Word?
- A Project to Guarantee Better Security for Open-Source Projects
- My Network Go-Bag
- Build a “Virtual SuperComputer” with Process Virtualization