Slow output from Acceleport XEM PCI - Linux 2.6.28 kernel (Fedora 10)

The digiboard serial output, even at 115k baud is dog slow. Not anywhere near the baud rate. Multi-second random pauses, peak speed nowhere near baud rate.

What we are seeing is big backlogs on the digiboard and no problems on the internal serial (/dev/ttyS0).

Input on the digiboard seems fine.

We’re running with dgap-1.3-14, but I had to modify it to use the new kernel indirect references to the service routines a year ago since DIGI hadn’t put out the update until this summer.

The beta dgap-1.3-16 compiles cleanly out of the box with our kernel, but I didn’t see anything in a difference listing that showed it would perform any differently than the -14 driver as far as output speed. The changes seemed to be for the 2.6.31 kernel and above.

Is there anything I can look into that might help diagnose this problem?

We’re going to try and test with -16 driver and see if we can replicate the problem our engineers are seeing at the customer’s site in Australia.

The hardware used is an HP Proliant DL580G5 with 4 CPUs and 6 cores each. Major CPU horsepower, but seriously I/O “output” bound.

Thanks.

Kevin

The pauses and slow throughput sound indicative of a resource contention between the Xem PCI card and something else in the server. You might want to check /proc/pci or /proc/interrupt (or equivalent) to see if any other devices are using the same IRQ as the Xem card. In particular, RAID, SCSI and other controllers as well as NICs don’t like to share IRQs.

For further info on resource contention and steps to resolve it, please refer to this article:
http://www.digi.com/support/kbase/kbaseresultdetl.jsp?id=223

Still waiting to hear back from the guys in Australia, but our identical test machine showed no overlap of IRQs for the 3 Digi Acceleport XEM boards in the machine. There were some other outputs for other PCI devices that showed a latency value of 0, but the output of “lspci -v” for the dgap boards didn’t show the latency field at all. We’re going to boot into the BIOS after a test and see if anything shows up that might guide us further.

These machines are limited in that you have no control over the IRQs that the machine assigns to your card. The IRQ is “slot” driven, and various HP help forums suggest moving the card to a different slot to avoid IRQ sharing. However, like I said, the IRQs for each board are different, so that shouldn’t be our problem.

How many ports are running simultaneously at this baud rate?

Basically, the XEM product has been qualified to sustain 57600 across all ports simultaneously. At 115200, only a limited number of ports can sustain this baud rate (depending on the overall load on the ports at a given time).

What happens if the baud rate is decreased to 57600?

It should also be noted that the XEM product will absolutely have more latency than the built in serial port, as this product works on a polling basis (approx. 20 ms.), whereas the built in serial port is interrupt driven. We do offer products that are interrupt driven and can sustain the speeds seen on the built in serial port in the event you are interested.

Be sure that the EBI cable from the host adapter is connected to the EBI IN connector on the ports module. Power off the server if this cable neeeds to be moved.