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

Reply via email to