Daily Quota issues

We are using an older version of the BOINC server code so it's possible that the behavior is different from other BOINC projects. So far I can't give you a reason why user aborted tasks should decrease the daily quota. The upside of this behavior is that if the host is overcomitted with work (as in your case) and the user aborts it all it would immediately fill up again with new work (if aborts wouldn't decrease the quota). So the quota acts as a brake on this host and gives the user time to sort out what was going wrong.

Implementing the quota per device would be nice but also entails a major rewrite of the relevant code and also non-trivial DB changes that need to be tested and so forth.

Plus a few other tiny things like server resources and bandwidth :-).  Einstein does use lots of large data files.

No argument with that.  However the true gold standard is to not download tasks/data you don't want in the first place.  A system that encourages you to do that is desirable, particularly when it's very easy to avoid getting caught.  You just need to use a little bit of forethought.

So why didn't you just temporarily set NNT for all the projects other than the one you wanted lots of tasks from?

The so-called huge problem of aborted tasks counting against your daily quota is really a storm in a teacup.  OK, let's suppose you have thousands of tasks from this project (for whatever reason) that you really need to abort.  As long as you have just a couple of tasks left that you wont abort (even from a different search or type) go right ahead and abort the thousands of others.  Sure, your quota is now blown.  As you complete each one of the remaining tasks, your quota will double, and double, and double again, so that within a very small number of completed tasks you will be back to full quota.

The other issue that has been mentioned in this thread - the incorrect MD5 checksum being distributed for the JPLEPH data file - has nothing to do with the policy in place for 'penalising' mass aborting of tasks.  It would seem to be very much a server side problem and I don't know why something hasn't been said/done about it.  My entire fleet (with one exception) is unaffected.  Some comment from the Devs would be very welcome, I'm sure.

As for the one exception, last week while the project was having its 'disk full' moment, a car demolished a power pole in a neighbouring suburb here and we lost power for quite a while until things were repaired.   As is always the case with these events, a small fraction of machines may have been doing something critical at the precise moment.  I had a few machines that needed repairs and one in particular with a badly scrambled disk.  It was a SCSI drive running on an old adaptec PCI controller card running in an Ivy Bridge generation machine.   It had a lot of completed tasks on board - the power outage occurred whilst uploading to the project had been out for many hours.  I put a lot of time and effort into attempting to repair the damage and retrieve the unreported work but eventually had to admit defeat.  The controller card had a firmware utility that provided a number of functions like disk verification and low level formatting so I low level formatted the volume and then I was able to create a new set of partitions and filesystems that checked out fine.  So I reinstalled the OS and reloaded BOINC on the same disk.

For me, reloading BOINC is just copying a complete template into place, with the entire project directory preloaded with everything needed.  To recreate the former host ID that the machine had, I edited the template state file to give it that particular ID.  It's a very small set of edits.  When the recreated machine first contacts the project, it supplies that ID and, if done correctly, the server will recognise it and send (in batches of 12 per request) the lost tasks that the machine previously had.  I've never had a case of this not working properly.

This time I had wondered about whether or not there would be a problem with the JPLEPH file.  The project directory contained the correct file but the template state file (by design) contained no reference to it so I knew there would be one sent with the scheduler reply and I did expect it might contain a bad checksum.  I wanted to see if the problem still existed and was prepared to fix it if it did.

And that's exactly what happened.  The scheduler sent the first batch of 12 'lost tasks' and they immediately errored out with the bad MD5sum error.  So I just disabled network activity to prevent the error tasks from being reported, stopped BOINC and corrected the MD5sum in the state file.  While there, I also edited to remove error indicators and change the <result> blocks back to being pristine new tasks as received.  I've done this sort of thing before so I do know what to look for.  On restarting, I had 12 new tasks once again and crunching went ahead without further incident.

I'm documenting all this because it may help the Devs fix the problem, whatever it is.  It would appear you only will be affected by this if you don't already have a correct entry in the state file for the JPLEPH file.  So this should be affecting people who first join or add a new host and subsequently request FGRP style work - both CPU and GPU.  If you have had such work previously on a particular host, the correct entry should already be in the state file so you should see no problem.  Once you correct it, the problem doesn't recur.  As there are different download servers in different timezones, I wonder if it might be just a particular download server involved.  I would have expected to see more complaints if every new host experiences the problem.  Maybe it has already been fixed without comment.  My experience with the problem was some days ago now.