LHC@home

I received a message when trying to get new work, and I have never seen this message before. I also do not really understand what it means. This is the message:
<p>
Message from server: (won't finish in time) Computer on 21.5% of time, BOINC on 83.8% of that, this project gets 25.0% of that
<p>
Anyone knows what it means?

The deadline of the WU is 12/10/2005, so that should not be the problem...

---

<blockquote>I received a message when trying to get new work, and I have never seen this message before. I also do not really understand what it means. This is the message:
<p>
Message from server: (won't finish in time) Computer on 21.5% of time, BOINC on 83.8% of that, this project gets 25.0% of that
<p>
Anyone knows what it means?

The deadline of the WU is 12/10/2005, so that should not be the problem...</blockquote>

From the figures given LHC will get about 5% of real time for running SixTrack, i.e. about 1 hour per day. You don't say which of your computers this has appeared on, but if BOINC estimates the run time to be anything more than about 10 hours you won't finish the unit before the deadline.

To run units successfully you can increase LHC's share of the processor time, or increase the time that the computer is switched on.

---

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

Well, while the message was sent by the server, my computer was actually working on the LHC@home workunit and the estimated completion time was around 1hour and 5minutes. But could anyone explain what is meant by: Computer on 21.5% of time, BOINC on 83.8% of that.

---

<blockquote>Well, while the message was sent by the server, my computer was actually working on the LHC@home workunit and the estimated completion time was around 1hour and 5minutes. But could anyone explain what is meant by: Computer on 21.5% of time, BOINC on 83.8% of that.</blockquote>

From the data logged by BOINC your computer is on just 21.5% of the time - i.e. around 5 hours per day. BOINC is running 83.8% of that, so about 4 hours per day, and LHC gets 25% share of the resource, i.e. about 1 hour per day.

I'd guess that the server was referring to a request for new work, rather than the result actually in progress at the time. But it is just a guess.

If you can post more information from your log file then we might be able to go further in diagnosing the message, but I can only tell you what I see here.

---

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

If nothing else I would like to evaluate that message and your log files. If you could, zip up the TXT and OLD files in the BOINC directory and send them to p.d.buck@comcast.net

For future reference you can look up messages like that in the Wiki ... look of the BOINC Messages link on the first page and strangely enough I have all the messages I can find listed in alphabetical order. I do have two examples of this very message.

Oddly enough the reason I, and the other editors, do this is so you can look up the answers ... :)

And as we learn and get examples, well, we make everyone smarter ...

Anyway, if you send me your logs, I do appreciate it ...

---

<blockquote>If nothing else I would like to evaluate that message and your log files. If you could, zip up the TXT and OLD files in the BOINC directory and send them to p.d.buck@comcast.net

For future reference you can look up messages like that in the Wiki ... look of the BOINC Messages link on the first page and strangely enough I have all the messages I can find listed in alphabetical order. I do have two examples of this very message.

Oddly enough the reason I, and the other editors, do this is so you can look up the answers ... :)

And as we learn and get examples, well, we make everyone smarter ...

Anyway, if you send me your logs, I do appreciate it ...</blockquote>
This message is modified in the current server source. It does not mention resource share as that is handled by the CPU scheduler.

---

BOINC WIKI

<blockquote>Well, while the message was sent by the server, my computer was actually working on the LHC@home workunit and the estimated completion time was around 1hour and 5minutes. But could anyone explain what is meant by: Computer on 21.5% of time, BOINC on 83.8% of that.</blockquote>

3 pieces of information would be of use in helping people identify what you're seeing:

- How much work do you have for LHC on your computer already? As indicated you're processing a WU. But how many do you have in addition waiting to be processed?

- What is your computer? Are we talking a 486 or a Pentium here? Or are we talking an Athlon 64/FX or Pentium 4 3.0c here? The overall processing power you have can make a big difference here.

- If you've been running LHC for any length of time to get a general idea on how long it takes you to process a WU, how long is it?

My Athlon XP has been able to rather consistently process one of these WUs in about 3.25 to 3.5 hours (less when the WU finishes before completing all 1 million runs). I run 24/7, but if I were to run it as you've got yours setup, I could still complete a unit in 3-4 days. That would fall within the deadline I've seen with these units (units I have on my comp now having a deadline of 10/15).

However my computer is not your computer so wouldn't make an apples to apples comparison. We also don't know how much LHC work you have on your computer currently.

---

<blockquote>
3 pieces of information would be of use in helping people identify what you're seeing:
</blockquote>

Actually if you click on his name and view his computers you get all three items for free :).

It would be nice however if Kamukwam came back and told us whether he finally understood what MikeW was telling him. I thought it was clear enough the first time but even clearer in the second attempt. I'd like to ask the user if he could actually leave the machine on a bit more. It's a bit hard for multiple projects to grab much of a slice of the time if the numbers are as MikeW calculated. Maybe his machines have been off for quite a while and now that they are running again BOINC is just doing its normal thing of settling into a stable operating pattern.

This thought actually got my attention and having now looked more closely, the above would seem to be the case because his #2 ranked computer was attached back in Feb but now has a results list going back only to Oct 02 and his #1 ranked computer, attached Aug 24, only goes back to Sep 28. The earlier data said LHC had a 25% share so he must be running close to 24/7 now (at least on #1) to have as many results as he does in his results list. Its a shame that LHC doesn't seem to show the version of BOINC when you examine a result in the results list.

I would reckon that the answer to his original query is that BOINC is trying to stabilize and is preventing the downloading of work in order to assist the process. All he needs to do is be patient. He has 2 results in progress on each machine so everything looks cool!!

Edit: It's a pity you can't PM people sometimes when you reckon you actually might have worked out the answer to their question :). I hope he comes back and can decipher the explanation - particularly MikeW's second one which is very clear.

---

Cheers,
Gary.

I run my P4HT 3.4Ghz for about 12 hours a day average and i have currently got a LHC@home WU being crunched which is not due to be returned until till the 17th of October suspending the work fetch for all projects on my computer because Boinc thinks my PC is overcommitted. This is rubbish as this work unit has only a few hours to go and even if i downloaded work from other projects this LHC@home work unit would be finished later today or tommorrow morning at the latest.

There's something well wrong with some of the code in that Boinc work scheduler.

---

Ross,

Post your boinc-project allocations, boinc client uptime %, and boinc client version we can tell you why it's doing that.

It took my 10 active hosts about 1.5 months to finally even out to something which resembled predictability. The Boinc client does work correctly and in 99%+ of cases it's right.

---

<blockquote>Ross,

Post your boinc-project allocations, boinc client uptime %, and boinc client version we can tell you why it's doing that.

It took my 10 active hosts about 1.5 months to finally even out to something which resembled predictability. The Boinc client does work correctly and in 99%+ of cases it's right.
</blockquote>

My project allocaions are:-

Einstein 300 (42.86%)
Climate Prediction 100 (14.29%)(Currently suspended)
Predictor 14.29% 100 (14.29%)
LHC@Home 100 (14.29%)
Seti 100 (14.29%)

Client uptime 63.8777%

Boinc Client Version 4.45

---

<blockquote>I run my P4HT 3.4Ghz for about 12 hours a day average and i have currently got a LHC@home WU being crunched which is not due to be returned until till the 17th of October suspending the work fetch for all projects on my computer because Boinc thinks my PC is overcommitted. This is rubbish as this work unit has only a few hours to go and even if i downloaded work from other projects this LHC@home work unit would be finished later today or tommorrow morning at the latest.

There's something well wrong with some of the code in that Boinc work scheduler.

</blockquote>

A message to Ross I have had this happen on both of my computers the latest being over committed for one second until then being told round robin being started.
On one comp my 856 MHZ doing Einstein (33.3%), Seti the same and Stzaki the same.
On the one I am typing on my 3GHZ maxhine depending on which Intel Utility I use I am doing LHC and Seti both doing 50%. If you go to Stzaki on their message board you will see one sec work that is mine read it it may help you or cause confusion.

---

<blockquote><blockquote>Ross,

Post your boinc-project allocations, boinc client uptime %, and boinc client version we can tell you why it's doing that.

It took my 10 active hosts about 1.5 months to finally even out to something which resembled predictability. The Boinc client does work correctly and in 99%+ of cases it's right.
</blockquote>

My project allocaions are:-

Einstein 300 (42.86%)
Climate Prediction 100 (14.29%)(Currently suspended)
Predictor 14.29% 100 (14.29%)
LHC@Home 100 (14.29%)
Seti 100 (14.29%)

Client uptime 63.8777%

Boinc Client Version 4.45


</blockquote>
If the next project is Einstein, then there is a factor of 3, since the uptime is only 63% (and on time is about 50%) this is probably about another factor of 3. This gives a factor of 9 that the time remaining is multiplied by to determine if any more work should be downloaded now. So a few hours (say 10 for conveniece) is suddenly expanded to 90 hours - or about 4 days. Please note that if left alone, the host would have downloaded more work in a few hours.

---

BOINC WIKI

<blockquote><blockquote><blockquote>Ross,

Post your boinc-project allocations, boinc client uptime %, and boinc client version we can tell you why it's doing that.

It took my 10 active hosts about 1.5 months to finally even out to something which resembled predictability. The Boinc client does work correctly and in 99%+ of cases it's right.
</blockquote>

My project allocaions are:-

Einstein 300 (42.86%)
Climate Prediction 100 (14.29%)(Currently suspended)
Predictor 14.29% 100 (14.29%)
LHC@Home 100 (14.29%)
Seti 100 (14.29%)

Client uptime 63.8777%

Boinc Client Version 4.45


</blockquote>
If the next project is Einstein, then there is a factor of 3, since the uptime is only 63% (and on time is about 50%) this is probably about another factor of 3. This gives a factor of 9 that the time remaining is multiplied by to determine if any more work should be downloaded now. So a few hours (say 10 for conveniece) is suddenly expanded to 90 hours - or about 4 days. Please note that if left alone, the host would have downloaded more work in a few hours.</blockquote>


I think it must have been a problem with that particular WU as once it finished Boinc went out of panic mode and downloaded Wu's for all projects about 16 WU's in total. This included another 2 LHC WU's which are due to be returned on 16/10 about 12 hours before the last WU that went into panic mode was due to be returned. These LHC WU's did not go into panic mode so it must have been a one off situation.

---