LHC@home

Just curious here. Why not make the deadline for LHC WUs even shorter? 3-4 days? I guess there might be technical reason for not making it that short, but that would be interesting to hear too.

As we have seen there are those who would compalin about not being able to keep a big cacheof WUs. However, since LHC is really a throughput project wouldn't it be best for the project with many users and more or less no caches? No caches at all might of course lead to higher load on the servers and not be practical for that reason.

<blockquote>Just curious here. Why not make the deadline for LHC WUs even shorter? 3-4 days? I guess there might be technical reason for not making it that short, but that would be interesting to hear too.

As we have seen there are those who would compalin about not being able to keep a big cacheof WUs. However, since LHC is really a throughput project wouldn't it be best for the project with many users and more or less no caches? No caches at all might of course lead to higher load on the servers and not be practical for that reason.</blockquote>

Unless the general preference "maximum days to connect" is reduced as well, I foresee work actually taking longer as results expire before return and the WU takes forever to validate.

Shorter cues would result but, all projects must accommodate dial-up volunteers. They need a moderately long cue to minimize the use of their line.

---

<img src="http://www.boincstats.com/stats/teambanner.php?teamname=GasBuddy"> <img src="http://www.boincstats.com/stats/banner.php?cpid=84c0cf7846cbf28338406e54b3eb8a83">

>Unless the general preference "maximum days to connect" is reduced as well, I
>foresee work actually taking longer as results expire before return and the WU
>takes forever to validate.

Will boinc download more WUs than the machine is estimated to be able to finish before their deadline? If it does not then this problem shouldn't occur.
Even if some WUs expire my impression is that the shorter deadline should cause them to be resent to new hosts fairly quickly.

>Shorter cues would result but, all projects must accommodate dial-up
>volunteers. They need a moderately long cue to minimize the use of their line.

Unless a single WU takes 4 days, and you only connect every 4 days, this shouldn't be a problem for those on dial-up either.


As I said earlier deadlines this short might not be practical for many reasons, but I'm curiosu to find out what the limiting factors are.

One limiting factor is the deadlines of other BOINC projects. I have had to micromanage the balance between LHC and Einstein until recently because Einstein used a deadline of seven days. The result was that I dropped einstein because the scheduling was too time-consuming to manage.

I suspect that the shorter deadlines now used by LHC and 14 day deadline used by Einstein will precipitate similar issues in reverse.

---

Gaspode the UnDressed
http://www.littlevale.co.uk

<blockquote>One limiting factor is the deadlines of other BOINC projects. I have had to micromanage the balance between LHC and Einstein until recently because Einstein used a deadline of seven days. The result was that I dropped einstein because the scheduling was too time-consuming to manage.

I suspect that the shorter deadlines now used by LHC and 14 day deadline used by Einstein will precipitate similar issues in reverse.
</blockquote>
Client versions 4.45 and later don't need the micromanaging to meet the deadlines (or at least get close to them).

---

BOINC WIKI

BOINCing since 2002/12/8

For people with continual access to the internet, a shorter limit would not be a problem. However, dial-up users who infrequently access the net may be locked out. As was pointed out in this thread, a boinc project must accomadate everyone.

---

<blockquote>
Client versions 4.45 and later don't need the micromanaging to meet the deadlines (or at least get close to them). </blockquote>

I'm running 4.45 and 4.72. With the combination of CPU, deadlines, differing run times of the two projects, and my chosen allocation of CPU time (70:30 LHC:Einstein) I couldn't complete an Einstein unit in the time available without micromanaging BOINC, or basically allowing BOINC to run Einstein all the time. I could have changed the allocation to 50:50, or maybe 30:70, but I prefer to run LHC. Since BOINC couldn't cope with the short Einstein deadlines I dropped it. For what it's worth all my machines are running Einstein while LHC is out of work. I'll switch back when LHC restarts.

---

Gaspode the UnDressed
http://www.littlevale.co.uk

<blockquote>I'm running 4.45 and 4.72. With the combination of CPU, deadlines, differing run times of the two projects, and my chosen allocation of CPU time (70:30 LHC:Einstein) I couldn't complete an Einstein unit in the time available without micromanaging BOINC, or basically allowing BOINC to run Einstein all the time. I could have changed the allocation to 50:50, or maybe 30:70, but I prefer to run LHC. Since BOINC couldn't cope with the short Einstein deadlines I dropped it. For what it's worth all my machines are running Einstein while LHC is out of work. I'll switch back when LHC restarts.
</blockquote>
If you leave BOINC alone to manage the resources, it'll meet the Einsten deadlines, then not download more from E@H until it's needed to meet your resource allocation goals. On a given day, it might not be the 70/30 or whatever split you define, but over the long run, it'll honor your allocation. You just have to leave it alone to do it!

MJ

---

BOINC Wiki Thanks to Paul D. Buck and associates

<blockquote>
If you leave BOINC alone to manage the resources, it'll meet the Einsten deadlines, then not download more from E@H until it's needed to meet your resource allocation goals. On a given day, it might not be the 70/30 or whatever split you define, but over the long run, it'll honor your allocation. You just have to leave it alone to do it!

MJ</blockquote>

Mostly I do just leave BOINC to get on with it. The theory is good, but with computers actually missing deadlines it seems that the practice isn't quite there yet.

---

Gaspode the UnDressed
http://www.littlevale.co.uk

<blockquote>

Mostly I do just leave BOINC to get on with it. The theory is good, but with computers actually missing deadlines it seems that the practice isn't quite there yet.</blockquote>



Then my guess is, you are still using too large queue for this computer.

And as a long time dial-up user I see no difference in connecting once a week for 35mins or every day for 5mins. You do check your e-mail daily ?

Except for the holidays. But then your computer can have one too :)

<blockquote>

Then my guess is, you are still using too large queue for this computer.

</blockquote>

Queue usually set to 0.5 day...

---

Gaspode the UnDressed
http://www.littlevale.co.uk

It's the problem that's been beat to death over on the SETI boards -

The "Cache Size" and the "Connect Every xx Days" need to be separate parameters.

That will let people size their cache as desired and still be able to connect and upload/download/report on a timely basis.

---

Most dial-up users that run more than 1 project will agree that shorter deadlines require more attention. The reasons are many.
The client side scheduler has made this problem far less severe, but shorter deadlines can still cause sweat on the forehead.

The "Cache Size" and the "Connect Every xx Days" need to be separate parameters.
This is very tempting, but may cause more problems than exist now if parameters are not chosen correctly.

I still feel more comfortable with longer deadlines. In the expected life for any project, I can’t see that a few days will slow things down that much.

---

>I still feel more comfortable with longer deadlines. In the expected life
>for any project, I can’t see that a few days will slow things down that much.

For most BOINC projects I agree.

This will wary a lot between different projects. Most current BOINC projects don't rely on getting one bacth of work completely done before a new one can be generated. The current extremes seems to be CPN, for which a single WU can take months to complete, and LHC, for which one needs to analyse the results of one batch before the next can be started.

For CPDN alsmot anything is fine as long as the WU eventually gets done. For LHC the ideal situation as far as the science is concerned would be to have everyone download 1 wu, process it, send it back and download 1 new WU.
This isn't practical for most users, but those wishing be as helpful as possible for the science of the LHC-project should try to keep caches small and connect often instead.