you are right, that never really got sorted out. Would be good to pick that up again, and try to sort out, using low cost components, how to make that work.
On Fri, Sep 23, 2022 at 2:00 PM Mike Stein <[email protected]> wrote: > 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 <[email protected]> > wrote: > >> >> >> On Fri, Sep 23, 2022 at 2:59 AM Brian White <[email protected]> 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. >> >
