in reply to Re^2: Losing bytes with Device::SerialPort ?
in thread Losing bytes with Device::SerialPort ?

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...

  • Comment on Re^3: Losing bytes with Device::SerialPort ?

Replies are listed 'Best First'.
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.