Run Time Mystery
23 Jul 2013 4:27:20 UTC
Topic 197089
(moderation:
I currently have three CPU only machines running Binary Pulser WUs. All three have 64bit AMD dual core CPUs. Two have a CPU clock speed of 1.9 GHz and running 32 bit WindowsXP. The third has a CPU clock speed of 2.6 GHz and is running 64bit Windows 7. (CPU clock speeds as shown by CPU-Z).
The Win7 machine takes an average of 8.6 hrs per WU whereas the slower Win XP machines only require an average of 3.8 hrs ! All three machines are also running Cosmology@home -- run times for those jobs vary from WU to WU, but it appears that the Win7 machine is faster -- as it should be.
I note that the application version is different for the XP machines and the W7 machine -- BRP4X64 for 64 bit Win7 and BRP4SSE for 32 bit WinXP. Is something amiss in the 64bit app, or what??
BOINC bench marks are definitely better for the Win7 machine --
XP Machines: 1851/1922 FP, 3167/3271 INT (one measures slightly faster).
Win7 Machine: 2342 FP, 6029 INT.
I posted a similar note earlier when I was running gamma-ray pulser WUs and noticed a similar ~3X longer run times in the Win7 machine. Someone suggested that maybe it was paging since in had 'only' 2Gb of memory -- that did not appear to be the case, but I increased the memory to 4Gb just in case; no change.
When BOINC is not running in the Win7 machine, the System Idle time is 98 to 99%, so I don't think anything else is taking up any significant CPU time.
Has anyone else seen this sort of thing, or is it just me?
Run Time Mystery
)
I run also the Gamma-ray pulsar search tasks and i have very different runtimes.
1 has finished after less more than 6200 sec. the other shows 9to 10% in progressbar.Is that normal?
My system Win7 64,12Gb Ram.Irun 6cores simultan.
Greetings
Regardless of whether it
)
Regardless of whether it takes 4 hrs or 8 hrs of CPU time to run a BRP4 WU, the skimpy 62.5 points of credit just ain't worth it!
But I still believe that there is something wrong with the BRP4 64-bit app -- the Win7 machine in question runs WUs from other projects in less time than the XP machines. NOT the case for BRP4X64 WUs.
RE: the Win7 machine in
)
That might be a clue, right there
If you are mixing simultaneous work from multiple projects, the ways that the jobs compete with each other for resources will vary with architecture.
If you want to simplify your assessment of the behavior of your host on a particular project, you'd get a more comparable answer by assuring that in the interval for which you make the comparison, it runs work of only exactly one type (not just one project, but one flavor within that project) on all cores (virtual or not)
I've seen cases where for a particular combination of tasks, the "least favored" type could make remarkably slow progress--just because the competition for resources was adjudicated by the OS "not necessarily to its advantage".
None of this is any sort of evidence of something wrong with the BRP4 application.
RE: RE: the Win7 machine
)
Maybe... maybe not. I have another machine with similar hardware running 64-bit Windows7 running a mixture of projects - but NOT Einstein@Home - that does not show this behavior.
Anyway, I've removed Einstein from the machine in question and am now running SETI instead.
Good hints in this
)
Good hints in this thread.
My einstein tasks were making no progress and Seti were.
Suspending Seti tasks got Einstein going again. But only 4
of them actually taking meaningful CPU, 6 others claim to be
running but they are not taking much CPU at all (none?).
So there is something in the scheduling.
This on x86-64 Ubuntu 13.04. Linux kernel 3.8.0-27-generic #40-Ubuntu SMP
A 12-physical-core machine restricted to 10 cores for boinc.
With Seti suspended, I
)
With Seti suspended, I suspended Einstein and then resumed Einstein.
Now I have 10 einstein making progress instead of just 4.
Resumed Seti tasks and things look 'normal'.
I have no idea what was going on, but at least I have a simple
workaround if I get into that odd state again.
The 'running' einstein (the ones not making
actual progress) were showing --- as remaining.
And Linux knew they were not really running, though boinc
thought they were running.
Or so I think now.