5970 - Timing Observation
Questions and Answers : Windows : 5970 - Timing Observation
Reporting a (possibly) strange timing for 5970s. I am running two 5970s in my main box. They complete in circa 360-390 seconds @810/300. The recorded time in my account is either side of 690 seconds. The GPU timing is exactly the same as the CPU timing according to my Account record for the machine, but its not using that much CPU - in reality its hardly using any as such.
|ID: 388 · Rating: 0 · rate: /|
The GPU timing is exactly the same as the CPU timing according to my Account record for the machine, but its not using that much CPU - in reality its hardly using any as such.
You seem to be using core 0 and that CPU equals GPU time is probably an effect of that. I've seen CPU time lowering if I switch to core 3 (in project preferences). Maybe you should try that and see if it makes a difference. It can also affect completion times (faster or slower, depending on things), though.
You seem to have some CPU cores dedicated for feeding GPU units so that's probably why you are not negatively affected by the "extra CPU usage". If you didn't, this would probably make a difference.
Hmm, is there also a difference in recorded runtime vs. time shown in the last Summary on the stderr output?
|ID: 521 · Rating: 0 · rate: /|
..... Hmm, is there also a difference in recorded runtime vs. time shown in the last Summary on the stderr output? ..
Yes, thats my main point, and why I posted in the first place.
The recorded runtime is always close on twice the time shown in the last summary of stderr - hence my lose deduction of maybe it has something to do with me running crossfire, and some part of the timing algorithm is counting by card .. x2 .... ?? Not exactly the most scientific conclusion of the month rofl, but will serve to illustrate more where I am coming from.
The recorded CPU time is always the same as recorded GPU time. Actual observed reality crunching time is always the same as the last summary of stderr - hence why its never fussed me as such, its academic in a credit sense.
Due to the latter, it all has no effect on me in a practical sense, from that angle its a curiosity.
However from the Project perspective, the incorrectly recorded GPU time gives a false impression to those thinking of joining, and who browse through completed WUs to get examples of how card types are running vis credit awards before making a decision to join. It will also seem to prospective 5970 joiners that here 5970s are crunching at half the rate that DNETC does, for the same credit award. Looking at the number of 5790s around the Project in the dual card category, the number of those coming to that irroneous conclusion may well be more than would seem the case on the surface.
A more wild thought is it maybe around for any card type that runs as a dual in crossfire, leading to the irroneous conclusion that crossfire is bad in the Project. The latter has been stated, but I've always doubted that, as I cant see any reason for it being so, and have never observed any negative effects of crossfire - unless I'm missing something so close to me nose that I cant see it :) Many card types will be better off running no crossfire due to the scaling penalty inside the Driver - an age old AMD issue, which whilst getting better is still there. For 5970s, its a different equation, as it has to run crossfire inside each card anyway, so whilst there may well be a scaling issue when running two 5970s in crossfire, whether or not individuals would actually do so is very much a personal choice. Most running 5970s do choose to run them crossfire.
Both effects of incorrect recorded GPU time, are easily resolved by looking inside stderr at the summary statement, where it will always be found that stderr time = reality time. But, how many will do that on initial look at the Project, or even existing crunchers drawing the wrong conclusion from GPU output recorded time, trusting the latter to be correct (when in fact its not).
EDIT: If you decide to run some tests on this with test WUs or part WU/part algorithm, delighted to help by running some for you - I can pm you my mail addy to send them to as part of an "in house" test if it helps
|ID: 530 · Rating: 0 · rate: /|
Quick follow on from this, another observation which may help.
|ID: 560 · Rating: 0 · rate: /|
|ID: 573 · Rating: 0 · rate: /|
Okie Doke - will give it a go - I do have a one day cache set, so will be a while before I come back if the selection is inside the WU - dont know how that operates. If its just a case of selection and update and then will work via core 3 greatful you let me know, I can then keep an eye open for changes a little better. I assume Core 3 will turn up inside the stderr, not core zero as at present.
|ID: 576 · Rating: 0 · rate: /|
If its just a case of selection and update and then will work via core 3 greatful you let me know
Yes, just set new core number on the preferences and do an update from your client. New core should be used when next work unit starts and it will be logged in stderr output. That's where you can also verify any speed differences.
|ID: 593 · Rating: 0 · rate: /|
Questions and Answers :
5970 - Timing Observation