alt.os.linux - *Slow* disk performance, suggestions anyone?

Author

*Slow* disk performance, suggestions anyone?

Darren Best

2002-10-11, 9:24 pm

I'm reasonably new to Linux, so take it easy.

I have installed Linux before on an AMD K6/2-350 (that was SuSE 6.3),
and its performance was not terribly dissimilar to Windows 98SE.

I have a different (but still outdated) machine now. Its basic specs:
- PC Chips M599LMR motherboard (SiS 530 chipset, integrated video)
- AMD K6/2-450 cpu
- 256 MB PC100
- IBM 60GXP HD, 30GB (hda, three FAT32 partitions)
- IBM 120GXP HD, 80GB (hdb, two ReiserFS partitions + swap)

This machine, again, has Windows 98SE installed (but never Linux). I
installed Mandrake onto the second drive, and everything has gone
smoothly. EXCEPT everything is *very* slow. The OS and applications
take forever to load.

I had been rather "generous" with selecting packages to install. I
have since gone in and turned off some of the services I had
installed, but things have not changed noticably (if at all).

At first I (and others) chalked it up to insufficient hardware for the
new distribution. After all, I wouldn't expect WinXP to fly on this
machine. But then someone suggested I run hdparm to check my drive
performance. Here are my current settings (I included the Windows
drive (hda) to see if the filesystem made any difference, or if my
Linux drive (hdb) was somehow defective):
____

[root@localhost darren]# hdparm /dev/hda

/dev/hda:
multcount = 16 (on)
IO_support = 3 (32-bit w/sync)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 3737/255/63, sectors = 60036480, start = 0

[root@localhost darren]# hdparm /dev/hdb

/dev/hdb:
multcount = 16 (on)
IO_support = 3 (32-bit w/sync)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 10011/255/63, sectors = 160836480, start = 0
____

and here are the timing results:
____

[root@localhost darren]# hdparm -Tt /dev/hda

/dev/hda:
Timing buffer-cache reads: 128 MB in 11.04 seconds = 11.59 MB/sec
Timing buffered disk reads: 64 MB in 12.23 seconds = 5.23 MB/sec

[root@localhost darren]# hdparm -Tt /dev/hdb

/dev/hdb:
Timing buffer-cache reads: 128 MB in 11.14 seconds = 11.49 MB/sec
Timing buffered disk reads: 64 MB in 12.53 seconds = 5.11 MB/sec
____

From what I've seen on the web (and a couple of posters on this issue
a couple of days ago said in the alt.os.linux.mandrake group), these
results are WAY slow. Others with similar aged hardware and full
Mandrake 9.0 installs are showing far (like, 8x!!) better disk
performance.

So.... what could be causing this? I've done a search in Usenet and
the Web, but can't find any known performance issues between Linux and
IBM drives, or Linux and the SiS 530 chipset, or anything solid.

I will try to reinstall if someone can give me a GOOD reason why that
might help (like proof that a "standard" install would be guaranteed
to work much, much faster than a "custom" install). Similarly, I will
try a different distribution if you think there may be something about
specifically Mandrake and my hardware.

Please, no "get a better computer" comments. I want to know if I can
run a modern distro (with all the bloated KDE3/OO.o/OtherPrettyStuff
intact) on this hardware.

I'm looking forward to anyone's suggestions. Thanks in advance.

Dave Uhring

2002-10-11, 10:24 pm

Shyamal Prasad

2002-10-11, 10:24 pm

"Darren" == Darren Best <darren@sweetums.ca> writes:

Darren> From what I've seen on the web (and a couple of posters on
Darren> this issue a couple of days ago said in the
Darren> alt.os.linux.mandrake group), these results are WAY slow.
Darren> Others with similar aged hardware and full Mandrake 9.0
Darren> installs are showing far (like, 8x!!) better disk
Darren> performance.

Can't give you specific help, but try reading this:

http://linux.oreillynet.com/pub/a/l...arm.html?page=1

Cheers!

Wes Newell

2002-10-11, 11:24 pm

On Fri, 11 Oct 2002 20:58:55 -0500, Darren Best wrote:

> [root@localhost darren]# hdparm -Tt /dev/hda
>
> /dev/hda:
> Timing buffer-cache reads: 128 MB in 11.04 seconds = 11.59 MB/sec
> Timing buffered disk reads: 64 MB in 12.23 seconds = 5.23 MB/sec
>
> [root@localhost darren]# hdparm -Tt /dev/hdb
>
> /dev/hdb:
> Timing buffer-cache reads: 128 MB in 11.14 seconds = 11.49 MB/sec
> Timing buffered disk reads: 64 MB in 12.53 seconds = 5.11 MB/sec
> ____
> So.... what could be causing this? I've done a search in Usenet and the
> Web, but can't find any known performance issues between Linux and IBM
> drives, or Linux and the SiS 530 chipset, or anything solid.

One more thing. Run;
hdparm -i /dev/hd(x)
Need to see what mode it's running in.
You also might try turning 32bit IO off. I get much better performance
here with the default 16 bit. hdparm -c0 /dev/hd(x)

Richard James

2002-10-12, 3:24 am

Darren Best wrote:

> I'm reasonably new to Linux, so take it easy.
>
> I have installed Linux before on an AMD K6/2-350 (that was SuSE 6.3),
> and its performance was not terribly dissimilar to Windows 98SE.
>
> I have a different (but still outdated) machine now. Its basic specs:
> - PC Chips M599LMR motherboard (SiS 530 chipset, integrated video)
> - AMD K6/2-450 cpu
> - 256 MB PC100
> - IBM 60GXP HD, 30GB (hda, three FAT32 partitions)
> - IBM 120GXP HD, 80GB (hdb, two ReiserFS partitions + swap)
>
> This machine, again, has Windows 98SE installed (but never Linux). I
> installed Mandrake onto the second drive, and everything has gone
> smoothly. EXCEPT everything is *very* slow. The OS and applications
> take forever to load.
>
> I had been rather "generous" with selecting packages to install. I
> have since gone in and turned off some of the services I had
> installed, but things have not changed noticably (if at all).
>
> At first I (and others) chalked it up to insufficient hardware for the
> new distribution. After all, I wouldn't expect WinXP to fly on this
> machine. But then someone suggested I run hdparm to check my drive
> performance. Here are my current settings (I included the Windows
> drive (hda) to see if the filesystem made any difference, or if my
> Linux drive (hdb) was somehow defective):
> ____
>
> [root@localhost darren]# hdparm /dev/hda
>
> /dev/hda:
> multcount = 16 (on)
> IO_support = 3 (32-bit w/sync)
> unmaskirq = 1 (on)
> using_dma = 1 (on)
> keepsettings = 0 (off)
> readonly = 0 (off)
> readahead = 8 (on)
> geometry = 3737/255/63, sectors = 60036480, start = 0
>
> [root@localhost darren]# hdparm /dev/hdb
>
> /dev/hdb:
> multcount = 16 (on)
> IO_support = 3 (32-bit w/sync)
> unmaskirq = 1 (on)
> using_dma = 1 (on)
> keepsettings = 0 (off)
> readonly = 0 (off)
> readahead = 8 (on)
> geometry = 10011/255/63, sectors = 160836480, start = 0
> ____
>
> and here are the timing results:
> ____
>
> [root@localhost darren]# hdparm -Tt /dev/hda
>
> /dev/hda:
> Timing buffer-cache reads: 128 MB in 11.04 seconds = 11.59 MB/sec
> Timing buffered disk reads: 64 MB in 12.23 seconds = 5.23 MB/sec
>
> [root@localhost darren]# hdparm -Tt /dev/hdb
>
> /dev/hdb:
> Timing buffer-cache reads: 128 MB in 11.14 seconds = 11.49 MB/sec
> Timing buffered disk reads: 64 MB in 12.53 seconds = 5.11 MB/sec
> ____
>
> From what I've seen on the web (and a couple of posters on this issue
> a couple of days ago said in the alt.os.linux.mandrake group), these
> results are WAY slow. Others with similar aged hardware and full
> Mandrake 9.0 installs are showing far (like, 8x!!) better disk
> performance.
>
> So.... what could be causing this? I've done a search in Usenet and
> the Web, but can't find any known performance issues between Linux and
> IBM drives, or Linux and the SiS 530 chipset, or anything solid.
>
> I will try to reinstall if someone can give me a GOOD reason why that
> might help (like proof that a "standard" install would be guaranteed
> to work much, much faster than a "custom" install). Similarly, I will
> try a different distribution if you think there may be something about
> specifically Mandrake and my hardware.
>
> Please, no "get a better computer" comments. I want to know if I can
> run a modern distro (with all the bloated KDE3/OO.o/OtherPrettyStuff
> intact) on this hardware.
>
> I'm looking forward to anyone's suggestions. Thanks in advance.

Man there is slow, there is the speed of a dead dog and then there is that
computer of yours.

It could be the IDE controller or most likley you need to tune Linux

Make sure that in your kernel under IDE, ATA and ATAPI you have selected
SiS5513 chipset support. I believe this should offer a remarkable
improvment to that system.

Here are the stats for my machine running on a ASUS A7V133 Motherboard
This is using a Promise Raid Controller as the IDE controller on the
motherboard.

PDC20265: chipset revision 2
PDC20265: not 100% native mode: will probe irqs later
PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
ide0: BM-DMA at 0x8400-0x8407, BIOS settings: hda

io, hdb

io
ide1: BM-DMA at 0x8408-0x840f, BIOS settings: hdc

io, hdd

io

/dev/hda IBM-DPTA-372050
/dev/hdb IBM-DTLA-307015

These are 20GB and 15GB drives older that the ones you have

root@wildfire:/# hdparm -Tt /dev/hda /dev/hdb

/dev/hda:
Timing buffer-cache reads: 128 MB in 0.68 seconds =188.24 MB/sec
Timing buffered disk reads: 64 MB in 2.86 seconds = 22.38 MB/sec

/dev/hdb:
Timing buffer-cache reads: 128 MB in 0.69 seconds =185.51 MB/sec
Timing buffered disk reads: 64 MB in 1.80 seconds = 35.56 MB/sec

And here are my HDparm settings

root@wildfire:/# hdparm /dev/hda /dev/hdb

/dev/hda:
multcount = 0 (off)
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 2495/255/63, sectors = 40088160, start = 0

/dev/hdb:
multcount = 0 (off)
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 1867/255/63, sectors = 30003120, start = 0

Ricahrd

--
Again they chanted RTFM, RTFM, then one of the bozos who I was later to find
out was a Archbozo, he grabbed a large manual off the wall and beganeth to
club me unto death with it. -- Book Of the Newbie Chapter 1 --

Jim Townsend

2002-10-12, 3:24 am

Darren Best

2002-10-12, 1:24 pm

Shyamal Prasad <shyamal.prasad@sbcglobal.net> wrote in message news:<87d6qggy42.fsf@rattler-faked-dsl.sbcglobal.net>...
> "Darren" == Darren Best <darren@sweetums.ca> writes:
>
> Darren> From what I've seen on the web (and a couple of posters on
> Darren> this issue a couple of days ago said in the
> Darren> alt.os.linux.mandrake group), these results are WAY slow.
> Darren> Others with similar aged hardware and full Mandrake 9.0
> Darren> installs are showing far (like, 8x!!) better disk
> Darren> performance.
>
> Can't give you specific help, but try reading this:
>
> http://linux.oreillynet.com/pub/a/l...arm.html?page=1
>
> Cheers!

That's actually the same link to where I learned that I probably have
a problem!

Following their suggestions gave me a minimal performance boost, but
nothing too noticable. Thanks, though!

Darren Best

2002-10-12, 1:24 pm

Dave Uhring <dmuhring@yahoo.com> wrote in message news:<uqf3ds6a94rs96@corp.supernews.com>...
>
> It does not matter how fast a hard drive you attach to a slow IDE
> controller. The data rate is going to be limited by the capability of
> that controller. And the IDE controller is a part of your motherboard.
>
> You can install an aftermarket PCI IDE controller with the same
> capability as your drives and gain the read/write speed which you seek.
> A re-install will be the easiest way to accomplish your objective.

The SiS 530 chipset supports UDMA 66, while the IBM drives are Ultra
ATA-100 drives. Is the SiS controller (only one generation behind)
going to really be *that* much slower than the newer controllers?

I'm not arguing just for the sake of arguing. I just have no cash to
purchase more hardware right now. Thanks for the input.

Darren Best

2002-10-12, 2:24 pm

Richard James <thisemailwontwork@all.will.it> wrote in message news:<fgi8oa.k0d.ln@server.techdrive.foo>...

> Man there is slow, there is the speed of a dead dog and then there is that
> computer of yours.

Gee, thanks ;-)

> It could be the IDE controller or most likley you need to tune Linux
>
> Make sure that in your kernel under IDE, ATA and ATAPI you have selected
> SiS5513 chipset support. I believe this should offer a remarkable
> improvment to that system.

Could you please direct me to where I could be shown how to do this?
As I originally stated, I am newish to Linux and the kernel is a
strange, mysterious place!!

> Here are the stats for my machine running on a ASUS A7V133 Motherboard
> This is using a Promise Raid Controller as the IDE controller on the
> motherboard.
>
> PDC20265: chipset revision 2
> PDC20265: not 100% native mode: will probe irqs later
> PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
> ide0: BM-DMA at 0x8400-0x8407, BIOS settings: hda

io, hdb

io
> ide1: BM-DMA at 0x8408-0x840f, BIOS settings: hdc

io, hdd

io
>
> /dev/hda IBM-DPTA-372050
> /dev/hdb IBM-DTLA-307015
>
> These are 20GB and 15GB drives older that the ones you have
>
> root@wildfire:/# hdparm -Tt /dev/hda /dev/hdb
>
> /dev/hda:
> Timing buffer-cache reads: 128 MB in 0.68 seconds =188.24 MB/sec
> Timing buffered disk reads: 64 MB in 2.86 seconds = 22.38 MB/sec
>
> /dev/hdb:
> Timing buffer-cache reads: 128 MB in 0.69 seconds =185.51 MB/sec
> Timing buffered disk reads: 64 MB in 1.80 seconds = 35.56 MB/sec
>
>
> And here are my HDparm settings
>
> root@wildfire:/# hdparm /dev/hda /dev/hdb
>
> /dev/hda:
> multcount = 0 (off)
> IO_support = 0 (default 16-bit)
> unmaskirq = 0 (off)
> using_dma = 1 (on)
> keepsettings = 0 (off)
> readonly = 0 (off)
> readahead = 8 (on)
> geometry = 2495/255/63, sectors = 40088160, start = 0
>
> /dev/hdb:
> multcount = 0 (off)
> IO_support = 0 (default 16-bit)
> unmaskirq = 0 (off)
> using_dma = 1 (on)
> keepsettings = 0 (off)
> readonly = 0 (off)
> readahead = 8 (on)
> geometry = 1867/255/63, sectors = 30003120, start = 0
>
> Ricahrd

An earlier poster suggested the age of my controller (and, I suppose,
its support from within Linux) might have something to do with my
performance. You have insinuated the same thing. You appear to have
a recent RAID controller, so that may bear out this theory.

Perhaps the Mandrake 9.0 kernel (and its default kernel optimizations)
is such that my older chipset is not supported for high performance?
Mandrake's web site seems to be rather skimpy on technical details but
at thier hardware compatibility page they claim support for SiS 630
and 735 chipsets, not the 530.

You may be on to something. If support for this chipset could be
included into my kernel, performance should be much better, should it
now? As I said above, I have NO idea how to do this. If you could
please advise, I would be very grateful. Thanks.

Juha Laiho

2002-10-12, 3:24 pm

darren@sweetums.ca (Darren Best) said:
>I have installed Linux before on an AMD K6/2-350 (that was SuSE 6.3),
>and its performance was not terribly dissimilar to Windows 98SE.
>
>I have a different (but still outdated) machine now. Its basic specs:
>- PC Chips M599LMR motherboard (SiS 530 chipset, integrated video)
>- AMD K6/2-450 cpu
>- 256 MB PC100
>- IBM 60GXP HD, 30GB (hda, three FAT32 partitions)
>- IBM 120GXP HD, 80GB (hdb, two ReiserFS partitions + swap)

I'm starting to suspect it's your video adapter that is using up your
memory bandwidth. See:

>[root@localhost darren]# hdparm -Tt /dev/hda
>
>/dev/hda:
> Timing buffer-cache reads: 128 MB in 11.04 seconds = 11.59 MB/sec

This isn't coming from your disks. It isn't coming from your IDE
adapter. It's right from the OS buffer cache (i.e. RAM).

Compared to results from a 150MHz Pentium:

# hdparm -tT /dev/sda

/dev/sda:
Timing buffer-cache reads: 128 MB in 5.07 seconds =25.25 MB/sec

So, it's not your disk subsystem that is giving you pain (my disk
transfer results are slower than yours!), but your memory transfer
rate. With the CPU you have, I think your memory transfer rate should
easily exceed 50 MB/s.

If you were in X (graphics) when you ran that test, try switching into
text mode and re-running the test from there. If you get different
results, this proves that the root cause is that your display adapter
is one of those that use your system RAM as display adapter RAM -- which
completely hogs your memory bandwidth when in graphics mode.

To help the situation a little bit, you can switch to lower resolution
and depth (amount of colors). Unfortunately, to truly correct the
situation, you'll need to get a real graphics adapter. For that machine,
I think something like Matrox Millennium II or Matrox G200 might be
well-balanced choices -- and those should be available second-hand at
reasonable prices (and also, their picture quality is very good).
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)

PeteVine

2002-10-12, 3:24 pm

On Sat, 12 Oct 2002 07:25:01 +0000, Richard James tremente scripsit manu:

> And here are my HDparm settings
>
> root@wildfire:/# hdparm /dev/hda /dev/hdb
>
> /dev/hda:
> multcount = 0 (off)
> IO_support = 0 (default 16-bit)
> unmaskirq = 0 (off)
> using_dma = 1 (on)
> keepsettings = 0 (off)
> readonly = 0 (off)
> readahead = 8 (on)
> geometry = 2495/255/63, sectors = 40088160, start = 0

You could gain some performance from turning multiple sector I/O on.
You should check your disks with hdparm -i to see how many secors per I/O
are supported and then enable multcount with -m option.

--
PeteVine
10:03pm up 6 days, 1:34, 4 users, load average: 1.01, 1.11, 1.12
64 processes: 60 sleeping, 4 running, 0 zombie, 0 stopped
CPU states: 16.6% user, 2.9% system, 80.3% nice, 0.0% idle

Linux registered user #250250
http://counter.li.org

n1pop

2002-10-12, 4:24 pm

I can't help fix your issue, but I can provide a data point for those
who would too quickly blame the hardware. Here is my legacy system:

Intel 440BX mobo, Intel Celeron 300 CPU
- 96MB RAM (your standard issue 136-pin SIMMS)
- Maxtor 40GB HD as /dev/hda, truncated to 32GB due to BIOS limitation
- Maxtor 13GB HD as /dev/hdb - Internal 100MB ZIP as /dev/hdd4
- HP CD-Writer+ 8200a as /dev/hdc
- USB 40MB pocket Zip as /dev/sda4
- Cirrus CL500d PCI video (OEM)
- ESS 1869 ISA audio (OEM)
- Creative Flash56i modem (controller-based)

This is a circa 1998 motherboard and original CPU.

Here's my hdparm output:

:hdparm /dev/hda
/dev/hda:
multcount = 16 (on)
I/O support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 4111/255/63, sectors = 66055248, start = 0 busstate = 1
(on)

:hdparm /dev/hdb
/dev/hdb:
multcount = 16 (on)
I/O support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 1661/255/63, sectors = 26684784, start = 0 busstate = 1
(on)

:hdparm -Tt /dev/hda
/dev/hda:
Timing buffer-cache reads: 128 MB in 1.89 seconds = 67.72 MB/sec
Timing buffered disk reads: 64 MB in 2.90 seconds = 22.07 MB/sec

:hdparm -Tt /dev/hdb
/dev/hdb:
Timing buffer-cache reads: 128 MB in 2.03 seconds = 63.05 MB/sec
Timing buffered disk reads: 64 MB in 2.87 seconds = 22.30 MB/sec

Hope this helps.

Dave Uhring

2002-10-12, 5:24 pm

Darren Best wrote:

> Dave Uhring <dmuhring@yahoo.com> wrote in message
> news:<uqf3ds6a94rs96@corp.supernews.com>...
>>
>> It does not matter how fast a hard drive you attach to a slow IDE
>> controller. The data rate is going to be limited by the capability
>> of
>> that controller. And the IDE controller is a part of your
>> motherboard.
>>
>> You can install an aftermarket PCI IDE controller with the same
>> capability as your drives and gain the read/write speed which you
>> seek. A re-install will be the easiest way to accomplish your
>> objective.
>
> The SiS 530 chipset supports UDMA 66, while the IBM drives are Ultra
> ATA-100 drives. Is the SiS controller (only one generation behind)
> going to really be *that* much slower than the newer controllers?
>
> I'm not arguing just for the sake of arguing. I just have no cash to
> purchase more hardware right now. Thanks for the input.

You probably do not have CONFIG_BLK_DEV_SIS5513 set in your kernel, thus
the kernel you are using likely does not know how to deal with your IDE
controller. So you might try building a new kernel with specific
support for that chipset.

http://www.ibiblio.org/pub/Linux/do...rnel-HOWTO.html

Richard James

2002-10-12, 11:24 pm

Darren Best wrote:

> An earlier poster suggested the age of my controller (and, I suppose,
> its support from within Linux) might have something to do with my
> performance. You have insinuated the same thing. You appear to have
> a recent RAID controller, so that may bear out this theory.
>
> Perhaps the Mandrake 9.0 kernel (and its default kernel optimizations)
> is such that my older chipset is not supported for high performance?
> Mandrake's web site seems to be rather skimpy on technical details but
> at thier hardware compatibility page they claim support for SiS 630
> and 735 chipsets, not the 530.
>
> You may be on to something. If support for this chipset could be
> included into my kernel, performance should be much better, should it
> now? As I said above, I have NO idea how to do this. If you could
> please advise, I would be very grateful. Thanks.

I'd say the problem most likley is that your kernel is not compiled for
support for the chipset. As Dave Uhring said you need that compiled in.
Unfortunatley I know squat about mandrake begin a slackware user. Here is
how I would do it in Slackware

Open up a terminal
Change to root using su
su -
cd /usr/src/linux
make menuconfig
Press the down key until ATA/IDE/MFM/RLL support is highlighted
press enter
Select IDE, ATA, and ATAPI Block Devices
press enter
Make sure generic PCI IDE chipset support is compiled in
it should look like this [*]
Go down to SiS5513 chipset support and press the space bar until the box on
the left looks like [*] this means it will be built into the kernel
Press the Right arrow and select exit (Do this three times)
When prompted for saving the new kernel configuration press enter on yes
When back at the command prompt type
make install
when it is finished reboot the computer

I dunno if this is exactly how you would do it in Mandrake though

Richard

Darren Best

2002-10-12, 11:24 pm

Wes Newell <w.newell@verizon.net> wrote in message news:<qCMp9.3822$qb.1513@nwrddc01.gnilink.net>...
> On Fri, 11 Oct 2002 20:58:55 -0500, Darren Best wrote:
>
> > [root@localhost darren]# hdparm -Tt /dev/hda
> >
> > /dev/hda:
> > Timing buffer-cache reads: 128 MB in 11.04 seconds = 11.59 MB/sec
> > Timing buffered disk reads: 64 MB in 12.23 seconds = 5.23 MB/sec
> >
> > [root@localhost darren]# hdparm -Tt /dev/hdb
> >
> > /dev/hdb:
> > Timing buffer-cache reads: 128 MB in 11.14 seconds = 11.49 MB/sec
> > Timing buffered disk reads: 64 MB in 12.53 seconds = 5.11 MB/sec
> > ____
> > So.... what could be causing this? I've done a search in Usenet and the
> > Web, but can't find any known performance issues between Linux and IBM
> > drives, or Linux and the SiS 530 chipset, or anything solid.
>
> One more thing. Run;
> hdparm -i /dev/hd(x)
> Need to see what mode it's running in.

Here's what came out of hdb:

/dev/hdb:

Model=IC35L080AVVA07-0, FwRev=VA4OA52A, SerialNo=VNC402A4C8ASNA
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=52
BuffType=DualPortCache, BuffSize=1863kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=160836480
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 *udma2 udma3 udma4 udma5
AdvancedPM=yes: disabled (255) WriteCache=enabled
Drive conforms to: ATA/ATAPI-5 T13 1321D revision 1: 2 3 4 5

> You also might try turning 32bit IO off. I get much better performance
> here with the default 16 bit. hdparm -c0 /dev/hd(x)

Made essentially no difference :-(

Thanks for the suggestions, I'll continue with some of the others listed below.

Wes Newell

2002-10-13, 12:24 am

On Sat, 12 Oct 2002 13:46:55 -0500, Darren Best wrote:
> Perhaps the Mandrake 9.0 kernel (and its default kernel optimizations)
> is such that my older chipset is not supported for high performance?
> Mandrake's web site seems to be rather skimpy on technical details but
> at thier hardware compatibility page they claim support for SiS 630 and
> 735 chipsets, not the 530.
>
> You may be on to something. If support for this chipset could be
> included into my kernel, performance should be much better, should it
> now? As I said above, I have NO idea how to do this. If you could
> please advise, I would be very grateful. Thanks.

You're off base. Support is in the kernel for the 530 chipset. If you
want to see it, make sure you have the sources loaded. su to root, cd
/usr/src/linux, and run "make xconfig". You should be able to find it
from there. it's about 3 or 4 levels deep in the IDE controller section.

Wes Newell

2002-10-13, 12:24 am

On Sat, 12 Oct 2002 23:07:42 -0500, Darren Best wrote:

> Wes Newell <w.newell@verizon.net> wrote in message
> news:<qCMp9.3822$qb.1513@nwrddc01.gnilink.net>...
>> On Fri, 11 Oct 2002 20:58:55 -0500, Darren Best wrote:
>>
>> > [root@localhost darren]# hdparm -Tt /dev/hda
>> >
>> > /dev/hda:
>> > Timing buffer-cache reads: 128 MB in 11.04 seconds = 11.59 MB/sec
>> > Timing buffered disk reads: 64 MB in 12.23 seconds = 5.23 MB/sec
>> >
>> > [root@localhost darren]# hdparm -Tt /dev/hdb
>> >
>> > /dev/hdb:
>> > Timing buffer-cache reads: 128 MB in 11.14 seconds = 11.49 MB/sec
>> > Timing buffered disk reads: 64 MB in 12.53 seconds = 5.11 MB/sec
>> > ____
>> > So.... what could be causing this? I've done a search in Usenet and
>> > the Web, but can't find any known performance issues between Linux
>> > and IBM drives, or Linux and the SiS 530 chipset, or anything solid.
>>
>> One more thing. Run;
>> hdparm -i /dev/hd(x)
>> Need to see what mode it's running in.
>
> Here's what came out of hdb:
>
> /dev/hdb:
>
> Model=IC35L080AVVA07-0, FwRev=VA4OA52A, SerialNo=VNC402A4C8ASNA
> Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
> RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=52
> BuffType=DualPortCache, BuffSize=1863kB, MaxMultSect=16, MultSect=16
> CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=160836480
> IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120} PIO
> modes: pio0 pio1 pio2 pio3 pio4
> DMA modes: mdma0 mdma1 mdma2
> UDMA modes: udma0 udma1 *udma2 udma3 udma4 udma5 AdvancedPM=yes:
> disabled (255) WriteCache=enabled Drive conforms to: ATA/ATAPI-5 T13
> 1321D revision 1: 2 3 4 5

This shows you running at udma2, or sometimews called udma 33, ata33,
whatever. Anyway, are you using 80 wire cables?
This is strange. I just installed 9.0 on a sis chipset board this
afternoon and I was meaning to look at the settings, but I forgot since
everything was running fine.
Anyway, I looked at the kernel, and assumming you're running the
stanbdard kernel, support for the sis530 is there. Really strange.

Darren Best

2002-10-13, 12:24 am

Juha Laiho <Juha.Laiho@iki.fi> wrote in message news:<ao9tcc$hl2$1@ichaos.ichaos-int>...

> I'm starting to suspect it's your video adapter that is using up your
> memory bandwidth. See:
>
> >[root@localhost darren]# hdparm -Tt /dev/hda
> >
> >/dev/hda:
> > Timing buffer-cache reads: 128 MB in 11.04 seconds = 11.59 MB/sec
>
> This isn't coming from your disks. It isn't coming from your IDE
> adapter. It's right from the OS buffer cache (i.e. RAM).
>
> Compared to results from a 150MHz Pentium:
>
> # hdparm -tT /dev/sda
>
> /dev/sda:
> Timing buffer-cache reads: 128 MB in 5.07 seconds =25.25 MB/sec
>
> So, it's not your disk subsystem that is giving you pain (my disk
> transfer results are slower than yours!), but your memory transfer
> rate. With the CPU you have, I think your memory transfer rate should
> easily exceed 50 MB/s.
>
> If you were in X (graphics) when you ran that test, try switching into
> text mode and re-running the test from there. If you get different
> results, this proves that the root cause is that your display adapter
> is one of those that use your system RAM as display adapter RAM -- which
> completely hogs your memory bandwidth when in graphics mode.
>
> To help the situation a little bit, you can switch to lower resolution
> and depth (amount of colors). Unfortunately, to truly correct the
> situation, you'll need to get a real graphics adapter. For that machine,
> I think something like Matrox Millennium II or Matrox G200 might be
> well-balanced choices -- and those should be available second-hand at
> reasonable prices (and also, their picture quality is very good).

Maybe you're on to something (and thanks for clueing me in on the
difference between the results). I changed inittab to boot to
runlevel 3, and tried hdparm again. The results were a buffer cache
rate of about 43.3 MB/s, and a buffered disk rate of about 18.4 MB/s,
a tremendous increase for both, but perhaps not as much as you
expected.

If I understand you correctly, if I were to use a cheap accelerated
PCI video card (sorry, no AGP slot), then its use of on-board memory
would reduce or eliminate the bottleneck I am experiencing. But
before I spend any money, I'd like to know that this will actually
happen. In your post (I assume that you have a separate,
non-integrated video card on your P150), you did not say if *you* ran
hdparm while in runlevel 3, or if you had a hefty desktop envirnment
running. Perhaps you will run into the same level of performance
degradation on your system as I do on mine! Or, put another way, will
I see the buffer cache reads go back down again once I start KDE with
the new card installed?

I guess I just want to be sure that the problem isn't primarily in
Mandrake's ability to access my hardware (perhaps with non-optimized
kernel settings), rather than the hardware itself. Thanks for your
response, and I look forward to your next reply.

Oh, BTW, the hefty KDE is required: If I can't make the desktop look
good *and* be responsive, the wife won't let me blast away the Windows
partitions ;-)

Peter T. Breuer

2002-10-13, 3:24 am

In alt.os.linux Wes Newell <w.newell@verizon.net> wrote:
> On Sat, 12 Oct 2002 13:46:55 -0500, Darren Best wrote:
>> Perhaps the Mandrake 9.0 kernel (and its default kernel optimizations)
>> is such that my older chipset is not supported for high performance?
>> Mandrake's web site seems to be rather skimpy on technical details but
>> at thier hardware compatibility page they claim support for SiS 630 and
>> 735 chipsets, not the 530.

> You're off base. Support is in the kernel for the 530 chipset. If you

How do you know?

> want to see it, make sure you have the sources loaded. su to root, cd
> /usr/src/linux, and run "make xconfig". You should be able to find it

This is nonsense. That shows him Linus's config, not the config of his
running kernel! He has to find the .config for his running kernel
(it'll be in the kernel rpm) and examine that.

> from there. it's about 3 or 4 levels deep in the IDE controller section.

It's a possibility, not a fact.

Peter

Juha Laiho

2002-10-13, 8:24 am

darren@sweetums.ca (Darren Best) said:
>If I understand you correctly, if I were to use a cheap accelerated
>PCI video card (sorry, no AGP slot), then its use of on-board memory
>would reduce or eliminate the bottleneck I am experiencing. But
>before I spend any money, I'd like to know that this will actually
>happen.

It'll eliminate the bottleneck, I'd claim. But I understand your need
for the certainity in this case. Unfortunately I don't have first-hand
experience on these, as I've strived to avoid integrated-anything.

I remember having a discussion similar to this, but cannot remember
when, you might like to check google for my articles containing word
'hdparm'. Even that'll get you quite a number to sift through, but there
you might also find some more information on what were the effects.

>In your post (I assume that you have a separate, non-integrated video
>card on your P150),

Yes.

>you did not say if *you* ran hdparm while in runlevel 3, or if you had
>a hefty desktop envirnment running.

I ran that in text mode - sorry for omitting that information. While
writing my previous response, I did realise that I need to re-check
my own performance under X as well (though my window manager is
minimalistic). The results were so close (within 10%) that I just
ignored this aspect. But I agree; I should've reported both of these
results. Here's one set run from within an X session
(1024x768@32bits/pixel, 76Hz refresh):

/dev/sda:
Timing buffer-cache reads: 128 MB in 4.97 seconds =25.75 MB/sec
Timing buffered disk reads: 64 MB in 20.44 seconds = 3.13 MB/sec

Actually changing the runlevel was overkill (but I understand that
that might've been the first choice to find how to get out of a X
session). You should see the difference even while X is running
(but you just switch out of the X session). This switching can be
done with Ctrl-Alt-F1. You'll get back with Alt-F[something];
probably something like Alt-F7 or Alt-F8; just start from Alt-F2
and keep switching until you find your X session.

>Perhaps you will run into the same level of performance degradation
>on your system as I do on mine! Or, put another way, will I see the
>buffer cache reads go back down again once I start KDE with the new
>card installed?

As I said, to me this seems an issue with needed memory bandwidth - and
with the architecture where an integrated display adapter uses part of
the system main memory as the display memory. To produce a high-
resolution image at a high colour depth and at an acceptable refresh
rate, the display processor will need data at a rather enormous speed.

(at this point, please try to verify that my assumption that your
system is architected this way - i.e. that the machine doesn't have
separate display memory - is correct. I just made this deduction based
on your hdparm results and your other system specs)

Calculating from my above screen mode:
There are 1024x768 pixels. Each pixel takes up 32 bits (4 bytes). Each
pixel is redrawn 76 times per second. This means that the display
processor must read 1024x768x4x76 bytes per second from the display
memory. This is 768x4x76 kbytes, i.e. 233472 kbytes - or 228 megabytes.
Per second. Each second, continuously.

To get the idea about this speed, compare it with the bandwidth of
the regular PCI bus: 32 bits parallel with 33 MHz clock.
4 * 33 (132) megabytes/second. Another comparision point would be the
system memory bandwidth on my other machine (PIII@866MHz, Windows);
at least one tool reports that at somewhere bit over 300MBytes/sec
(thus a bit over what would be required for the above display mode).

The message I'm trying to give here is that memory speeds required
by decent resolutions and colour depths are just huge. This is why
display adapters have "always" had their own memory: the system
memory (or the bus used to access system memory) has always been too
slow.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)

Littlefish

2002-10-13, 9:24 am

Shut down Qmail in services and watch the speed increase. PC Chips MB
are slow anyway! Shut down unwanted services. this means they are still
installed but not running.
Littlefish
"Darren Best" <darren@sweetums.ca> wrote in message
news:71f7ce7.0210111758.7062f5c7@posting.google.com...
> I'm reasonably new to Linux, so take it easy.
>
> I have installed Linux before on an AMD K6/2-350 (that was SuSE 6.3),
> and its performance was not terribly dissimilar to Windows 98SE.
>
> I have a different (but still outdated) machine now. Its basic specs:
> - PC Chips M599LMR motherboard (SiS 530 chipset, integrated video)
> - AMD K6/2-450 cpu
> - 256 MB PC100
> - IBM 60GXP HD, 30GB (hda, three FAT32 partitions)
> - IBM 120GXP HD, 80GB (hdb, two ReiserFS partitions + swap)
>
> This machine, again, has Windows 98SE installed (but never Linux). I
> installed Mandrake onto the second drive, and everything has gone
> smoothly. EXCEPT everything is *very* slow. The OS and applications
> take forever to load.
>
> I had been rather "generous" with selecting packages to install. I
> have since gone in and turned off some of the services I had
> installed, but things have not changed noticably (if at all).
>
> At first I (and others) chalked it up to insufficient hardware for the
> new distribution. After all, I wouldn't expect WinXP to fly on this
> machine. But then someone suggested I run hdparm to check my drive
> performance. Here are my current settings (I included the Windows
> drive (hda) to see if the filesystem made any difference, or if my
> Linux drive (hdb) was somehow defective):
> ____
>
> [root@localhost darren]# hdparm /dev/hda
>
> /dev/hda:
> multcount = 16 (on)
> IO_support = 3 (32-bit w/sync)
> unmaskirq = 1 (on)
> using_dma = 1 (on)
> keepsettings = 0 (off)
> readonly = 0 (off)
> readahead = 8 (on)
> geometry = 3737/255/63, sectors = 60036480, start = 0
>
> [root@localhost darren]# hdparm /dev/hdb
>
> /dev/hdb:
> multcount = 16 (on)
> IO_support = 3 (32-bit w/sync)
> unmaskirq = 1 (on)
> using_dma = 1 (on)
> keepsettings = 0 (off)
> readonly = 0 (off)
> readahead = 8 (on)
> geometry = 10011/255/63, sectors = 160836480, start = 0
> ____
>
> and here are the timing results:
> ____
>
> [root@localhost darren]# hdparm -Tt /dev/hda
>
> /dev/hda:
> Timing buffer-cache reads: 128 MB in 11.04 seconds = 11.59 MB/sec
> Timing buffered disk reads: 64 MB in 12.23 seconds = 5.23 MB/sec
>
> [root@localhost darren]# hdparm -Tt /dev/hdb
>
> /dev/hdb:
> Timing buffer-cache reads: 128 MB in 11.14 seconds = 11.49 MB/sec
> Timing buffered disk reads: 64 MB in 12.53 seconds = 5.11 MB/sec
> ____
>
> From what I've seen on the web (and a couple of posters on this issue
> a couple of days ago said in the alt.os.linux.mandrake group), these
> results are WAY slow. Others with similar aged hardware and full
> Mandrake 9.0 installs are showing far (like, 8x!!) better disk
> performance.
>
> So.... what could be causing this? I've done a search in Usenet and
> the Web, but can't find any known performance issues between Linux and
> IBM drives, or Linux and the SiS 530 chipset, or anything solid.
>
> I will try to reinstall if someone can give me a GOOD reason why that
> might help (like proof that a "standard" install would be guaranteed
> to work much, much faster than a "custom" install). Similarly, I will
> try a different distribution if you think there may be something about
> specifically Mandrake and my hardware.
>
> Please, no "get a better computer" comments. I want to know if I can
> run a modern distro (with all the bloated KDE3/OO.o/OtherPrettyStuff
> intact) on this hardware.
>
> I'm looking forward to anyone's suggestions. Thanks in advance.

Darren Best

2002-10-13, 12:24 pm

"Peter T. Breuer" <ptb@oboe.it.uc3m.es> wrote in message news:<007boa.7s4.ln@news.it.uc3m.es>...

> running kernel! He has to find the .config for his running kernel
> (it'll be in the kernel rpm) and examine that.

Peter, I am admittedly newish to Linux and most definately not
familiar with manipulating the kernel. Can you point me to any guides
that explain how I might do what you propose above (even better if it
refers specifically to Mandrake 9.0). Thanks.

Darren Best

2002-10-13, 1:24 pm

Wes Newell <w.newell@verizon.net> wrote in message news:<Nj7q9.2753$dc.874@nwrddc04.gnilink.net>...
[colo
r=darkred]
> >> One more thing. Run;
> >> hdparm -i /dev/hd(x)
> >> Need to see what mode it's running in.
> >
> > Here's what came out of hdb:
> >
> > /dev/hdb:
> >
> > Model=IC35L080AVVA07-0, FwRev=VA4OA52A, SerialNo=VNC402A4C8ASNA
> > Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
> > RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=52
> > BuffType=DualPortCache, BuffSize=1863kB, MaxMultSect=16, MultSect=16
> > CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=160836480
> > IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120} PIO
> > modes: pio0 pio1 pio2 pio3 pio4
> > DMA modes: mdma0 mdma1 mdma2
> > UDMA modes: udma0 udma1 *udma2 udma3 udma4 udma5 AdvancedPM=yes:
> > disabled (255) WriteCache=enabled Drive conforms to: ATA/ATAPI-5 T13
> > 1321D revision 1: 2 3 4 5
>
> This shows you running at udma2, or sometimews called udma 33, ata33,
> whatever. Anyway, are you using 80 wire cables?[/color]

Yep, standard 80-wire IDE cables, both drives running master and slave
off the primary controller, with a CD-RW drive as master on the
secondary controller.

> This is strange. I just installed 9.0 on a sis chipset board this
> afternoon and I was meaning to look at the settings, but I forgot since
> everything was running fine.
> Anyway, I looked at the kernel, and assumming you're running the
> stanbdard kernel, support for the sis530 is there. Really strange.

How did you do this (ie. "look at the kernel" to see support for the
SiS 530)? As I said before, I'm new to fine-tuning Linux performance,
and not only do I not know how to check things in the kernel, I find
the idea of mucking around in there a bit scary :-) Any "plain
English" guides to this topic? Or could you run down (point-by-point)
the steps you took to do what you did (since you have a similar
system). Thanks.

Darren Best

2002-10-13, 1:24 pm

Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote in message news:<3skaoa.dt3.ln@ix.netcom.com>...
> Darren Best fed this fish to the penguins on Saturday 12 October 2002
> 11:22 am:
>
> >
> > The SiS 530 chipset supports UDMA 66, while the IBM drives are
>
> UDMA 66 system here too -- 733MHz PIII, RDRAM
>
> Ultra/dev/hdb:
> multcount = 16 (on)
> I/O support = 3 (32-bit w/sync)
> unmaskirq = 0 (off)
> using_dma = 1 (on)
> keepsettings = 1 (on)
> nowerr = 0 (off)
> readonly = 0 (off)
> readahead = 8 (on)
> geometry = 4982/255/63, sectors = 80043264, start = 0
> Timing buffer-cache reads: 128 MB in 0.66 seconds =193.94 MB/sec
> Timing buffered disk reads: 64 MB in 1.76 seconds = 36.36 MB/sec
>
>
> -c0 (16 bit default) gets me 188.xx/36.xx

Someone below (Juha Laiho) in this thread mentioned the possibility of
my integrated video having something to do with my performance (see
his comment and my response below). What do have for a video card in
your system? Did you run hdparm with X shutdown or with a desktop
environment running?

Peter T. Breuer

2002-10-13, 1:24 pm

In alt.os.linux Darren Best <darren@sweetums.ca> wrote:
> "Peter T. Breuer" <ptb@oboe.it.uc3m.es> wrote in message news:<007boa.7s4.ln@news.it.uc3m.es>...

>> running kernel! He has to find the .config for his running kernel
>> (it'll be in the kernel rpm) and examine that.

> Peter, I am admittedly newish to Linux and most definately not
> familiar with manipulating the kernel. Can you point me to any guides

There's no need to be. It's no big deal.

> that explain how I might do what you propose above (even better if it

Well, what was difficult to understand about "find the .config for the
running kernel and examine it"? I'm puzzled. I even told you where to
find it (or where to look to find where to find it, if you prefer .. in
the kernel rpm for your distro and kernel). What was the point of
troubling to spell out "go down to the shop on the corner and ask for some
potatos" if you are going to ignore the help and say "can you point me to
some general resource on french fries"? As though nobody had told you
what to do and where to go?

> refers specifically to Mandrake 9.0). Thanks.

It'd not be better, but worse. But the Kernel HOWTO springs to mind as
a first recourse, if not the README in the kernel source directory. I'd
start with the latter. Less fuss.

Peter

Christopher Browne

2002-10-13, 3:24 pm

"Littlefish" < Littlefish_au_spam_killer_@yah
oo.com> wrote:
> Shut down Qmail in services and watch the speed increase. PC Chips MB
> are slow anyway! Shut down unwanted services. this means they are still
> installed but not running.

I'd commend the idea of shutting off unneeded services as a /security/
improvement, but would certainly pooh-pooh the notion that this should
dramatically affect speed.

qmail isn't going to consume much in the way of system resources
(memory or CPU) if there's no mail needing to be delivered. The same
is true for most services.

The only time qmail would start chewing resources is if there's a lot
of mail queued, and even so, it's considered a pretty efficient MTA.

The only way this should be causing a problem is if you're running an
open relay on behalf of 250 Nigerian scam artists, and they're using
your system to relay a million spam messages per day.
--
(concatenate 'string "cbbrowne" "@ntlug.org")
http://www.ntlug.org/~cbbrowne/linuxdistributions.html
"Open Software and freeing source code isn't socialism. It isn't
socialist. It's neither socialist nor capitalist; it just is."
-- Arthur <afrain@usa.net>

Darren Best

2002-10-13, 4:24 pm

Juha Laiho <Juha.Laiho@iki.fi> wrote in message news:<aobps4$rvu$1@ichaos.ichaos-int>...

> I ran that in text mode - sorry for omitting that information. While
> writing my previous response, I did realise that I need to re-check
> my own performance under X as well (though my window manager is
> minimalistic). The results were so close (within 10%) that I just
> ignored this aspect. But I agree; I should've reported both of these
> results.

This bears out that the memory bandwidth when running in X is causing
me a problem, as less for you. But it doesn't *necessarily* mean that
my hardware is entirely at fault. See below for my reasons for
believing so....

> As I said, to me this seems an issue with needed memory bandwidth - and
> with the architecture where an integrated display adapter uses part of
> the system main memory as the display memory. To produce a high-
> resolution image at a high colour depth and at an acceptable refresh
> rate, the display processor will need data at a rather enormous speed.
>
> (at this point, please try to verify that my assumption that your
> system is architected this way - i.e. that the machine doesn't have
> separate display memory - is correct. I just made this deduction based
> on your hdparm results and your other system specs)

Yes, the specs for the motherboard claim that it uses up to 8 MB for
video memory, AGP accelerated. What you're saying is that the video
performance is screwed when it has to go back to the system memory all
the time.

> Calculating from my above screen mode:
> There are 1024x768 pixels. Each pixel takes up 32 bits (4 bytes). Each
> pixel is redrawn 76 times per second. This means that the display
> processor must read 1024x768x4x76 bytes per second from the display
> memory. This is 768x4x76 kbytes, i.e. 233472 kbytes - or 228 megabytes.
> Per second. Each second, continuously.

I'm not booted into Mandrake right now, but I do know that I'm running
1280x1024 @ 65000 colours (16 bit?). Don't recall the refresh rate.

> To get the idea about this speed, compare it with the bandwidth of
> the regular PCI bus: 32 bits parallel with 33 MHz clock.
> 4 * 33 (132) megabytes/second. Another comparision point would be the
> system memory bandwidth on my other machine (PIII@866MHz, Windows);
> at least one tool reports that at somewhere bit over 300MBytes/sec
> (thus a bit over what would be required for the above display mode).
>
> The message I'm trying to give here is that memory speeds required
> by decent resolutions and colour depths are just huge. This is why
> display adapters have "always" had their own memory: the system
> memory (or the bus used to access system memory) has always been too
> slow.

So then explain to me why I get perfectly acceptable performance in
Windows. My last PC had a similar motherboard setup (with an AMD
K6/2-350, 192 MB PC100 ram), but I had a basic ATi Rage 128 AGP card
with 8 MB onboard. Windows 98SE performs substantially *better* on my
new machine than my old one, which would likely be due to the faster
CPU and more ram. I run Windows at 1280x1024 on my new machine: I ran
my old machine at 1024x768, so if anything I should have seen a
performance hit!

Does it have to do with X, and the fact that Windows does more direct
hardware interaction? I'm not trolling: I just don't see (in your
explanation) why Windows shouldn't also see a horrendous decrease in
performance in using the integrated video vs. using a separate card.
Although I'm not taxing my video in Windows (no 3D games or anything),
I'm not taxing my video in Linux, either!

If I am correct, this brings me back to Mandrake 9.0 just not
supporting my graphics subsystem very well, and it taking my disk
performance down into the crapper with it. I'm begging the people
replying above in this thread to please tell me how I might check the
kernel to verify any optimized support, and if not, how to patch the
kernel if possible. Any thoughts?

Sorry, I can't compare my performance of Linux on the two machines: I
did not try to install any Linux on the old box.

Wes Newell

2002-10-13, 6:24 pm

On Sun, 13 Oct 2002 02:22:40 -0500, Peter T. Breuer wrote:

> In alt.os.linux Wes Newell <w.newell@verizon.net> wrote:
>> On Sat, 12 Oct 2002 13:46:55 -0500, Darren Best wrote:
>>> Perhaps the Mandrake 9.0 kernel (and its default kernel optimizations)
>>> is such that my older chipset is not supported for high performance?
>>> Mandrake's web site seems to be rather skimpy on technical details but
>>> at thier hardware compatibility page they claim support for SiS 630
>>> and 735 chipsets, not the 530.
>
>> You're off base. Support is in the kernel for the 530 chipset. If you
>
> How do you know?

Because the SIS drivers are compiled into the kernel by default. And that
driver supports his chipset along woth a ton of other sis chipsets. This
is it.
CONFIG_BLK_DEV_SIS5513=y[color
=blue]
>
>> want to see it, make sure you have the sources loaded. su to root, cd
>> /usr/src/linux, and run "make xconfig". You should be able to find it
>
> This is nonsense. That shows him Linus's config, not the config of his
> running kernel! He has to find the .config for his running kernel (it'll
> be in the kernel rpm) and examine that.[/color]

Hmmm.. Maybe, but it will be the same. It's in every kernel I've
compiled.
>
>> from there. it's about 3 or 4 levels deep in the IDE controller
>> section.
>
> It's a possibility, not a fact.

Well, I don't see how his system would even boot if it didn't support the
controller. I've been there with OS/2 and Highpoint.

Wes Newell

2002-10-13, 6:24 pm

On Sun, 13 Oct 2002 12:22:11 -0500, Darren Best wrote:

> Wes Newell <w.newell@verizon.net> wrote in message
>
>> This is strange. I just installed 9.0 on a sis chipset board this
>> afternoon and I was meaning to look at the settings, but I forgot since
>> everything was running fine.
>> Anyway, I looked at the kernel, and assumming you're running the
>> stanbdard kernel, support for the sis530 is there. Really strange.
>
> How did you do this (ie. "look at the kernel" to see support for the SiS
> 530)? As I said before, I'm new to fine-tuning Linux performance, and
> not only do I not know how to check things in the kernel, I find the
> idea of mucking around in there a bit scary :-) Any "plain English"
> guides to this topic? Or could you run down (point-by-point) the steps
> you took to do what you did (since you have a similar system). Thanks.

Well, I'm pretty sure that you couldn't even boot without it, but look
for this;
CONFIG_BLK_DEV_SIS5513=y
in your /boot/config file.
If it's not there, I'll be shocked.

Wes Newell

2002-10-13, 6:24 pm

On Sun, 13 Oct 2002 12:26:00 -0500, Darren Best wrote:

> Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote in message

>> buffer-cache reads: 128 MB in 0.66 seconds =193.94 MB/sec Timing
>> buffered disk reads: 64 MB in 1.76 seconds = 36.36 MB/sec
>>
>>
>> -c0 (16 bit default) gets me 188.xx/36.xx
>
> Someone below (Juha Laiho) in this thread mentioned the possibility of
> my integrated video having something to do with my performance (see his
> comment and my response below). What do have for a video card in your
> system? Did you run hdparm with X shutdown or with a desktop
> environment running?

The system i installed 9.0 on yesterday (SIS 730S) used on board video
(32meg of 128). I called and walked her through installing hdparm and
testing. She got 104 and 39 mb/s with -tT. Ran in KDE terminal. Duron
600. I don't know if this will work, but try booting from the
installation cd into rescue mode and try it from there. I'm at a loss.

Dennis Lee Bieber

2002-10-13, 8:24 pm

Darren Best fed this fish to the penguins on Sunday 13 October 2002
10:26 am:

>
> Someone below (Juha Laiho) in this thread mentioned the possibility of
> my integrated video having something to do with my performance (see
> his comment and my response below). What do have for a video card in
> your system? Did you run hdparm with X shutdown or with a desktop
> environment running?

That's from an X-term session. Current video is an NVidia GeForce 4 Ti
4200 -- WITH NO NVIDIA DRIVERS (not even the Mandrake "nv"). My card is
not recognized by v8.2 enough to even get the nv drivers loaded, and
the NVidia instructions seem to assume you are replacing an "nv"
configuration. So... I'm running the installer FRAME-BUFFER device at
1280x1024x16.

The RDRAM is PC700 with ECC.

--
--
> ==============================
==============================
== <
> wlfraed@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
> wulfraed@dm.net | Bestiaria Support Staff <
> ==============================
==============================
== <
> Bestiaria Home Page: http://www.beastie.dm.net/ <
> Home Page: http://www.dm.net/~wulfraed/ <

Waldek Hebisch

2002-10-14, 11:24 am

Richard James (thisemailwontwork@all.will.it) wrote:
: Darren Best wrote:

: > I'm reasonably new to Linux, so take it easy.
: >
: > I have installed Linux before on an AMD K6/2-350 (that was SuSE 6.3),
: > and its performance was not terribly dissimilar to Windows 98SE.
: >
: > I have a different (but still outdated) machine now. Its basic specs:
: > - PC Chips M599LMR motherboard (SiS 530 chipset, integrated video)
: > - AMD K6/2-450 cpu
: > - 256 MB PC100
: > - IBM 60GXP HD, 30GB (hda, three FAT32 partitions)
: > - IBM 120GXP HD, 80GB (hdb, two ReiserFS partitions + swap)
: >
: > This machine, again, has Windows 98SE installed (but never Linux). I
: > installed Mandrake onto the second drive, and everything has gone
: > smoothly. EXCEPT everything is *very* slow. The OS and applications
: > take forever to load.
: >
<snip>
: > /dev/hda:
: > Timing buffer-cache reads: 128 MB in 11.04 seconds = 11.59 MB/sec
: > Timing buffered disk reads: 64 MB in 12.23 seconds = 5.23 MB/sec
: >

That is defintely a memory problem.

: > So.... what could be causing this? I've done a search in Usenet and
: > the Web, but can't find any known performance issues between Linux and
: > IBM drives, or Linux and the SiS 530 chipset, or anything solid.
: >

However, even with such bad memory performance the system can run well.
I would also look at motherboard specs --- if your motherboard really
supports 256 MB RAM. A lot of motherboard allows you to put into
slots a lot of memory, but allows fast acces (make the memory cacheable)
only to the first 64MB. On such machines taking out memory (or telling
the kernel to use only first 64MB) gives substantial speed-up. Many
Windows version use only first 64MB so this may explain differnce
between Linux and Windows.

--
Waldek Hebisch
hebisch@math.uni.wroc.pl or hebisch@hera.math.uni.wroc.pl

Stuart Levy

2002-10-14, 10:24 pm

In article <01ccoa.n3v.ln@news.it.uc3m.es>, Peter T. Breuer wrote:
[...OP, urged to check whether SIS IDE controller support was in his
kernel, was unsure how to determine that ...]
>Well, what was difficult to understand about "find the .config for the
>running kernel and examine it"? I'm puzzled. I even told you where to
>find it (or where to look to find where to find it, if you prefer .. in
>the kernel rpm for your distro and kernel).

Hey, I've been using Linux for quite a while, and I'm not puzzled about
the OP's problem. Have RPM builders adopted a general convention about
knowing which .config file was used to build the current kernel??

If you built it by compiling /usr/src/linux-<whatnot>, then
of course it'll be in /usr/src/linux-<whatnot>/.config.

But if you've just installed some distribution's binary kernel RPM,
is there a standard place to find the .config?

In Red Hat 7.3, I'm delighted to find that the kernel-rpm-installation
puts a /boot/config-<kernelversion> file in /boot along with the
/boot/vmlinuz-<kernelversion>. That's wonderful. But earlier Red Hats
didn't seem to do this, and it appears that other RPM-based
distributions may use different conventions, judging from someone's
mention of "/boot/config".

To check that it's not hiding somewhere in the (RH-pre-7.3) kernel rpm,
I just tried (on a Red Hat 7.2 system, with 2.4.9-34smp kernel from .rpm)
rpm -q -l kernel-smp-2.4.9 | grep -i config
and found nothing with "config" in its name except the i2o_config.o module.

Now, if you install the *kernel-source* RPM, there'll be a pile of
/usr/src/linux-<kernelversion>/configs/kernel-<kernelversion>-<arch>.config
where one of the .config's names resembles that of the installed binary
kernel-<kernelversion>.<arch>.rpm. That seems to be *the* way (in RH before
7.3) to get kernel configs for their pre-packaged kernels.

Maybe Mandrake does this right, and puts binary kernels' .config files in a
place that's sensible once you know it. But it seems unfair to consider it
obvious otherwise. This kind of configuration info is often not well
documented -- and even if it's written down somewhere, it may be hard to
guess where to look.

Stuart Levy, slevy@ncsa.uiuc.edu

Peter T. Breuer

2002-10-15, 2:24 am

In alt.os.linux Stuart Levy <slevy@niri.ncsa.uiuc.edu> wrote:
> In Red Hat 7.3, I'm delighted to find that the kernel-rpm-installation
> puts a /boot/config-<kernelversion> file in /boot along with the
> /boot/vmlinuz-<kernelversion>. That's wonderful. But earlier Red Hats
> didn't seem to do this, and it appears that other RPM-based
> distributions may use different conventions, judging from someone's
> mention of "/boot/config".

All had a config. I "know" this because alan cox has been for years
rejecting a/my kernel patch to record the compilation parameters
in /proc on the grounds that distros can add the .config wherever they
like, even on the end of the kernel image if they prefer! So it
must always have been there in redhat.

> To check that it's not hiding somewhere in the (RH-pre-7.3) kernel rpm,
> I just tried (on a Red Hat 7.2 system, with 2.4.9-34smp kernel from .rpm)
> rpm -q -l kernel-smp-2.4.9 | grep -i config
> and found nothing with "config" in its name except the i2o_config.o module.

Curious. Try "conf" instead.

> Now, if you install the *kernel-source* RPM, there'll be a pile of

Well, yes, of course.

> Maybe Mandrake does this right, and puts binary kernels' .config files in a
> place that's sensible once you know it. But it seems unfair to consider it
> obvious otherwise. This kind of configuration info is often not well
> documented -- and even if it's written down somewhere, it may be hard to
> guess where to look.

Your test notwithstanding, I am as certain as I can be that all distros
record the kernel config info with the /binary/ kernel, and have always
done so, as a matter of good practice.

Peter

Stuart Levy

2002-10-15, 12:24 pm

I'd written, in hunting for a .config in pre-7.3 Red Hat binary kernel RPMs:

>> To check that it's not hiding somewhere in the (RH-pre-7.3) kernel rpm,
>> I just tried (on a Red Hat 7.2 system, with 2.4.9-34smp kernel from .rpm)
>> rpm -q -l kernel-smp-2.4.9 | grep -i config
>> and found nothing with "config" in its name except the i2o_config.o module.

and in article <0jbgoa.35c.ln@news.it.uc3m.es>, Peter T. Breuer suggested:

>Curious. Try "conf" instead.

OK, I did, and then visually scanned the complete output of
"rpm -ql kernel-smp-2.4.9" (from RH 7.2). It really isn't there.

>All had a config. I "know" this because alan cox has been for years
>rejecting a/my kernel patch to record the compilation parameters
>in /proc on the grounds that distros can add the .config wherever they
>like, even on the end of the kernel image if they prefer! So it
>must always have been there in redhat.

I think it really wasn't. Maybe Alan was just saying what he thought
ought to happen, instead of what had already happened?

The Red Hat people must have been expecting that, if people hadn't
installed the kernel source RPM, they didn't care what configuration
settings had been used. So with 7.3, Red Hat has finally gotten it right;
apparently Mandrake did earlier; anyone know about SuSE?

If you submit your /proc/config (or whatever it is) patch to Alan Cox again,
you can claim my vote in support of it! Given the lack of standardization
across distributions, it really seems appropriate for the kernel to
standardize on recording its own config information.

Stuart Levy, slevy@ncsa.uiuc.edu

Trevor Hemsley

2002-10-15, 4:24 pm

On Tue, 15 Oct 2002 17:12:13 UTC, slevy@niri.ncsa.uiuc.edu (Stuart
Levy) wrote:

> So with 7.3, Red Hat has finally gotten it right;
> apparently Mandrake did earlier; anyone know about SuSE?

This is SuSE 7.3 but it was there in 7.1 too.

trevor@trevor4:/usr/src/linux> ls -la /boot/*config*

-rw-r--r-- 1 root root 38191 Sep 28 2001
/boot/vmlinuz.config

Even more interesting, if you boot a stock SuSE (2.4.10) kernel you
get a /proc/config.gz which appears to be the config file for the
running kernel when I zcat it. I don't think this was there in 7.1 but
I don't know for sure.

--
Trevor Hemsley, Brighton, UK.
Trevor-Hemsley@dial.pipex.com

Steve Wampler

2002-10-15, 7:24 pm

Trevor Hemsley wrote:
>
> On Tue, 15 Oct 2002 17:12:13 UTC, slevy@niri.ncsa.uiuc.edu (Stuart
> Levy) wrote:
>
> > So with 7.3, Red Hat has finally gotten it right;
> > apparently Mandrake did earlier; anyone know about SuSE?
>
> This is SuSE 7.3 but it was there in 7.1 too.
>
> trevor@trevor4:/usr/src/linux> ls -la /boot/*config*
>
> -rw-r--r-- 1 root root 38191 Sep 28 2001
> /boot/vmlinuz.config

Hmmm, not on this (factory installed, so who knows) RH 7.3
system:

->ls -la /boot/*conf*
zsh: no matches found: /boot/*conf*

In fact, how could a *file* in /boot ever be considered the
right way to go? I can have (and do have) several different
kernels that can be selected at boot time. Unless each writes
to /boot when it boots (a *bad* idea), /boot/*config* is
likely to be inaccurate.

Add another vote to /proc/config.

--
Steve Wampler -- swampler@noao.edu
Quantum materiae materietur marmota monax si marmota
monax materiam possit materiari?

john

2002-10-16, 6:24 am

You will find the software is looking for an 8bit urart chip
check the messages it slowed my computer to zero then I deleted it and the
thing is faster now.

"Steve Wampler" <swampler@noao.edu> wrote in message
news:3DACA3DC.FC4DAE24@noao.edu...
> Trevor Hemsley wrote:
> >
> > On Tue, 15 Oct 2002 17:12:13 UTC, slevy@niri.ncsa.uiuc.edu (Stuart
> > Levy) wrote:
> >
> > > So with 7.3, Red Hat has finally gotten it right;
> > > apparently Mandrake did earlier; anyone know about SuSE?
> >
> > This is SuSE 7.3 but it was there in 7.1 too.
> >
> > trevor@trevor4:/usr/src/linux> ls -la /boot/*config*
> >
> > -rw-r--r-- 1 root root 38191 Sep 28 2001
> > /boot/vmlinuz.config
>
> Hmmm, not on this (factory installed, so who knows) RH 7.3
> system:
>
> ->ls -la /boot/*conf*
> zsh: no matches found: /boot/*conf*
>
> In fact, how could a *file* in /boot ever be considered the
> right way to go? I can have (and do have) several different
> kernels that can be selected at boot time. Unless each writes
> to /boot when it boots (a *bad* idea), /boot/*config* is
> likely to be inaccurate.
>
> Add another vote to /proc/config.
>
> --
> Steve Wampler -- swampler@noao.edu
> Quantum materiae materietur marmota monax si marmota
> monax materiam possit materiari?

Sponsored Links