New Dataset 15% Faster
29 Jul 2006 5:19:50 UTC
Topic 191629
(moderation:
Has an optimized been done to cause this? Running the same frequency on an sse3 and all of a sudden 2 of the last wu's have my stated increase.(1 in progress as of this edit) Nothing changed on this end. Is there that much difference in datasets? And I am on a new one in same frequencies with these results? Or is there a speedup in the app? here
I also am claiming the same amount of credit.
New Dataset 15% Faster
)
Nothing changed at our end.
There shouldn't be a noticable difference in the operations necessary to run two workunits if the give the same credit.
However in reality - on modern OS - there are some operations necessary that aren't related to the actual calculation (switching tasks, restarting tasks from checkpointing, cummunication with the BOINC client etc.), so the actual CPU time varies a bit (by a few percent). But 10 or 15% is a bit too much. Is this consistent with wall-clock time?
BM
BM
Yes Bernd it does bear out to
)
Yes Bernd it does bear out to wall clock time. I do run an optimimized Boinc client but the real cpu time co-oberates my findings.
I do also run seti in tandem,HT,but I do not believe that there should be that big a difference for about a day now from what I have been running previously for weeks now.... But thank-you for your quick response and do hope if you do optimize on the server end you do announce this first. such as supporting sse2,3,3DNOW,etc...There must be something different with the seti units I am running to cause this...or thier truly is some difference with the datasets that can cause some to credit hunt(as I have previously noticed on another host w/o HT)...I hope the latter is not the case..
RE: Has an optimized been
)
What does this snippet from one of your results tell you? ;-)
5.3.12.tx36
70820
67728
2022.7
cu,
Michael
RE: RE: Has an optimized
)
Michael it tells me real cpu-time vs. reported...and watching wu to clock time it bears out....there is a difference perhaps at times 5-10% in what time it took and what was reported by the client....so I wish to take this out of the equation.If you look at the host in questions previous consistent run times of the wu's still showing you will see what I am questioning here
If I understand your right,
)
If I understand your right, one 'virtual' CPU is running E@H and the other one E@H. Because these CPUs share the same resources(FPU, SSE etc.), there can be noticeable time differences.
cu,
Michael
RE: I do also run seti in
)
In running HT, one increases ones chances of getting variation in reported CPU time, depending on what sort of application is in "the other" thread at the time your thread is running.
I've seen examples both ways--where the "other" application can cause a longer reported CPU time, and where a different other application can cause a shorter one.
Long preamble--short suggestion: is it possible that your system has had a material difference in its non-Einstein workload lately? Or that cache depletion, long-term debt correction, or the like has caused a difference on pairing?