Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!newshost.telstra.net!news.ci.com.au!wabbit.cc.uow.edu.au!metro!metro!inferno.mpx.com.au!news.mel.aone.net.au!imci4!newsfeed.internetmci.com!news.mathworks.com!fu-berlin.de!news.belwue.de!news.uni-stuttgart.de!news.rhrz.uni-bonn.de!RRZ.Uni-Koeln.DE!zpr.uni-koeln.de!se From: se@ZPR.Uni-Koeln.DE (Stefan Esser) Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: Serious performance problems with NCR PCI SCSI card Date: 21 Feb 1996 23:32:31 GMT Organization: Institute for Mathematics, University of Cologne, Germany Lines: 48 Sender: se@Sysiphos (Stefan Esser) Message-ID: <4gga2f$61d@news.rrz.uni-koeln.de> References: <4gf23e$1vv@fozzie.sun3.iaf.nl> NNTP-Posting-Host: sysiphos.mi.uni-koeln.de To: geert@fozzie.sun3.iaf.nl (Geert Bosch) In article <4gf23e$1vv@fozzie.sun3.iaf.nl>, geert@fozzie.sun3.iaf.nl (Geert Bosch) writes: |> When I wanted to benchmark a new IBM Spitfire 1 GB drive yesterday, |> I noticed some really strange performance problems. What I wanted |> to test was throughput of sequential reads, these were the results |> of both FreeBSD (using dd, reading raw filesystem sd0a) and OS/2 |> (directly calling the OS/2 API from a small testprogram, reading |> raw filesystem). Both tests ran on the same system (486DX33 w/ |> 16 MB RAM) on same disk. |> |> FreeBSD OS/2 |> (kB) (kB/s) (kB) (kB/sec) |> Blocksize (kB) Total Speed Total Speed |> 1 39996 102 51200 1430 |> 4 39996 403 51200 1269 |> 8 39996 805 51200 1278 |> 16 39996 1611 51200 3096 |> 32 39996 3218 51200 3997 |> 48 39996 4240 (not measured) |> |> The very strange thing is that FreeBSD or the NCR driver or dd |> seems to be limited to 100 reads/second (which *is* really bad). |> There is no problem with the timing, the FreeBSD test with 1 kB |> blocksize *really* took 8 mins. Even my ethernet can do much |> faster than that with 1 kB packet size. |> |> Isn't the standard timeslice of many unices 10 ms? Is there any |> code which might require waiting till next clock tick? I checked |> that the NCR driver did find the right IRQ, but I've included |> the output of the dmesg command, because there might be clues in |> it (although I couldn't find them). Well, but I could. Please assign another interrupt to the NCR, not IRQ 15 as it is currently set up ... Guess you assigned the IDE compatibility interrupt to the NCR. I've seen strange things like this happen before in this case. How about using 9, 11 or 12 ? Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/~se <se@ZPR.Uni-Koeln.DE>