Date: Tue, 10 Oct 1995 06:45:41 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, se@zpr.uni-koeln.de Cc: hackers@freebsd.org Subject: Re: VLB Disk Controllers Message-ID: <199510092045.GAA23299@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>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 ... This includes the transfer time too. I know that the transfer speed is about 3.0MB/sec (slightly less than the standard PIO 1 speed of 3.3MB/sec). Thus about 171 usec is for transferring and about 111 usec for sub-command overheads. These numbers aren't very accurate. I biased the estimates towards IDE by ignoring kernel overheads and extra driver overheads for setting up the first sector. These overheads seem to be much larger than I thought. I changed all the 8192's in the program to 1024 and all 4096's to 512 to get a better test of single- sector performace: output for disklatency-512 /dev/rwd0: Command overhead is 689 usec (time_512 = 924, time_1024 = 1159) transfer speed is 2.17916e+06 bytes/sec This result is the same to within +- 2 usec every time for rwd0, but for rsd*, it varies so much that time_1024 is often less than time_512 so the transfer speed appears to be negative! >} 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 :) I think that is from the drive's cache being turned off. The test assumes that the data that it reads is all cached to avoid counting seek times and to reduce randomness. It should be more accurate with larger buffers, but the buffers must be small enough to stop the drive's cache from thrashing. >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 ...) This is consistent with the large times that I got for the disklatency_512 test. If the kernel overhead dominates, then randomness in it would cause the apparently negative speeds. This leaves some interesting problems that we can do more about than device overheads: 1) why is the kernel overhead so large? 2) is the kernel overhead really so large? I don't remember it showing up relative to transfer overhead in profiles. 3) how can the test be improved to distinguish kernel overheads and to reduce randomness? To begin with it should attempt to determine the drive's cache size and fill the cache. Then it should read from buffers of sizes 512, 1024, ..., min(256K, drive's cache size). It should check that the user + sys time is almost equal to the real time (if not, the other processes may be stealing too much time or the device may be taking to long to respond, perhaps because the data isn't cached). 4) why are my rsd* times much more random than my rwd0 times? I get these times for reading /dev/zero: 486DX/33: output for disklatency-512 /dev/zero: Command overhead is 193 usec (time_512 = 209, time_1024 = 224) transfer speed is 3.26364e+07 bytes/sec 486DX/33: output for disklatency /dev/zero: Command overhead is 241 usec (time_4096 = 344, time_8192 = 447) transfer speed is 3.99119e+07 bytes/sec 486DX2/66: output for disklatency-512 /dev/zero: Command overhead is 170 usec (time_512 = 186, time_1024 = 202) transfer speed is 3.15738e+07 bytes/sec 486DX2/66: output for disklatency /dev/zero: Command overhead is 209 usec (time_4096 = 339, time_8192 = 468) transfer speed is 3.16325e+07 bytes/sec (slower than 486DX/33 :-() These memory speeds are consistent with the speed of the L2 cache measured in more accurate ways. The kernel overhead is much less than 573 usec, but still quite large, and there are extra overheads for real disks. The program is misnamed :-). It tests more than disks, and command overhead, not command latency. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510092045.GAA23299>