On Fri, 31 Jan 2025, Steve Lewis via cctalk wrote: > So while some protocol gets developed for that system, I experimented with > other actual vintage system trying to "talk to" a modern PC (where "modern > PC" is a 3GHz i7 laptop). For the actual task of transferring files, there > are many other better options, but I still wanted to "push the envelope" of > what classic RS232 could do on these systems. > > And it was interesting that even modern-PC to modern-PC, it only handled > 460Kbps. But it causes two "opposite" questions: > 1) How is it even doing over 115.2Kbps? (is that still "RS232"?) > 2) Why is it so slow even on modern systems?
FWIW I was able to get reliable serial communication under Linux of up to 3.5Mbps with off-the-shelf proper PCIe UART hardware clocked at 62.5MHz despite that line drivers used with said hardware (soldered onboard) were spec'd for up to 1MHz only[1]. This was with plain PIO interrupt-driven operation, but then the UARTs used had decent FIFO sizes of 128 characters and the FIFO trigger level for the interrupt was reasonably set. Finally at 4.0Mbps data corruption reproducibly triggered, but it was garbled rather than lost characters, so I conclude the reason was either line drivers finally giving up or the transmission frequency hitting the bandwidth limit of the serial communication cable used. That was actually with POWER9 hardware rather than a boring x86 PC, but I don't think the architecture of the system mattered much if at all. > So I tested a bunch of (relatively modern, post-UART) vintage systems: > 4.77MHz PC w/ 1.8MHz/8250, 12MHz 286 (with Unknown), 386/486, and a Pentium > all null-modem connected to a modern-make PC - just to verify how fast they > should be pushed (download) a data stream. None of them (not even the > Pentium) could be clocked past 115.2K on this serial line. (I know the > host system isn't dictating the speed, but whatever integrated UART is > available-- then the software that controls that UART to clock divide to > "commonly defined baud rates"). With slower host hardware and PIO operation this just boils down to interrupt handling latency vs UART FIFO sizes. If a receive interrupt cannot be served in time for the FIFO to keep from overflowing, you'll get dropped characters. If there's no FIFO and all you have is the receive shift register, then it's getting hopeless very quickly, just as it used to be the case with the 8250/16450 UARTs. With DMA (e.g. Zilog Z8530 SCC or some 8250 improvements) you should be able to run at higher baud rates just fine even with slower host hardware as the DMA transfer can continue between the UART and host memory while the CPU gets to serving an interrupt request; that's how synchronous serial protocols normally operate too. References: [1] <https://lore.kernel.org/r/alpine.deb.2.21.2106071700090.1...@angie.orcam.me.uk/> Maciej
