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).
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- Home, My Backup Data Center
- Tech Tip: Really Simple HTTP Server with Python
- Please correct the URL for Salt Stack's web site
1 hour 50 min ago
- Android is Linux -- why no better inter-operation
4 hours 5 min ago
- Connecting Android device to desktop Linux via USB
4 hours 34 min ago
- Find new cell phone and tablet pc
5 hours 32 min ago
7 hours 56 sec ago
- Automatically updating Guest Additions
8 hours 9 min ago
- I like your topic on android
8 hours 55 min ago
- This is the easiest tutorial
15 hours 31 min ago
- Ahh, the Koolaid.
21 hours 10 min ago
- git-annex assistant
1 day 3 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?