Times (Elapsed / CPU) for BRP5/6/6-Beta on various CPU/GPU combos - DISCUSSION Thread

Yes I did

2 ULTRA KAZE (3000 rpm, 133 CFM) push air on GPUs and temps drop to 82C

Just want to show temp diference (under the same conditions) between two app version.

1.52 run 17C warmer on GTX 570

On the Sandy Bridge vs. Westmere matter, very tentatively I think that as I have them configured, the Westmere may well have superior memory/IO performance, with the Sandy Bridge having superior CPU throughput, or possibly task switch latency.

As the 1.39 application version put a lot of stress on memory/IO needs, the Westmere won, but with the change to 1.52 that need was wonderfully reduced (improved), so that the latency or actual CPU computational capacity of the host when executing the service task assumed greater relative importance.

(a long time ago, we joked that certain people made hand-waving arguments with such vigor as nearly to achieve lift-off. I'll confess that in this post I'm in that domain).

Regarding TTthrottle. I'm pretty sure it does not use GPU power or temperature targetting. I agree that using voltage reduction, where attainable, rather than task interruption would be an energetically much more efficient means. I don't know whether the requisite control interface is readily available to the developer, nor whether he could readily sort out precisely which GPU installations would appropriately respond to that form of direction as he could supply it. Maybe on reflection I'll post an inquiry on those lines to his user board.

Meanwhile, I may want to re-think my goals of shifting thermal load to desired times of day vs. simple overall power efficiency. If I decide my household power consumption is higher than I'd like, but discard interest in heating impact, I should probably pursue interventions to lower GPU operating voltage, by whatever name they are styled. If I want to shift heat away from the most inconvenient parts of the day, an alternate method to TThrottle is to use BOINC'S operating hours of the day facility, though I recall not liking it much the time I tried it. Even here in New Mexico the sun does not shine every day, and, as the year rolls by, the overheated time period shifts anyway.

For those looking at my hosts, currently I have TThrottle running (the overhead is small), but the limits set high enough that it is not intervening. The room housing two of the hosts is, however, rapidly heading into the part of the year when it is too hot in the morning sun, while the third is in the room where it is slowly getting too hot in the afternoon. So once my RAC gets close to catching up to my 1.52 raised production, I'll probably resume some form of power conservation. I have little doubt that the otherwise wonderful beta applications have raised my household monthly energy consumption above my informal target.

@Gary regarding your notes on GPU time variability in the Results Only thread here http://einsteinathome.org/node/198004&nowrap=true#139604

I do not see much variability in recent tasks.

I also saw some variability in early times.

Instead of using the last 100 tasks - how do the numbers look using the last 50?

Gary,

It is worth remembering that we just report Elapsed time, and not what fraction of that time a particular WU (assuming one is running multiplicity greater than 1X) actually is enjoying the services of the GPU.

Imagine two simultaneously resident WUs, one of which demands CPU service substantially more frequently than the other, but for which said CPU service in practice is accomplished in an infinitesimal amount of time (some combination of negligible amount of computation or transfer actually requested, low latency, high throughput of the CPU...). If task management for the GPU tends to leave it servicing the current task until set aside awaiting service, then in the hypothesized case the more frequently demanding task will be reported with a much longer elapsed time on the GPU than the other, even though in the case I've made up, the two consumed a negligibly different amount of resource.

Something at least partially akin to this oversimplified pictures seems to be going on, as multiple careful observers have observed there to be a sort of base population regarding ET/CPU time, but that WUs running on the GPU at the same time as one of the less favored WUs actually reported materially shorter than base population ET--presumably through no special virtue of their own.

Aside from that, I've noticed in my many adventures of fiddling with process priorities, core affinities, and number of allowed CPU jobs, that for some applications on some hosts, some values of these adjustments would render greatly more equal the ETs for a stream of work which with other settings were far more unequal.

Lots of words, not much of an answer buried in them--but maybe more food for thought on the ET variation issue. Now on 1.47/1.50, I'm convinced that a lot of the variability was driven by a fundamental WU interaction with the code, and the considerable correlation of CPU and ET variation helped give this credibility. I still think there are real "somewhat worse" units for 1.52, but that the strong variation from host to host in 1.52 variability suggests there is some simple "bag squeezing" of the type I sketched above going on also.