North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

fixing TCP buffers (Re: packet reordering at exchange points)

  • From: E.B. Dreger
  • Date: Tue Apr 09 18:53:25 2002

> Date: Tue, 9 Apr 2002 16:03:53 -0400
> From: Richard A Steenbergen <[email protected]>


> 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 <[email protected]>
To: [email protected]
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 <[email protected]>, or you are likely to
be blocked.