Paolo Mantegazza wrote:
>
> Hi,
>
> > > I never cared of tracking the source, but just checked with the machine
> > > configured the way I needed for my control experiments, generally a
> > > single ADC/DAC+DIO board, either ISA or PCI. Never mixed the twos.
> >
> > Did you configure the PCI board as a master or slave?
>
> It was muster, If I remember well.
>
> > What is the manufacturer, make, and model number of the PCI ADC/DAC+DI0?
>
> There were two: Bluechip Technologu and National Instruments.
>
> > Did you have any other types PCI/ISA boards plugged into the PC at the
> > same time like maybe a network board?
>
> I think there was an ISA NE2000 compatible ethernet card. As I told you
> it was sometime ago and I worked with the installation as it was. The PC
> was used by different people and it was unpractical to plug in and out
> at any particular moment.
I think this configuration shows why you were getting such low useable
rates. John Storrs has done some jitter testing with an ISA NE2000. He
first ran his tests with the card running under Linux while taking five
samples in RTL with his PLD-based fast data acquisition board. He
consistently recorded a 17 uSec jitter resulting in about a 60 kHZ
period (1/17 uS = 60 kHZ). He then re-ran the tests with a PCI ethernet
card and recorded a 3 uSec jitter resulting in about in about a 333 kHZ
period.
If you are getting reliable rates at 30 kHZ then by considering aliasing
effects this correlates strongly with John Storrs jitter period of 60
kHz for a ISA NE2000 device.
>From this data we can say that by just switching from ISA devices to PCI
devices, in general, one should expect to see a five times improvement
in useable hard real time data rates.
Further, since Linux can start a bus access just prior to the start of
an RTL interval. The response from the device can occur during an RTL
interval. The simple work-around for this problem is to wait at least
the time setting configured in the Master Latency Timer Register of each
device queued in the PCI North Bridge plus bus access and arbitration
delays. This waiting must be done by successive reading of a
clock/timer value within an RTL interval, and not by using a function
like pthread_make_periodic_np.
The Master Latency Timer setting for each device may also be reduced.
Then there are PCI devices configured as bus masters. By setting the
device as a slave at the beginning of the RTL interval and returning it
to a master at the end of the RTL interval this problem can be fixed.
This leaves PCI devices that may have been permanently configured as
masters by the manufacturer. These devices require an RTL driver that
is capable of routing data between Linux and RTL while minimizing the
impact on high data rates. The other option is not to use such devices
during times that they may interfere with RTL data rates.
If it possible to run some new tests using these suggestions I would be
very interested in the results.
- Kal.
>
> Ciao, Paolo.
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
