Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!metro!ultima!kralizec.zeta.org.au!godzilla.zeta.org.au!not-for-mail From: bde@kralizec.zeta.org.au (Bruce Evans) Newsgroups: comp.os.386bsd.questions Subject: Re: NetBSD - routing and slip Date: 24 Jan 1994 20:19:39 +1100 Organization: Kralizec Dialup Unix Sydney - +61-2-837-1183, v.32bis and v.42bis Lines: 54 Message-ID: <2i03rbINN1t7@godzilla.zeta.org.au> References: <2gv4lc$l0i@darkstar.UCSC.EDU> <CJJ0w6.ADo@usenet.ucs.indiana.edu> <2h1neg$gju@pdq.coe.montana.edu> <CJJHoM.r9@usenet.ucs.indiana.edu> NNTP-Posting-Host: godzilla.zeta.org.au In article <CJJHoM.r9@usenet.ucs.indiana.edu>, Jim Pitts <pitts@mimosa.astro.indiana.edu> wrote: > >Many moons ago I posted posted something about how the sio drivers had solved >all the problems in my life ... how great they are. I got several flame >messages telling me that the NetBSD drivers were faster and I was an idiot. >Not the latter -may- be true, I don't deny it ... but I honestly never saw >any performance loss when I went to FreeBSD and its sio drivers. I >never measured with enough intrest to notice a speed -increase-. The com driver should be slightly faster for input on fast machines (486's) at low speeds (14400-57600 bps), because it has less delays due to buffering. Buffering should not cost for output, but the released versions of sio have a bug that cause delays averaging 5 msec per packet (bad for small packets). Fixing this improved the throughput for my standard test, a zmodem transfer at 115200 bps on a local line, from about 9500 cps to about 11000 cps. Slip throughput didn't change much and is still slightly below 10000 cps. Input latency is harmful for slip but not for streaming protocols such a zmodem. The sio driver has much lower overheads than most drivers. This allows you to run multiple bidirectional transfers at 115200 bps on fast machines with 16550's, and allows slow machines with 16450's to work reasonably. To "work", the driver must get a throughput of within 10% of the maximum possible at a given line speed, possibly using flow control, and there must not be any silo overflows. The overheads in the following table were calculated from the time taken to run a cpu-bound process (counting from 1 up for about 30 seconds) while doing a serial transfer in the background. System times reported by /usr/bin/time are very inaccurate (much too small) with sio. /* * Results for serial overheads (in %). * All for a single line at 115200 bps. * FreeBSD uses sio; linux uses the standard driver; performance bugs * in select() involving VMIN had to be fixed in both kernels to avoid * small i/o's. * machine uart O/S read write r+w comments * 486/33 16550 FreeBSD 8.1 4.0 11.6 (version 1.0.2 + many changes) * linux 27.0 9.3 34.8 (version 0.99pl14 + few changes) * 16450 FreeBSD 20.5 16.5 31.4 (better than 16550 linux :-) * linux 97s 43.1 88s (s = saturated, speed OK) * 386/20 16450 FreeBSD 52.4 42.0 71.8 (tx speed dropped to 9000 cps) * 486/33 16550 FreeBSD 56.8 21.6 69.8 (non-turbo - 10-30 times slower) * linux 74.7S 63.0 78.2S (S = saturated && lost speed) * 16450 FreeBSD F 93.7 F (F = saturated && lost ticks) * linux F F F */ -- Bruce Evans bde@kralizec.zeta.org.au