When Steve and I were playing with M100 to M100 communication over the internet way back when, he spent a fair bit of time trying to overcome the small buffer in the Model Ts but I don't think he could ever get it to work 100%. IIRC reducing the buffer size in the ethernet 'modem' down to one did solve the problem but wasn't an option with all versions of the adapters.
m On Fri, Sep 23, 2022 at 1:09 PM John R. Hogerhuis <jho...@pobox.com> wrote: > > > On Fri, Sep 23, 2022 at 2:59 AM Brian White <b.kenyo...@gmail.com> wrote: > >> >> I believe all the right chip does is help, and make more code more likely >> to make it through >> > > Chip/driver wise the two things I've observed: > > You can configure the FTDI driver buffering threshold on Windows all the > way down to 1 byte, which I think is what we want. This is really about > decreasing transmit latency on the Windows side in case of a sensitive > receiver on the Model T side... that is, TS-DOS. > The prolific drive has bugs under the Windows API, last I checked. There > is a facility under Win32 and the .Net Framework for reading a block of > data with a timeout. It works with the FTDI, it doesn't work with Prolific. > I believe it is a driver issue. I can work around it in software, and have, > but just generally spec it out of commercial projects because it is not > correct. > > On Linux, I've never really noticed a difference between Prolific and > FTDI. But my experience is the same as yours, that software flow > control does not work with our laptop. Linux is too slow to react to a > flow-off presumably since it is in-band in the data and gets buffered, and > overwhelms the tiny 64-byte, interrupt driven receive buffer on the Model > T. And as Mike mentions, USB, Wifi-Serial add create even more overhead and > burstiness. > > I could imagine some low level hardware scheme (specific > hardware+driver+configuration) overcoming the buffering of XON/XOFF > specifically, in the wired case... but this is the first I've heard of it. > And it really seems like it would have to be configured. Hardware isn't > normally involved in software flow control. > > -- John. >
