You can only install it as admin. But what you could try then is set the rights to the normal user, so he can read/write the BOINC directory and its subdirectories.

Or install BOINC as a service, that way it will always run, no matter who is logged in.

---

I wonder if your system wasn't doing one (or more) results that were nearing their deadline. Since 5.6.x there's no visible EDF anymore. So if you are attached to one project only and results preempt, it must be because another result is about to pass its sell by date.

Can you check that?

---

stopped at 100%, started next

Ah, the stopping at 100% thing. I have told the devs already about this and they haven't a clue what it could be. So report any further of these strange things happening, please. :)

---

Running 5.8.0 on a C2D, the benchmark seems high but that's not my current problem although it may be related. The 'time to completion' seems to be increasing instead of decreasing. I have WUs with to complete times of 00:37:xx that complete at about 00:21:xx but the 'time to completion' of the queued WUs continues to increase. Shouldn't they decrease? This could be related to a mix of long vs. short WUs but I don't think that should matter. This seems to affect any project's WUs.

As you can imagine this cramps my ability to get a set of WUs based on the time to complete, as it is now I'm set to a 0.5 day load but I can only get and store about 0.25 day's worth of WUs. And yes, I know that I can adjust this manually but I don't want to and it should just work correctly.

---

If your contact time is 0.5 days, but your network connection is permanent, I'd think BOINC will pull work anyhow when the work buffer is depleted... not sure how 5.8 responds to that situation.

I'm on an always-on DSL connection so getting work is not a big problem except when there are the weekly scheduled outages.

I never run Boinc while gaming or doing anything that's CPU intensive. The difference in times for un-molested WU runs and WUs running while I'm otherwise using the computer is only a few seconds, so I think the real clock time has nothing to do with the disparity in time used vs. reported time to completion.

Just today the times seem to have settled down, they seem to have stopped increasing but they're not decreasing either. It looks like a ratio is set wrong or not being properly used so now I have ~ 21/37 = 0.567568. Interestingly the DCF for that project is 0.584535 in the .xml file.

While 2 WUs finished at the same time on HT or Dualcore machines only one WU running further (Boinc 5.8.1). This is still an old problem but not fixed yet. Suspend or update will help to awake the second WU.

Windows XP SP1, P4 HT

What we think(reason) and what we know is often far apart....here a description http://boinc-wiki.ath.cx/index.php?title=Duration_Correction_Factor. Switch your machine off for parts of the day for several days in a row with work in progress and work in buffer and observe the DCF value. It's one of the key drivers that determine how much work the projects send to a client.

First of all, I'm neither stupid nor inexperienced, I am a software developer with 30+ years of experience, I speak at least 10 programming languages and I consider myself an expert in at least 3. I do know what DCF is and how it is supposed to work both in plain english and in code.

You don't want to know what I think? Well, fine then, I'll tell you what I know. Nothing has changed in the operating environment of this computer between Boinc 5.4.11 and 5.8.0, the DCF worked properly with 5.4.11 and does not with 5.8.0. The accumulated CPU time for any particular WU seems to be correct no matter what the computer is otherwise doing (or not doing), as far as I know the actual clock time plays no part in the calculation.

I have no idea how shutting down the machine would have any possible effect on accumulated CPU time except by reducing the total throughput, it certainly can't affect the DCF except in a very minor way by extending the work time for units in-progress due to re-running parts of WUs from checkpoints. At least I have never seen this behavior (WU time anomalies) on any computer running various Boinc versions since the beginning of the Boinc system.

---

Nothing has changed in the operating environment of this computer between Boinc 5.4.11 and 5.8.0

Not in the OS, no. But things have changed in BOINC. Which would be normal, since it's released as a higher version number.

What is new then, you'd ask?

* New CPU Scheduler.
* New Work Fetch Policy.
* CPU Capability detection.
* Revamped logging solution.
* Improved security for POSIX compliant systems (only implemented for the Mac)
* Add support for file compression on upload.
* BOINC Simple GUI.
* Added memory usage limits for BOINC applications. (Check preferences for new settings)

The first 2 hack directly into any DCF you had before.
But as always, the less you tinker with it, the faster it'll work again as before. Although with a difference.

5.8.x has to learn again from the beginning. If you are attached to 3 projects, a 5.4.x version would get you 1 day worth of work combined all over the projects. Now depending on resource share, the debts for the various projects and if you want to give Boinc time to learn again, it will fetch that day worth of work per project. Within boundaries of course.

If you force to catch more work, because you want a project to have more work, it isn't Boinc's fault that it crunches one project only at one time, even without notifying you of the state it is in (there is no EDF mode anymore).

You may also notice that the switch between projects time isn't so strict anymore. Although if one project has a lot of small results, Boinc will try to run that one only for as long as the switch over time goes (default 60 minutes), or until it has no results for that project in queue anymore.

But in a nutshell, the only thing really still comparable between 5.4.x and 5.8.x is that it is Boinc. It has changed so much and for the better that it may take a while to get used to again.

---

And now with 5.8.1:

Unhandled Exception Detected...

- Unhandled Exception Record -
Reason: Access Violation (0xc0000005) at address 0x0033BA64 read attempt to address 0x00000008

Engaging BOINC Windows Runtime Debugger...


"Boinc Manager is not able to connect to..." and after some tries to restart Boinc it connected.

pre-empting :O

Waiting you mean... Preempted is no longer shown. It's now "Waiting". ;-)

---

Yes, I believe it did checkpoint at real 100%, as the task, after getting its turn again, did not need more than few CPU seconds during swapping to finish. And I believe if I had enough RAM available, the task would finish immediately.

I think a prerequisite for it to happen is that the computer should crunch for different projects. I think the various FAAHs have too similar deadlines, if some computer crunches only FAAH. Possibly having different WCG apps is enough?

Peter

Just installed Boinc 5.8.1-gnu on my mandriva 2005 LE machine KDE environment (just to test :o):
Minor problems I noticed in the simple view:

-The message button doesn't work: the manager crashes immediatly and my Rosetta Wu crashed also. Each time I press the message button, the manager crashes but the Einstein Wus are OK (boinc as a service is running OK)
-The buttons are cutted horizontaly: the text is almost unreadable without the "info-bubbles" explaining what the button is supposed to do.
-The "get help button" tries to open the following adress in Epiphany: http://.....;⽵manager_links.php/?target=simple

In the preferences window:
-the buttons at the bottom (next to the ?) are completly unreadable: I can't see the text, I just see a blue line with white dots (I suppose the text is in White on a blue background).
-The ? button tries to open: http://......
��manager_links.php/?target=simple_preferences&controlid=5112
and I have to push it twice to open the browser (once: the browser doesn't open)

Screenshot1
Screenshot2

When in pause, I think the little green dot desappearing is not enough to show that Boinc is in pause (there is no tray icon in Linux): so the red word "in pause" somewhere in the simple view would be welcome, IMHO.(I know Linux guys are not using the pause button, but nonetheless......:o))

Although these problems, the other features are working and boinc is working, so keep on the good work...

HTH
(BTW, I have a cc_config.xml file, so perhaps I can pass an option to know why the manager crashes when I push the message button)

---

Just installed Boinc 5.8.1-gnu on my mandriva 2005 LE machine KDE environment (just to test :o):
Minor problems I noticed in the simple view:

-The message button doesn't work: the manager crashes immediatly and my Rosetta Wu crashed also. Each time I press the message button, the manager crashes but the Einstein Wus are OK (boinc as a service is running OK)
-The buttons are cutted horizontaly: the text is almost unreadable without the "info-bubbles" explaining what the button is supposed to do.
-The "get help button" tries to open the following adress in Epiphany: http://.....;⽵manager_links.php/?target=simple

In the preferences window:
-the buttons at the bottom (next to the ?) are completly unreadable: I can't see the text, I just see a blue line with white dots (I suppose the text is in White on a blue background).
-The ? button tries to open: http://......
��manager_links.php/?target=simple_preferences&controlid=5112
and I have to push it twice to open the browser (once: the browser doesn't open)

Screenshot1
Screenshot2

When in pause, I think the little green dot desappearing is not enough to show that Boinc is in pause (there is no tray icon in Linux): so the red word "in pause" somewhere in the simple view would be welcome, IMHO.(I know Linux guys are not using the pause button, but nonetheless......:o))

Although these problems, the other features are working and boinc is working, so keep on the good work...

HTH
(BTW, I have a cc_config.xml file, so perhaps I can pass an option to know why the manager crashes when I push the message button)

Hello Arnaud,

Just for the sake of testing I did the same with my Ubuntu 6.10 host.
Installed 5.8.1, loaded my latest dutch translation and "installed" some skins by creating a "skins" ("Skins" did not work) directory and placing the needed skin files there.

Results were almost the same.

Message button closed the BOINC manager, but BOINC (and the app running) remained active.

Buttons were also to small.
(as I can remember I saw somewhere a simular post regarding this "size" issue on MAC-OS)

Regarding pausing the running wu; when loaded proper, the Simple Gui also should display the work status under the slide show (in your screenshot the BOINC in black logo), on the spot where now a white beam is shown.

I also saw some strange behaviour after viewing the Simple Gui.
Closing the BOINC manager should close all, but after viewing the Simple Gui all stays active.
No simular behaviour without viewing the Simple Gui.
The manager comes with the "close confirmation" message and all stops.

Besides from that the manager seems to work fine, Seti and Docking wu's are running OK.

regards,
Rene

---

Nothing has changed in the operating environment of this computer between Boinc 5.4.11 and 5.8.0

Not in the OS, no. But things have changed in BOINC. Which would be normal, since it's released as a higher version number.

What is new then, you'd ask?

* New CPU Scheduler.
* New Work Fetch Policy.
* CPU Capability detection.
* Revamped logging solution.
* Improved security for POSIX compliant systems (only implemented for the Mac)
* Add support for file compression on upload.
* BOINC Simple GUI.
* Added memory usage limits for BOINC applications. (Check preferences for new settings)

The first 2 hack directly into any DCF you had before.
But as always, the less you tinker with it, the faster it'll work again as before. Although with a difference.

5.8.x has to learn again from the beginning. If you are attached to 3 projects, a 5.4.x version would get you 1 day worth of work combined all over the projects. Now depending on resource share, the debts for the various projects and if you want to give Boinc time to learn again, it will fetch that day worth of work per project. Within boundaries of course.

If you force to catch more work, because you want a project to have more work, it isn't Boinc's fault that it crunches one project only at one time, even without notifying you of the state it is in (there is no EDF mode anymore).

You may also notice that the switch between projects time isn't so strict anymore. Although if one project has a lot of small results, Boinc will try to run that one only for as long as the switch over time goes (default 60 minutes), or until it has no results for that project in queue anymore.

But in a nutshell, the only thing really still comparable between 5.4.x and 5.8.x is that it is Boinc. It has changed so much and for the better that it may take a while to get used to again.

Jord,
Have been running ver 5.8.0 since 13th Dec and DCF is not being taken into account on the three projects I run. Seti, SetiB and Einstein. That is on both computers, Pent M and C2D.

Andy

I have some hosts running 5.8.1 that aren't showing the correct user friendly application names (when viewed in BoincView). I've seen this on Rosetta and WGC.

The client_state.xml file does contain relevant user_friendly_name entries, but the contents are wrong (they're set to the old application name not the new user friendly version).

A manual update on those projects does not update the user friendly names. The only way to get them to change is to reset the project.

Shouldn't an update allow the user friendly names to be updated? Bug?

---

Jord,
Have been running ver 5.8.0 since 13th Dec and DCF is not being taken into account on the three projects I run. Seti, SetiB and Einstein. That is on both computers, Pent M and C2D.

Andy

And you reported that on the Alpha site/email list, right? Or you told JM7? ;-)
Although this could well have to do with the variation in WU length.
EAH has short and long ones.
Seti has ultra short to extreme long ones.
SetiB has ultra short to extreme long ones.

If you run a couple of short ones first for a while, then you get pitched a very long one, how would DCF know that? It's set per project, not per application. Maybe that it needs that, though.

---

Shouldn't an update allow the user friendly names to be updated? Bug?

Um, explain. What are user friendly names? Give an example or two.

---

Shouldn't an update allow the user friendly names to be updated? Bug?

Um, explain. What are user friendly names? Give an example or two.

WGC has an application called "fcg1", BOINC Manager uses that name in the Task list in the Advanced View. However, in the Simple View on the "fgc1" tab it shows the Application as "Genome Comparison" instead - the "Genome Comparison" is the user_friendly_name that comes from the project.

BoincView also shows the Application as "Genome Comparison" instead of "fgc1".

That's on a host that's working and its what I'd expect to see on all hosts running 5.8.1 and WGC.

On a different host running 5.8.1, the application is still showing as "fgc1". If I reset the WGC project on that host, it'll start showing "Genome Comparison" instead, but I think just an Update should do it.

WGC uses friendly names for all its projects, hdc is Help Defeat Cancer, faah becomes FightingAIDS I think. Rosetta uses them too, but it just uses "Rosetta" as the friendly name for "rosetta" (different case).

---

Ah OK. In that case I think you will get the new names once BOINC has contacted the WCG scheduler and gotten the new naming convention in. Do you (or anyone else) still have one machine that shows the names in the old format, so you can test if Boinc automatically updates?

---

Ah OK. In that case I think you will get the new names once BOINC has contacted the WCG scheduler and gotten the new naming convention in. Do you (or anyone else) still have one machine that shows the names in the old format, so you can test if Boinc automatically updates?

Yes, I have a few hosts showing the old format names and they don't seem to be updating them on their own or with manual updates. The hosts have been running 5.8.0 since before Christmas and 5.8.1 for the last 48 hours with a 'connect to' period of 0.2 days, so they've contacted the WGC scheduler a few times now.

---