This is a typical example of a user whoi did set the 'Connect to network about every days' to a value much larger than 1.0. I guess it is set to the maximum of 10.
No one should be able to download more than 8 WUs/day/CPU independent from the 'connect to network' setting. But this guy managed it somehow to circumvent this, because he got many more than 8 WUs/day.
So I share the suspicion, the CPUID must have been corrupted or otherwise changed:
Actually, I think your problems may have sorted themselves out. You've just uploaded another successful result and the server has upped your allocation to 4/day. It was 2/day last time I looked.
This is a typical example of a user whoi did set the 'Connect to network about every days' to a value much larger than 1.0. I guess it is set to the maximum of 10.
No one should be able to download more than 8 WUs/day/CPU independent from the 'connect to network' setting. But this guy managed it somehow to circumvent this, because he got many more than 8 WUs/day.
Michael
Agree partially¹: 'should'!
Actually, the limit changes from 8 to whatever lower limit, when some uploaded result is bad. It does not lower this limit when nothing is uploaded at all.
¹) partially, because there is at least one box with 16 CPU's http://einsteinathome.org/host/229490
and I cound 50+ boxes with 8 CPU's. So a hard limit is not good for these boxes.
I've looked at my settings...I changed connecct to network from 3 to 1 day(s).
If your machine can connect 24/7, then 0.1 is good enough. Every other value is just needed for machines which cannot connect whenever they need to.
Example: Time-limited connections or similar.
If you set the connection to 0.1, this means, that a new WU is loaded about 2.4 hours (144 minutes) before the actual crunch gets ready. When you set it to 1.0, then you always have one which is crunched and one which hangs around.
Please, if you have a permanent connection, then set the 'connect every' field to 0.1. Thanks.
I think you might have 2 ready to roll, is that correct...
On the button Gary.
Keith,
That's good. Your last successful result has validated so all is fine as far as crunching is concerned. If your connect to network is set to 1.0 days then that sounds fine. I imagine your other projects have work and perhaps even have started to crunch in place of EAH. In short, if everything else appears to be normal then you should be OK for the moment.
There is a potential future problem when the xxxx ghosts start expiring. I don't know how many you have and I'm not going to scroll through 80 pages just to look :). If there are already ghosts expiring then this will decrease your daily limit by 1 for each expiring ghost. However you will never go below 1 and it will double for each successfully returned result. Until all the ghosts have expired, you are probably going to have problems getting new work.
I will draw your predicament to Bruce's attention just in case there is any benefit to be gained from your experience. If things deteriorate, please start a thread if you need any assistance.
This is a typical example of a user whoi did set the 'Connect to network about every days' to a value much larger than 1.0. I guess it is set to the maximum of 10.
No one should be able to download more than 8 WUs/day/CPU independent from the 'connect to network' setting. But this guy managed it somehow to circumvent this, because he got many more than 8 WUs/day.
Michael
Agree partially¹: 'should'!
Actually, the limit changes from 8 to whatever lower limit, when some uploaded result is bad. It does not lower this limit when nothing is uploaded at all.
It is also lowered when a result times out, as Gary says one less for each timeout.
Quote:
¹) partially, because there is at least one box with 16 CPU's http://einsteinathome.org/host/229490
and I cound 50+ boxes with 8 CPU's. So a hard limit is not good for these boxes.
Thats why I wrote "8 WUs/day/CPU". So a box with 16 cruching demons will get 128 WUs per day at most. (WU/day/CPU == WU*CPU/day) ;-)
And yes, a hard limit is bad for every CPU needing less than 3h to complete a result.
Please, if you have a permanent connection, then set the 'connect every' field to 0.1. Thanks.
Whilst I fully agree with the sentiment here, you can't really make a blanket statement, even for a reliable always-on connection. The user needs to consider a number of factors other than just the connection itself, eg:-
1. The version of BOINC the user is running.
2. How many projects are in the mix.
3. How reliable are those projects.
4. The actual deadlines of all projects.
5. The accuracy of the original crunch estimate for each result.
6. The resource shares you wish to adopt.
etc, etc.
If Seti is in the mix then you are going to be worried about project reliability.
If LHC is in the mix, look at the huge range of crunch times.
Etc, etc ...
There isn't a simple "one size fits all" and we have to try to see things from the perspective of the individual user. In this particular case I'm guessing that Seti is probably one of four or five projects on this box and a value of 0.5 to 1.0 is probably very appropriate.
Personally, I run 0.1 or less for most of the time but then again I probably do a bit too much "micromanaging" :). There is more safety in a value higher than 0.1 if you don't (or can't) watch things all the time, particularly with the EAH deadline now at 14 days. What a boon that has been.
RE: 2 actual returned
)
So you've actually got no more "ready to run" EAH results on your work tab at the moment?
EDIT: I think you might have 2 ready to roll, is that correct.
Cheers,
Gary.
RE: This is a typical
)
No one should be able to download more than 8 WUs/day/CPU independent from the 'connect to network' setting. But this guy managed it somehow to circumvent this, because he got many more than 8 WUs/day.
So I share the suspicion, the CPUID must have been corrupted or otherwise changed:
http://crystalmark.info/software/CrystalCPUID/index-e.html
Or maybe a manipulation of some *.xml file?
cu,
Michael
RE: Actually, I think your
)
And it was 1 some time earlier today.
I think you might have 2
)
I think you might have 2 ready to roll, is that correct...
On the button Gary.
RE: RE: This is a typical
)
Agree partially¹: 'should'!
Actually, the limit changes from 8 to whatever lower limit, when some uploaded result is bad. It does not lower this limit when nothing is uploaded at all.
¹) partially, because there is at least one box with 16 CPU's
http://einsteinathome.org/host/229490
and I cound 50+ boxes with 8 CPU's. So a hard limit is not good for these boxes.
RE: I've looked at my
)
If your machine can connect 24/7, then 0.1 is good enough. Every other value is just needed for machines which cannot connect whenever they need to.
Example: Time-limited connections or similar.
If you set the connection to 0.1, this means, that a new WU is loaded about 2.4 hours (144 minutes) before the actual crunch gets ready. When you set it to 1.0, then you always have one which is crunched and one which hangs around.
Please, if you have a permanent connection, then set the 'connect every' field to 0.1. Thanks.
RE: I think you might have
)
Keith,
That's good. Your last successful result has validated so all is fine as far as crunching is concerned. If your connect to network is set to 1.0 days then that sounds fine. I imagine your other projects have work and perhaps even have started to crunch in place of EAH. In short, if everything else appears to be normal then you should be OK for the moment.
There is a potential future problem when the xxxx ghosts start expiring. I don't know how many you have and I'm not going to scroll through 80 pages just to look :). If there are already ghosts expiring then this will decrease your daily limit by 1 for each expiring ghost. However you will never go below 1 and it will double for each successfully returned result. Until all the ghosts have expired, you are probably going to have problems getting new work.
I will draw your predicament to Bruce's attention just in case there is any benefit to be gained from your experience. If things deteriorate, please start a thread if you need any assistance.
Good luck!!
Cheers,
Gary.
Cheers for the help.
)
Cheers for the help. Regarding Bruce, I contacted him last time when it first appeared, but before he had chance to take a look...you can guess.
RE: RE: RE: This is a
)
It is also lowered when a result times out, as Gary says one less for each timeout.
Thats why I wrote "8 WUs/day/CPU". So a box with 16 cruching demons will get 128 WUs per day at most. (WU/day/CPU == WU*CPU/day) ;-)
And yes, a hard limit is bad for every CPU needing less than 3h to complete a result.
cu,
Michael
RE: Please, if you have a
)
Whilst I fully agree with the sentiment here, you can't really make a blanket statement, even for a reliable always-on connection. The user needs to consider a number of factors other than just the connection itself, eg:-
1. The version of BOINC the user is running.
2. How many projects are in the mix.
3. How reliable are those projects.
4. The actual deadlines of all projects.
5. The accuracy of the original crunch estimate for each result.
6. The resource shares you wish to adopt.
etc, etc.
If Seti is in the mix then you are going to be worried about project reliability.
If LHC is in the mix, look at the huge range of crunch times.
Etc, etc ...
There isn't a simple "one size fits all" and we have to try to see things from the perspective of the individual user. In this particular case I'm guessing that Seti is probably one of four or five projects on this box and a value of 0.5 to 1.0 is probably very appropriate.
Personally, I run 0.1 or less for most of the time but then again I probably do a bit too much "micromanaging" :). There is more safety in a value higher than 0.1 if you don't (or can't) watch things all the time, particularly with the EAH deadline now at 14 days. What a boon that has been.
Cheers,
Gary.