Bruce is aware of this and is watching. I don't know if there will be a change. The last word I had was that these short work units/results are likely to be an anomaly ... I have been getting some work that is in the 2 1/2 hr area, but like you I am doing them as quickly as 48 minutes on the G5 ...
OK, thanks, Paul.....I guess we will just have to be patient and keep monitoring the faster machines.....Cheers, Rog.
No need for active monitoring except on dial-ups - just set a low resource share for Rosetta (a 1% share will still complete its wu for the 28 day deadline) and when the box runs dry it will increase the actusl crunch share for Rosetta.
The only poeple this will not work for are dial-up users who understandably don't want their boxes making extra calls - especially if their connection has 'peak' and 'off-peak' call rates.
Yeah, I just did an update and hit daily quota. I think I have enough work to last to midnight ... :)
There's an interesting point - is it midnight UTC or midnight on the server's time zone that the next day's quota becomes available?
And a second point, for JM7 and friends - would it be possible to add code to a later version of the server so that when a user gets a quota error they get deferred a suitable length of time?
This would have to be a little after midnight, and would have to increase slightly with each successive one, or the server would be setting itself up for a DOS attack at midnight... so there would have to be some kind of counter and some kind of parameter telling the server how long it needed to add for each successive quota bloater. I'm already guessing that the implications might make the mod more trouble than it is worth...
And the third point, if quota remains a problem on any project for a while, don't be surprised if loadsa users doing manual updates one day clobber their server at five past midnight...
When the host hits their quota, the scheduler tells the client to defer until after midnight the next day. Some random time in the first hour.
Next time you hit your quota, check the project status and see what the "communications deferred" interval is. With an 8 WU/day quota it was easy to test, increasing the "connect every" interval did it. Its a bit harder with 16 WU per day with slower systems.
Well, I added some Rosetta work and SETI. And the lastest batch of EAH work is all longer estimated time (~3 hours per) so I am back to being good to go ...
OK, thanks, Paul.....I guess we will just have to be patient and keep monitoring the faster machines.....Cheers, Rog.
No need for active monitoring except on dial-ups - just set a low resource share for Rosetta (a 1% share will still complete its wu for the 28 day deadline) and when the box runs dry it will increase the actusl crunch share for Rosetta.
Wouldn't this require the box running dry on a semiregular basis? Otherwise the 1st time it runs dry Rosetta will be well over it's share of CPU time, and unless another dry spell strikes will not get any cycles for a very long time. One 8 hour block of Rosetta will take 33days of 100% alberting before it resumes running.
Wouldn't this require the box running dry on a semiregular basis? Otherwise the 1st time it runs dry Rosetta will be well over it's share of CPU time, and unless another dry spell strikes will not get any cycles for a very long time. One 8 hour block of Rosetta will take 33days of 100% alberting before it resumes running.
That's the point - if Einstein is dry, you'd run Rosetta; otherwise, you'd run roughly 1 Rosetta WU per month. The scheduler won't let you return the work past deadline, so all would be well. (Although I can see where if you have a large cache, it could be a problem.)
_My_ preference is for the "backup" project to have at least a 10% share, that way you work on it at least a couple of times each day. And while CPDN WUs "last forever" and from that viewpoint make a good backup, the _last_ thing you want to do is get in deadline trouble with a 1-year result, so if CPDN is the backup, I prefer it to get at least 20-25%.
I have encounter just two max quota days since the quota was changed to 16. The thing is each case I got a whole lot of <1 hour WUs (30 in one case). If the WUs were better mixed I doubt that the quota would need to be increased at all.
Bruce is aware of this and is
)
Bruce is aware of this and is watching. I don't know if there will be a change. The last word I had was that these short work units/results are likely to be an anomaly ... I have been getting some work that is in the 2 1/2 hr area, but like you I am doing them as quickly as 48 minutes on the G5 ...
RE: Bruce is aware of this
)
Yeah, I just did an update
)
Yeah, I just did an update and hit daily quota. I think I have enough work to last to midnight ... :)
SETI@Home is back on the air, so, maybe I can get some work from there ...
==== edit
I just gated in some Rosetta and SDG work ... :)
Ought to tide me over ...
RE: RE: Bruce is aware of
)
No need for active monitoring except on dial-ups - just set a low resource share for Rosetta (a 1% share will still complete its wu for the 28 day deadline) and when the box runs dry it will increase the actusl crunch share for Rosetta.
The only poeple this will not work for are dial-up users who understandably don't want their boxes making extra calls - especially if their connection has 'peak' and 'off-peak' call rates.
~~gravywavy
RE: Yeah, I just did an
)
There's an interesting point - is it midnight UTC or midnight on the server's time zone that the next day's quota becomes available?
And a second point, for JM7 and friends - would it be possible to add code to a later version of the server so that when a user gets a quota error they get deferred a suitable length of time?
This would have to be a little after midnight, and would have to increase slightly with each successive one, or the server would be setting itself up for a DOS attack at midnight... so there would have to be some kind of counter and some kind of parameter telling the server how long it needed to add for each successive quota bloater. I'm already guessing that the implications might make the mod more trouble than it is worth...
And the third point, if quota remains a problem on any project for a while, don't be surprised if loadsa users doing manual updates one day clobber their server at five past midnight...
R~~
~~gravywavy
Its midnight server
)
Its midnight server time.
When the host hits their quota, the scheduler tells the client to defer until after midnight the next day. Some random time in the first hour.
Next time you hit your quota, check the project status and see what the "communications deferred" interval is. With an 8 WU/day quota it was easy to test, increasing the "connect every" interval did it. Its a bit harder with 16 WU per day with slower systems.
Walt
Well, I added some Rosetta
)
Well, I added some Rosetta work and SETI. And the lastest batch of EAH work is all longer estimated time (~3 hours per) so I am back to being good to go ...
RE: RE: RE: Bruce is
)
Wouldn't this require the box running dry on a semiregular basis? Otherwise the 1st time it runs dry Rosetta will be well over it's share of CPU time, and unless another dry spell strikes will not get any cycles for a very long time. One 8 hour block of Rosetta will take 33days of 100% alberting before it resumes running.
RE: Wouldn't this require
)
That's the point - if Einstein is dry, you'd run Rosetta; otherwise, you'd run roughly 1 Rosetta WU per month. The scheduler won't let you return the work past deadline, so all would be well. (Although I can see where if you have a large cache, it could be a problem.)
_My_ preference is for the "backup" project to have at least a 10% share, that way you work on it at least a couple of times each day. And while CPDN WUs "last forever" and from that viewpoint make a good backup, the _last_ thing you want to do is get in deadline trouble with a 1-year result, so if CPDN is the backup, I prefer it to get at least 20-25%.
I have encounter just two max
)
I have encounter just two max quota days since the quota was changed to 16. The thing is each case I got a whole lot of <1 hour WUs (30 in one case). If the WUs were better mixed I doubt that the quota would need to be increased at all.