I installed the 2 port AccelePort Xp card on a Sun server running Solaris 8. We have some small test programs to examine throughput and determinism reading and writing over the serial ports. I ran a program that writes a single byte over the port, and blocks trying to read that same byte back before repeating the write again (with the help of a wire kludge on the port to feedback to itself). If I run this program over the stock installed /dev/ttyb port and watch the Tx line with a scope I see the time gap between the write of each byte is about 50 microseconds. Yet, if I run the same exact test over one of the AccelePort card ports, it runs at an atrocious speed of about 10 MILLIseconds. What could explain the fact that the expanded ports are 200 times slower? Are the Digi drivers just that bad? The program sets up the port properly during initialization so they should have the same configuration when used. I have not been able to find any other configuration discrepencies not being explicitly set that would allow for such a speed difference. Has anyone else noticed that these ports are extremely slow or found a fix?
The built-in serial port is non-intelligent interrupt driven whereas, the Xp Adapter is an intelligent adapter (polling based). Our adapter will buffer the data until the next poll. The built-in port will interrupt the CPU right away to send the data.
Could the data be residing in the port buffer?
That makes sense, and I’m not really surprised. Is there some way to get out of polling mode, or reduce the buffer so that it’s forced to empty immediately? I assume you are talking about the same bufsize that is displayed by doing a ditty -n on the device. (I think the default is 100). I believe I did try changing this value to 1 or something like that, but saw no difference. Of course if it still has to wait some set poll time, then it wouldn’t really matter. Is there a way to change the poll time?
There is no ability to change the buffer or poll rate.
You may want to contact Digi Tech. Support to pursue this.
(952) 912-3456
I probably have the same issue with the AccelePort Xem/PCI card on a linux 2.6.18 kernel (RHEL5) using the src.rpm for RHEL4. My onboard UART is way faster than when using any of the Digi ports.
Concerning the AccelePort Xem/PCI:
- is the driver for this card polling based?
- is it possible to turn of polling and use an interrupt instead?
- does the card do any buffering?
- is it possible to decrease buffer size (1 char only)?
- what is NEW_TTY_BUFFERING and NEW_TTY_LOCKING and should I set it to Yes?
- how can I improve the performance of the driver/card?
Concerning the AccelePort Xem/PCI:
- is the driver for this card polling based?
a. Yes.
- is it possible to turn of polling and use an interrupt instead?
a. No. A non-intelligent adapter would be needed, such as, the ClassicBoard or Digi NEO.
- does the card do any buffering?
a. No. It works on a polling basis for servicing the serial ports.
- is it possible to decrease buffer size (1 char only)?
a. It is not really a matter of buffering, one character can be sent immediately (as can be demonstrated with our dinc utility). It is simply the nature of a polling driver.
- what is NEW_TTY_BUFFERING and NEW_TTY_LOCKING and should I set it to Yes?
These flags only pertain to specific Red Hat kernels:
The NEW_TTY_BUFFFERING installation flag pertains to 2.6.16+ only. (However Fedora Core 5 backported it to 2.6.15).
NEW_TTY_LOCKING can be used in 2.4 and 2.6.9, it pertains to a tty locking change in the Red Hat kernel that was backported to 2.4.
- how can I improve the performance of the driver/card?
It is not possible with this product. For optimum performance a non-intelligent adapter should be considered instead as it would perform similar to the built in serial port.
Thanks for your reply. Is it possible to set the poll frequency using e.g. configuration files. I saw in the code that it is set to 20ms. I would like to poll more frequent to see if that solves my problem while the CPU load, because of the higher rate of polling, is still managable.
No, unfortunately the poll rate cannot be changed from the 20 ms default.
Your best bet would be to look into a non-intelligent adapter for the lowest latency.