Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 31 Jan 2002 16:59:31 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Mike Silbersack <silby@silby.com>
Cc:        Storms of Perfection <gary@outloud.org>, thierry@herbelot.com, replicator@ngs.ru, hackers@FreeBSD.ORG
Subject:   Re: Clock Granularity (kernel option HZ)
Message-ID:  <3C59E873.4E8A82B5@mindspring.com>
References:  <20020131172729.X38382-100000@patrocles.silby.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Mike Silbersack wrote:
> The TCP stack, on the other hand, is perfectly happy with 10ms resolution.
> Retransmission timeouts are only actually used when loss occurs on the
> network, and 10ms is more than accurate enough for retransmission.  (I
> believe that retransmit timeouts are rounded up to 1 second, but don't
> quote me on that.)  The other timed events (keepalive timeouts, delayed
> ack timeouts, etc) are also in good shape with 10ms accuracy.

You will get a factor of 6 (approximately) improvement in
throughput vs. overhead if you process packets to completion
at interrupt, and process writes to completion at write time
from the process.

Running through NETISR introduces a dequeueing latency that
adds incredible latency overhead.

I was able to triple the connnections per second rate, to
about 22,000, without a SYN cache, by processing this way,
and that's running them fully up to the creation of the
socket: it's not some fake to-the-stack number that can't
be used for useful work without more work that's not counted
in the sampling.

See the Rice University paper on LRP.

-- Terry



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C59E873.4E8A82B5>