View previous topic :: View next topic |
Author |
Message |
moob7 Tux's lil' helper
Joined: 22 Jan 2006 Posts: 80
|
Posted: Mon Mar 20, 2006 2:58 am Post subject: [solved] from p4 to AMD64 - key lag & audio stutter |
|
|
Due to a hardware failure, I had to replace my old pentium4 system with a new Althon64 system. Essentially I threw the old hard drive (with grub & windows & gentoo linux) and the old gfx & sound cards and put them in the new computer, booted.
Grub is fine (despite being compiled for p4). Linux runs (despite being compiled for p4). windows runs as expected. I began to get three new problems on the linux side.
- under moderate to heavy CPU load, audio playback stutters
- under moderate to heavy CPU load, keyboard response is laggy (typing)
- under moderate to heavy CPU load, the mouse pointer gets jerky/laggy.
Obviously, while pentium4 binaries will run on an AMD64, it is slow.
So I did the obvious thing: change the make.conf to reflect the new CPU being of the AMD family, recompile the kernel ... and everything else. I wish to continue running a 32-bit linux and I desire to avoid a complete re-install. So I am attempting to set the system up as if running on an older pre-64bit AMD (ie: staying 32-bit!).
Despite the recompiles, I still have those three Problems. Essentially my AMD64 is handling multiasking worse than my old P4, which is insane. So I'm obviously doing something wrong. (side note, windows has no problems, so the new hardware (including motherboard) must be ok).
My current /etc/make.conf:
Code: | USE="-canna -cjk -freewnn alsa oss jack mmx sse2 real doc gtkhtml java gcj win32codecs dvd mad ogg theora aac tga xgl"
# in CFLAGS, I changed -mcpu=i686 to -march=pentium4
# but then I got the amd64 - so pentium4 kinda slows it a bit
# yet we don't want to compile for 64-bit (logn story) so
# we say "athlon"
# old: CFLAGS="-O2 -march=pentium4 -fomit-frame-pointer"
CFLAGS="-march=athlon -O2 -pipe -fomit-frame-pointer"
# don't fuck with CHOST - tweak MARCH xor MCPU flags instead
CHOST="i686-pc-linux-gnu"
# I have two sound cards. Fortunately alsa can handle that
ALSA_CARDS="ens1371,ice1712"
CXXFLAGS="${CFLAGS}"
MAKEOPTS="-j2"
# I added the entire next line (there was no LDFLAGS before) to possibly optimize linking
LDFLAGS="-Wl,-O1"
# portage_niceness to optionally ease up the CPU consumption of emerge
# compilation ... seems icky so it is commented out
# PORTAGE_NICENESS = 1
PORTDIR_OVERLAY="/usr/local/pcc_portage"
# pcc - prevent rsync changes on certain things
RSYNC_EXCLUDEFROM = "/etc/portage/rsync_excludes"
# pcc - There are no "ACCEPT-KEYWORDS" in this file. Good.
# Keep it that way. It's more stable that way, so they say.
|
Prior to the new hardware, my CHOST was the same but the "-march" part was set to "pentium4".
So, yeah, I'm confused. Does anyone have any idea as to what I should do? My next step is to perhaps to to recompile all again with "-mcpu=i686" instead of the "-march" but I thought I'd stop and ask around here before going that route.
Last edited by moob7 on Tue Mar 21, 2006 1:32 am; edited 1 time in total |
|
Back to top |
|
|
whig l33t
Joined: 27 Nov 2004 Posts: 973 Location: New Zealand
|
Posted: Mon Mar 20, 2006 3:46 am Post subject: |
|
|
When things go laggy look at your logs and run dmesg to see if problems are being reported. Keep a "top" window open in case it is a program hogging all your cpu. |
|
Back to top |
|
|
TerranAce007 Apprentice
Joined: 13 Dec 2004 Posts: 281 Location: Texas
|
Posted: Mon Mar 20, 2006 12:31 pm Post subject: |
|
|
It might end up being less of a hassle to just do a new install using the new cpu settings. This way, you know everything is getting set up right and there won't be any traces of the old system causing problems.
Also, I think you can compile a 32 bit system while still optimizing for the newer amd64 arch if you do something like this:
Code: | CFLAGS="-march=k8 -pipe -O2"
CHOST="i686-pc-linux-gnu"
|
I always use x86_64-pc-linux-gnu myself though, for 64 bit. _________________ It's all funny until someone gets hurt.
Then it's hilarious. |
|
Back to top |
|
|
tcfelker n00b
Joined: 24 Jun 2003 Posts: 46
|
Posted: Tue Mar 21, 2006 12:28 am Post subject: |
|
|
Use hdparm to make sure DMA is enabled for your disks. If they're SATA, make sure proper support for the controller chipset is built into the kernel. It's unlikely that things being 32-bit instead of 64-bit would cause problems, especially stuttering, because the performance difference is not that great. |
|
Back to top |
|
|
moob7 Tux's lil' helper
Joined: 22 Jan 2006 Posts: 80
|
Posted: Tue Mar 21, 2006 1:31 am Post subject: |
|
|
whig wrote: | When things go laggy look at your logs and run dmesg to see if problems are being reported. Keep a "top" window open in case it is a program hogging all your cpu. |
OMG, wow. That never occurred to me and yet it is so obvious in retrospect.
Dmesg had no problems but top revealed that kjournald and pdflush were eating up all the CPU. Near as I can tell, they have something to do with ext3 journaling. That then led me to investigate the hard drives. Then I realized that these are the same hard drives that I have been using (from before, on the old machine).
What is between the CPU and the hard drives? the motherboard. I checked the bios and cmos. All was well there. Then I looked at the kernel configuration. There was my problem: I had to change the IDE controller from my old motherboard chipset to my new motherboard. Recompiled kernel. Rebooted. System now runs smooth like it used to.
What a dope I am. :p
Thanks All is well now |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|