Speed issues
Peter Chant
Under Arch the machine seems much faster. Under slack this machine (triple
core phenom II, 4GB) did not feel much faster than the one it replaced
(Athlon XP 2.5G 1GB).
Both running x86_64. Slack distro is 13.0.
I know that the comparison is rather subjective and there are a number of
disparities - kde 4.3 v 4.2 etc, but on slack the machine is not snappy
under xfce! I do realise that there are various things installed on slack
that I had not set up on Arch, sendmail, mysql, bind, apache - however,
these are lightly loaded and only consume memory when not asked to do
something - with 4GB memory should not be an issue with either. Also these
services did not tax the Athlon XP - so should provide negligible load on
this machine. Also gkrellm on slack shows a moderate load on all three
cores when doing anything taking, with constant blips, even when I am just
making this post - whereas Arch barely registers any load.
I also find that applications load faster in arch. With a SATA drive can
this be a config issue:
bash-3.1# hdparm /dev/sda
/dev/sda:
IO_support = 1 (32-bit)
readonly = 0 (off)
readahead = 256 (on)
geometry = 56065/255/63, sectors = 1953525168, start = 0
bash-3.1#
Both using ext4.
Any idea why slack is slower? How do I test this and fix slack?
First few lines from top:
top - 08:32:53 up 7:10, 4 users, load average: 0.24, 0.91, 0.78
Tasks: 172 total, 1 running, 171 sleeping, 0 stopped, 0 zombie
Cpu(s): 2.3%us, 0.3%sy, 0.0%ni, 97.2%id, 0.0%wa, 0.1%hi, 0.0%si,
0.0%st
Mem: 3796992k total, 3575252k used, 221740k free, 316632k buffers
Swap: 1060248k total, 274028k used, 786220k free, 1076372k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3346 root 20 0 414m 76m 3284 S 5 2.1 7:05.20 X
3436 pete 20 0 661m 68m 21m S 1 1.8 4:37.77 plasma
9547 pete 20 0 290m 30m 17m S 1 0.8 0:00.56 konsole
3443 pete 20 0 9036 1044 652 S 0 0.0 0:03.15 ksysguardd
1 root 20 0 3928 580 540 S 0 0.0 0:00.36 init
2 root 15 -5 0 0 0 S 0 0.0 0:00.00 kthreadd
3 root RT -5 0 0 0 S 0 0.0 0:00.00 migration/0
PS - ATI experience on Arch - should have got a different chipset there as
well!
Peter Chant
Clarification:
> these are lightly loaded and only consume memory when not asked to do
these are lightly loaded and consume only memory when not asked to do
notbob
> disparities - kde 4.3 v 4.2 etc, but on slack the machine is not snappy
> under xfce!
This is due to the fact that xfce, just like kde, is also a pig. It
started adding useless bloat/bling at least 2 revs back. Try fluxbox.
nb
Peter Chant
twm is lightning fast in Arch on a triple core...
Fair point, but how is KDE _much_ faster in Arch than either KDE or xfce in
Slack. Given similar desktops, recent kernels, libs in each they ought to
be within the same realms in responsiveness.
Pete
Henrik Carlqvist
> Just made my slack box dual boot with Arch to compare graphics card issues.
> Under Arch the machine seems much faster. Under slack this machine (triple
> core phenom II, 4GB) did not feel much faster than the one it replaced
> (Athlon XP 2.5G 1GB).
> I also find that applications load faster in arch. With a SATA drive
> can this be a config issue:
>
> bash-3.1# hdparm /dev/sda
>
> /dev/sda:
> IO_support = 1 (32-bit)
> readonly = 0 (off)
> readahead = 256 (on)
> geometry = 56065/255/63, sectors = 1953525168, start = 0
> bash-3.1#
>
> Both using ext4.
>
> Any idea why slack is slower? How do I test this and fix slack?
Before trying to fix the problem(s) you should identify some good
measurements that you can compare. Once you have found what to measure you
can comare those numbers between arch and slackware and say something like
with benchmark X arch is Y % faster than Slackware rather than just saying
that arch might seem a little faster.
If you suspect differences in the hd configuration you could do a simple
benchmark with:
hdparm -t /dev/sda
You can also test
hdparm -T /dev/sda
Those tests will show the raw bandwidth without and with cache. There you
have some numbers that you can compare between Arch and Slackware and you
can also compare those numbers after doing different changes.
With
hdparm -i /dev/sda
you will see some settings of the drive. Does those settings differ
between Arch and Slackware?
If the settings doesn't differ and both systems give the same raw disk
performance you might still gett different file system performance.
One way to comare that is to:
dd if=/boot/vmlinuz of=/dev/null
Unlike hdparm -t the dd-test is only somewhat useful the first time you
run it. The next times it is run it will only read from the cache in your
RAM.
If dd indicates that one system is faster than the other it could be
because they are on different parts of the disc. Usually discs are faster
at the beginning of the disc so the first partitions might have better
performance than the last partitions.
Other things to check is your graphics performance. One simple test is
glxgears. Another program is x11perf which can do some simple tests. If
your graphics performance differ, look att what settings might differ. Do
both systems use the same driver? Do they have the same resolution and bit
depth? Do they have the same options in xorg.conf?
regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc3(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost
Peter Chant
> Fair point, but how is KDE _much_ faster in Arch than either KDE or xfce
> in
> Slack. Given similar desktops, recent kernels, libs in each they ought to
> be within the same realms in responsiveness.
This is not an Arch v Slack flame btw - I want to fix my slack install.
Pete
Douglas Mayne
> Just made my slack box dual boot with Arch to compare graphics card
> issues. Under Arch the machine seems much faster. Under slack this
> machine (triple core phenom II, 4GB) did not feel much faster than the
> one it replaced (Athlon XP 2.5G 1GB).
>
<snip>
>
The only thing I can think that could be different between your setups is
the Linux kernel itself. Perhaps, optimizing the kernel for specific CPU
architecture could make some difference.
IME, the Slackware releases are incremental improvements, without
breaking things. That remains true, with the exception of Slackware 13's
broken xorgsetup, and the choice of ext4 is a bit "out there," IMO.
OT: I am trying out both VMWare ESX 4i and Slack 13+ today. I have a
virtual machine running as follows:
Linux Kernel: 2.6.30.9 (optimized for coppermine Pentium III)
CPU: Virtual Intel Core 2 Duo 6750
Memory: Virtual 512MB
Disk: 8G on Virtual LSI SCSI controller, formatted XFS
Network: Virtual Intel gigabit ethernet
It seems plenty snappy to me, even with low memory allocation, and
requiring desktop access via tightvnc over a ssh tunnel. YMMV.
--
Douglas Mayne
Lew Pitcher
> On Wed, 25 Nov 2009 08:35:53 +0000, Peter Chant wrote:
>> Just made my slack box dual boot with Arch to compare graphics card
>> issues. Under Arch the machine seems much faster. Under slack this
>> machine (triple core phenom II, 4GB) did not feel much faster than the
>> one it replaced (Athlon XP 2.5G 1GB).
> The only thing I can think that could be different between your
> setups is the Linux kernel itself. Perhaps, optimizing the kernel
> for specific CPU architecture could make some difference.
Properly setup, there should be virtually no difference in speed
between any of the chronologically comparable distributions. And if
there is a difference, it would be far too small to notice by a
human being. Anyone who claims to notice a difference either has a
broken distro, or their head is up their ass. We find that most
people that post to this newsgroup suffer from both situations.
LewPi...@LewPitcher.ca
--
Official Website -->> http://lewpitcher.ca/
Something to look at: -->> http://www.emusclemag.com/
Lonely in Brampton? -->> http://gaypros.meetup.com/cities/ca/on/brampton/
Peel HIV/AIDS Network -->> http://www.phan.ca/home.html
notbob
But they aren't.
Open an editor on a tty (no open DEs) and time the cursor moving
across 80 columns, then open a desktop (slack has 6!) and an xterm and
the same editor and time the cursor movement again. It's pig slow in
both kde and xfce. I can't speak about Arch linux. I'm no game boy
or graphics wiz, but I'm fast enough to see, and reject, a 20% speed
drop in cursor moven't on those two bloated desktops.
nb
Peter Chant
>>
> The only thing I can think that could be different between your setups is
> the Linux kernel itself. Perhaps, optimizing the kernel for specific CPU
> architecture could make some difference.
I'm running 64 bit, the only available option when building a kernel is amd
64 (or some similar option) there seems to be only one option to pick if you
run 64. Just rebuilt the slack kernel using make oldconfig and 2.6.30.6 -
disabled mtrr's as suggested in a post a while back no noticable difference
to slack. Can't remember what Arch uses but it will be rather new.
_Should_ be little difference here.
>
> IME, the Slackware releases are incremental improvements, without
> breaking things. That remains true, with the exception of Slackware 13's
> broken xorgsetup, and the choice of ext4 is a bit "out there," IMO.
>
ext4 on both.
> OT: I am trying out both VMWare ESX 4i and Slack 13+ today. I have a
> virtual machine running as follows:
>
> Linux Kernel: 2.6.30.9 (optimized for coppermine Pentium III)
> CPU: Virtual Intel Core 2 Duo 6750
> Memory: Virtual 512MB
> Disk: 8G on Virtual LSI SCSI controller, formatted XFS
> Network: Virtual Intel gigabit ethernet
>
> It seems plenty snappy to me, even with low memory allocation, and
> requiring desktop access via tightvnc over a ssh tunnel. YMMV.
>
The advantage I found with a CPU supporting virtulisation - virtual machines
suddenly became usable.
Peter Chant
> On 2009-11-25, Peter Chant <pet...@MpeteOzilla.Vco.ukE> wrote:
>
>> Fair point, but how is KDE _much_ faster in Arch than either KDE or xfce
>> in
>> Slack. Given similar desktops, recent kernels, libs in each they ought
>> to be within the same realms in responsiveness.
>
> But they aren't.
>
This is not a flame: you are completely missing my point. It is not about
comparing kde and xfce with fluxbox, it is asking why KDE on Slack is slower
than KDE on Arch.
> Open an editor on a tty (no open DEs) and time the cursor moving
> across 80 columns, then open a desktop (slack has 6!) and an xterm and
> the same editor and time the cursor movement again. It's pig slow in
> both kde and xfce. I can't speak about Arch linux. I'm no game boy
> or graphics wiz, but I'm fast enough to see, and reject, a 20% speed
> drop in cursor moven't on those two bloated desktops.
I have just upgraded as a machine that is well in excess of what I really
need had got to the price point where it was a sensible upgrade option.
Even if I am running "bloated" desktop environments they should run
snappily. They are not. I should not be waiting watching bouncing cursor
animations whilst Firefox or open office think about loading - they should
load rapidly. They do in Arch and do not in Slack. These are both current
distos. Both unsing KDE. They ought to have similar performance. They do
not. My Slackware install is somehow broken.
Peter Chant
>
> Before trying to fix the problem(s) you should identify some good
> measurements that you can compare. Once you have found what to measure you
> can comare those numbers between arch and slackware and say something like
> with benchmark X arch is Y % faster than Slackware rather than just saying
> that arch might seem a little faster.
>
Thanks, some good stuff there. Really should have remembered hdparm. Will
run some tests.
> Other things to check is your graphics performance. One simple test is
> glxgears. Another program is x11perf which can do some simple tests. If
> your graphics performance differ, look att what settings might differ. Do
> both systems use the same driver? Do they have the same resolution and bit
> depth? Do they have the same options in xorg.conf?
Sucks at the moment on both. Can't get ATI proprietary driver to work on
either. Last time I managed it it took a whole weekend of fiddling and I
can't remember the trick. Radeon and radeonhd drivers are not faring much
better. Apart from some tearing arch without best drivers seems generally
snappier than Slackware does with the proprietary drivers.
--
http://www.petezilla.co.uk
notbob
>
> This is not a flame: you are completely missing my point. It is not about
> comparing kde and xfce with fluxbox, it is asking why KDE on Slack is slower
> than KDE on Arch.
Hard to tell w/o you indicating setups of each. Did you install slack
with httpd, mysqd, samba, etc, running in background? How about Arch?
We're not mindreaders.
nb
Henrik Carlqvist
> Apart from some tearing arch without best drivers seems generally
> snappier than Slackware does with the proprietary drivers.
How much difference do you see? How many fps do you get from glxgears?
What is your output from "x11perf -tilerect500" on the different systems?
Loki Harfagr
> We're not mindreaders.
s/\([^ ]* [^ ]* \)\(....\)\(.*$\)/\2 \1\3/
Lew Pitcher
> I have just upgraded as a machine that is well in excess of what I
> really need had got to the price point where it was a sensible
> upgrade option. Even if I am running "bloated" desktop
> environments they should run snappily. They are not. I should
> not be waiting watching bouncing cursor animations whilst Firefox
> or open office think about loading - they should load rapidly.
> They do in Arch and do not in Slack. These are both current
> distos. Both unsing KDE. They ought to have similar performance.
> They do not. My Slackware install is somehow broken.
This is exactly correct. If both distros are running properly then
any difference in speed would not be noticed by unaided human
senses.
Peter Chant
> Peter Chant <pet...@MpeteOzilla.Vco.ukE> wrote:
>> Apart from some tearing arch without best drivers seems generally
>> snappier than Slackware does with the proprietary drivers.
>
> How much difference do you see? How many fps do you get from glxgears?
> What is your output from "x11perf -tilerect500" on the different systems?
At present I think I will configure arch some more and run the two desktops
over a more extended timeframe. I'm having real trouble getting an
accelerated server at the moment. I can't even run glxgears in slack as
after a kernel recompile the ati drivers are not playing ball again. I'm
kicking myself for getting a mobo with ATI on board graphics - either I've
got something fundamentally wrong or I must have picked one of the worst
chipsets.
Neither system is running accelerated - it is not pretty and no where near
as good as my anchient Nvidia card using the VESA driver.
Peter Chant
> If you suspect differences in the hd configuration you could do a simple
> benchmark with:
>
> hdparm -t /dev/sda
>
> You can also test
>
> hdparm -T /dev/sda
>
> Those tests will show the raw bandwidth without and with cache. There you
> have some numbers that you can compare between Arch and Slackware and you
> can also compare those numbers after doing different changes.
Don't think disks are an issue from the looks of things:
SLACK
=====
/usr/sbin/hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 338 MB in 3.01 seconds = 112.15 MB/sec
/usr/sbin/hdparm -T /dev/sda
/dev/sda:
Timing cached reads: 7768 MB in 2.00 seconds = 3885.50 MB/sec
/usr/sbin/hdparm -i /dev/sda
/dev/sda:
Model=SAMSUNG HD103UJ , FwRev=1AA01113,
SerialNo=S13PJ90S300749
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=34902, SectSize=554, ECCbytes=4
BuffType=DualPortCache, BuffSize=32767kB, MaxMultSect=16, MultSect=?16?
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=1953525168
IORDY=on/off, tPIO={min:120,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 *udma6
AdvancedPM=yes: disabled (255) WriteCache=enabled
Drive conforms to: unknown: ATA/ATAPI-3,4,5,6,7
* signifies the current active mode
dd if=/boot/vmlinuz of=/dev/null
9773+1 records in
9773+1 records out
5004096 bytes (5.0 MB) copied, 0.200893 s, 24.9 MB/s
ARCH
====
/sbin/hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 346 MB in 3.01 seconds = 114.96 MB/sec
/sbin/hdparm -T /dev/sda
/dev/sda:
Timing cached reads: 7702 MB in 2.00 seconds = 3853.01 MB/sec
/sbin/hdparm -i /dev/sda
/dev/sda:
Model=SAMSUNG HD103UJ, FwRev=1AA01113, SerialNo=S13PJ90S300749
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=34902, SectSize=554, ECCbytes=4
BuffType=DualPortCache, BuffSize=unknown, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=1953525168
IORDY=on/off, tPIO={min:120,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 *udma6
AdvancedPM=yes: disabled (255) WriteCache=enabled
Drive conforms to: unknown: ATA/ATAPI-3,4,5,6,7
* signifies the current active mode
dd if=/boot/vmlinuz of=/dev/null
Unfortunately I got approx 950MB/sec in arch for the DD test, so I must have
loaded the kernel from cache rather than disk.
Henrik Carlqvist
> Unfortunately I got approx 950MB/sec in arch for the DD test, so I must have
> loaded the kernel from cache rather than disk.
At least in Slackware /boot/vmlinuz is a symbolic link pointing to your
kernel in use and there are also some alternative kernels in /boot. Maybe
you can try with some other kernel? If not, maybe you can find some other
big file which isn't already cached?
Grant
>Peter Chant <pet...@MpeteOzilla.Vco.ukE> wrote:
>> Unfortunately I got approx 950MB/sec in arch for the DD test, so I must have
>> loaded the kernel from cache rather than disk.
>
>At least in Slackware /boot/vmlinuz is a symbolic link pointing to your
>kernel in use and there are also some alternative kernels in /boot. Maybe
>you can try with some other kernel? If not, maybe you can find some other
>big file which isn't already cached?
Some big iso image is good, copy to several names (not symlink) so it
doesn't get cached for each run, delete the copies after you done
testing.
There's probably a command to flush the memory cache -- but that'd mean
RTFM (Gasp!) kernel twiddly bits, no doubt fully documented somewhere
under .../linux-$(uname -r)/Documentation/* Or grab latest linux man
pages <http://www.kernel.org/doc/man-pages/> and seek wisdom therein.
Grant.
--
http://bugsplatter.id.au
Peter Chant
> The only thing I can think that could be different between your setups is
> the Linux kernel itself. Perhaps, optimizing the kernel for specific CPU
> architecture could make some difference.
Disabling nepomuk/strigi made a huge difference. It seems that it runs in
the background, consumes a fair amount of CPU but, judging from the
responsiveness after having left the machine in KDE for a while, seems to
consume enough resources to push the desktop apps into swap. As soon as you
touch the mouse / keyboard the hdd light lights up and you have to wait
whilst the application associated with whatever window you clicked on gets
loaded back out of swap. How much resources should nepomuk/strigi need? It
bogs down a triple core 4GB machine!
Aaron W. Hsu
>Disabling nepomuk/strigi made a huge difference.
Specifically, this is a well known problem with the file indexer. The
Semantic elements of the indexer isn't going to cause too many problems
in my experience, but the indexer as written in 4.2 has a problem that
prevents it from being able to "scale back" its resource consumption. On
my machine, it used one core all the time and about 800MB of RAM.
Disabling this will make a huge difference.
Aaron W. Hsu
--
A professor is one who talks in someone else's sleep.
Henrik Carlqvist
> Disabling nepomuk/strigi made a huge difference.
Sorry I didn't mention top when giving tip on some benchmarks to use. It
has now taken you more than a week to find out what made your Slackware
installation slow. I thought that the use of top was so obvious that it
wasn't worth mentioning.
Anyway, top is a tool that quickly shows you how heavily loaded your
machine is. By default it sorts your processes by cpu consumtion, but it
can also sort your processes by memory consumtion. For more information,
see "man top" and pay extra attention to the interactive commands.
Chick Tower
> Disabling nepomuk/strigi made a huge difference.
So Arch Linux has them disabled by default? Or did forget you disabled
them there?
--
Chick Tower
For e-mail: aols2 DOT sent DOT towerboy AT xoxy DOT net
Aaron W. Hsu
>On Wed, 02 Dec 2009 08:23:34 +0000, Peter Chant wrote:
>> Disabling nepomuk/strigi made a huge difference.
>So Arch Linux has them disabled by default? Or did forget you disabled
>them there?
I expect that this problem is fixed in later versions of KDE. I think
Arch Linux uses 4.3 instead of 4.2.
Peter Chant
> On Wed, 02 Dec 2009 08:23:34 +0000, Peter Chant wrote:
>
>> Disabling nepomuk/strigi made a huge difference.
>
> So Arch Linux has them disabled by default? Or did forget you disabled
> them there?
House decorating has taken priority. However, trying to enable ATI
proprietary drivers there seems to have killed X! So I need to play around
with it a bit to see what is happening.
Pete
Peter Chant
> I expect that this problem is fixed in later versions of KDE. I think
> Arch Linux uses 4.3 instead of 4.2.
Yes, it does, but I have not checked to see what is running.
Pete
Peter Chant
> Peter Chant <pet...@MpeteOzilla.Vco.ukE> wrote:
>> Disabling nepomuk/strigi made a huge difference.
>
> Sorry I didn't mention top when giving tip on some benchmarks to use. It
> has now taken you more than a week to find out what made your Slackware
> installation slow. I thought that the use of top was so obvious that it
> wasn't worth mentioning.
>
No, I did use top - it was one of the first things I did do. As you say,
for anyone with a modest amount of experience it should be the first port of
call.
I've found out where properly to disable nepomuk as just killing did not
seem to work, it kept reappearing. Also something fishy appeared to be
going on - after killing nepomuk things still seemed slow - even though top
indicated that the machine is lightly loaded. Performance now seems
acceptable, but for a new machine with a reasonable processor and memory I
would have expected something more.
I now have the ATI proprietary drivers installed, but I still get a little
tearing on the video - which I find surprising as subjectively it is no
better than the five year old machine it replaced graphics wise. Phonrix
gave a good review for HD3200 though, I did do research before parting with
cash. Also the drivers seem only to install on the 10th attempt even though
I appear to do nothing different. I would have though that new on-board
graphics would beat any five year old graphics, on-board or separate.
Something is a little odd. That an the bios on this mobo seems a little
odd. I've never been an overclocker, but I am an electronics engineer and I
find the overclocking section in the bios impenetrable - I just ended up
setting everything to auto. Also there is a 10 second delay where just a
cursor (underscore) appears on screen presumably whilst various hardware
interfaces sort themselves out, until you are used to it you think there is
a serious hardware problem.
Unfortunately I don't think this was my most successful upgrade.
Thanks for your help,
Pete
Henrik Carlqvist
> Also there is a 10 second delay where just a cursor (underscore) appears
> on screen presumably whilst various hardware interfaces sort themselves
> out, until you are used to it you think there is a serious hardware
> problem.
Some CMOS setup have different settings for "quick boot" and what to
display at boot.
I have also found that some BIOSes need some extra time at boot when HD
settings are set to "auto". If you instead choose the settings of your
current HD in CMOS setup the boot might be a few seconds faster.
Peter Chant
> Peter Chant <pet...@MpeteOzilla.Vco.ukE> wrote:
>> Also there is a 10 second delay where just a cursor (underscore) appears
>> on screen presumably whilst various hardware interfaces sort themselves
>> out, until you are used to it you think there is a serious hardware
>> problem.
>
> Some CMOS setup have different settings for "quick boot" and what to
> display at boot.
Yes, also the splash screen, which was default, did not display some of the
bios keypress shortcuts that were diplayed when it was deactivated. Also
pressing <F8> to bring up a boot device menu was not displayed on screen at
all! Would have been nice to know it was there sooner, especially as the
boot options in the bios seemed on the hole to preclude booting from usb!
The ten second delay I think from documentation is configurable but IIRC was
explained as something to do with avoiding race conditions with USB, but
perhaps I'm remembering correctly. However, to those who don't expect it it
is discocerting as it looks like the machine has hung on boot.
>
> I have also found that some BIOSes need some extra time at boot when HD
> settings are set to "auto". If you instead choose the settings of your
> current HD in CMOS setup the boot might be a few seconds faster.
On the whole I'd pick reliable and informative over fast.
Pete