Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!linus!decvax!ucbvax!ucdavis!lll-crg!seismo!brl-tgr!tgr!speck%cit-vlsi@CIT-VAX.ARPA
From: speck%cit-vlsi@CIT-VAX.ARPA (Don Speck)
Newsgroups: net.unix-wizards
Subject: larger buffer -> slower net transfer?
Message-ID: <1929@brl-tgr.ARPA>
Date: Sun, 6-Oct-85 04:19:39 EDT
Article-I.D.: brl-tgr.1929
Posted: Sun Oct  6 04:19:39 1985
Date-Received: Mon, 7-Oct-85 06:17:42 EDT
Sender: news@brl-tgr.ARPA
Lines: 21


    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.arpa