On 25 Mar, Tim Waugh wrote:
> On Sun, Mar 25, 2001 at 01:18:45AM +0100, Uwe Bonnes wrote:
>
>> Why does parport_pc_fifo_write_block_pio poll until the fifo is totally
>> empty? i.m.h.o. it should write to the fifo until it's full and then wait for
>> the fifo interrupt.
>
> I think (without looking at the code) the idea was that if we can
> catch the FIFO when it's empty, we know how many bytes we can send
> without looking again, and so we can do an IO burst using outsb.
>
> So I think it's hanging around for a little while to give the FIFO a
> chance to empty so that it can fill it up again quickly.
>
> That algorithm was never based on empirical evidence though.
>
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.
R Horn
-- 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 : Sun Mar 25 2001 - 17:46:26 EST