Take a look at this strace fragment:
0.000120 write(4, "S31A80014B3D000010C8029FD7D00180"..., 56) = 56
0.000156 write(4, "\3", 1) = 1
0.000104 ioctl(4, TCSBRK, 0x1) = 0
0.009621 read(4, "\6", 1) = 1
1. I write() 56 bytes (a Motorola S-Record).
2. I write() an ETX.
3. I call tcdrain().
4. I read() an ACK back.
That ioctl(TCSBRK) is the tcdrain().
This is over /dev/ttyS0 115 kbps RS-232 to another machine (that isn't
running Linux).
tcsdrain() takes about 9.6 ms to return. By my calculations, 57 bytes at
115 kbps should take about 5 ms to actually transmit over the medium. I've
watched it on my oscilloscope and it does in fact take about 5 ms to
transmit the data. So why does it take 9 ms for tcdrain() to return? It
seems that tcdrain() has a built-in extra delay of 4.6 ms.
This effectively halves my throughput.
I watch on the oscilloscope and I see:
1. the 5 ms of data transmission.
2. the ACK from the other machine immediately after the data transmission
has completed.
3. 4.6 ms of dead air before the next transmission begins.
If I remove the tcdrain(), then the delay just shifts into read().
I'm using 2.2.12-20smp (Red Hat 6.1).
Any ideas?
Regards,
Brad
-
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/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:28 EST