1) Message boards : Number crunching : Linux - any users getting any WU (Message 47751)
Posted 14 days ago by Profile Retvari Zoltan
You speak (type ;-/ ) as if you have some inside knowledge.
I had an experimental Linux host, which stopped receiving workunits without any apparent reason, just like other hosts did. I was experimenting with SWAN_SYNC at that time, and I thought that maybe I've messed up something with the OS or BOINC manager. I think that I've reinstalled the Linux, but it still could not get work after that.

Is there a flag?
That would be a simple explanation, but we haven't received any information related to this issue from the staff yet.

Anyway to say... "curl http... grid...?aflag=vvv" that will return a reason?
I think if there's a flag, you could not check it like this.

And I've said before - I/we are more than willing to lend some eyes. I found out a long time ago (when I was helping Ms. Ada) that you can write some code, has a bug, and you can read it 1000 time and never see the bug.
True, but it seems that Elvis has left the building.
2) Message boards : Number crunching : Linux - any users getting any WU (Message 47742)
Posted 16 days ago by Profile Retvari Zoltan
Ah, I don't have $500, $700 + for a new card just because someone doesn't think a 770 has the horsepower for their job. I was running right at 500K per day - that's not enough? OK, then how about ZERO!
It's not your GTX770, this card should be fine. There's a bug in the scheduler's logic, and it seems it does not send work for many Linux hosts. We could not figure the reason for this error yet.
3) Message boards : Number crunching : GTX 770 won't get work (Message 47741)
Posted 16 days ago by Profile Retvari Zoltan
If you can go back to a driver that supports cuda 6.5 and you should get the old App as I do on my 660ti cc 3.0
This solution works only for Windows hosts, as there's no CUDA6.5 client present for Linux (see the applications page)
4) Message boards : News : App update 17 April 2017 (Message 47717)
Posted 22 days ago by Profile Retvari Zoltan
Excellent detail there, especially the juicy innards of process priorities and the SWAN_SYNC variable!

Just one point of clarification - I believe BOINC CPU apps are set to run at "Idle" priority by default, instead of "Low".
You are right.
This is my mistake, as I use a localized OS (in Hungarian) and it calls this priority level "alacsony" which I've translated back to English ("low"), while originally this priority level is called "Idle".
5) Message boards : News : App update 17 April 2017 (Message 47713)
Posted 22 days ago by Profile Retvari Zoltan
The science and methods have nothing to with with the priority of the executable.
The GPUGrid app (just like any other GPU app) runs at "below normal" process priority, while CPU apps run at "low" process priority (which is one lower than "below normal"). Other processes usually run at "normal" piority.
SWAN_SYNC does not change the process priority level, it changes the behavior of the app.

With SWAN_SYNC off:
1. the app gives the control back to the OS
2. the GPU gives an interrupt (signaling that it has finished the tiny part of the calculation), and due to this interrupt the OS gives the control back to the GPUGrid app
3. The app reads the result, does some calculations in double precision (if needed), then sends the next piece of the calculation to the GPU.
4. it starts all over again, until the number of iterations has been reached

With SWAN_SYNC on:
1. the GPUGrid app continuously polls the GPU waiting for the GPU to finish the actual piece of calculation
2. the app reads the result, does some calculations in double precision (if needed), then sends the next piece of the calculation to the GPU.
3. it starts all over again, until the number of iterations has been reached

Now, with modern Windows OSes there's an extra time needed in every CPU-GPU interactions due to Windows Display Driver Model. That's why the GPUGrid app runs faster (has higher GPU utilization) under Windows XP and Linux.
This cycle has to run a couple of thousand times per second. If the given batch needs a lot of double precision calculations, the difference of overall processing speed between WDDM and non-WDDM OS will be larger, and with SWAN_SYNC on this difference is even higher (due to the missing step in the processing cycle)

Other GPU projects (like SETI@home, or Einstein@home) do not interact that frequently with the GPU, hence they can reach higher GPU utilization.

90% is a dream. Try in the 60s with a single task and low 80s with two tasks. Think of the flops that could be achieved if GPU util was above 95%.
I have 95% GPU usage under Windows XP, so it's not the fault of the GPUgrid app alone.
6) Message boards : Number crunching : GPUGRID active users are falling dramatically! (Message 47673)
Posted 28 days ago by Profile Retvari Zoltan
What happened between 21st & 22nd of April? (actually a month before this date)

Apologies for being late to the party. Assuming boincstats are accurate (and noticing other projects are losing active hosts and users as well) the Win10 Creator's Edition update must have occurred around that time. That certainly broke some hosts.
The Creator's update is not a mandatory update (yet), and it is distributed over a long period of time. I think that those who forced this update could also manage those problems which could prevent GPUGrid from working correctly; if the problems persist they could even revert back to the previous version. The only issue I've faced after updating to the Creator's update is that the Windows Search broke down in Outlook; but it turned out later that it wasn't the Creator's update (as the error showed up on not updated PCs). So my experiences do not support this explanation.

Number continues to fall :(
No, the number of active GPUGrid users is fluctuates around 1800 since two weeks. I think it will rise again in September.
7) Message boards : Graphics cards (GPUs) : GPUGRID slows down after 1:30 min and recovers after pressing key or moving mouse (Message 47663)
Posted 28 days ago by Profile Retvari Zoltan
Yes, it is confirmed that it is another program that works at the same time on the GPU. After closing Boinc in 1: 30m puts the GPU to work until I move the mouse.
In the Task Manager, ordered by CPU, the program does not appear nor hear noise from the system fans.
Have you selected the "details" tab? BTW a GPU mining application won't use your CPU much. NVidia has a monitoring tool which shows the names of your GPUs and the applications which are using your GPUs.

Thanks for the help. I will follow the track of a bitcoin type trojan as these are the only ones that could use the GPU.
Try Malwarebyte's antimalware.
8) Message boards : Graphics cards (GPUs) : No GPUGRID jobs for over a week (Message 47653)
Posted 28 days ago by Profile Retvari Zoltan
Perhaps the server put your host to the blacklist forever. To fix this you should try to force the BOINC manager to request a new host ID for your host. You can do it by stopping the BOINC manager, editing the client_state.xml, searching for <hostid>260678</hostid>, and replace the number to the number of a previous host of yours (or a random number, if you don't have an older host), saving the client_state.xml, and restaring the BOINC manager. Maybe it won't work for the first time, so you might try this a couple of times.
9) Message boards : News : App update 17 April 2017 (Message 47639)
Posted 31 days ago by Profile Retvari Zoltan
... GPUGRID fails to resume properly after being suspended. ... The task in question was a 918 version.

Are you aware of this issue?
It's a know bug, seems to depend on the workunit batch.
A similar bug is when you (or the BOINC manager) suspend(s) the task, it could take a while when it really happens.

Is there any additional information I can provide?
No.
10) Message boards : Graphics cards (GPUs) : No GPUGRID jobs for over a week (Message 47633)
Posted 33 days ago by Profile Retvari Zoltan
Exit BOINC manager with stopping scientific applications, and then update your NVidia driver.


Next 10