| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
| World Community Grid Forums
|
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 13
|
|
| Author |
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
OK, I have this spare desktop that is set up to dual boot Windows XP and Gentoo Linux 2007.0. I have both set up to use the BOINC client.
Here are the funky results:
Keep in mind that this the exact same computer doing the work. Why is the Linux client taking SO much longer to churn out work compared to Windows XP? |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Hello Surface,
My first guess is that the throttle is not set to 100% on your Linux client. My second guess is that you may have a background process running on Linux that preempts the CPU. Lawrence |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Thanks for the starting points Lawrence.
I ran a quick test to make sure that the faah module was using 100% CPU... it is. When I run top it is constantly in the %99.x range. As far as background tasks preempting the CPU... I'm a little muddy on what all is exactly setup on my Linux partition. I did shut down X and ran BOINC for the console for two days, but that did not seem to affect the time. There is some 'preempt' terminology in the kernel config, much of which is over my head (or not explained well). Anyway, as long as BOINC does not restart the faah module, I can run the client overnight and then check top in the morning to see what the CPU time says vs. how much time has really elapsed. Not sure if that will help much though. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
OK, here is some more info...
Running the CPU benchmarks gives these results: Linux Benchmark WindowsXP It seems the things that are running in the background in linux are: avahi dbus hald crond (I shut these down before running the benchmarks) Other things to note are: Linux is running in vesafb console mode (no X), and I'm using udev. The difference between the benchmarks doesn't seem like it would cause such a big time difference... but I really don't know what the benchmarks are measuring. I'm guessing that, at this point, I need help tuning my kernel. Unless there ARE some differences between the two BOINC clients? |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Hello Surface,
Could you look at the Results Status page and confirm that the last FAAH result took nearly 30 hours to run in Linux? If that is confirmed, then somebody with Linux experience will have to help out. Lawrence |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
OS Status Sent Date Return Date CPU Points |
||
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
Suggest to check what the actual CPU mhz/ghz speed is when the BOINC process is running under Linux. That OS should in fact, so is the word, process a job slightly faster.
----------------------------------------
WCG
Please help to make the Forums an enjoyable experience for All! |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Hello Surface,
The Results Status show that you run your Windows work units at about the same speed as other Windows computers, but that you run your Linux work units much slower than other Linux users. So the problem is not with Linux but with something on your computer. As long as your throttle is at 100%, the only cause that I can conceive is that some other process is running in the background. Lawrence |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Sekerob:
Linux: Lawrence: Here is a ps dump... Thu Sep 27 17:28:19 CDT 2007 The thing that makes me think that the its not background tasks is that the CPU time is quite high. If it was a background task taking over, the CPU time for FAAH would still be around 5hrs, but BOINC is reporting that the task had control of the CPU for 16-30 hours. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Hi Surface.
One invalid, and one wildly overrunning and overclaiming task. It's not looking good for Linux, is it? My colleagues may have been chasing red herrings, since the throttle doesn't affect CPU time - it just makes the task run longer in wall clock time. The same is true of other processes leaching CPU time from WCG. So, what can cause discrepancies in CPU time? Actually, more than you might expect. Power saving features on the CPU can cause it to underclock. Memory problems have a significant effect, particularly if your L2 cache is damaged or disabled. Finally, intensive IO will affect crunching. Don't run BOINC at the same time as your backup process, and be wary of inconsiderate virus scanners. |
||
|
|
|