Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!necntc!ames!sdcsvax!ucbvax!CORNELLC.BITNET!MAB
From: MAB@CORNELLC.BITNET (Mark Bodenstein)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: TCP performance limitations
Message-ID: <8710051601.AA14825@ucbvax.Berkeley.EDU>
Date: Mon, 5-Oct-87 11:24:26 EDT
Article-I.D.: ucbvax.8710051601.AA14825
Posted: Mon Oct  5 11:24:26 1987
Date-Received: Thu, 8-Oct-87 04:36:48 EDT
References: <JBVB%ai.ai.mit.edu@crnlvax2.BITNET>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 33

>  ...           We recently unrolled the TCP checksum loop, and a ~35%
>speed improvement there produced a ~15% overall throughput increase on
>memory-to-memory TCP.
>  ...
>James B. VanBokkelen
>FTP Software Inc.
>

Could you provide more detail on how you unrolled this loop?

(The complication being that the length of the loop is determined by
the length of the data.  Some alternatives I can think of would be:

1. to keep checking to see if you're done

2. to unroll the loop for each possible data length, and chose and
   execute the appropriate unrolled loop

3. to pad the data with zeros to the maximum length to be processed

(One could also try various combinations of these three.)

1. seems inefficient, and thus defeats the purpose of unrolling the loop.
2. seems efficient, but perhaps excessive.
3. seems to penalize short segments (e.g. ACKs), of which there are
   many.

Or am I missing something?)

Thanks.

Mark Bodenstein      (mab@cornellc.bitnet@wiscvm.wisc.edu)
Cornell University