On Sun, Feb 09, 2025 at 09:01:51PM -0600, Steve Lewis via cctalk wrote:
[...]
> In my experience, a 12MHz '286 couldn't fully utilize the 1.8432MHz 8250
> (i.e. in my testing, I was able to receive at 57600 over a null modem
> cable on said '286, in a sustain {ZModem} stream without any errors; but
> at 115200 the system just got too many errors to be a worthwhile
> transfer). That's how I mean there is a crossing point where the combined
> CPU, memory speed, hard drive speed of the system is "under powered" for
> the full potential of its UART. But it was a number of years before
> "modulation-tech" modems blasted past even 9600 baud (at least at the
> consumer level), so that 1.8432 MHz pick was fine for most of the 80's.The actual clock speed of the UART is an implementation detail. The limiting factor to reliable PC serial throughput is often interrupt latency rather than raw baud rate, and that is due to cheaping out on implementation and not that the CPU is too slow to process a piddling 12K of data per second. The 8250, 6551, Amiga serial port, etc do not have FIFOs and so generate one interrupt per byte. The CPU has to respond to the interrupt and retrieve the incoming byte before the next byte has arrived. At 9600 baud, that needs to happen within 1ms. At 115,200 baud, it's 87µs. Older operating systems -- especially from the era where non-FIFO serial ports were still standard -- would leave interrupts disabled for extended periods. It was a cheap way for single-CPU systems to perform uninterruptable critical sections. A special kind of critical section is the handling of some other interrupt (e.g. keyboard or disk). Thus the maximum potential interrupt latency is increased by these little bits of work which randomly pop up at inconvenient times. You would have probably observed that the serial error rate increased during disk I/O. 1ms is a fairly reasonable rule-of-thumb for maximum interrupt latency on a general-purpose computer of the mid-80s, and thus 9600 baud or so is about all you're going to get reliably. So you could have an infinite UART clock and infinite baud rate, but so long as the data comes in no faster than 1ms per byte, it'll still work reliably. Your specific 286 was doing somewhat better than that; perhaps your terminal client was disabling interrupts and bit-banging the serial port during transmission of ZMODEM blocks. (As to that 87µs, I wouldn't rely on even the latest whizz-bang machine to consistently beat that deadline. The interrupt has to wend its way through the PCI bridge and the IO-APIC, and then the CPU has to notice the interrupt, then complete whatever work is stuck in the pipeline or otherwise get into a state where it can do a mode switch and call the ISR. Most interrupts will be handled in a handful of microseconds, and maybe even mere hundreds of nanoseconds, but the worst-case interrupt latency is rather closer to infinity than we'd all like. But this is classiccmp, not moderncmp.) Doubling the UART clock rate will double the maximum baud rate, but that wins you nothing if the machine can't handle all of those interrupts in time. In the case of the PC, it also means that the wrong value will be programmed into the UART's divider for a given baud rate because a 1.8432MHz base clock is assumed. The proper solution to dodgy PC serial port performance was of course to upgrade to the 16550 which had a FIFO which could buffer a few bytes while the PC got round to answering the interrupt. It's not the greatest UART and adds novel failure modes, but it does have the extremely useful property that it is register-compatible with the 8250 and so older software can still drive it without needing to be patched. The 16550 (at 1.8432Mhz) still has the same top speed of 115,200 baud, but that's just fine for the kind of applications which use physical RS-232-compatible serial ports such as dialup modems and serial mice. RS-232 only guarantees up to 20 kilobaud anyway, and anything faster is out of spec and works through luck. Fortunately, we had a lot of luck by the late 1990s when V.90 dialup came around. Want to go even faster over long cable runs? We have Ethernet for that sort of thing, and it's rather more reliable at it.
