Too many WU's

Colin Porter
Colin Porter
Joined: 15 Feb 05
Posts: 21
Credit: 5,157,307
RAC: 2,282
Topic 188197

Just set up another comp to crunch E@H. Pref's were set to connect every 1 day. So why did it download 6 WU's?
At minimum this will take 60+ hours and more like 72 hours (3 days). No prob if you don't mind leaving it on 24/7 - but I don't want to. Also in order to complete these WU's I now cannot resource share with another project - unless I do leave it on 24/7.

If you want the general public to participate, you really need to make E@H user friendly. By that I mean that after starting the project, they only need to check progress once a day max. The average Joe does not want to be chasing deadlines every day.

Warning! This post contains atrocious spelling, and terrible grammar. Approach with extreme edginess.

It's not the speed, but the quality - Until I get a faster computer

Ned Ludd
Ned Ludd
Joined: 9 Feb 05
Posts: 23
Credit: 56,045
RAC: 0

Too many WU's

> Just set up another comp to crunch E@H. Pref's were set to connect every 1
> day. So why did it download 6 WU's?
> At minimum this will take 60+ hours and more like 72 hours (3 days). No prob
> if you don't mind leaving it on 24/7 - but I don't want to. Also in order to
> complete these WU's I now cannot resource share with another project - unless
> I do leave it on 24/7.
>
> If you want the general public to participate, you really need to make E@H
> user friendly. By that I mean that after starting the project, they only need
> to check progress once a day max. The average Joe does not want to be chasing
> deadlines every day.

Actually....

As BOINC develops a track record on your machine, it definitely appears to adjust the amount of work available based on your response time, resource shares, etc.

Also, the odds are pretty good that work returned after the deadline will still get credit.

I agree that the deadline should not be less than the highest setting for "connect every x days" plus a decent margin.



Bruce Allen
Bruce Allen
Moderator
Joined: 15 Oct 04
Posts: 1,109
Credit: 172,125,663
RAC: 0

> Just set up another comp to

> Just set up another comp to crunch E@H. Pref's were set to connect every 1
> day. So why did it download 6 WU's?
> At minimum this will take 60+ hours and more like 72 hours (3 days). No prob
> if you don't mind leaving it on 24/7 - but I don't want to. Also in order to
> complete these WU's I now cannot resource share with another project - unless
> I do leave it on 24/7.
>
> If you want the general public to participate, you really need to make E@H
> user friendly. By that I mean that after starting the project, they only need
> to check progress once a day max. The average Joe does not want to be chasing
> deadlines every day.
>

2005-03-02 12:35:07 [normal ] OS version Microsoft Windows XP Home Edition, Service Pack 2, (05.01.2600.00)
2005-03-02 12:35:07 [normal ] Request [HOST#55418] Database [HOST#55418] Request [RPC#1] Database [RPC#0]
2005-03-02 12:35:07 [normal ] Processing request from [USER#17457] [HOST#55418] [IP XX.XX.124.50] [RPC#1] core client version 4.19
2005-03-02 12:35:07 [normal ] [HOST#55418] got request for 138489.794783 seconds of work; available disk 1.000000 GB

Your machine requested 138489.794783 seconds of work. That's about 1.6 days, or 40 hours of work. Hence the 5 WU you got. There was also an earlier request for a smaller amount of work.

Bruce

Director, Einstein@Home

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 4,888
Credit: 29,445,233,063
RAC: 35,291,251

> Your machine requested

Message 6657 in response to message 6656

> Your machine requested 138489.794783 seconds of work. That's about 1.6 days,
> or 40 hours of work. Hence the 5 WU you got. There was also an earlier
> request for a smaller amount of work.
>
> Bruce

Yeah, but he only wanted 1.0 days according to his prefs. Seems like a new comp always gets considerably more than it needs or wants when it first starts up. Is there any way to stop this initial burst of work when a comp first starts? Maybe the default "connect" time could be set to something like 0.5 days and then reset to the desired value after the first work unit is well under way.

Cheers,
Gary.

Ageless
Joined: 26 Jan 05
Posts: 2,949
Credit: 5,374,792
RAC: 0

Since he's got another

Message 6658 in response to message 6657

Since he's got another computer crunching at the same account, he'll run into time-debt. At that time, BOINC checks the new computer, sees that it hasn't contacted home base yet for the time the old on may have, and thus gives the amount of units which is enough for the time-debt to be taken care of.

Unless I misunderstood BOINCs time-debt, that it may be per host. But I am sure either JK or JM7 will put me right on that. ;)

John McLeod VII
John McLeod VII
Moderator
Joined: 10 Nov 04
Posts: 547
Credit: 632,255
RAC: 0

> Since he's got another

Message 6659 in response to message 6658

> Since he's got another computer crunching at the same account, he'll run into
> time-debt. At that time, BOINC checks the new computer, sees that it hasn't
> contacted home base yet for the time the old on may have, and thus gives the
> amount of units which is enough for the time-debt to be taken care of.
>
> Unless I misunderstood BOINCs time-debt, that it may be per host. But I am
> sure either JK or JM7 will put me right on that. ;)
>
I do not believe that you have the correct idea.

The debt is for scheduling the CPU(s) on a single computer (what project gets run next on a CPU based on what has not run recently on that computer that has work present. The debt does nothing across computers.

Ageless
Joined: 26 Jan 05
Posts: 2,949
Credit: 5,374,792
RAC: 0

Thanks for the correction,

Thanks for the correction, JM7. :)

Keck_Komputers
Keck_Komputers
Joined: 18 Jan 05
Posts: 376
Credit: 5,744,455
RAC: 0

> > Your machine requested

Message 6661 in response to message 6657

> > Your machine requested 138489.794783 seconds of work. That's about 1.6
> days,
> > or 40 hours of work. Hence the 5 WU you got. There was also an earlier
> > request for a smaller amount of work.
> >
> > Bruce
>
> Yeah, but he only wanted 1.0 days according to his prefs. Seems like a new
> comp always gets considerably more than it needs or wants when it first starts
> up. Is there any way to stop this initial burst of work when a comp first
> starts? Maybe the default "connect" time could be set to something like 0.5
> days and then reset to the desired value after the first work unit is well
> under way.
>
The hard coded default for a new machine is 0.1 days. One problem is that BOINC thinks the computer is up and crunching 24/7 on a new machine, even on a machine that really is on 24/7 the numbers are slightly lower. Another is that after the first project is contacted the queue size is updated and more work is requested. Another point of confusion is that BOINC tries to keep the queue between x and 2x days (4.1x clients) per project.

So the from the information provided here things happened exactly as expected. 1) Request small amount of work and get preferences. 2) Request additional work to bring queue level up to the desired max (2 days).

[edit] By the next time that computer contacts the server BOINC will have adjusted the on and active fractions some and it will request less work.

BOINC WIKI

BOINCing since 2002/12/8

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 4,888
Credit: 29,445,233,063
RAC: 35,291,251

> So the from the information

Message 6662 in response to message 6661

> So the from the information provided here things happened exactly as expected.
> 1) Request small amount of work and get preferences. 2) Request additional
> work to bring queue level up to the desired max (2 days).
>
> [edit] By the next time that computer contacts the server BOINC will have
> adjusted the on and active fractions some and it will request less work.

Thanks for the comments. I fully understand everything you are saying. However, from the perspective of first time users, particularly if they have seti classic experience where it was virtually mandatory to keep a multi-day cache, you can understand why they set 5 day caches and get badly bitten. Maybe you shouldn't be allowed to excessively increase the hard coded default until your first WU has finished by which time better judgement might be possible. It really is sad to see people wasting crunching time on expired WUs.

Cheers,
Gary.

Keck_Komputers
Keck_Komputers
Joined: 18 Jan 05
Posts: 376
Credit: 5,744,455
RAC: 0

> > So the from the

Message 6663 in response to message 6662

> > So the from the information provided here things happened exactly as
> expected.
> > 1) Request small amount of work and get preferences. 2) Request
> additional
> > work to bring queue level up to the desired max (2 days).
> >
> > [edit] By the next time that computer contacts the server BOINC will
> have
> > adjusted the on and active fractions some and it will request less work.
>
> Thanks for the comments. I fully understand everything you are saying.
> However, from the perspective of first time users, particularly if they have
> seti classic experience where it was virtually mandatory to keep a multi-day
> cache, you can understand why they set 5 day caches and get badly bitten.
> Maybe you shouldn't be allowed to excessively increase the hard coded default
> until your first WU has finished by which time better judgement might be
> possible. It really is sad to see people wasting crunching time on expired
> WUs.
>
The setting I like, that is currently partially enabled at seti, is a project imposed maximum queue. You can not set your queue longer than 10 days at seti. The reason I consider this partially enabled is you can still set your queue higher at another project and seti will not lower it automatically.

[edit] This setting seems to be enabled here also.

BOINC WIKI

BOINCing since 2002/12/8

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 4,888
Credit: 29,445,233,063
RAC: 35,291,251

> The setting I like, that is

Message 6664 in response to message 6663

> The setting I like, that is currently partially enabled at seti, is a project
> imposed maximum queue. You can not set your queue longer than 10 days at seti.
> The reason I consider this partially enabled is you can still set your queue
> higher at another project and seti will not lower it automatically.
>
> [edit] This setting seems to be enabled here also.

Exactly!! It's 10 days here as well and that's just crazy for a 7 day expiry time. BA is resisting many calls to increase the expiry time but in the end I reckon it will be increased perhaps not all the way to 14 but maybe to 10. There should be some strong advice to new users not to increase the time beyond say 1 day until a couple of units have been done and the results returned.

The understandable problem is that many first timers want to just get going without doing all the reading to gain an appreciation of the gotchas. They browse the prefs and see this nice setting which will impact their cache size and they take it literally without even considering things like other projects and hours of comp on time per day, let alone the "doubling" factor you referred to in a previous post.

So I guess my question is ... How hard would it be to implement a project settable hard limit for connect time which only applied for the first say two completed results and then disappeared in favour of the user settable one?

Cheers,
Gary.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.