[olug] Parallel port interrupt

[Eric Penne]

Thanks for the reply.  I did some googling and found an interesting page
or two.

http://www.fisica.unlp.edu.ar/rt/

This was testing the standard kernel vs a real time kernel on a P120 with
kernel 2.0.29.  They generated pulses for both and timed how far apart
they were on average.  Then they used those pulses to trigger an interrupt
through the parallel port and timed it with different loads.

Standard kernel response to the interrupt with a high CPU load: mean 4
milliseconds, max 10 milliseconds.
No Load: mean 0.02 ms, max 0.05 ms

With the Real time kernel response with a high CPU load: mean 0.003 ms,
max 0.015 ms
no load: mean 0.003 ms, max 0.015 ms

They did the tests by trying to max out different sub systems (network,
disk, etc) and the worst case for either kernel was 4 ms.  We think this
is good enough for our work.  The 2.4 kernel may exhibit different
behavior but we'll see.  I'm also not sure how the 2.5 kernels will
respond since they have a new scheduler.  Currently we think they pulses
will not come more than 2 times per second.

Another study was timing how fast the gettimeofday() command could be run
using different loads, different scheduling settings, and different
priority processes.  The kernel was 2.2.12 on a PII 350MHz.

http://www.music-cog.ohio-state.edu/~sf/brm.www/brm.2/linux.doc.pdf

The study was for playing midi music I think.  With the right settings,
under full load the maximum difference between any two gettimeofday()
calls in 1,000,000 samples was 69 microseconds (0.069 ms).  This was
without a real time kernel.  The worst case under full load and based on
priority was 840,000 microseconds (.84 seconds).

With the right settings from a non-realtime kernel using a gettimeofday()
and a parallel port interrupt signal, I think the minimum number of pulses
per second that we could detect would be 1/(0.010 + 0.069) = 12.7 or 12
full pulses.  Therefore as long as the power meter doesn't pulse more than
10 times/second we won't be worried.  Switching to a real time kernel
probably won't give us more than 30 pulses per second.  In that case we
may need to switch to another option of using a microcontroller as the
interrupt handler that just outputs RS232 to the control PC.

FYI
Eric



> Eric Penne [mailto:epenne at olug.org] wrote:
>> Has anybody used interrupts on the parallel port for data
>> logging in Linux?
>
> No, but that never stopped me from throwing in my two cents... ;)
>
>> The problem is simple.  We want to monitor the power used by
>> our facility.
>>  We have a device that outputs a pulse at a time interval based on how
>> much power we are using.  For example 1 pulse per second for
>> using 10kW
>> and 2 pulses per second for 20kW.  Therefore each pulse corresponds to
>> 2.7kWh.
>
> Neet idea...simple but effective if resolution/accuracy is not the
> paramount requirement.
>
>> The pulse needs to be picked up by the computer and an
>> interrupt routine
>> would get the time of day to the nearest millisecond (or second).  How
>> fast are the pulses going to be coming in versus how fast the computer
>> responds to the parallel interrupt?  We don't know that yet since the
>> device hasn't been installed.  This can be done using RTLinux
>> but we would
>> like to see if it can be done using a regular kernel.
>>
>> The functions in time.h can do milli/microsecond accuracy but the big
>> question is how fast can the kernel respond to the parallel port
>> interrupt?
>
> I don't know the stated accuracy, but in general a tight loop within
> Linux on a Pentium-100 or higher should be able to poll the port quite
> rapidly (100's of times per second at least).  A way to judge might be
> to determine the theoretical maximum "pulses per second".  If you are
> not getting 1000's or tens of thousands of pulses per second -- you're
> not monitoring the output of a commercial power plant, are you? :) --
> then a non-RT Linux system dedicated to this project should be
> sufficient.  At worst case, if you see odd spikes/drops in what is
> otherwise a smooth or linear graph before and after could be accounted
> for in a missed pulse for a split second.
>
> If you ARE monitoring something very critical (i.e. a power plant,
> hospital generator/UPS, etc) then you might want to consider the real
> time Linux solution -- better over-spend/-plan than have things go
> massivly wrong just to save a few bucks... :O
>
> Either way, a low-mid range Linux system running only the required
> services (NO X11, NO Sendmail, NO FTP server, etc) should do this just
> fine.
>
> Dan
> _______________________________________________
> OLUG mailing list
> OLUG at olug.org
> http://lists.olug.org/mailman/listinfo/olug