Date: Wed, 18 Jun 1997 18:16:49 -0700 (PDT) From: Tom Samplonius <tom@sdf.com> To: sthaug@nethelp.no Cc: ccsanady@scl.ameslab.gov, hackers@freebsd.org, matt@3am-software.com Subject: Re: Network concurrency problems!? Message-ID: <Pine.BSF.3.95q.970618181004.11965A-100000@misery.sdf.com> In-Reply-To: <4913.866668314@verdi.nethelp.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 18 Jun 1997 sthaug@nethelp.no wrote: > > > Also, if you expect a PPro-200 to saturate 4 100 Mbps links, I think you > > > are a wee bit optimistic. (One link, no problem.) > > > > Why? As long as the ethernet hw is fast, is should be no problem. > > It's a problem because of the resource usage of the TCP/IP stack and the > driver. > > The FreeBSD TCP/IP stack is good, but it's not the most efficient. As far > as I know, there is still an extra pass over the data to perform the TCP > checksum, for instance. Would a TCP socket have more system overhead than a file on a UFS filesystem? I guess you can tess this by running dd on a mfs, and tcpblast/netpipe/ttcp on loopback? Somehow I think the socket would be faster. ... > > However, I really doubt whether most ethernet adapters offload enough > > functions from the main CPU. The trend is to make very stupid > > controllers, which are slaved to the CPU for everything. > > There has been a good deal of debate on whether offloading is really the > best idea for network protocol implementations. A lot of people have tried > it, and a lot of people have failed. If you look at Van Jacobson't work > you'll find him arguing in the opposite direction: A "stupid" (in reality: > simple and efficient) controller, and a very efficient protocol stack > implementation. Not really what I was refering to. I was thinking about controllers that minimize interupt calls, use DMA, avoid PIO, and align data transfered to the host. Tom
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95q.970618181004.11965A-100000>