FreeBSD 4.8-R kernel.GENERIC
user ppp
P II - 400
128 MB RAM
56K ext. modem, 45.3K connection
Something in the socket/proto/network interface area doesn't
work correctly when tcp.recvspace=56K, the default value in 4.8-R.
It DOES work correctly when tcp.recvspace= 16K, 32K, 48K.
I see the followin
FreeBSD 4.8-R kernel.GENERIC
user ppp
P II - 400
128 MB RAM
56K ext. modem, 45.3K connection
The following is something I posted to freebsd-net about a week
ago. Since then I have pinpointed the cause of the problem.
It's not a bug, it's a configuration problem.
>From running tcpdump on an ftp t
I have a few TCP window size issues.
1. In FreeBSD 4.8-R the kernel default recv window is 56 KB. This
is so large that it causes dropped packets due to queue overflow
with my V.90 link (BW 5 KB/s on compressed data).
2. The 4.4BSD TCP implementation has never had the correct precedence
Actually I have just fixed it in my copy of 4.8-R. I have a document
that describes the problem and my solution. I could send you that
and/or a set of patches. You might want to sketch out your own
solution before you look at mine, though. Also, I'm not done
testing mine yet.
> Carl
me changes and we take that and ignore the metrics value.
> This is not yet tested in reality... just theoretical ;-)
>
> Anyway, I'm interested in your solutions as well.
>
> Carl Mascott wrote:
> >
> > Actually I have just fixed it in my copy of 4.8-R. I have a do
te is established, as long
as the kernel default recv window size is > 4096 (slight
simplification here).
Lev Walkin wrote:
> Carl Mascott wrote:
> > I have a few TCP window size issues.
> [skip]
> > 3. RFC 793 (TCP) says that shrinking the receive window after
> >connec
> Andre Oppermann wrote:
> Carl Mascott wrote:
> >
> > Here's a case that your logic does not handle correctly.
> >
> > 1. Kernel default buffer size = 32 KB
> >
> > 2. Routing table buffer size = 48 KB
> >
> > 3. Application sets buff
2PM -0400, Carl Mascott wrote:
> >
> > NOTE: AFAIK, 4.4BSD through FreeBSD 4.6-R seem to have done
> > alright without the PR 11966 patch, but if someone knows
> > different, please speak up.
>
> I'm not really surprised. I would have thought that a well-beha
