Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Gentoo on slow machines
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks
View previous topic :: View next topic  
Author Message
pentium120
n00b
n00b


Joined: 14 Jan 2005
Posts: 29

PostPosted: Mon Jan 31, 2005 1:06 am    Post subject: Gentoo on slow machines Reply with quote

Although my screen name may lead you to believe so, I didn't install Gentoo on a Pentium 120... however, it was a pretty slow workstation nonetheless -- a Pentium 2-MMX/ 266 with 64MB of RAM.

I got a compile error during bootstrap. So I added the march=pentium2 and removed the mcpu=i686 command in the make.conf file and dropped in an extra 96MB RAM. I'm not sure which of these fixed the problem -- perhaps neither, but I did feel that it was worth keeping in mind as a data point for others in the community.

I do know that my Pentium 120 w/48MB RAM can run FreeBSD so I'm inclined to believe that the march option / mcpu removal fixed my problem. This seems strange though, considering the fact that march is an optimization and not a requirement.

Anyway, this is something that you guys with old hardware and compile errors might want to look into.

----
Other tips for slow machines:

-- Keep your kernel small; modularize optional devices and only load the modules if/when necessary
-- Run no GUI or a lightweight GUI such as XFCE
-- Run a separate hard drive for your swap partition
-- Install the recommended compiler cache if you have some spare HD space...
Code:
emerge ccache
You'll need the extra compilation speed =)

More to come . . .
Back to top
View user's profile Send private message
angoraspruce
Apprentice
Apprentice


Joined: 08 Jan 2005
Posts: 193
Location: Minnesota, USA

PostPosted: Mon Jan 31, 2005 1:29 am    Post subject: Re: Gentoo on slow machines Reply with quote

pentium120 wrote:

-- Run a separate hard drive for your swap partition

I like this suggestion. Only thing I'd add is that the swap drive be on its own ide. If I understand it properly, having both drives on the same ide will cause the speed to be halved for each (or there abouts).

Best regards :)
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Mon Jan 31, 2005 1:39 am    Post subject: Reply with quote

one of the testbed platforms that i used to write the Stage 1 on 3 install HowTo was a Pentium-Classic 133 with 64 MB of RAM. :!: If you read that how-to, you shouldn't have any problems completing an install on older hardware.

Even a memory-crippled slug of a PC like that (it didn't even support UDMA) had no problems using a rather extreme level of optimization, including -O3 and a host of developer-disapproved CFLAGS and CXXFLAGS. The only downside was that every time that i preformed a basic gentoo installation, it took an entire week. 8O

IME, its worth taking the extra time to optimize using -O3 and an aggressive set of CFLAGS. you pay for the time in compiling up front, but the system will become responsive enough to make the effort worthwhile.

Code:
CHOST="i586-pc-linux-gnu"
CFLAGS="${CFLAGS} -O3 -march=pentium -pipe -mtune=pentium -fforce-addr -momit-leaf-frame-pointer -fomit-frame-pointer -ftracer -funroll-loops -falign-functions -fmerge-all-constants -mfpmath=sse -maccumulate-outgoing-args -fprefetch-loop-arrays"

CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden -fvisibility=hidden"

_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
angoraspruce
Apprentice
Apprentice


Joined: 08 Jan 2005
Posts: 193
Location: Minnesota, USA

PostPosted: Mon Jan 31, 2005 2:08 am    Post subject: Reply with quote

Bob P wrote:

Code:
CHOST="i586-pc-linux-gnu"
CFLAGS="${CFLAGS} -O3 -march=pentium -pipe -mtune=pentium -fforce-addr -momit-leaf-frame-pointer -fomit-frame-pointer -ftracer -funroll-loops -falign-functions -fmerge-all-constants -mfpmath=sse -maccumulate-outgoing-args -fprefetch-loop-arrays"

CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden -fvisibility=hidden"


At school I have a small network of 12 Slackware 9.1 machines and a FreeBSD 5.3 server. They're Pentium and Pentium II (133-450), and I'm thinking about switching them to Gentoo this summer. It's good to hear that it's possible on the older machines (which was my biggest concern), and great to see a suggested list of cflags. Thanks.

Best regards :)
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Mon Jan 31, 2005 2:33 am    Post subject: Reply with quote

angoraspruce wrote:
Bob P wrote:

Code:
CHOST="i586-pc-linux-gnu"
CFLAGS="${CFLAGS} -O3 -march=pentium -pipe -mtune=pentium -fforce-addr -momit-leaf-frame-pointer -fomit-frame-pointer -ftracer -funroll-loops -falign-functions -fmerge-all-constants -mfpmath=sse -maccumulate-outgoing-args -fprefetch-loop-arrays"

CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden -fvisibility=hidden"


At school I have a small network of 12 Slackware 9.1 machines and a FreeBSD 5.3 server. They're Pentium and Pentium II (133-450), and I'm thinking about switching them to Gentoo this summer. It's good to hear that it's possible on the older machines (which was my biggest concern), and great to see a suggested list of cflags. Thanks.

Best regards :)

before you get too eager to run with those CFLAGS, make a point of reading the Stage 1 on 3 Guide. Those are NOT recommended CFLAGS by any means. they're just a list of CFLAGS that I was able to get away with on my testbed systems. If you're interested in a single set of homogeneous CFLAGS that are likely to work on a heterogeneous group of machines, you'll be better served by a more conservative set of flags, like those recommended in the Guide.

although alot of people tend to knock the use of -O3 on older hardware, i find that -O3 optimization provides noticable improvement over -O2 optimization, especially on older hardware. the painful part is that the compile times are markedly prolonged.

if i were working on upgrading a cluster of old machines like you've alluded to, i'd consider starting off with Stage 3 installs, just to get the sytems up and running quickly, then using distributed compiling with distcc to rebuild each of the machines one at a time, using the other PCs to share the workload. this approach would give you the fastest uptime for the group as a whole.
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
angoraspruce
Apprentice
Apprentice


Joined: 08 Jan 2005
Posts: 193
Location: Minnesota, USA

PostPosted: Mon Jan 31, 2005 3:23 am    Post subject: Reply with quote

Bob P wrote:
although alot of people tend to knock the use of -O3 on older hardware, i find that -O3 optimization provides noticable improvement over -O2 optimization, especially on older hardware.

Thanks for the further explanation. I'll keep the -O3 definitely in mind. And I like the idea of starting with a stage 3, then using distcc to rebuild the machines one at a time. They're used by my students only during the week, so I'd have each weekend do a machine. It'll take 'till Christmas, true, but that won't matter if I begin with Stage 3 so they're all available. And I like the idea of playing with distributive compiling. After having done it 12 or more times over, I'll maybe have learned something! (Thanks again.)
Back to top
View user's profile Send private message
pentium120
n00b
n00b


Joined: 14 Jan 2005
Posts: 29

PostPosted: Mon Jan 31, 2005 9:58 am    Post subject: Reply with quote

I just want to thank everyone for all the great ideas. I didn't think of the IDE bottleneck, but it makes sense that it may exist. Old hard drives make great swap drives, as long as their access time is still *somewhat* acceptable and they aren't making any funny noises 8O I have a 1GB 5 1/4" form factor UW-SCSI that keeps chuggin' along.

Old Promise ATA 66/100/133 controllers are practically a dime a dozen these days so they'll do the job as that second controller. The other nice thing about a second controller is data integrity. If your cron backup job(s) are properly spaced out, the additional controller just might be the final link to saving your data. And yes, I have seen the buggers die too =)
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks All times are GMT
Page 1 of 1

 
Jump to:  
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