Skip site navigation (1)Skip section navigation (2)
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>