Date: Mon, 9 Oct 1995 19:59:08 +0100 From: se@zpr.uni-koeln.de (Stefan Esser) To: Bruce Evans <bde@zeta.org.au> Cc: hackers@freebsd.org Subject: Re: VLB Disk Controllers Message-ID: <199510091859.AA02809@Sysiphos> In-Reply-To: Bruce Evans <bde@zeta.org.au> "Re: VLB Disk Controllers" (Oct 8, 9:48)
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 8, 9:48, Bruce Evans wrote: } Subject: Re: VLB Disk Controllers } >} >Seems the NCR is faster on 512 byte transfers. } >} } >} Nope, the 573 us is for _8_ transfers of 512 bytes because my drive } >} doesn't support multi-mode, and it's on a slower machine :-). I'm } >} surprised that it is as high as 573/8 = 72 us per command. This is all } >} host software (not bus related) overhead except for about 10 usec to } >} write the command to the controller. } } >Don't think so. There are 16 transfers in the 8KB test, } >and thus the per sector overhead is in fact accounted } >for in the transfer rate ! } } That's true for IDE, but not for SCSI. The NCR would be much slower if } it was forced to issue 7 more commands per 4K. That's part of its } advantage. However, multi-sector transfers for IDE might give the } same advantage to IDE. The reduction in the command overhead would not } be 7 * 72, it would be 7 * (72 - drive_overhead_per_sector). It's } likely that the drive processor is slower than an i486 and possible that } the drive processor+firmware is slower than an i486+software. Thus the } reduction may be negative :-). Actually :-(. Hmm, looking at your numbers: % Cheap IDE on 486DX/33 ISA SAMSUNG SHD-3212A (slow disk): % output for disklatency /dev/rwd0: % Command overhead is 573 usec (time_4096 = 2830, time_8192 = 5087) % transfer speed is 1.81489e+06 bytes/sec Time per sector is (2830-573)/8 = 282 micro seconds, not 72 ! The 573 microseconds are the actual command overhead caused by the kernel (system call, locking pages, ...), or I must be totally confused ... } dd is not so good for this sort of test because the time for outputtinh } to /dev/null is significant. Both my benchmark and dd have granularity } problems - they count the time in seconds. They should use gettimeofday() } instead of time(). } } >(BTW: I've got 1585 transfers/s in the 512 byte test. } >That's 630 us per *transfer*. And the startup overhead } >can't possibly be higher :) } } The NCR seems to be a bit faster than the Adaptec 2842. Not sure, actually, but both seem really quite fast, at least compared to eg. our Sparc10s (with their 10ms command overhead :) If I take my earlier number of 730us command overhead for the NCR and assume that the above 573us are actually kernel overhead, then the NCR driver itself seems to impose an overhead of only soem 160 microseconds per transfer ... (BTW: That is about the value to be expected according to the Atlas' technical data sheet ...) 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/staff/esser/esser.html <se@ZPR.Uni-Koeln.DE>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510091859.AA02809>