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).
Special Reports: DevOps
Have projects in development that need help? Have a great development operation in place that can ALWAYS be better? Regardless of where you are in your DevOps process, Linux Journal can help!
With deep focus on Collaborative Development, Continuous Testing and Release & Deployment, we offer here the DEFINITIVE DevOps for Dummies, a mobile Application Development Primer, advice & help from the experts, plus a host of other books, videos, podcasts and more. All free with a quick, one-time registration. Start browsing now...
- SUSE – “Will not diverge from its Open Source roots!”
- Dealing with Boundary Issues
- Vagrant Simplified
- Libreboot on an X60, Part I: the Setup
- System Status as SMS Text Messages
- October 2015 Issue of Linux Journal: Raspberry Pi
- Bluetooth Hacks
- Disney's Linux Light Bulbs (Not a "Luxo Jr." Reboot)
- New Products
- October 2015 Video Preview