Yes,
during my lowlatency tests I discovered that the diskdriver really freezes
the kernel for a long time. (several msecs).
Of course the scheduler isn't able to run during this time, and your serial
FIFO could easily go into a underrun/overrun state, and you might loose
characters.
assuming an UART with a 16bytes FIFO at 38400baud = ca. 4000bytes/sec
= 250usecs per char.
Multiply this with the 16 byte FIFO then you get 4ms.
That means if your process (or the driver) do not run at least every 4ms,
then you will loose characters.
And since there is no IRQ pre-emption in Linux, you are screwed.
You should really try Ingo's preliminary lowlatency patches (only available for
2.2.10)
(link here http://www.gardena.net/benno/linux/audio)
and tune the EIDE disk as best as you can
( hdparm -u 1 -d 1 -c 1 )
This REALLY helped for audio: I got 2.1ms latency on a P133, and
David Olofson reported 1ms latency (rock solid during disk I/O) on his Celeron
box !
If you try out the patches, can you please post the results on linux-kernel
( and CC me because I'm not on the list).
PS: perhaps you can try out my "latencytest" to see if your IDE disk causes
major latencies during heavy disk I/O.
On my box a non DMAed disk + standard kernel 2.2.9,
sometimes gave me up to 2000ms (!!) latencies (= the box is completely frozen
during this time due to the disk I/O).
During these 2000ms you will loose TONS of characters.
( In the DMAed case the peaks were around 70ms-130ms)
Benno.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/