Return to BSD News archive
Xref: sserve comp.os.386bsd.misc:1254 comp.os.linux:56370 Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!spool.mu.edu!bloom-beacon.mit.edu!news.kei.com!news.byu.edu!cwis.isu.edu!u.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (A Wizard of Earth C) Newsgroups: comp.os.386bsd.misc,comp.os.linux Subject: Re: NetBSD TCP/IP network benchmarks Date: 16 Oct 1993 06:22:04 GMT Organization: Weber State University, Ogden, UT Lines: 74 Message-ID: <29o3uc$r56@u.cc.utah.edu> References: <1993Oct9.015400.8763@beaver.cs.washington.edu> <29db3j$g5j@u.cc.utah.edu> <D87-MAL.93Oct13192905@orinoco.nada.kth.se> NNTP-Posting-Host: cs.weber.edu In article <D87-MAL.93Oct13192905@orinoco.nada.kth.se> d87-mal@orinoco.nada.kth.se (Mats Löfkvist) writes: >In article <29db3j$g5j@u.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: > > In article <1993Oct9.015400.8763@beaver.cs.washington.edu> cmaeda@cs.washington.edu (Chris Maeda) writes: > >In article <294eho$h4q@wzv.win.tue.nl> guido@gvr.win.tue.nl (Guido van Rooij) writes: > >>I am getting 500k+ between my FreeBSD and a sun ipx. And that with an 8 > >>bit wd8003ep. Thanks to the ed-driver. > > > >More likely thanks to the sun ipx. > > Actually, unlikely. The Sun driver misuses the Lance chipset buffering and > has a max throughput of about 3Mbits/S -- about 1/3 the possible. > >What driver? SunOS 4? 5? BSD4.4? Send and/or receive? >I have seen ~1MB/s when ftp'ing big (3+MB) files from an ipx to an hp730. SunOS 4.1.x and below (not the SVR4 stuff). Also, the FreeBSD stuff is much less CPU bound than the other; to get high throughput on SVR4, you have to be very CPU bound -- SVR4 has very, very, vey, very, very, very bad timer code and only gets reliable timer resoloutions to 10mS (at the same time violating SVID for getitimer/setitimer). They trade CPU clocks for the driver speed. Specifically: The current SVR4 code is incorrect for the implementation of the the SVID Third Edition, Volume III real time extensions; in point of fact, SVR4 is not SVID compliant. gettimeofday() is updated in ticks; this is insufficient for even typical non-RT tasks, but it is allowed. The specific portion of the SVID states: "The resoloution of the system clock is hardware dependant; the time may be updated continuously, or in ticks". The clear implication is that the system clock speed if updated continuously MUST be >= to the tick speed resoloution -- the LBOLT speed of 100 Hz, yielding a resoloution of 10mS. getitimer/setitimer resoloution is stated to be the system clock resoloution NOT THE SYSTEM CLOCK UPDATE RESOLOUTION!!! The relevant section of SVID states: "Time values smaller than the resoloution of the system clock are rounded up to this resoloution" Note that it specifically states SYSTEM CLOCK RESOLOUTION and does not say SYSTEM CLOCK UPDATE RESOLUTION. Basically, this means buzz loops for drivers with better than 10mS time criticaity -- read SCSI, Ethernet, and QIC-40/80 drivers (for the 386 version of Solaris -- QIC-40/80 is non-applicable to SPARC, since it isn't supported at all). Of course, there is no resoloution requirement above the system clock update, which may occur in ticks, for select() (a good thing, since it is implemented on poll(), which supposedly has a 1mS resoloution, but in reality is also limited to 10mS). Of course, since they have to fix the timer code for getitimer()/setitimer(), they might as well fix select() to use the same mechanism at the same time to allow it to once again become useful -- then again, since the politically correct interface to do anything now is poll(), this wouldn't guarantee political correctness, but at least would guarantee customer satisfaction, a less lofty goal. Hint: try to run a statically linked SunOS binary on Solaris, one that uses select. Be sure you have room for the core file. I'm still annoyed that I can't port my best user mode software to SVR4 because of this; I'm not about to rewrite it to do buzz-loops. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.