Return to BSD News archive
Xref: sserve comp.unix.bsd:7621 comp.os.linux:15140 Newsgroups: comp.unix.bsd,comp.os.linux Path: sserve!manuel.anu.edu.au!munnari.oz.au!metro!ipso!runxtsa!bde From: bde@runx.oz.au (Bruce Evans) Subject: Re: IDE faster than SCSI-2 Message-ID: <1992Nov8.072924.6374@runx.oz.au> Organization: RUNX Un*x Timeshare. Sydney, Australia. References: <1992Nov5.080716.10386@ntuix.ntu.ac.sg> <1df7dqINN37o@tartarus.uwa.edu.au> Date: Sun, 8 Nov 92 07:29:24 GMT Lines: 46 In article <1df7dqINN37o@tartarus.uwa.edu.au> oreillym@tartarus.uwa.edu.au (Michael O'Reilly) writes: >Othman Ahmad (eoahmad@ntuix.ntu.ac.sg) wrote: >: [...] >: JUlian's machine >: is a 50MHz EISA 486 with a 1.3GB drive attached via a Bustek 742a SCSI2 >: adapter. It has 16MB of ram. Part of the disk (about 200MB is taken up >: by mach2.6 and is unavailable to 386bsd. >: >: I checked the load on this machine, it is very light. There is only another >: user apart from I. >: >: iozone 1 >: >: Writing the 1 Megabyte file, 'iozone.tmp'...1.766667 seconds > ^ > ^ This is useless. It tells no-one anything. A one meg >file should fit entirely in the cache. So unless BSD is braindead, and >doesn't cache (which I doubt), then you have just measured the cache >speed. On my 486/33, 8 meg ram, a 1 meg files get 10 megs per second. 1 MB in 1.76 seconds is way below the cache speed. In fact it is quite likely to be a good estimate for actual disk speed. Disk caching in 386BSD-0.1 is quite broken. First, only 10% of memory is used for the disk+swap cache. This is smaller than I like. (Comments in the code say that only 5% of memory after the first 2MB are allocated to the cache, but due to bugs, 10% of all memory is allocated. A fix has been posted.) Second, only half of the 10% is used for the disk cache. (Some (usually all) of the other half is reserved for buffers for swapping.) Third, memory for each buffer is allocated twice, so only 2.5% of memory is used for the disk cache! A fix is in Terry's patch kit. Fourth, bugs in the caching algorithm caused the cache to thrash. A fix is in the patch kit. Fifth, another kernel limit requires limiting the initial 10% allocation to 256 buffers to avoid panics (the limit is in the patch kit). (I actually use a limit of 503 to get 251 disk buffers and 252 swap buffers. This is fairly safe because the system almost never swaps.) >I don't know exactly what you measured, but it sure ain't disk speed. It probably was disk speed! I don't know exactly what the cache size is on Julian's system. If the system has all the standard patches, it will have 128 disk buffers for a total cache size of about 512K if the file system has a block size of 4K. That is consistent with the benchmark. -- Bruce Evans (bde@runx.oz.au)