I am putting together a barebones system with an AMD64 x2 and for right
now am just testing various components in it and am using Debian Etch.

With the Sata drive installed there are lots of problems that I haven't
worked around yet, but there is no doubt that the machine is VERY fast.

But when I install the IDE drive as the boot drive, the disk access is so
slow that it is very obvious that there is a problem. REALLY slow,
something like 1/10 the speed. Or to give an actual example, loading a
large subdirectory from a USB drive onto the Sata took about 3 minutes.
With the IDE installed the identical operation took over 40 minutes.

I have the same Etch on two other machines with IDE's and they are just as
fast as the Sata, given the difference in CPU horsepower, so it is
obvious, I think, that this Mobo doesn't like Linux and IDE. It is a mini
ITX that is for one of those small footprint machines like the Ice Cube
but there is no name on it. lspci shows that the chipset is nvidia.

Before I put this new Mobo on the shelf for trade to some winders dude,
can anybody think of something to try?

horizon

horizon wrote:
> I am putting together a barebones system with an AMD64 x2 and for right
> now am just testing various components in it and am using Debian Etch.
>
> With the Sata drive installed there are lots of problems that I haven't
> worked around yet, but there is no doubt that the machine is VERY fast.

Mm. I went for a single celeron and a SATA disk, and on 32bit intel
etch, and it FLIES. REALLY impressed. Downloading files from it across
teh internal network I swear its faster an my local IDE dsks.


>
> But when I install the IDE drive as the boot drive, the disk access is so
> slow that it is very obvious that there is a problem. REALLY slow,
> something like 1/10 the speed. Or to give an actual example, loading a
> large subdirectory from a USB drive onto the Sata took about 3 minutes.
> With the IDE installed the identical operation took over 40 minutes.
>
> I have the same Etch on two other machines with IDE's and they are just as
> fast as the Sata, given the difference in CPU horsepower, so it is
> obvious, I think, that this Mobo doesn't like Linux and IDE. It is a mini
> ITX that is for one of those small footprint machines like the Ice Cube
> but there is no name on it. lspci shows that the chipset is nvidia.
>
> Before I put this new Mobo on the shelf for trade to some winders dude,
> can anybody think of something to try?
>

No reason that SATA won't work. Probably you justs need to plug away at it.

> horizon

On Fri, 07 Sep 2007, horizon wrote:

> With the IDE installed the identical operation took over 40 minutes.

Obviously, that's not reasonable. Try hdparm, hdparm -t and hdparm -T.

For comparison, here are the results on my IDE hard drive:

[root@poontang ~]# hdparm /dev/hda

/dev/hda:
multcount = 16 (on)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 16383/255/63, sectors = 40020664320, start = 0


[root@poontang ~]# hdparm -t /dev/hda

/dev/hda:
Timing buffered disk reads: 92 MB in 3.00 seconds = 30.65 MB/sec


[root@poontang ~]# hdparm -T /dev/hda

/dev/hda:
Timing cached reads: 1260 MB in 2.00 seconds = 628.67 MB/sec


--
Yves Bellefeuille
<yan@storm.ca>

Yves Bellefeuille wrote:
> On Fri, 07 Sep 2007, horizon wrote:
>
>> With the IDE installed the identical operation took over 40 minutes.
>
> Obviously, that's not reasonable. Try hdparm, hdparm -t and hdparm -T.
>
> For comparison, here are the results on my IDE hard drive:
>
> [root@poontang ~]# hdparm /dev/hda
>
> /dev/hda:
> multcount = 16 (on)
> IO_support = 1 (32-bit)
> unmaskirq = 1 (on)
> using_dma = 1 (on)
> keepsettings = 0 (off)
> readonly = 0 (off)
> readahead = 256 (on)
> geometry = 16383/255/63, sectors = 40020664320, start = 0
>
>
> [root@poontang ~]# hdparm -t /dev/hda
>
> /dev/hda:
> Timing buffered disk reads: 92 MB in 3.00 seconds = 30.65 MB/sec
>
>
> [root@poontang ~]# hdparm -T /dev/hda
>
> /dev/hda:
> Timing cached reads: 1260 MB in 2.00 seconds = 628.67 MB/sec
>
>
Here are three of mine (10,000 rpm SCSI drives); these are hdparm -Tt

#/sbin/hdparm -Tt /dev/sda
/dev/sda:
Timing cached reads: 1504 MB in 2.00 seconds = 751.59 MB/sec
Timing buffered disk reads: 222 MB in 3.00 seconds = 73.90 MB/sec

# /sbin/hdparm -Tt /dev/sdb
/dev/sdb:
Timing cached reads: 1576 MB in 2.00 seconds = 786.90 MB/sec
Timing buffered disk reads: 242 MB in 3.02 seconds = 80.26 MB/sec

# /sbin/hdparm -Tt /dev/sdc


/dev/sdc:
Timing cached reads: 1644 MB in 2.00 seconds = 821.45 MB/sec
Timing buffered disk reads: 150 MB in 3.00 seconds = 49.99 MB/sec

These drives are loaded populating a database at the moment, but sdb is
lightly loaded compared to the other two. These are all going at once.

--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 23:25:01 up 30 days, 2:47, 4 users, load average: 5.40, 5.30, 5.23

horizon wrote:
> I am putting together a barebones system with an AMD64 x2 and for right
> now am just testing various components in it and am using Debian Etch.
> With the Sata drive installed there are lots of problems that I haven't
> worked around yet, but there is no doubt that the machine is VERY fast.
> But when I install the IDE drive as the boot drive, the disk access is so
> slow that it is very obvious that there is a problem. REALLY slow,
> something like 1/10 the speed. Or to give an actual example, loading a
> large subdirectory from a USB drive onto the Sata took about 3 minutes.
> With the IDE installed the identical operation took over 40 minutes.

I once almost tried a side-by-side by adding an IDE but the socket was not
accessible without disassembling the case meaning I have no experience for
comparison on the same machine.

However it is not credible that either a serial or parallel internal could be
slower than a USB drive.

Also I have had a 1.5GHz machine with an older 40GB IDE and a 3GHz with a new
160 GB SATA working side by side with the same RH4 release and both with 512M
RAM. I never noticed a difference in the time to boot. I was not looking for one
but do pay enough attention that I could not have missed a factor of ten.

If you can give more detailed information on exactly how the IDE is mounted
including any DMA setting it might help. Check your BIOS to see the same options
are activated for both disks. Also a watched computer never boots. Use your
watch. Because of no side-by-side experience I have no boot times but SATA is
faster. See specs on both, google the manufacturer's specs. I don't keep spec
sheets around either.

> I have the same Etch on two other machines with IDE's and they are just as
> fast as the Sata, given the difference in CPU horsepower, so it is
> obvious, I think, that this Mobo doesn't like Linux and IDE.

However the buss has its own speed and is the usual bottleneck for internal
drives. Are they the same for both?

> It is a mini
> ITX that is for one of those small footprint machines like the Ice Cube
> but there is no name on it. lspci shows that the chipset is nvidia.

> Before I put this new Mobo on the shelf for trade to some winders dude,
> can anybody think of something to try?

Is there a reason you want to boot from the IDE? If it is a secondary drive
does it do things where transfer times matter? I mean put it together and solve
the problem later.

--
No one complained when Jews drove Palestinians into the sea.
-- The Iron Webmaster, 3858
nizkor http://www.giwersworld.org/nizkook/nizkook.phtml
Larry Shiff http://www.giwersworld.org/computers/newsagent.phtml a8

On 7 Sep, 17:35, horizon <bd...@heffdiffer45.com> wrote:
> I am putting together a barebones system with an AMD64 x2 and for right
> now am just testing various components in it and am using Debian Etch.
>
> With the Sata drive installed there are lots of problems that I haven't
> worked around yet, but there is no doubt that the machine is VERY fast.
>
> But when I install the IDE drive as the boot drive, the disk access is so
> slow that it is very obvious that there is a problem. REALLY slow,
> something like 1/10 the speed. Or to give an actual example, loading a
> large subdirectory from a USB drive onto the Sata took about 3 minutes.
> With the IDE installed the identical operation took over 40 minutes.

Hmmm. My working assumption is that your "hdparm" settings for your
IDE drive are mis-set. Most Linux setups boot, by default, with them
set to "hdparm -d0c0", which is an extremely conservative setting you
can boot 10 year old drives with. By resetting them *in your init
scripts* or in an appropriate /etc/sysconfig setting, it should be
possible to reset them to "-d1c1".

You also don't mention the make of your IDE or SATA drives. A lot of
older IDE drives, or especially of laptop drives common in blade
computers, have quite slow RPM's of 5400 or even 4200, and a lot of
modern SATA drives have RPM's of 10,000. This makes a quite noticeable
difference in seek times and transfer rates.


> I have the same Etch on two other machines with IDE's and they are just as
> fast as the Sata, given the difference in CPU horsepower, so it is
> obvious, I think, that this Mobo doesn't like Linux and IDE. It is a mini
> ITX that is for one of those small footprint machines like the Ice Cube
> but there is no name on it. lspci shows that the chipset is nvidia.

No, these are not side-by-side comparisons. Take a look at the hdparm
settings I mentioned, and if you want a real test, try swapping the
IDE drive to your other machines.

> Before I put this new Mobo on the shelf for trade to some winders dude,
> can anybody think of something to try?
>
> horizon

On Fri, 07 Sep 2007 18:35:00 +0200, horizon wrote:

> I am putting together a barebones system with an AMD64 x2 and for right
> now am just testing various components in it and am using Debian Etch.


Here they are. You'all hit the problem dead center.

hdparm /dev/hda
/dev/hda:
multcount = 0 (off)
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 0 (off)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 60801/255/63, sectors = 976773168, start = 0

hdparm -t /dev/hda
/dev/hda:
Timing buffered disk reads: 10 MB in 3.16 seconds = 3.16 MB/sec

hdparm -T /dev/hda
/dev/hda:
Timing cached reads: 2548 MB in 2.00 seconds = 1273.70 MB/sec

Shouldn't be a problem to fix this, but it brings up the question of why?
By the way, hdparm is not installed as part of the Debian installation.

I have probably installed Debian over a hundred times since my old Red Hat
days and have never had this come up. Wondering what there is on this
MoBo that makes Debian trigger all the HD settings off.

Thanks
horizon

On Sat, 08 Sep 2007, horizon wrote:

> Here they are. You'all hit the problem dead center.
>
> hdparm /dev/hda
> /dev/hda:
> multcount = 0 (off)

Ouch.

> IO_support = 0 (default 16-bit)

Ouch.

> unmaskirq = 0 (off)

Ouch again.

> using_dma = 0 (off)

Big ouch.

You get the idea.

--
Yves Bellefeuille
<yan@storm.ca>

On Fri, 07 Sep 2007 18:35:00 +0200, horizon wrote:

> I am putting together a barebones system with an AMD64 x2 and for right
> now am just testing various components in it and am using Debian Etch.

Turns out that the problem is that the Default Etch kernel (2.6.18)
doesn't recognise anything on this MoBo. Apparently it is really new. I
went to nvidia.org to download the Linux NFORCE drivers but there was a
statement saying that they are no longer provided because they are
included in all new kernel sources. They just didn't say which kernel
they started with.

So I downloaded 2.6.22 and it worked fine, although it took half the
night to compile with the IDE drive blinking once per source line. As I
said before, hdparm is not loaded on a default installation and I "think"
I remember - from way back - that some file in /etc/ states that Debian
uses something else for disk parameter management.

Apt-get loads hdparm just fine and it works from a query mode, but
changing hdparm.conf doesn't seem to do anything. Giving hdparm
commands at the command line does work. No big deal since the hdparm
output is the same as my other machines now - i.e. everything on that is
supposed to be on. Some day when I am just browsing, I will figure out
what is in charge of Debian disk management.

So I can use this machine with the IDE drive if I have to, but am still
working on the Sata which is a hard road so far.

Thanks for the help.

horizon

On 8 Sep, 21:29, horizon <bd...@heffdiffer45.com> wrote:
> On Fri, 07 Sep 2007 18:35:00 +0200, horizon wrote:
> > I am putting together a barebones system with an AMD64 x2 and for right
> > now am just testing various components in it and am using Debian Etch.
>
> Here they are. You'all hit the problem dead center.
>
> hdparm /dev/hda
> /dev/hda:
> multcount = 0 (off)
> IO_support = 0 (default 16-bit)
> unmaskirq = 0 (off)
> using_dma = 0 (off)
> keepsettings = 0 (off)
> readonly = 0 (off)
> readahead = 256 (on)
> geometry = 60801/255/63, sectors = 976773168, start = 0
>
> hdparm -t /dev/hda
> /dev/hda:
> Timing buffered disk reads: 10 MB in 3.16 seconds = 3.16 MB/sec
>
> hdparm -T /dev/hda
> /dev/hda:
> Timing cached reads: 2548 MB in 2.00 seconds = 1273.70 MB/sec
>
> Shouldn't be a problem to fix this, but it brings up the question of why?
> By the way, hdparm is not installed as part of the Debian installation.
>
> I have probably installed Debian over a hundred times since my old Red Hat
> days and have never had this come up. Wondering what there is on this
> MoBo that makes Debian trigger all the HD settings off.
>
> Thanks
> horizon

They do this, historically, for various reasons. There's an ld chunk
of the Linux kernel that sets defaults for this, and people have been
misreading it *for years* to think it would reboot the machine to
preserve the last set of device settings. Unfortunately, powering off
the machine resets them at boot time to the lowest possible
performance settings, in order to boot the oldest, most cantankerous
bits of old hardware. That makes it the job of the system
configurators to detect and set them more appropriately, and a lot of
such tools have never done this right or provided the options to reset
it properly.

RedHat used to put files for this in /etc/sysconfig that would get run
at boot time., which I thought made complete sense, but I don't have a
system in hand right now to check that with. The quick and dirty
option is to put it manually in /etc/rc.local, but there's nothing
wrong with a little init script to set this.