1) Message boards : Server and website : Unable to get WUs (Message 48009)
Posted 3 days ago by Profile Retvari Zoltan
The "one-week crunching" contest is not put on by GPUGrid, and they shouldn't be blamed if it coincides with a work shortage. In my opinion, the contest should use some other project.

Yes, it is annoying. They always seem to pick on the projects that are low on work. I don't think they bother to check.

This project (perhaps others too) is using a very low work cache, to achieve very short turnaround times (as the next work is generated by the results of the present workunits). When a crunching contest lures many users to this project, the work cache runs empty in a very short time.
The project personnel keep an eye on the workunit cache, and add some work to it if it's ready and needed.
2) Message boards : Graphics cards (GPUs) : How often should I replace my GPU thermal paste? (Message 47976)
Posted 6 days ago by Profile Retvari Zoltan
if I use this gpu constantly every day, how often do you recommend I change the thermal paste?
I recommend doing it every spring (before the hottest time in the year).

Now I am aware that they don't need changing unless they get close to their max temp
This is the other aspect: if the GPU temps are high (or higher than usual) it's needed to dust off the fins, and perhaps change the thermal paste.

It's like changing the oil in the engine of your car: it should be done after every 15.000km (~10.000 miles), or every year; whichever comes first.

but I'm really trying to get the most life out of mine as possible.
While lower temps are good for longevity, every such operation (disassembling the PC and the card itself) has a risk of causing a fatal failure by physical harm (kicking of an SMD component, dropping the cooler assembly on the card, bending the PCB, etc) or electrical harm (static discharge).
3) Message boards : Number crunching : 1 Work Unit Per GPU (Message 47964)
Posted 14 days ago by Profile Retvari Zoltan
I reproduced your problem - GPUGrid GPU tasks aren't honoring that <process_priority_special>. Other projects' GPU tasks do honor it.

I guess that's another bug to add to GPUGrids list of brokenness. Dangit.
If I can recall it correctly, this behavior is intentional.
Originally, the GPUGrid app run at the same process priority level ("Idle") as CPU tasks, but it turned out to hinder GPU performance. Back then this <process_priority_special> did not exist (or the staff thought that it wouldn't be used by many participants) so it's been hard coded into the app to run at "below normal" priority level.

EDIT: it was the result of "iterating" the optimal process priority level, as when it was hard coded to "above normal" some systems (Core2 Duo and Core2 Quad using SWAN_SYNC) became sluggish back then. While it's not explicitly stated, see this post by GDF (and the whole thread).
EDIT2: See this thread also.
4) Message boards : Number crunching : 1 Work Unit Per GPU (Message 47954)
Posted 15 days ago by Profile Retvari Zoltan
Thanks for the reply. I'm curious how much of a speedup your process hacking actually gets?
I was experimenting with process priority and CPU affinity also on my various CPUs (i7-870, i7-980x, i7-4770k, i3-4160, i3-4360, i7-4930k), but the GPU performance gain from these tricks was negligible compared to the lack of WDDM, and less (or none) CPU tasks.
This led me to the conclusion that a single PC could not excel simultaneously in GPU and CPU performance, thus there's no need for a high-end CPU (though it should be state of the art) to maximize high-end GPU performance. It is very hard to resist the temptation of running 12 CPU tasks on a very expensive (6-core+HT) CPU which will reduce GPU performance; thus it's better to build (at least) two separate PCs: one for CPU tasks and one for GPU tasks. This is the reason for my PCs with i3 CPUs: I rather spend more money on better GPUs than on better CPUs.
Regarding RAC (or PPD): the loss of RAC of a high-end GPU by running CPU tasks simultaneously on the same PC is much bigger than the RAC gain of CPU tasks, so the overall RAC of the given PC will be lower if it runs CPU and GPU tasks simultaneously.
Of course if someone could have only one PC, their possibilities for performance optimization are limited, and my advice is not worth to be applied (because of the huge loss in the user's overall CPU performance).
Sorry for writing the same thing different ways many times, but my experiences are confirmed by the fact that my GTX 980Ti's (driven by i3 CPUs) are competing with GTX 1080Ti's on the performance page. Though the days of my GTX 980Ti's (running under Windows XPx64) are numbered, as the next generation (Volta) GPUs will wash them away from the top list even with WDDM, we could still use Linux to avoid WDDM, so my advice will still stand.
5) Message boards : Number crunching : 1 Work Unit Per GPU (Message 47953)
Posted 15 days ago by Profile Retvari Zoltan
is the 1 Work Unit Per GPU rule now set?
It's not set. There was a debate about this earlier when there was a shortage, with minimal response from the staff.
I think it would be much better if the low-end cards would be refused to get work from the long queue, as this is predictably futile considering the 5 days deadline.
See this workunit.
6) Message boards : GPUGRID CAFE : The milestone thread (Message 47943)
Posted 18 days ago by Profile Retvari Zoltan
Gratulálok - I hope that is congratulations in Hungarian.
That's right. :)

Luckily this is a one word phrase (without any synonyms), so the machine translation won't mess it up. But (believe me) don't try to machine translate complex sentences to Hungarian, as it will be: (perhaps it's true for many languages)
a, funny
b, gibberish
c, ambiguous
d, unintelligible
We (Hungarians - perhaps other nationalities also) exploit this as a spam filter, as machine translated spam messages usually fit to at least one of the above.
The funniest results of such machine translations come from the far east, usually in the form of a user's manual.

Köszönöm szépen! "Thank you (very) much!"
Google translate will do this right only because this is another unmistakable phrase.
But
Köszönöm = Thanks
szépen = beautifully
If I say "Nagyon köszönöm" it means the same thing,
Nagyon = very (much)
in this case the order of the two words are reversed, because this is a simple attributed expression with the same meaning, but more formal than "Köszönöm szépen" (which is more informal)
The subjective is usually hidden in the Hungarian language, unless it should be emphasized, or to make it unambiguous (so in the formal language it's usually not hidden).
The combination of the above is also valid (and have the same meaning):
Nagyon szépen köszönöm! (which is formal and informal also)
7) Message boards : Number crunching : 1 Work Unit Per GPU (Message 47942)
Posted 18 days ago by Profile Retvari Zoltan
less CPU tasks = higher GPU usage
To clarify, are you saying that the only reason that disabling HT is showing an improvement is because it's reducing the number of CPU tasks from other projects?
Yes.

That would imply that the increase in CPU usage from 12.5% (HT) to 25% (HT off) does not in itself improve WU return times.
Yes.

For example, if no other projects were running, I would still think that more CPU usage is better regardless, but perhaps it is not that simple.
It's not that simple, as there are many factors which are reducing the GPU usage.
WDDM has the most impact, and it can't be turned off; you should use Linux or Windows XP (up to GTX 980 Ti, so you can choose only Linux for your GTX 1080)
More than 1 CPU task usually cause demonstrable decrease (depending on the task, as these are usually work on large data sets, which won't fit in the L3 cache of the CPU, thus they will flood the memory bus which will slow everything down a bit).
Using SWAN_SYNC (in combination with no CPU tasks) could increase the the GPU usage on Windows XP by up to ~15%, and by up to ~5% on Windows 10.

BTW you can try it very easily by simply suspending all CPU projects in BOINC manager for a test period.
8) Message boards : Number crunching : 1 Work Unit Per GPU (Message 47940)
Posted 18 days ago by Profile Retvari Zoltan
I've been experimenting and have seen slightly higher utilization when HT is off on my i7-7700k.
That's because there are only 3 CPU tasks running when HT is off, and 7 when HT is on.
You can gain a little further GPU utilization if you run only 1 CPU task, or no CPU tasks at all.

[when HT is off] CPU usage jumps from 13% to 25% per WU
That's because when HT is on your CPU can handle 8 threads (on the 4 physical cores), so one thread uses 100%/8=12.5% (~13%),
while your CPU can handle 4 threads on the 4 physical cores when HT is off, so one thread uses 100%/4=25%

GPU-Z shows a small gain in usage [when HT is off].
See my first explanation for its reason. (less CPU tasks = higher GPU usage)

I wish there was a way to force the WU to use a full physical core without turning HT off, but I haven't been able to figure it out. I tried setting <cpu_usage>2.0</cpu_usage> with HT on, but that didn't help, still 13% usage.
The <cpu_usage> option tells the BOINC manager how many cores (threads) to assign for the given application, it does not instructs the application to use that many cores (threads). You can use the SWAN_SYNC environmental variable to instruct the GPUGrid application to use a full core (thread), but it won't use more than one.

My comments apply to Windows 10, cpu usage in Linux seems less, I'm not sure this would help there.
There's no WDDM in Linux, so GPU usage will be higher under Linux than on Windows 10 (Vista, 7, 8, 8.1).
9) Message boards : GPUGRID CAFE : The milestone thread (Message 47933)
Posted 21 days ago by Profile Retvari Zoltan
Today I've passed over 10 billion credits.
My new rank is Tryptophan.
It took 7 years and 2 months.


Start: June 2010. (GTX 480)
300 million: 17 Sep 2011. 248 days to pass over Stoneageman :DD
400 million: 27 Nov 2011.
500 million: 26 Jan 2012.
600 million: 22 Mar 2012. (the release of GTX 680)
700 million: 13 May 2012.
1 billion: 13 Sep 2012. (28 months since my start)
1.5 billion: 8 Feb 2013.
2 billion: 28 Jun 2013. (9 months since 1 billion)
3 billion: 9 Apr 2014. (9 months since 2 billion)
4 billion: 15 Nov 2014. (7 months since 3 billion)
5 billion: 1 Jun 2015. (7 months since 4 billion)
6 billion: 3 Jan 2016. (7 months since 5 billion)
7 billion: 7 Jun 2016. (5 months since 6 billion)
8 billion: 26 Nov 2016. (5 months and 19 days; 172 days since 7 billion).
9 billion: 21 Mar 2017. (115 days since 8 billion; 5 days less than 3 months).
10 billion: 30 Sep 2017. (6 months since 9 billion due to reduced heat output for the summer)
10) Message boards : News : An important note for Windows XP users (Message 47909)
Posted 30 days ago by Profile Retvari Zoltan
I agree that support should continue for xp as long as the video cards that it supports are still relevant to the project.
Me too.

Here is an example of an obsolete computer, running an obsolete operating system, with an obsolete video driver in the top 10 in the performance tab:
Rank User name Avg (h) Total GPU description of fastest setup 1 Phil 5.08235 17 NVIDIA GeForce GTX 1080 Ti (4095MB) driver: 384.94 2 Retvari Zoltan 6.03388 121 NVIDIA GeForce GTX 980 Ti (4095MB) driver: 358.50 3 PappaLitto 6.10000 54 NVIDIA GeForce GTX 1080 Ti (4095MB) driver: 385.41 4 Bedrich Hajek 6.13636 11 NVIDIA GeForce GTX 980 Ti (4095MB) driver: 355.82 5 Thurgwood 6.22727 11 NVIDIA GeForce GTX 1080 Ti (4095MB) driver: 382.33 6 Tobi 6.35294 17 NVIDIA GeForce GTX 1080 Ti (4095MB) driver: 385.41 7 bcavnaugh 6.45224 67 NVIDIA GeForce GTX 1080 Ti (4095MB) driver: 378.92 8 Trotador 6.57273 22 [2] NVIDIA GeForce GTX 1080 (4095MB) driver: 370.28 9 Jackal 6.67368 38 NVIDIA GeForce GTX 1080 (4095MB) driver: 385.28 10 Drallin 6.74375 16 NVIDIA GeForce GTX 1080 (4095MB) driver: 385.41

It's actually number 4 right now, ahead of a few (not all) pascals, but still relevant.
My WinXPx64 host is number 2 on this list.

Did they hire the new technical people, yet?
There's no sign of that.


Next 10