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.

Credit award is fine and normal (3880 per WU), and all seems fine - except the seemingly strange timing that is recorded. Had a nose around, and most folk seem to get a reality timing for CPU - for some reason my GPU timing is just under twice reality, and always matched by the same timing for CPU.

Makes no difference in reality to me, its all ticking along nicely, just a wierd timing recorded. It maybe a side effect of running the two cards crossfire, dont know. I am running 4 PRPNet WUs on the 6 cores, so plenty left over to run the GPU WU.

Just reporting a strange observation, not expecting any "resolution" as such, as all else seems ok.

Regards
Zy

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?

-w

..... 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

Regards
Zy

Quick follow on from this, another observation which may help.

Last night I cut back on some CPU WUs that I was running. I knew it would hit the GPU a fair bit running them against all 6 cores, but wanted to help out on a Project. However I decided I had done my bit for them, and cutt back on CPU core tasks, so that one Core was freed up for use by each GPU.

GPU WU speed as expected went up by 30% or so (11 mins down to the now +or- 8 mins), which was in line with expectation. The surprise was the recorded GPU time, that went up also (!) from circa 1100 seconds to either side of 1900 seconds (recorded GPU & CPU time are still the same).

Stderr time on the summary line remained the reality time though, so as before the recorded GPU time is cosmetic, reality for the time actually taken is Stderr time. Looks like something inside the Wrapper is not counting the actions of the Core application properly - its a re-run of the posts above, just confirming it is happening and not a one off.

Regards
Zy

Hi,

Indeed, there's a significant difference. Could you try to switch to core 3 and see if that helps with recordings?

CPU time is indeed something that's recorded by the wrapper but I'm using BOINC library functions for that. I'll try to verify for next version if there's some bug with that.

-w

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.

Any other tweek or experiment you want running, post or PM me - delighted to help if I can, no problems using me as a quiet guinea pig :)

Regards
Zy

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.

-w