Date: Sat, 8 Apr 1995 00:35:36 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com> To: taob@gate.sinica.edu.tw (Brian Tao) Cc: freebsd-current@FreeBSD.org Subject: Re: Disk performance Message-ID: <199504080735.AAA14324@gndrsh.aac.dev.com> In-Reply-To: <Pine.BSI.3.91.950408140448.787A-100000@aries.ibms.sinica.edu.tw> from "Brian Tao" at Apr 8, 95 02:50:19 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > On Fri, 7 Apr 1995, Rodney W. Grimes wrote: > > > > > 'top' shows this (sometime during the latter half of the run): > > > > > > PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND > > > 20444 root 48 0 244K 424K run 0:41 51.76% 50.35% iozone > > > > I get the following stats using 3 different utilities (I was glad to > > see that thy agreed within reason!): [We are not comparing apples to > > apples here, I am running on a P54C-90, your tests where on a DX4/100] > > > > systat -vm processor mode line: > > 19.3%Sys 2.0%Intr 0.5%User 0.0%Nice 78.3%Idl > > I asked because the P90 (the one with those twin Maverick drives) > peaks at less than 10% CPU, but of course it can barely manage > 1.3MB/sec with iozone so the CPU is idle 90% of the time. Thus my > initial reaction to the 50% figure above was "too high", and so: I tend to agree that it does look a little high. But remeber we still have to bcopy the bytes between user land and the kernel, which well be somewhat slower on the 486 class of machines due to the data path width to memory. (It does not scale 2X like you think it would, it seems the memory desiges in Pentium systems leave a little to be desired :-(). > > > Is this a reasonable figure? Probabaly, it's with in reason, but could be better. > > You forgot that the CPU is not 100% busy. > > My feeling is that it should have been lower and not anywhere > close to 100% usage. Sending out 366 I/O requests to a SCSI device > and waiting for them to return did not seem to warrant a 50% busy > state with a 100-MHz processor on a 33-MHz bus. I gather this is > where IDE drives fare much worse? Yes, IDE drives load the cpu down far more, as they not only have to bcopy the bytes to and from user land, they also have to bcopy them to and from the disk. The scsi systems win here because the transfers between the disk and main memory are all done by the scsi adapter (well, at least for bus mastered scsi adapters). > > What that 2.7mS number > > relates to closest is the fact that 8192 bytes fly under the disk head > > in ~2.7mS. Your Quantum 1080 is a 5400 RPM (90 RPS) drive, meaning > > it takes 11.11mS for one revolution, turning a few more numbers through > > xcalc 2.7mS/11.11mS * (16 sectors per 8192 bytes)=65 sectors/revolution. > > You mean 11.11/2.7, but I get your point. Quantum's data sheet Ooopss, your right, I flipped the time values when I wrote it above, it was done in xcalc correctly though. > for the Empire 1080 shows 64 to 107 sectors per track. I tested it > on my sd0g partition which is located between cylinders 467 to 862 > (out of 1017). The iozone file is probably located along the inner > half of that cylinder group, given that the filesystem is over half > ful now. So given the overheard in iozone and other little errors, 65 > sectors/track is pretty good guess. :-), just bloody amazing!!! Wish I had a little chunk of code to read the notch page for that drive so I could find out just how close I really was! > BTW, is the best place for a swap partition along the outer edge > of the disk where there are more sectors/track, or are there other > factors (e.g., disk head seeking between swap and ufs partitions)? Historically the seek time was the dominant factor, but now with seeks times and rotational delays getting all to close togeather it's all becoming muddy. I tend to try and locate my swap area on boot disks between / and /usr since these are the most active file systems for that disk. > Does it really make much difference with only one spindle to swap on? Probably not much, though you don't want to locate it far away from the most active area of the disk, IMHO. > > > % time dd if=/dev/zero of=/dev/null bs=102400 count=10240 > > > > It is hard to be sure exactly what is being measure here, It is > > a combination of bzero speed, RAM -> CPU and CPU <-> cache bandwidths. > [...] > > I tried to correlate the number with a memory benchmark program on > > my system and it comes up to be faster than the CPU -> main memory > > write bandwidth but about 1/2 the speed of main memory read bandwidth. > > The P90 gets roughly the same benchmark (if you could call it > that) as both the DX4/100 and DX2/66, about 33MB/sec. The Sparc1 > upstairs gets 13.3MB/sec but the SGI Crimson next door gets something > like 128MB/sec. Probably not much more useful on its own than any > other benchmark. Especially with out detailed information about how the kernel implements the buffer copies to and from user land. I'm pretty sure the SGI boxes use page flipping, and I know the SGI machines have very fast memory systems in them from other tests. AHh.. just ask phk@FreeBSD.org why the sun's are so bloody slow. Most 486 machines can outperform SS1000 :-). I expect to be able towards the end of next week show some really amazing numbers on a Pentium system with respect to memory speeds. Let's all hope that the new EDO and Pipelined Burst SRAM stand up to the theories and we start to see 100++MB/sec main memory speeds on a Pentium like we should. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504080735.AAA14324>