Re^2: Losing bytes with Device::SerialPort ?

You are holding the serial port open so the serial port driver will certainly receive all the data that comes in for you, whether or not your process is scheduled.

You are wrong. There is absolutely no certainty that the device driver will be able to offload each byte from the UART in a timely manner, and with the FIFO buffering disabled, it is 16 or 64 times more likely not to be able to do so.

It has nothing to do with whether the process is scheduled, or whether the serial port is open or not. The problem is one of timely response by the device driver to each IRQ request. With the hardware buffering turn off, data loss is endemic at anything above very low transmission speeds. Any higher priority IRQ activity (like DMA requests) can prevent the DD from storing the inbound byte before the next one replaces it. This can be mitigated to some extent by enabling rts/cts or XON/XOFF handshaking, but the net result is that you reduce throughput to a crawl.

This may have nothing or everything to do with the OPs problem, but it is certainly one way that his symptoms could occur.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Comment on Re^2: Losing bytes with Device::SerialPort ?

Replies are listed 'Best First'.
Re^3: Losing bytes with Device::SerialPort ? by Celada (Monk) on Dec 22, 2005 at 22:48 UTC
You are right that there are some ways that data can be dropped on the floor, however I stand by assessment that it is very unlikely here, assuming the computer in question is halfway recent. Sure, in theory IRQs from the serial port can be ignored in critical sections long enough for it to matter, but asynchronous serial ports are so slow compared to modern CPUs and UARTs without buffers are so rare nowadays (even in embedded equipment (except for TTL serial ports)) that it hardly ever matters. At 115200 bps, it takes more than a millisecond to completely fill up a 16550 buffer, and that's a long time. My empirical basis for this is that we could run upwards of 32 dumb serial ports on commodity PC hardware all transferring at 14400 bps (or more, thanks to modem compression), in or around 1993. And we know how much faster PCs are now than they were then...	[reply]
Re^4: Losing bytes with Device::SerialPort ? by BrowserUk (Patriarch) on Dec 22, 2005 at 23:05 UTC
Agreed. Circa 1992, we had a PS/2 model 80 (20MHz 386) running OS/2 happily handling 64 ports at 9600; but it was important that the FIFO buffering was enabled. It's hard to see why it wouldn't be by default, but if it wasn't that could explain the symptoms described. It's also possible to set the IRQ threshold below the buffer maximum. This is useful when conducting bidirection conversations involving short sequences; for example when handshaking. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal? "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]