Over the years, I have noticed a performance impact on linux computers versus identical hardware running windows. The linux clients perform at about 80% compared to windows. Has anyone else noticed this and have any performance tuning recommendations?

I have accumulated many machines with no hard disks and have build linux seti appliances that run off CD. On boot, they download the latest boinc client from a local server, copy over necessary xml and config files, download the appropriate lunatics apps and app_info based on cpu specs, and start boinc all automatically.

I would like to see these seti appliances have benchmarks closer to their windows peers.

Any thoughts?

Scott

I did notice this myself.
There may be something in this older thread that could be of assistance. How much slower is Ubuntu?

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

1) Don't confuse benchmarks with actual, real-world, throughput. Ignore the benchmarks - try to find two computers, running comparable applications (same degree of optimisation, like SIMD instruction set used) and working on comparable SETI tasks (look for the 'True Angle Range' figure in the stderr_txt output). That's the only really important comparison.

2) We had a long discussion with a similar title many, many years ago - sparked off by a volunteer with a single computer, dual-booted into the two operating systems - so absolutely and directly comparable. In that case, Linux was nearer 50% slower: it turned out the be because linux was running the 'low priority' BOINC applications in a low-power, cool-running mode, whereas Windows was keeping the CPU running at full power. Once Linux was tuned to use full CPU power, the times became comparable.

I've noticed the same thing with Mac OS versions of the CPU apps (which are often based on Linux versions) run a decent clip slower than similar work units on my Windows machines. I'd say AP's can be as much as 40-50% slower with the same base build number. MB v6 ran about the same speed, but v7 I know still has not seen an "optimized" non-stock version released so they are running about half the speed as well.

Chris

---

Thanks Richard and HAL,

The power settings sound like a valid explanation and I will see if I can modify them though this will require rebuilding the image with additional packages. These clients are all runlevel 3 without any power packages (powertop, cpupower, etc). It's a minimal linux build. I see no indication of any power saving processes (monitor is always on etc.). Do you thinking adding such packages and customizing the power settings will achieve better performance (RAC)?

So in comparing the stderr output files I did find a discrepancy. Windows (32 bit) is running SSSE3 MB app. My linux client (64 bit) is only running SSE2 MB app. What I've discovered is that /proc/cpuinfo only has a flag for ssse3 not sse3. My script to detect the correct MB app is looking for "sse3" which does not exist. I did this to match the file names and did not realize the "sse3" mb app can be "used with sse3 or higher" and never noticed ssse3 which appears later in the flag listing.

Anyway, first thing I need to do is rewrite the script to look for "ssse3" at which point it will install the ssse3 app not the sse2 app. Will fix that before investigating the power settings, but thank you for the lead.

---

Windows (32 bit) is running SSSE3 MB app. My linux client (64 bit) is only running SSE2 MB app. What I've discovered is that /proc/cpuinfo only has a flag for ssse3 not sse3. My script to detect the correct MB app is looking for "sse3" which does not exist. I did this to match the file names and did not realize the "sse3" mb app can be "used with sse3 or higher" and never noticed ssse3 which appears later in the flag listing.

Anyway, first thing I need to do is rewrite the script to look for "ssse3" at which point it will install the ssse3 app not the sse2 app. Will fix that before investigating the power settings, but thank you for the lead.

SSE3 is sometimes flagged by the CPU as PNI (Prescott New Instructions).

---

Thanks Richard and HAL,

The power settings sound like a valid explanation and I will see if I can modify them though this will require rebuilding the image with additional packages. These clients are all runlevel 3 without any power packages (powertop, cpupower, etc). It's a minimal linux build. I see no indication of any power saving processes (monitor is always on etc.). Do you thinking adding such packages and customizing the power settings will achieve better performance (RAC)?

So in comparing the stderr output files I did find a discrepancy. Windows (32 bit) is running SSSE3 MB app. My linux client (64 bit) is only running SSE2 MB app. What I've discovered is that /proc/cpuinfo only has a flag for ssse3 not sse3. My script to detect the correct MB app is looking for "sse3" which does not exist. I did this to match the file names and did not realize the "sse3" mb app can be "used with sse3 or higher" and never noticed ssse3 which appears later in the flag listing.

Anyway, first thing I need to do is rewrite the script to look for "ssse3" at which point it will install the ssse3 app not the sse2 app. Will fix that before investigating the power settings, but thank you for the lead.

I've found the old thread. Read Toby at Message 725163 - he fixed it with

sudo cpufreq-selector -g performance

(Ubuntu) - no packages or rebuilding.

(March 2008 ! )

The power settings sound like a valid explanation and I will see if I can modify them though this will require rebuilding the image with additional packages. These clients are all runlevel 3 without any power packages (powertop, cpupower, etc). It's a minimal linux build. I see no indication of any power saving processes (monitor is always on etc.). Do you thinking adding such packages and customizing the power settings will achieve better performance (RAC)?

If you don't want to install additional packages you can also poke the /sys interfaces yourself. ArchWiki has a good page on the CPU Frequency Scaling.

in BOINCS cc_config.xml file, look for the line:

<no_priority_change>0</no_priority_change>

and change the "0" to "1" so its:

<no_priority_change>1</no_priority_change>

Then save the file, stop the client apps and restart boinc.

This runs SETI, and other BOINC launched apps, at the same priority level as the BOINC client. Normally these apps run at the super nice level to cause the lowest system impact and not interfere with the user.

So if your system becomes sluggish change the setting back and restart BOINC and its clients.

I hope this helps :)

---