Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!nntp.coast.net!howland.reston.ans.net!Germany.EU.net!wizard.pn.com!brighton.openmarket.com!decwrl!pa.dec.com!depot.mro.dec.com!enomem.lkg.dec.com!usenet From: matt@3am-software.com (Matt Thomas) Newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,comp.unix.bsd.freebsd.misc Subject: Re: TCP latency Date: 10 Jul 1996 20:09:14 GMT Organization: Digital Equipment Corporation Lines: 60 Sender: thomas@netrix.lkg.dec.com (Matt Thomas) Message-ID: <4s12la$pm8@enomem.lkg.dec.com> References: <4paedl$4bm@engnews2.eng.sun.com> <4rfkje$am5@linux.cs.helsinki.fi> <31DC8EBA.41C67EA6@dyson.iquest.net> <4rlf6i$c5f@linux.cs.helsinki.fi> <31DEA3A3.41C67EA6@dyson.iquest.net> <Du681x.2Gy@kroete2.freinet.de> <31DFEB02.41C67EA6@dyson.iquest.net> <4rpdtn$30b@symiserver2.symantec.com> <x7ohlq78wt.fsf@oberon.di.fc.ul.pt> <Pine.LNX.3.91.960709020017.19115I-100000@reflections.mindspring.com> NNTP-Posting-Host: netrix.lkg.dec.com X-Newsreader: knews 0.9.3 In-Reply-To: <Pine.LNX.3.91.960709020017.19115I-100000@reflections.mindspring.com> To: Todd Graham Lewis <tlewis@mindspring.com> Xref: euryale.cc.adfa.oz.au comp.os.linux.networking:44699 comp.unix.bsd.netbsd.misc:3988 comp.unix.bsd.freebsd.misc:23232 In article <Pine.LNX.3.91.960709020017.19115I-100000@reflections.mindspring.com>, >Question #1: Which aspects of network performance under FreeBSD and/or > Linux are most in need of improvement? Extra credit for > well-reasoned answers. If latency is unimportant, which I > don't think anyone is seriously asserting, then what else is > important, to which everyone should have an answer. It depends on what your goal is. If you are a video server sending out lots and lots of data the first and foremost problem is the amount of memory references that need to be done when a packet is received or transmitted. This ties directly into the number of video session you can support. You will find that memory references are on a par with or exceed the amount of time doing protocol processing. If you are Web Serving, you spend lots of time doing connection build up and teardown and protcol processing. Much less time will be spent moving/massaging data than dealing with protocol overhead. >These are obviously not cut and dried issues. TCP has been around >for 15 years and we're still wrestling with them. So please, enlighten >us end users, (and I mean that b/c I'd love to hear the various >opinions), what is left to be done? I wonder whether can one can truly comprehend tcp_input() from BSD. It keeps going and going and going ... The BSD tcp code is "subtle". >Question #2: Does latency optimization have ancillary benefits in terms > of general code robustness or quality? Probably not. It introduces special cases into the code and that usually can result is code paths that stagnate (and bit rot when more changes are made). Radical idea. Requires no new system calls. Define some new MSG_ variables called MSG_ASYNC, MSG_COMPLETE, and MSG_PARTIAL. When a sendmsg is done and MSG_ASYNC is set in the flags argument, sendmsg(2) will own the data pointed to by the supplied msgbuf structure. sendmsg(2) will return immediately with a -1 and errno set to EINPROGRESS. When the system is done with the buffer, it will set MSG_COMPLETE in msg_flags member. If not all the data supplied was consumed, MSG_PARTIAL will also be set and any iovec entry will have its iov_len set to the number of bytes not transferred into the kernel. [more needs to be written but you should get the idea.] This would allow application such as ftp to directly send data without having to copy into the kernel thereby eliminating one data copy. Doing the same on receive is much more difficult (but possible). The idea for receive would be to combine the copy to user-space with the checksum validation which allow one data reference to eliminated (this assumes that checksum failures will be rare). This would also reduce latency somewhat since the window could advance immediately without having to wait for the user to do the read/recv. This will only work it is cheaper to remap the page(s) for the data into the kernel than it is to copy the data. -- Matt Thomas Internet: matt@3am-software.com 3am Software Foundry WWW URL: http://www.3am-software.com/bio/matt.html Westford, MA Disclaimer: I disavow all knowledge of this message