Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!spool.mu.edu!newspump.sol.net!uwm.edu!news-res.gsl.net!news.gsl.net!news.mathworks.com!enews.sgi.com!news.sgi.com!news.msfc.nasa.gov!newsfeed.internetmci.com!news.kei.com!news.texas.net!news1.best.com!nntp1.best.com!shellx.best.com!not-for-mail From: rcarter@best.com (Russell Carter) Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: 100BaseT tuning considerations? Date: 3 Sep 1996 16:12:52 -0700 Organization: BEST Internet Communications Lines: 42 Message-ID: <50ie1k$rve@shellx.best.com> References: <4vin1s$4um@server.cs.vt.edu> <4vsr44$iom@hpindda.cup.hp.com> <4vv36e$dqo@shellx.best.com> <5055kh$bkc@hpindda.cup.hp.com> NNTP-Posting-Host: shellx.best.com In article <5055kh$bkc@hpindda.cup.hp.com>, Rick Jones <raj@cup.hp.com> wrote: >Russell Carter (rcarter@best.com) wrote: >: In article <4vsr44$iom@hpindda.cup.hp.com>, Rick Jones <raj@cup.hp.com> wrote: >: >So, if you needed 25% of your CPU to go 10 Mbit/s, 40 Mbit/s with >: >100BT seems quite reasonable to expect. > >: Actually, the maximum network bandwidth is much more strongly >: correlated to main memory bandwidth, not CPU. In order to peak out > >Is the strength of that correlation related to the number of data >copies made by the stack on the way in or out? If the stack is really >inefficient and copies once from user to transport, checksums in >transport, copes between transport and driver, and then DMA's I can >see that being the main thing. If the stack is say a one or two pass >stack instead I have a slightly harder time, depending on the link MTU. My comment was meant to be strictly applied to P5/P6 PC motherboard technology, and not generalizable, and I see I didn't make that clear. The measured observation is that starting with P5-100 PB-SRAM technology the memory bandwidth +cpu is sufficient to drive 100mb E-NET to near peak TCP bandwidth, 90 mb/s or so, with FreeBSD. If you have slightly older technology, like a P5-120 with asynch SRAM, you will see the reported performance. The number of copies seems like it should be a big issue but the last time I perused your database (thanks for doing that!) it didn't seem to make much of a difference at all. > >: The 'stream' benchmark from McCalpin is an excellent measure of main >: memory bandwidth. > >Is there a particular correction factor one can apply to the output of >the stream benchmark to predict the performance of something like ttcp >or netperf on the same box? 40%, for the applicable systems. Russell > >rick jones