rjh@world.std.com writes:
>
> The optimal behavior depends in part on the sending parallel hardware
> and on the speed of the receiving hardware. For example, if the
> receiving hardware is very fast it can be faster to avoid the interrupt
> entirely. If you have hardware that can accept data at 1MB/sec there
> are only 16 microseconds between FIFO full and FIFO empty. Few Linux
> machines can do anything useful in those 16 microseconds. Some Linux
> machines will be faster with a brief pause because the interrupt
> handling logic will be slower.
>
> A general optimum solution does not exist because it depends on
> peripheral hardware characteristics, CPU speed, parallel I/O hardware
> speed, and Linux interrupt handling performance. If you use a spin loop
> delay, it is also affected by CPU load and other interrupt behavior.
I think there are few machines having ECP ports that will need longer
for one interrupt,32 io accesses and some other commands then the 16
microseconds you mention needed for polling on a very fast
pheriperal. So I favour the approach to wait for the interrupt and
then fill up the fifo as long as there is space in the fifo because it is
easy (kiss principle) and will work on a broad range of combination
from slow and fast machines and slow and fast pheripherals.
Even if the system can't use the time during the interrupts that is
not worse then using that time for polling. But it will be better for
most cases...
Bye
-- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de-- To unsubscribe, send mail to: linux-parport-request@torque.net -- -- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2b29 : Tue Mar 27 2001 - 17:08:17 EST