[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Help with hdparm



chainy <chainy@infonegocio.com> [2002-08-27 23:11:32 +0200]:
> On Tuesday 27 August 2002 18:53, Bob Proulx wrote:
> > I imagine that many things could affect the transfer speed.  One is
> > that I have a slightly faster CPU (classic slot-A 950MHz with 512kb
> > cache) versus the 500MHz previously posted.  I have 512MB of CL2 PC133
> > memory installed.  Note that this motherboard can use PC133 but only
> > runs at PC100 speeds IIRC.  Also, I expect that different disk drive
> > controllers will perform differently.  This is an older SD11
> > motherboard but I have updated IIRC to 611(?) BIOS some time ago.
> >
> > I believe the biggest lever is the newer drivers with the 2.4 kernel.
> > What kernel are you running?  If you are still running something older
> > then I would advise updating to 2.4.18 which has been a good version.
> 
> Thanks again for the info Bob, I am also running a 2.4.18 kernel that i 
> configured myself.
> 
> In my case i don't think the processor or memory are involved too much 
> because the results are very different.  It is also curious that i cannot 
> activate the udma in any level.
> 
> Maybe this is asking you too much but could you tel me what chipset options 
> do you have in your kernel?

Hmm...  It looks like I installed an SMP kernel.  Let me boot back to
the stock bf24 kernel.  Hey this is not right.  That is pretty slow.
Let's check the disk parameters.  So if I run a normal bf24 kernel I
am slow too.  But with a locally recompiled kernel things are fast.  I
don't know if the SMP flag is the difference or not.

hdparm -t /dev/hda

 Timing buffered disk reads:  64 MB in  7.60 seconds =  8.42 MB/sec

hdparm /dev/hda

/dev/hda:
 multcount    =  0 (off)
 I/O support  =  1 (32-bit)
 unmaskirq    =  1 (on)
 using_dma    =  0 (off)
 keepsettings =  0 (off)
 nowerr       =  0 (off)
 readonly     =  0 (off)
 readahead    =  8 (on)
 geometry     = 7299/255/63, sectors = 117266688, start = 0
 busstate     =  1 (on)

But if I boot back to the kernel that I recompiled then I get the
results I reported previously.  The configuration for which I reported
is the /boot/config-2.4.18-bf2.4 plus CONFIG_NOHIGHMEM=y and
CONFIG_SMP=y.  I did not mean to set SMP but since my main machine is
an SMP machine I must have set that out of habit.  Then it was
recompiled with CONFIG_M386=y because I did not change that from bf24,
which is silly, I will change that to get better optimizations.

I had a disk crash about three weeks ago.  I replaced the disk with a
new one and installed Debian onto it about two weeks ago.  I have not
done anything too crazy with this box since then.  But every machine
should be running Debian, right?  While normally booted as debian it
is a software test machine for me.

But this machines gets work and its real purpose in life as a dual
boot machine to play games.  Which means this machine has an Evil(TM)
nVidia GeForce 2 GTS in it.  In order to get Unreal Tournament running
under Linux I need to run the proprietary nVidia drivers.  Which
pretty much means I needed to recompile the kernel and the nVidia
module so that they will work together.  (But while I had UT working
before the last crash it does not work now.  I may be asking questions
of the list for help with that.)

When I get time I will rebuild the kernel without SMP, and with better
optimizations and post the results.

Bob

Attachment: pgp8PMEkgQdJU.pgp
Description: PGP signature


Reply to: