Return to BSD News archive
Newsgroups: comp.os.386bsd.questions Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!decwrl!decwrl!concert!news-feed-1.peachnet.edu!darwin.sura.net!howland.reston.ans.net!agate!boulder!alumni!plotkin From: plotkin@alumni.cs.Colorado.EDU (Leo Classic) Subject: Re: ed0: device timeout, freebsd cslip Message-ID: <CEM0Mr.1nA@Colorado.EDU> Sender: news@Colorado.EDU (USENET News System) Organization: University of Colorado, Boulder References: <CECt8C.29o@Colorado.EDU> <JKH.93Oct4083135@whisker.lotus.ie> <CEDnEn.D9r@usenet.ucs.indiana.edu> Date: Sat, 9 Oct 1993 03:06:26 GMT Lines: 82 First off, sorry for not replying to all the people who sent me mail re: this problem. alumni.cs has more crashes than a Volvo Safety Engineering program. I lost the mbox with your addressi. In article <CEDnEn.D9r@usenet.ucs.indiana.edu> pitts@bigbang.astro.indiana.edu (Jim Pitts) writes: >> >Boy, you are not far off on that one. Is there a good reason you are not >using the sio driver? I get 1.4-1.9K/sec from my 14.4 (USR Sportster) using >ftp/16550A/sio drivers. I *was* using the sio driver. Actualy, it's not the serial performance that's the problem. I get 1.4k+ with NetBSD, term and zmodem. The problem appears to be with the FreeBSD cslip. Details at the end of this posting. >The compression features of 14.4K modems can actually HURT your transfer >rate on gzipped files that are ALREADY compressed. As other people pointed out, this is simply not true with v42bis (or MNP10). But modem compression/error correction does hurt response time something fierce (remember, the modem latency is a hit *BOTH* ways!). I'd rather eat broken glass or sysadmin internetworked 3b2s than use MNP5, which is the only commonly used modem compression I know of which will hurt throughput. In any case, since most of my use is interactive cslip, I always turn off error correction and compression. > 1. gzip'ped files (packed binaries). > 2. ASCII text files. > 3. Executable binaries (non packed binaries). For all 3: zmodem, term, netbsd: 1.4k/sec. 386bsd: 1.1k/sec. FreeBSD: .6k/sec. >Do this for files above 500K in size to get good statistics. Finally, after >you do this with ftp, do the same tests with zmodem. You should get >1.4K/s for binaries, 1.2K/s for packed binaries, and almost 2K/s for ASCII >files. With v42bis I get about 1.6k/sec for compressed binaries, which is what can be expected from not sending parity and stop bits. Ok, back to the cslip problem. My completely groundless theory was that the new faster sio drivers spend more time servicing interrupts and ergo steal enough cycles from the rest of the OS that TCP timeouts occur. To test, I upgraded my machine to a 486/66. A 2.8 Mb/sec (coretest benchmark) VLB disk controller was installed to minimize the impact of writing the data to disk as I recieved it. The distribution kernel gave 1.29k/sec xfer rate. Not bad! Next, I cranked the motherboard clock to 40 mhz. Lemme tell you, kernel compile times on an 80mhz 486 will make you a believer in Intel! Windoze might run in real time on this box. However, the increase in FTP throughput was not statisticaly significant. Next I configured a kernel with syscons, support for my ethernet card and the ROUTER option. Ai karamba. Back to .6k/sec!!! So, we get to my question (yes. there's a reason I'm posting to this newsgroup.) Are there any FreeBSD and TCP knowledgeable people who care to help me out as I put on my hip waders and snorkel and prepare to dive into networking source? While I'd prefer that someone be Van Jacobsen, I'll be exteremely grateful to anyone who knows their way around Berzerkeley tcp and feels like helping me figure this puzzle out. Come to think of it, the 'threshold' on the 16550 FIFO might be set to be 15 bytes or something minor like that. But I somehow doubt it. --leo -- -- Leo plotkin@alumni.cs.colorado.edu "There is a fine line between gross and brilliant" -- me, on coding. /* Gross, make brilliant later */ -- Andrew Boardman