On Wed, 11 Feb 2004, Andre Oppermann wrote:
> Richard Wendland wrote:
> > Tom Pavel sent some patches to this list on 14 Jan 2004 that he has been
> > using to overcome this HZ/RFC1323 problem.
>
> I remember some comments (by BDE?) to the effect that the patch is not
> entirely correct.
It was j
On Wed, 11 Feb 2004, Richard Wendland wrote:
> Well, with HZ=1 RFC1323 TCP connections will stop after 59.7 hours,
> with HZ=10 after 6 hours. For those with long running TCP connections
> (eg remote backup) that could be a big deal. See 4.2.3 of RFC1323.
>
> It does seem quite a few pe
Richard Wendland wrote:
>
> > It breaks TCP Timestamp generation slightly, but that's not likely to
> > break much of anything in practice.
>
> Well, with HZ=1 RFC1323 TCP connections will stop after 59.7 hours,
> with HZ=10 after 6 hours. For those with long running TCP connections
> (e
> It breaks TCP Timestamp generation slightly, but that's not likely to
> break much of anything in practice.
Well, with HZ=1 RFC1323 TCP connections will stop after 59.7 hours,
with HZ=10 after 6 hours. For those with long running TCP connections
(eg remote backup) that could be a big de
Hi,
On Tue, Feb 10, 2004 at 02:08:57PM +0100, Bjorn Eikeland wrote:
> >>Any suggestions what can be causing this? (I've only got the one nic,
> >>and use a adsl router for internett)
> >You might also consider increasing the queue length of your pipes when
> >using prioriziation--- are you seeing
On Tue, 10 Feb 2004, Chuck Swiger wrote:
> I seem to recall some issues with setting HZ very fast, in that it breaks the
> uniqueness assumptions made by TCP sequence generation if HZ > 1000. Dummynet
> does want better than the standard 10ms granularity (HZ=100), so perhaps you
> might try HZ=1
