I'm not receiving new WU's for about 14 days or more. Somewhere here I've heard that this is just because longterm debt comes negative because of ... (don't know what of... I didn't reached any deadline in no of 3 projects I am in). Today's morning I had LTD=~-400000. I just suspended other projects and it downloads a new 6Mb file and 2 WU's for it. Rigth now I've uploaded these WU's and my LTD becomes ~-500000.
So, I suppose I have to wait for 5 days? But what for?
Explain please...
Copyright © 2024 Einstein@Home. All rights reserved.
My longterm debt gets down lower and lower...
)
I guess you are speaking about this host.
When looking further, you will see this host has only a "Maximum daily WU quota per CPU" of "2/day". Looking into the results, a lot of them have "Client error" due to "user requested transfer abort". This is the reason why you can only download 2 WU's the same day as the WU that has not returned a valid result lowers the daily quota.
The LTD will of course play a role also. If the aborted transfer of the WU's are playing a role in the LTD is something I don't know.
What is your setting of "connect to network about every xx days" ?
Greetings from Belgium
Thierry
RE: I'm not receiving new
)
Your last successful return of work was on 25th July and the server tried to send you 8 new work units on 27th July which is rather less than 14 days ago. It's actually less than 10. About 4 days ago you started another thread where you complained about getting large data files too frequently. Bruce asked you in that thread whether you were getting the same data file downloaded repeatedly or whether it was a new one each time. You told him it was a new one each time and you also said that because this was obviously some sort of error, you aborted the transfers.
Well, here is the story of what actually happened which anyone can find out by looking through the results list for the computer that had the problem - the one Thierry actually linked to. Your last three successful results were returned on 21, 25, 25 July respectively. There may have even been more but these have started to drop off the end of your results list because of their age. However the important point is that this successful work around 21 july would probably have been done in EDF mode (what I call the "deadline dance") and this is what probably started a small negative LTD for EAH. By 27 July, this debt may have been repaid or you may have forced the issue by suspending other projects - it doesn't really matter. EAH was ready for new work and there was an attempt to download 8 new units.
By chance, your last successful work had used up the large data file "w1_0679.5" which was now exhausted and the new work needed a new large data file "l1_1418.0" which was attempted to be downloaded from the server - all perfectly normal. This would have been the download that you aborted - 8 times in a row - which caused the trashing of your complete daily allowance. In the other thread, when Bruce asked you the question, you should have made it very clear to him that it was the same large data file that you kept aborting. He may have gone off chasing some obscure but non-existant bug :).
The thing I don't understand is how this aborting gave you a large negative LTD. There was no accumulated cpu time in those aborted units so I would have thought that there would be no effect on the LTD calcs. Bit of a puzzle .... Maybe JM7 can come up with an obscure bug in CC4.45 which adds -50,000 to LTD for every aborted unit :). Or maybe there's some simple explanation I'm missing. Was the negative LTD always there and did you force the download on 27 July by suspending the other projects? That would make sense, maybe??? Please realise that a projects LTD becomes negative if it has had more than its fair share of the cpu, according to the resource share that you have set.
Before I started writing this only one of the two was showing as "uploaded and reported". The other was still "in progress". It may have been uploaded and not reported. By the way, your new large data file which you allowed this time is "w1_1015.0" and it should be good for a few work units before it is exhausted, hopefully. However there is no guarantee and by bad luck, the two work units you have could exhaust the data file and you may need a new one again next time, particularly as "next time" could be quite a while away :).
The increase in negative LTD is perfectly normal. You forced BOINC to download new EAH work when it wasn't entitled to it. This has been recorded and your other projects will be given even more cpu time to compensate. You will now have an even longer "deadline drought" for EAH because you interfered.
If you really want EAH to get more of the cpu you should re-assess your resource shares and give EAH a bigger number. While all this restabilizing is going on, you should lower your "connect to network" setting as this speeds up the process of achieving stability. Choose a value of 0.1 and update projects regularly as work completes. Once the debts have been repaid, increase the "connect" setting to 0.5 - 0.75 - 1.0 - 1.25 etc, slowly and progressively until you find a setting that gives you enough work on hand without having to continually do the deadline dance. Don't make a further increase until you see the effect of the previous one. The motto is - have patience and don't interfere :).
As a matter of interest, what are your actual current resource share numbers for each project and what is your "connect to network" setting?
Cheers,
Gary.