speck%cit-vlsi@CIT-VAX.ARPA (Don Speck) (10/06/85)
The recent comments on ftp speed prompted me to profile
a simple SOCK_STREAM transfer to see if I could make it go
any faster, and I found something very strange: increasing
the write size beyond 1K made the transfer rate *slower*
(in both real and sys time), not faster.
write size sys time (10240K transferred, total)
1K 107 sec
2K 109 sec
1.25K 161 sec
5K 140 sec
10K 123 sec
This must be symptomatic of some great inefficiency in the
4.2bsd kernel. (It happens on both Vax and Sun). Why does
the kernel take longer to split a large write into packets
than if I split it myself? Isn't the rationale for having
it in the kernel "to make it fast"?
Don Speck speck@cit-vax.arparon@BRL.ARPA (Ron Natalie) (10/07/85)
Because since you did the fragmentation yourself it doesn't appear in the sys time. In addition, you neglected to mention if this was over a real network connection using TCP/IP or just an local stream, which makes a big difference. -Ron
chris@umcp-cs.UUCP (Chris Torek) (10/08/85)
The answer probably lies in such unappealing low-level things like data alignment and room temperatature :-). In particular you need to find out just what is being copyout()ed and whether mbufs or mclusters are being used. I just started to annotate sosend(), but it is far too large for posting here, I deem. So all I will say is look at the send high water mark and see when you will run into it (probably at 2K data); and check all your interface code for when it uses mclusters, and for when it `copies' by remapping and when it truly copies. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu