On Mon, 2003-08-11 at 04:25, Ian Dowse wrote: > Try the following patch. I can't remember if all the changes in > this are necessary, but I think I found it fixed problems when > interoperating with a Linux-like PLIP implementation. Unfortunately, it doesn't work -- just prolongs the time it takes for a timeout to occur. Being that it's a transmit timeout, rather than a receive timeout, it's making me think that the Linux laptop (which is significantly slower) isn't able to keep up with sending ACKs or something similar to the FreeBSD machine. Is there any sort of user or kernel -space utility to configure the timeouts on the FreeBSD side? The way I see it, if I can slow down the FreeBSD end, the Linux side should be able to talk at something close to "native" speed. I've been thinking about using dummynet to simulate latency, but I'm not really sure of how much to simulate -- even connections of 10 kB/sec (limited via scp's -l option) cause timeouts, whereas I've had other (small) things download at around 50 without a problem.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:18 UTC