Other projects aren't that picky...

ghstwolf
ghstwolf
Joined: 9 Feb 05
Posts: 24
Credit: 59103
RAC: 0

Todd Wright- If the computers

Todd Wright- If the computers are on and connected anyway, why would connecting every 2.5-4 days be a problem? I'm on fewer projects (seti, E@H, and CPDN), I'm set to connect every 12 hours (.5 days), and I have not run out of work yet. Yes I've been out of Wu's for a project, but the machine is always busy crunching (CPDN makes sure of that).

I haven't missed a deadline, without trashing the WU (a reinstall, and a roll back on windoze). With the number of seperate projects (and their servers), long times between connects are largely unneeded (maybe for dial-up, but even then every couple days should be fine). The only exception is if you're running 1 project exclusively. Just my opinion


Jord
Joined: 26 Jan 05
Posts: 2952
Credit: 5779100
RAC: 0

> Yes but an Einstein WU

Message 9883 in response to message 9874

> Yes but an Einstein WU takes about 7 times longer to process than a Predictor
> one - at least on my machines.

An Einstein WU claims at least 7 times more and gets at least 7 times more than your Predictor units as well.

If you are trying to compare emu eggs with peanuts, you're in the right place. E@H gives loads of credits, where PPAH gives only the lowest asked.

Todd Wright
Todd Wright
Joined: 6 Mar 05
Posts: 13
Credit: 39039
RAC: 0

> > Yes but an Einstein WU

Message 9884 in response to message 9883

> > Yes but an Einstein WU takes about 7 times longer to process than a
> > Predictor one - at least on my machines.
>
> An Einstein WU claims at least 7 times more and gets at least 7 times more
> than your Predictor units as well.
>
> If you are trying to compare emu eggs with peanuts, you're in the right place.
> E@H gives loads of credits, where PPAH gives only the lowest asked.

Credit was not the point. The discussion was about deadlines. I have found that people justify E@H's deadline by comparing it to Predictor, which has the same 7 day deadline, while forgetting that the work units of predictor take much less time to process. My point was that based on WU size, the predictor deadline is effectively 7 times larger if you compare apples to apples.

I am obviously being misunderstoor here, the other thread I was participating in is ample evidence of that, so its not worth my time to continue trying to explain the point, suffice to say that others have the same problems and they will not go away when I do.

Todd Wright
Todd Wright
Joined: 6 Mar 05
Posts: 13
Credit: 39039
RAC: 0

> Todd Wright- If the

Message 9885 in response to message 9882

> Todd Wright- If the computers are on and connected anyway, why would
> connecting every 2.5-4 days be a problem?

I want nothing more than to be able to connect every 2-3 days, yet I am told that the only way this project will work is if I change my settings for all projects to connect every 0.1 days. Again this shows that I am not being understood.

This is what happens when I have my PIII 800Mhz laptop, which is always on and always connected, set to connect every 3 days.

The work units take at least 25% longer to process than estimated and start missing the deadline. The miss the deadline because a) The software underestimates the processing time and loads up with too much work, and b) There is no padding in the deadline to allow for this, especially for machines with less than gigahertz processors, which the project seems to shun.

Thats it. Im done. Im spending my time and resources elsewhere.

Jord
Joined: 26 Jan 05
Posts: 2952
Credit: 5779100
RAC: 0

> > Todd Wright- If the

Message 9886 in response to message 9885

> > Todd Wright- If the computers are on and connected anyway, why would
> > connecting every 2.5-4 days be a problem?
>
> I want nothing more than to be able to connect every 2-3 days, yet I am told
> that the only way this project will work is if I change my settings for all
> projects
to connect every 0.1 days. Again this shows that I am not being
> understood.

You misunderstand the way that the "connect to server" works. You won't get one WU ever 2-3 days if you set your connect to server to between 2 and 3 days. You will get the amount of units that a machine of your speed (in benchmarks) needs for those amount of days for that project!

> This is
> what happens when I have my PIII 800Mhz laptop, which is always on and always
> connected, set to connect every 3 days.

You just misunderstood, maybe even after multiple people told you what would happen. So for once, read what will happen. You will get enough work units for all the projects you are attached to on that PC, on that preference, to make sure your computer will not run out of work units in 3 to max 6 days!!

Some projects still use the Connect to server every x days times two option. For every DAY you get TWO workunits.

I'm pretty sure your P3-800 can run both Einstein & CPDN without a problem. Even when you've set both to contact the server every 7 days. Neither of these projects use the l2 cache of the CPU that much. You may not be into credits that much, but you're earning loads here!

John McLeod VII
John McLeod VII
Moderator
Joined: 10 Nov 04
Posts: 547
Credit: 632255
RAC: 0

How about fixing the client

How about fixing the client so that it respects deadlines, and will do extra crunching for a project that has WUs approaching deadline? Then not download work from that project for awhile to make up?

Skip Da Shu
Skip Da Shu
Joined: 18 Jan 05
Posts: 140
Credit: 653486094
RAC: 2636468

> How about fixing the client

Message 9888 in response to message 9887

> How about fixing the client so that it respects deadlines, and will do extra
> crunching for a project that has WUs approaching deadline? Then not download
> work from that project for awhile to make up?

Two things...

1)Paul, looks like v4.32 might be doing that... not sure yet.

2) Todd, Set up a "school" or other profile with a lower "connect every x days" value and assign the 800Mhz to that profile. I am using 3 profiles for this purpose. The superslow computers use one profile, the OK 'puters use the other and all the 'bigger boys' get the default which has the highest "connect every x days" setting (which as explained is really "how much work do I keep around".

John McLeod VII
John McLeod VII
Moderator
Joined: 10 Nov 04
Posts: 547
Credit: 632255
RAC: 0

> > How about fixing the

Message 9889 in response to message 9888

> > How about fixing the client so that it respects deadlines, and will do
> extra
> > crunching for a project that has WUs approaching deadline? Then not
> download
> > work from that project for awhile to make up?
>
> Two things...
>
> 1)Paul, looks like v4.32 might be doing that... not sure yet.
>
> 2) Todd, Set up a "school" or other profile with a lower "connect every x
> days" value and assign the 800Mhz to that profile. I am using 3 profiles for
> this purpose. The superslow computers use one profile, the OK 'puters use the
> other and all the 'bigger boys' get the default which has the highest "connect
> every x days" setting (which as explained is really "how much work do I keep
> around".
>
4.35 has code tha makes every attempt to honor deadlines. In order to do this, it was necessary to not attempt to keep work from all projects on hand at all times. It is also necessary to crunch the nearest deadline WU first at times as well.

STE\/E
STE\/E
Joined: 18 Jan 05
Posts: 135
Credit: 143151972
RAC: 53292

Even Pirates@home has

Even Pirates@home has extended their former deadline of 1 (!) hour to 24 hours, regarding their ~10 minutes wu's
==========

At the Pirates Site you can turn in WU's 2 or 3 days late and you still get the credit. I've done it and recieved credit for every WU ...

Mike
Mike
Joined: 20 Feb 05
Posts: 151
Credit: 5536135
RAC: 0

Hi I missed it again. My

Hi

I missed it again.
My result was uploaded toonight within the deadline but when i wake up in the morning reported too late only a few minutes.

Great thing.

greetz Mike

Comment viewing options

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