> On Jan 31, 2025, at 4:30 PM, Maciej W. Rozycki via cctalk
> <cctalk@classiccmp.org> wrote:
>
> 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.
Was that with an actual RS232 port, i.e., a device using RS232 signal levels,
or a "TTL" logic level serial port? I'm guessing the latter.
In my high speed experiments, I found that the limit for RS232 data rates comes
from the relatively slow rise/fall times implemented in RS232 drivers. If you
have a port that uses logic levels the transitions are likely to be much faster
so loss of signal integrity occurs only at much higher speeds. With the RS232
drivers I have used (MAX3222), 250 kbps is roughly the upper limit.
paul
