Date: Tue, 7 Feb 1995 04:34:24 +0100 (MET) From: Andreas Johansson <ajo@ludd.luth.se> To: freebsd-questions@FreeBSD.org Subject: Trouble sending via TCP Message-ID: <199502070334.EAA03788@taurus.ludd.luth.se>
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 src.doc.ic.ac.uk 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 campusnet. 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: example: 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 university). 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 > ftp.fim.uni-linz.ac.at:/pub/soft/unix. --- 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? /Andreas -- <-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-> : E-mail: ajo@ludd.luth.se 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: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199502070334.EAA03788>