PLIP transmit timeouts -- any solutions?

Christopher Nehren apeiron at comcast.net
Mon Aug 11 08:27:51 PDT 2003


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20030811/c9c4097c/attachment.bin


More information about the freebsd-current mailing list