I've installed 4.43 on three computers with no problems noted so far except the Statistics Tab. Anyone else having a problem getting the stats to show up?

If your upgrading from a non-stat version, it takes several updates of the projects before stats show up.

---

Boinc V7.2.42
Win7 i5 3.33G 4GB, GTX470

If your upgrading from a non-stat version, it takes several updates of the projects before stats show up.

Thanks for the reply. I thought that might be the case, however I found an xml file "statistics_setiathome.berkeley.edu.xml" that I thought was for the statistics tab. I doubt installing 4.43 to another drive other than C: would cause any problems. I'll give it a couple days to see if it will work or not. Thanks again!

---

http://www.teamstarfire.org/

If your upgrading from a non-stat version, it takes several updates of the projects before stats show up.

Thanks for the reply. I thought that might be the case, however I found an xml file "statistics_setiathome.berkeley.edu.xml" that I thought was for the statistics tab. I doubt installing 4.43 to another drive other than C: would cause any problems. I'll give it a couple days to see if it will work or not. Thanks again!

Each project must connect once one each of three separate days in order for the stats for that project to start showing.

---

BOINC WIKI

Cheers John, FYI (if it works) the link below should get you my complete message file from the time of the update to my present time (21:17 UTC)
update from
4.56 to 4.43 messages
Yes, I really was running 4.56 on this host, I liked it, it never let me down so I stuck with it, then got very confused when the version numbers went down again, so I left it to get on with the job, instead of tampering :-)

TTFN

I need a username and password. Email me at jm7 at acm dot org.

John,

I've emailed you, I just hadn't set the file up properly on my webserver, thanks for your patience.

Ken

---

Ken Phillips

BOINC question? Look here



"The beginning is the most important part of the work." - Plato

Cheers John, FYI (if it works) the link below should get you my complete message file from the time of the update to my present time (21:17 UTC)
update from
4.56 to 4.43 messages
Yes, I really was running 4.56 on this host, I liked it, it never let me down so I stuck with it, then got very confused when the version numbers went down again, so I left it to get on with the job, instead of tampering :-)

TTFN

I need a username and password. Email me at jm7 at acm dot org.

John,

I've emailed you, I just hadn't set the file up properly on my webserver, thanks for your patience.

Ken

OK, I looked at the log, and it looks as if the CPDN WU was downloaded in response to a failed attempt to download a WU from another project. I will look at this code to see if I can find the problem. If I recall, this code is a bit different than the call where the timer initiates the download, and I was worried about it when I saw it, apparently rightly so.

---

BOINC WIKI

Cheers John, FYI (if it works) the link below should get you my complete message file from the time of the update to my present time (21:17 UTC)
update from
4.56 to 4.43 messages
Yes, I really was running 4.56 on this host, I liked it, it never let me down so I stuck with it, then got very confused when the version numbers went down again, so I left it to get on with the job, instead of tampering :-)

TTFN

I need a username and password. Email me at jm7 at acm dot org.

John,

I've emailed you, I just hadn't set the file up properly on my webserver, thanks for your patience.

Ken

OK, I looked at the log, and it looks as if the CPDN WU was downloaded in response to a failed attempt to download a WU from another project. I will look at this code to see if I can find the problem. If I recall, this code is a bit different than the call where the timer initiates the download, and I was worried about it when I saw it, apparently rightly so.

I just had a quick look through the log and was curious about this:

22/05/2005 13:36:14||Computer is overcommitted
22/05/2005 13:36:14||Nearly overcommitted.
22/05/2005 13:36:14||New work fetch policy: no work fetch allowed.
22/05/2005 13:36:14||New CPU scheduler policy: earliest deadline first.
22/05/2005 15:06:08||schedule_cpus: time 5400.093750
22/05/2005 15:06:08||New work fetch policy: work fetch allowed.
22/05/2005 15:06:08||New CPU scheduler policy: highest debt first.


Nothing changes except the schedulers evaluation of the situation. No WU's were completed in this time.

---

Kolch - Crunching for the BOINC@Australia team since July 2004.
Search for your own intelligence...

[quote22/05/2005 13:36:14||Computer is overcommitted
22/05/2005 13:36:14||Nearly overcommitted.
22/05/2005 13:36:14||New work fetch policy: no work fetch allowed.
22/05/2005 13:36:14||New CPU scheduler policy: earliest deadline first.
22/05/2005 15:06:08||schedule_cpus: time 5400.093750
22/05/2005 15:06:08||New work fetch policy: work fetch allowed.
22/05/2005 15:06:08||New CPU scheduler policy: highest debt first.


Nothing changes except the schedulers evaluation of the situation. No WU's were completed in this time.
[/quote]
After crunching for an hour and a half, the result has progressed further than originally anticipated, and the emergency is off for a while.

I watched a Shh unit and a CPDN unit trade 80% 20% like this for a couple of weeks. The Shh result was indeed running into time trouble, but if it got 100% of the time for 4 hours, it would think that it was a bit ahead and it would allow the CPDN uint in for an hour after which the shh unit would enter panic mode again. Every time that the CPU scheduler runs, it looks at the situation right now, and selects the mode for the next time slot.

---

BOINC WIKI

OK well explained thanks John. I can see that that is a better way of doing things rather than running the Shh WU flat out to completion which would then need the scheduler to run the CPDN WU flat out later to match resource share.

---

Kolch - Crunching for the BOINC@Australia team since July 2004.
Search for your own intelligence...

Haha...Just found the following message in my client:

23/05/2005 12:58:17 PM|SETI@home|Requesting 3.18 seconds of work

The result? Downloaded a new SETI WU. Nice one.

---

Kolch - Crunching for the BOINC@Australia team since July 2004.
Search for your own intelligence...

Haha...Just found the following message in my client:

23/05/2005 12:58:17 PM|SETI@home|Requesting 3.18 seconds of work

The result? Downloaded a new SETI WU. Nice one.

That is EXACTLY the type of thing that should have been fixed, prior to a re-write of the scheduler. (It's been a bug since the beta 18 months ago).

The client requests 3.18 seconds of work, and the server happily sends a WU with an estimated completion of 10 hours!

Why doesn't the server simply respond to a request for 3.18 seconds of work with "no work available"? (unless it has some WU's that will take less than 3.18 seconds!)

---

Haha...Just found the following message in my client:

23/05/2005 12:58:17 PM|SETI@home|Requesting 3.18 seconds of work

The result? Downloaded a new SETI WU. Nice one.

That is EXACTLY the type of thing that should have been fixed, prior to a re-write of the scheduler. (It's been a bug since the beta 18 months ago).

The client requests 3.18 seconds of work, and the server happily sends a WU with an estimated completion of 10 hours!

What's wrong with that? At the time the clients scheduler needs work, so it requests and gets work and can happily crunch away the next 10 hours. It's not that the client gets more than one workunit - that would be a bug.

Why doesn't the server simply respond to a request for 3.18 seconds of work with "no work available"? (unless it has some WU's that will take less than 3.18 seconds!)

Why shouldn't the client be allowed to fill its buffer?

---

KEINE PANIK

Sebastian admit that a request for 3.18 seconds of work is fairly pointless.

It took longer than that to download the WU. What is the average time to completion of a SETI WU? Who knows. I can tell you though that the WU that was downloaded to fill that request took 9538 seconds to complete. A short WU, but still that is almost 3000 times longer than the amount of work that was requested.

Taking a crazy logic problem further, why bother requesting work to the tenth or hundredth of a second?

My point is this is just odd behaviour and should be avoided.

---

Kolch - Crunching for the BOINC@Australia team since July 2004.
Search for your own intelligence...

Sebastian admit that a request for 3.18 seconds of work is fairly pointless.

Taking a crazy logic problem further, why bother requesting work to the tenth or hundredth of a second?

But where is the point of waiting 9500 seconds and then do the stuff that could already be done 9500 seconds ago?

---

KEINE PANIK

Each project must connect once one each of three separate days in order for the stats for that project to start showing.

Perhaps this should be stated on the statistics tab?

---

@kolch,

I'd be worried about this only if the estimated time to completion was actually shorter than the real crunch time, but I have yet to see that be the case. I think you should be happy you snuck an extra WU out of the new scheduler. LOL

Haha...Just found the following message in my client:

23/05/2005 12:58:17 PM|SETI@home|Requesting 3.18 seconds of work

The result? Downloaded a new SETI WU. Nice one.

That is EXACTLY the type of thing that should have been fixed, prior to a re-write of the scheduler. (It's been a bug since the beta 18 months ago).

The client requests 3.18 seconds of work, and the server happily sends a WU with an estimated completion of 10 hours!

Why doesn't the server simply respond to a request for 3.18 seconds of work with "no work available"? (unless it has some WU's that will take less than 3.18 seconds!)

No, this behavour is quite correct. Think of CPDN and WUs that take a couple of months to process, now, think of Einstein with 7 day deadlines. Now try to make a queue size that fits both with your scheme -- not possible. So WUs that over fill the request are downloaded (but only by less than one WU).

Yes, reporting the work request to the hundredth of a second does seem a bit odd, but it also doesn't hurt anything.

---

BOINC WIKI

OK so next time when the client requests a couple of seconds work from CPDN and I get a new WU I should be happy? Not that my client is going to do that soon as it is not currently allowed to add to the 2 CPDN WU's that are keeping both CPU's busy.

---

Kolch - Crunching for the BOINC@Australia team since July 2004.
Search for your own intelligence...

OK so next time when the client requests a couple of seconds work from CPDN and I get a new WU I should be happy? Not that my client is going to do that soon as it is not currently allowed to add to the 2 CPDN WU's that are keeping both CPU's busy.

When you need the WU, yes. Do you really want a queue that is 2 months large to fit the CPDN WU?

---

BOINC WIKI

[/quote]
I need to check what was actually built into 4.43, this should not be happening. The only times that a second CPDN WU should be downloaded are:
1) An idle CPU.
2) If the CPDN WU that you have is nearly completed.[/quote]

Hi John (McLeod),

I experience the same difficulty as Ken Phillips. My computer is quite slow (PIII 1 GHz). When I upgraded from 4.13 to 4.42 (end of last week) it downloaded a second CPDN workunit, even though the 1st one was around 50% of completion (i.e. around 800 CPU hours left).

I aborted this second CPDN WU and went back to 4.25 until I read your posts about how 4.4x manages the swap between the various projects (I am running Seti, CPDN, Einstein and Predictor = 4 x 100, Alife, BURP and Pirates = 3 x 20).

So I installed 4.43 and after a few hours the CPDN WU crashed with an error code I forgot to note.

Boinc Manager then downloaded 2 CPDN WUs (in addition to 8 ghost WUs which appear only on the CPDN results page) on May 23 (yesterday), respectively at 15:41:47 and 15:41:52.

Two hours ago my long term debts amounted to:
- Alife@Home: -4,219
- BURP: -39,942
- ClimatePrediction: +24,862
- Einstein@Home: +6,173
- Pirates@Home: -18,475 (which seems strange to me since I never processed any Pirates WU under 4.4x and very few under 4.13)
- Predictor@Home: +31,454 (I can't download any WU, in spite of 8 ghost WUs listed on my results page)
- Seti@Home: +416

Preferences are set to remove from memory and to connect every 0.1 day (SDSL connection)

Regards

I need to check what was actually built into 4.43, this should not be happening. The only times that a second CPDN WU should be downloaded are:
1) An idle CPU.
2) If the CPDN WU that you have is nearly completed.[/quote]

Hi John (McLeod),

I experience the same difficulty as Ken Phillips. My computer is quite slow (PIII 1 GHz). When I upgraded from 4.13 to 4.42 (end of last week) it downloaded a second CPDN workunit, even though the 1st one was around 50% of completion (i.e. around 800 CPU hours left).

I aborted this second CPDN WU and went back to 4.25 until I read your posts about how 4.4x manages the swap between the various projects (I am running Seti, CPDN, Einstein and Predictor = 4 x 100, Alife, BURP and Pirates = 3 x 20).

So I installed 4.43 and after a few hours the CPDN WU crashed with an error code I forgot to note.

Boinc Manager then downloaded 2 CPDN WUs (in addition to 8 ghost WUs which appear only on the CPDN results page) on May 23 (yesterday), respectively at 15:41:47 and 15:41:52.

Two hours ago my long term debts amounted to:
- Alife@Home: -4,219
- BURP: -39,942
- ClimatePrediction: +24,862
- Einstein@Home: +6,173
- Pirates@Home: -18,475 (which seems strange to me since I never processed any Pirates WU under 4.4x and very few under 4.13)
- Predictor@Home: +31,454 (I can't download any WU, in spite of 8 ghost WUs listed on my results page)
- Seti@Home: +416

Preferences are set to remove from memory and to connect every 0.1 day (SDSL connection)

Regards[/quote]
I believe that I have found the cause of the extra WUs being downloaded. For the first few seconds of a run the estimated time to complete is 0 rather than the original estiamte, and the download policy thinks that the project is completely out of work. The fix is that until the % complete moves from 0 the original estimate is used. Should be fixed in 4.44.

---

BOINC WIKI