Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 7 Feb 1995 04:34:24 +0100 (MET)
From:      Andreas Johansson <>
Subject:   Trouble sending via TCP
Message-ID:  <>

Next in thread | Raw E-Mail | Index | Archive | Help
According to DI. Christian Gusenbauer (written to -hackers some week ago
					I think):
> To send 10000 packets from the DEC to the i960 and vice versa, it takes about
> 20 to 61 seconds (for packets with 128/1536 Byte). To verify these tests, I
> connected a 486 DX/2 66 MHz running FreeBSD-current and a 386 33 MHz (both
> boxes with NE2000 comp. network cards) running 1.1.5. I repeated my tests and
> I have to say, that FreeBSD is much faster!
> But, starting with packet sizes > 1024 Byte, FreeBSD takes about 120 to
> 130 seconds to finish the benchmarks and that's much slower. So I want to
> ask all TCP/IP-hackers if you know, why?
> Is a packet size of more than 1024 Byte a problem for FreeBSD?

I'm getting a similar problem with FreeBSD-current, ftp:ed one week and a half ago perhaps. I'm using a 486/SX-25 with
4Mb ram (yeck), an Etherlink 16 card connected directly to Internet via our
I have tried binaries (and in the beginning older kernels, but they had even
more problems) from 2.0-RELEASE, 2.0-950112-SNAP and now I am running with
2.0-950202-SNAP. I don't have the machine to compile more than the kernel so
I will have to stick with the snapshots.

OK, the problem:

I get serious trouble when ftp:ing files FROM the FreeBSD machine, typically
5kb/sec against very fast machines. Receiving files to the FreeBSD machine
works ok -- I have recieved files at >800k/s.

I have now tried to change the MTU (after reading the quoted mail) and
amazingly the ftp sending speeds can be raised by lowering the MTU enough.
The critical point is different between different machines, f.i. ~360 when
transferring to a P-90 running Linux and ~200 when transferring to a
Sparc Station Classic. Because of the low MTU the transfers doesn't exactly
become ideal, but the speed is incresed significantly. Some examples:

MTU	Speed ftp:ing from FreeBSD machine to P-90
1500	~5k/s
380	100-250k/s

MTU     Speed ftp:ing from FreeBSD machine to Sparc
1500	~5k/s
300	~2k/s
200	~150k/s

The critical points are pretty sharp -- raising MTU by 10 from the critical
point can make speed drop to 5k/s.

When using 'hash' in ftp it is obvious that the transfer (with the lower MTU)
is not ok anyway, blocks are sent in bursts (could be 80 hash marks), then
wait, then send. With the higher MTU only a few marks are sent (perhaps two
or three) before it hangs for a while (thus the low speed).

I have tried NcFtp too, and it works pretty ok with some machines (not the
P-90). It seems it is calculating the best MTU while sending.

rcp is in the range <10k/s too with the P-90.

Now, there are machines where ftp works too, mainly old vax:es.
For example a vax 8300 (this is a _SLOW_ machine) can receive 200k/s at
MTU 1500. There are other vax:es which I don't know the name of which works
ok (they really enjoy these monsters at the computer society at our
I have not been able to test against another FreeBSD machine.

Anyone got any ideas what could be causing this? I really need to get this
fixed. I have thought about enabling TCPDEBUG in the kernel. Could this be
worth the compile time? :)

> Thanks, for all replies!

I second that.

> Christian.
> PS: If you want, you can find my little benchmark "bench.c" on

--- After more testing ---

I have investigated the problem further after I ftp:ed the source of bench.
Bench was not giving me much information so I changed it quite a bit so
it would tell me how quickly different sized packes were sent (while sending
the same amount of data) and only try one direction at a time (my problem is
only when sending).

Bench works like this: On one computer there is a server. It receives a block
from a TCP port and then returns a block. Loop. On the other computer there
is a client. It sends blocks with different sizes and waits for the server to
reply. Loop. There is some timing and other stuff too. If somebody is really
interrested in this the soure could be made available.

There was contrary to what I thought no problem in sending packets to any
other computer. Then I added checking of the blocks that were sent, and that
was the key to the problem, now I only need a solution :)

When running against very quick machines every third block recieved on that
machine contains garbage (probably found in the middle of the preceding block
or something like that). My program reports 33% blocks in which the first byte
of the block is incorrect. That is, I send one block with send and in the
other end sometimes two blocks are received, of which one is garbage.

The reason why lowering MTU helps ftp transfers is probably that more overhead
is added at my end and this helps the problem to go away.

ftp doesn't use send and recv to transfer files, so the reason for the _slow_
speed I have measured must be error-correction in the TCP-layer.

Any ideas?


: E-mail:                            Amiga 4000 is it! :
: S-mail: Andreas Johansson, Karhusvagen 5  6:618, 977 54 Lulea, SWEDEN :
:       There are two groups of people I'll _never_ understand:         :
:                     math-professors and women                         :

Want to link to this message? Use this URL: <>