If it happens again with more t4 works, I'll limit max_cpus, I assume it'll stop the server from sending me t4 tasks?

Two tasks supposedly terminated "successfully" after only a few seconds on one of my computers: 2276475 and 2278138. Both tasks were using the t4 version of NWChem long, and I suspect there's an error somewhere which wasn't detected properly.

The wingmates are still to return their results but the instant execution looks suspicious.

For the current batches :
short WUs : 200 credits
long WUs : 5000 credits

no this file is located in shared directory that is in the slot directory. example :

/var/lib/boinc-client/slots/1/shared

full example :

benoit@damotaf:~$ sudo ls /var/lib/boinc-client/slots/1/shared
 000764309.xyz	 input.tar.gz   nwchem_cp       OPT.b	    OPT.c    OPT.drv.hess    OPT.movecs   OPT.out   OPT-restart.nw   pub.pem   TD_singlet.nw
 FREQ.nw	 NWChem         NWChem.tar.gz  'OPT.b^-1'   OPT.db   OPT.gridpts.0   OPT.nw	  OPT.p     parameter.json   run.sh

I don't know about the Windows client, but the Linux client I get this boinc PPA
It works pretty much straight out of the box.
For ryzen and threadripper, setting cpu to 99 seems to work as well.

I am at work but can do this tonight when I get home. Is that file located in the project folder?

Thanks,
Greg

NWChem long queue is empty, no units to download.

Is it planned to add more wus?

Thanks!

Just got my first t8 Long to validate with credit. It ran for 73 hours.

Dear Crunchers,

Yesterday, I had to suspend an account for two weeks and remove credits, for obvious credit cheating. I'm quite annoyed that instead of doing science, I have to deal with this kind of behavior. We're small and we're short on time and it doesn't help scientific research...

The current credit system is too easy to fool, so I'm going to move to something simpler, robust and more generous on average: fixed credits. For short tasks (such as od9), I'm going to award 200 credits. This change requires draining the task queue. At that time, I will submit new tasks. These new tasks will be the opportunity to deploy the new code with checkpoints, system signals and affinity management for large systems (>32 cores). Some errors are to be expected, I can't test everything.

The last point concerns the requests for Gridcoin. I've been asked by the developers and by some of you. I am not against this possibility, but three points do not allow for the moment to be whitelisted. First, I can't guarantee to always have tasks waiting to be calculated. Secondly, the incentive to cheat will increase and I find that increasing the quorum is a waste of resources. Thirdly, I'm struggling with the server to keep it up. The upcoming arrival of larger molecules should settle the first point. For the second point, we are thinking about a validation by analyzing the result. I have already made many optimizations for the third point, at the moment it's much better.

Kindly
Benoit Da Mota

My suggestion would be to get with other Admins at other Projects and discuss both the User and how they are dealing with it, maybe even the folks at Seti as they are the ones where alot of people start crunching. You are not the first nor the last Project where people have tried to cheat, MOST get caught eventually. If a User is cheating here you can bet they're trying to cheat elsewhere too!! And yes being WhiteListed means a higher chance of people trying to cheat as it means more money in their pocket, that does NOT make GridCoin a bad thing it's just another thing for you Admins to be on the lookout for.

I recommend setting Max # CPUs = 1.