Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!metro!sequoia!ultima!kralizec.zeta.org.au!kralizec.zeta.org.au!not-for-mail From: bde@kralizec.zeta.org.au (Bruce Evans) Newsgroups: comp.os.386bsd.questions Subject: Re: VLB IDE cache controller Date: 27 Sep 1993 09:35:42 +1000 Organization: Kralizec Dialup Unix Sydney: +61-2-837-1183 V.32bis Lines: 28 Message-ID: <28590eINNa2o@kralizec.zeta.org.au> References: <27mf1g$ajt@news.u.washington.edu> <RAM.93Sep21145412@xor.epi.wisc.edu> <RAND.93Sep22161811@agassiz.cas.und.NoDak.Edu> NNTP-Posting-Host: kralizec.zeta.org.au In <RAND.93Sep22161811@agassiz.cas.und.NoDak.Edu> rand@cs.UND.NoDak.Edu (Douglas K. Rand) writes: >I've got a Promise Technology VLB caching controller with 4 Mbytes on >the controller (20 Mbytes main memory) and I see a signfigant >difference with the cache. Here are some simple performance numbers >for just the linking phase of building a new kernel: > First time Second time >cache disabled: 16.41 secs 16.21 secs >cache enabled: 9.20 secs 3.28 secs >What I did is time make, and then remove netbsd, and then time the >make again. With the cache disabled the second time is almost the same How many buffers does netbsd allocate when you have 20MB of main memory? (Look at the bootup message to see.) The comparison is not fair unless at least 4MB of main memory is allocated (and used) for the buffer cache. All versions of 386BSD-0.1 suffered from tiny caches of size 1M at best (256K-512K was more common). Another way that a caching controller might be faster is that it reduces the amount of i/o for synchronous directory updates. Are all or most caching controllers + drives protected against power failures? If not, the speed is bought at the cost of more chance of file system corruption. A different file system implementation can easily provide even more speed at the same cost by delaying directory updates. -- Bruce Evans bde@kralizec.zeta.org.au