fixing TCP buffers (Re: packet reordering at exchange points)
E.B. Dreger
eddy+public+spam at noc.everquick.net
Tue Apr 9 22:51:27 UTC 2002
> Date: Tue, 9 Apr 2002 16:03:53 -0400
> From: Richard A Steenbergen <ras at e-gerbil.net>
> To transfer 1Gb/s across 100ms I need to be prepared to buffer at least
> 25MB of data. According to pricewatch, I can pick up a high density 512MB
[ snip ]
> The problem isn't the lack of hardware, it's a lack of good software (both
[ snip ]
But how many simultaneous connections? Until TCP stacks start
using window autotuning (of which I know you're well aware), we
must either use suboptimal windows or chew up ridiculous amounts
of memory. Yes, bad software, but still a limit...
It would be nice to allocate a 32MB chunk of RAM for buffers,
then dynamically split it between streams. Fragmentation makes
that pretty much impossible.
OTOH... perhaps that's a reasonable start:
1. Alloc buffer of size X
2. Let it be used for Y streams
3. When we have Y streams, split each stream "sub-buffer" into Y
parts, giving capacity for Y^2, streams.
Aggregate transmission can't exceed line rate. So instead of
fixed-size buffers for each stream, perhaps our TOTAL buffer size
should remain constant.
Use PSC-style autotuning to eek out more capacity/performance,
instead of using fixed value of "Y" or splitting each and every
last buffer. (Actually, I need to reread/reexamine the PSC code
in case it actually _does_ use a fixed total buffer size.)
This shouldn't be terribly hard to hack into an IP stack...
--
Eddy
Brotsman & Dreger, Inc. - EverQuick Internet Division
Phone: +1 (316) 794-8922 Wichita/(Inter)national
Phone: +1 (785) 865-5885 Lawrence
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <blacklist at brics.com>
To: blacklist at brics.com
Subject: Please ignore this portion of my mail signature.
These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to <blacklist at brics.com>, or you are likely to
be blocked.
More information about the NANOG
mailing list