LHC@home

I tried the new v4.41 out on 1 PC, quite borked IMO ... hehe

I got all kinds of weird messages, it wouldn't report a finished WU no matter what I tried, it said something about the CPU needing to be scheduled ( Maybe we need to make an appointment before getting any new WU's ... :P) & something about the WU's deadlines were before the reconnect time ... I just went back to v4.25 again with no problems ... :)

> I tried the new v4.41 out on 1 PC, quite borked IMO ... hehe
>
> I got all kinds of weird messages, it wouldn't report a finished WU no matter
> what I tried, it said something about the CPU needing to be scheduled ( Maybe
> we need to make an appointment before getting any new WU's ... :P) &
> something about the WU's deadlines were before the reconnect time ... I just
> went back to v4.25 again with no problems ... :)

You are getting an information/status message saying that at this point in time the BOINC Daemon's Work Scheduler has to evaluate the current work loads/debt/shares and to then assign (schedule) a Work Unit to a CPU that is idle.

I know it is Geek speak, but ... it almost makes sense when you are in the right mindset. Of course, I am weirdsville anyway ... but that is what it is supposed to be telling you ...

---

I'm still playing around with the new v4.41 on 1 PC Paul, it seems to work ok as far as running the WU's but so far I haven't been able to Report any Finished WU's with it.

All I get is the following Message when I do an Update to try and Report any Finished WU's ... ???

AM||request_reschedule_cpus: project op
5/16/2005 6:10:46 AM||schedule_cpus: must schedule
5/16/2005 6:10:46 AM||earliest deadline: 1116790856.000000 v64D1D2MQonlyinjnoskew1b5offcomp-56s8_10562.3077_1_sixvf_44275_4
5/16/2005 6:10:46 AM||earliest deadline: 1116790856.000000 v64D1D2MQonlyinjnoskew1b5offcomp-56s8_10553.6539_1_sixvf_44270_3

Any Ideas or is this a bug or what, I'll get the finished WU's Reported if I have to go back to v4.25 but would like to keep running the v4.41 if I can get them Reported with it ...

PS: I went over to the Seti site because I seen a Thread there started on the v4.41 & apparently it's a known bug & other people are having the same problem reporting WU's to the other Sites too. Rom Walton said there would be a fix in the next release ...

> I'm still playing around with the new v4.41 on 1 PC Paul, it seems to work ok
> as far as running the WU's but so far I haven't been able to Report any
> Finished WU's with it.
>
> All I get is the following Message when I do an Update to try and Report any
> Finished WU's ... ???
>
> AM||request_reschedule_cpus: project op
> 5/16/2005 6:10:46 AM||schedule_cpus: must schedule
> 5/16/2005 6:10:46 AM||earliest deadline: 1116790856.000000
> v64D1D2MQonlyinjnoskew1b5offcomp-56s8_10562.3077_1_sixvf_44275_4
> 5/16/2005 6:10:46 AM||earliest deadline: 1116790856.000000
> v64D1D2MQonlyinjnoskew1b5offcomp-56s8_10553.6539_1_sixvf_44270_3
>
> Any Ideas or is this a bug or what, I'll get the finished WU's Reported if I
> have to go back to v4.25 but would like to keep running the v4.41 if I can get
> them Reported with it ...
>
> PS: I went over to the Seti site because I seen a Thread there started on the
> v4.41 & apparently it's a known bug & other people are having the same
> problem reporting WU's to the other Sites too. Rom Walton said there would be
> a fix in the next release ...

As far as I have been able to tell, that is the bug they are chasing. One of the reasons I am glad I stuck with earlier versions. :)

I know they want to get another stable version done, but it looks like they can't get the bugs squished faster than they are making new ones.

---

As far as I have been able to tell, that is the bug they are chasing. One of the reasons I am glad I stuck with earlier versions. :)
==========

Yup, I just went back to v4.25 & Reported the WU's, I won't go with a newer version again until I check the Seti Site first for bug's on the release. It's to much hassle switching version all the time & then you take the chance of messing things up & losing the WU's too ...

The new v4.42 release seems to have fixed the no Report for finished WU's problem, I tried it on 1 PC after a few people in the Seti Forum said they were able to Report finished WU's with it & it worked for me too ...

> I know it is Geek speak, but ... it almost makes sense when you are in
> the right mindset. Of course, I am weirdsville anyway ... but that is what it
> is supposed to be telling you ...
>
What do you mean almost. It makes perfect sense to me, but then I guess I am a geek. Do you have a better wording to suggest?

---

BOINC WIKI

> > I know it is Geek speak, but ... it almost makes sense when you
> are in
> > the right mindset. Of course, I am weirdsville anyway ... but that is
> what it
> > is supposed to be telling you ...
> >
> What do you mean almost. It makes perfect sense to me, but then
> I guess I am a geek. Do you have a better wording to suggest?
>
I have to say: the current output from the BOINC client is impenetrable to me. It's not even Geek speak. 'Project specific jargon' might describe it, and for those of us not following the twists and turns of BOINC development in minute detail the jargon makes no sense.

I guess it's down to Paul and JM7 to translate for the rest of us. Keep up the good work, guys!

---

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

> What do you mean almost. It makes perfect sense to me, but then
> I guess I am a geek. Do you have a better wording to suggest?

No. :)

If you look on Einstein@Home I explained the difference between The Scheduler and the BOINC Daemon Work Scheduler. And from the Operating System world, the way that you use the words makes sense. The problem is that not all Participants have studied Operating Systems ...

If you think back to those early days in the beta test when I foamed at the mouth about use of unambigous and clear termonology, well, this is the reason that *I* feel it is of such importance to have things properly and clearly named. If they are not, then people have problems with it.

My favorite bad name is still "core client" as it means nothing. As a matter of fact, with the current architecture is has no meaning at all ... yet it is still used, and worse, is used in project Official documentation.

---

even the actual 4.25 one is not quite reliable
quoting http://boinc.berkeley.edu/download.php#windows
<I>
* The BOINC screensaver conflicts with Microsoft Intellitype software.
* Applications that were built before October 2004 do not display screensaver graphics with the Service or Shared installation, or the Single-user installation with the password protect screensaver option on NT based machines.
* If BOINC runs at the same time as Windows XP 3D screensavers, the system becomes sluggish and unresponsive.
* Dial-up users should choose the single-user installation.
* Graphics sometimes do not work with ATI Graphics card. If you have this problem, please visit the SETI@home Q&A area, fill in the requested information, and click on the "I also have this question" button.

<B>If you experience any of these problems, we recommend using BOINC version 4.19.</B>
</I>
good thing I still use the good old 4.19 :)

---

even the actual 4.25 one is not quite reliable
quoting http://boinc.berkeley.edu/download.php#windows
==========

Maybe not, but I've been using v4.25 for quite awhile now without any problems.
The last few days I've even been running v4.42 on all my PC's without on problems so far ... :)

> Short answer, normal behaviour.
>
> écoute mois bien:
> But please listen to that I want to say about this and all perhaps following
> What is this, or what is that.
>
> The only recommanded Boinc Client Version out right now is still the version
> 4.19.
>
> Every Version above is alpha, that means perhaps not stable, not out for
> grands public.
>
> Those Version are still in test phases.
>
> So please
> stop to put this kind of Questions, basically non related to the
> toppics of
>
> Number Crunching
>
> Ici on parle d'autres chauses que du client, on parle des pros de LHC,
> des applications de LHC et des aspès techniques
>
> Here we (try) to talk about LHC related stuff, no work, to much work,
> no credits, Applications behaviour, not the CLIENT behaviour.
>
> I would like to invite you very friendly to put your question about a non
> official, not supported client at an other place.
>
> Your DB Country entry is france, take a look to
> par example there where the L?A boys and girls are at home.
> http://forum.boinc.fr/
>
> There you can talk in french and they would be proud to give you an answer.
> Perhaps.
> With a little liite time effort, you can teach yourself
> about boinc CLIENTS and what are their nomar behaviour.
>
> This type of Question is IMMO realy an abuse of this board and the dev stuff
> time.
>
>
>
>
>

---

> > Short answer, normal behaviour.
> >
> > écoute mois bien:
> > But please listen to that I want to say about this and all perhaps
> following
> > What is this, or what is that.
> >
> > The only recommanded Boinc Client Version out right now is still the
> version
> > 4.19.
> >
> > Every Version above is alpha, that means perhaps not stable, not out for
> > grands public.
> >
> > Those Version are still in test phases.
> >
> > So please
> > stop to put this kind of Questions, basically non related to the
> > toppics of





c'etait un tres grand plaisir de lire votre "reponse"
vive les ricolas et n'oubliez pas de nous fair part de de grosses nombres encore et encore et encore
vous etes ici pour aider ou juste montrer que vous avez les moyens de vous payer les grosses becanes
franchement vous me faites pitie
MERDE
> >
> > Number Crunching
> >
> > Ici on parle d'autres chauses que du client, on parle des pros de LHC,
> > des applications de LHC et des aspès techniques
> >
> > Here we (try) to talk about LHC related stuff, no work, to much work,
> > no credits, Applications behaviour, not the CLIENT behaviour.
> >
> > I would like to invite you very friendly to put your question about a
> non
> > official, not supported client at an other place.
> >
> > Your DB Country entry is france, take a look to
> > par example there where the L?A boys and girls are at home.
> > http://forum.boinc.fr/
> >
> > There you can talk in french and they would be proud to give you an
> answer.
> > Perhaps.
> > With a little liite time effort, you can teach yourself
> > about boinc CLIENTS and what are their nomar behaviour.
> >
> > This type of Question is IMMO realy an abuse of this board and the dev
> stuff
> > time.
> >
> >
> >
> >
> >
>

---

I've got 4.42 "development version" on one machine.. seems to be more stable than the 4.3x versions.. the rest of my machines are on 4.19. (that seems most stable.)

oh, now 4.43 is available from BOINC.

// Brian

---

Expanding the edge of Science.

> oh, now 4.43 is available from BOINC.
>
> // Brian
>
>
Got yesterday the 4.43 Version and installed to one m$ client.

First surprise, no more connection error while starting the boinc client.
At least so far, much less cpu usage than prior release, more left for the
"crunching" part.

Right now operating with 1 Predictor and 2 LHC Alpha WUs.
It looks like, the thingy with localy scheduling it running in "normal" mode instead of "panic" mode.

not seeing much of those messages:

request_reschedule_cpus: project op
schedule_cpus: must schedule

Stats tab already there and has "entries", the buttons are doing the action selected.

on first view, looks not bad;)

> > oh, now 4.43 is available from BOINC.
> >
> > // Brian
> >
> >
> Got yesterday the 4.43 Version and installed to one m$ client.
>
> First surprise, no more connection error while starting the boinc client.
> At least so far, much less cpu usage than prior release, more left for the
> "crunching" part.
>
> Right now operating with 1 Predictor and 2 LHC Alpha WUs.
> It looks like, the thingy with localy scheduling it running in "normal" mode
> instead of "panic" mode.
>
> not seeing much of those messages:
>
> request_reschedule_cpus: project op
> schedule_cpus: must schedule
>
> Stats tab already there and has "entries", the buttons are doing the action
> selected.
>
> on first view, looks not bad;)
>
>
>
Wenn Du etwas sarkatsitsch meinst oder ironisch, mach das nächstemal eine Notiz, sonst werden obenstehende Meldungen als gut betrachtet, was sie ja nicht sind.
Danke für die sinnlose Arbeit.
lB

adding:

just came home and looking to the clients.
The 4.43 client is still up, didn't crashed.
The works was finished a log time ago and have been reported.

2nd view:
the client was not getting work from any of the attached projects.
Depending the point of view, it's just a minor issue(!).

Ouside of this, the client looks great.

Due it's an alpha release, so nothing is running outside of the estimation...

Sometimes, good things need time to be cooked well.
______________________________________________________


> Wenn Du etwas sarkatsitsch(wär isch dasch?) meinst oder ironisch, mach das nächstemal eine
> Notiz, sonst werden obenstehende Meldungen als gut betrachtet, was sie ja
> nicht sind.
> Danke für die sinnlose Arbeit.
> lB

Das war sicher nicht sinnlos. Alles hat einen und macht Sinn. Der Mensch gar Unsinn. Schimpfe nicht mit mir, spare Deinen Zorn für die Entwickler auf.

It should be written and rewritten everytime, that the use of not recommended version of boinc clients is risky and can offer bad moments.

> Sometimes, good things need time to be cooked well.
> ______________________________________________________

When we look at how long it took for us to get the first work scheduler working, this is going well. THough I am still sitting on the sidelines until the dust settles. :)

Just for fun ... here is a point paper where we were discussing the issues with the then new work scheduler ... and before you ask, yes I am demented for saving something like this ... this is un-edited from its origin file with the exception of the removal of extra line feeds.

=====================================
Version 003

Two structural components should be understood before we proceed.

1) The host computer may have multiple logical or physical CPUs processing work for the attached projects. Work is assigned to each of the host's processing elements (CPUs) independently of all other processing elements.

2) There is only one work queue within the BOINC framework. This means that the work queue is used by all attached projects. (5)

This is how BOINC switches between multiple projects. Unless otherwise specified an equal resource share (100) is used since this is the default behavior of BOINC. The resource share for any project can be changed to any number to prioritize (emphasize or de-emphasize) CPU time allocated to projects. Each project must be attached separately to each BOINC client. The current beta project is one project that has two classes of work units Astropulse (AP) and SETI@Home (SAH).

BOINC adds up the resource shares to get a total. The resource shares can be set differently for different projects. If you have 4 projects on one computer the default values unchanged the total would be 400. It then converts this to a percentage by dividing a specific project's share by the total 100/400=0.25 or 25% per project. This is the percentage displayed in the projects tab of the GUI. If you have changed the default resource shares to, lets say, 100 for project 1, 100 for project 2, 300 for project 3 and 300 for project 4 the total would be 800, the specific project share for the projects 1 and 2 would be 100/800=12.5% and the specific project shares for projects 3 and 4 would be 300/800=37.5%

BOINC figures resource debt (rDbt) in a similar fashion. The exponential averaged CPU time is totaled for all projects (tCPU). Then a specific projects CPU time (pCPU) is divided by this total to get a percentage (eCPU% = pCPU / tCPU). This percentage is compared to the resource share percentage (share%)to get the resource debt. rDebt=share%-eCPU%.

When the CPU currently executing a BOINC project WU completes the processing on that specific WU, BOINC will schedule the next project to be processed. BOINC will attempt to schedule work starting with the project with the greatest resource debt. If there is work available within the queue then processing on the project's available work will begin. If there is no work in the queue for that project, then BOINC will attempt to contact that project's data server to get additional work units. If BOINC is unable to get work from this project's data server it will try the project with the next highest resource debt. It will continue stepping through the projects until it can retrieve work for the project with the highest resource debt (rDbt)that is not currently in a backed off state. The use of exponential back-off in the determination of which project to schedule is to prevent the flooding of the work servers with requests for work when there is none available. Note that there is a maximum upper limit on requests for work of 4 hours, with master fetches being capped at 2 weeks. (4) (1a) (1b) (1c)

BOINC will begin to process the work unit for the selected project that has the closest deadline. It will not run 2 or more projects at a percentage of the CPU, but will switch between projects based on which project has available work and also has the highest resource debt (rDbt). On hosts with multiple logical or physical CPUs it should be noted that each individual CPU will complete work and will then schedule new work based on the currently existing resource debts (rDbt) for all of the projects and then use WU deadlines to select a specific WU within the queue.

In the simplest terms, work on a WU is allocated based on the interplay of two factors.

- Resource debt (rDBT): is used to select the project that is next in line. And,

- Wouk Unit Deadline: The work unit with in the queue with nearest deadline is used to select the specific WU that is to be processed.

As you can see depending on your queue settings BOINC will run one to a few work units from one project then will run a similar amount of work from a different project.

========

Real world expectations and observations:

Typically, a new project will run exclusively for one to four weeks while the CPU allocation and resource debits even out. This also means that if a project has intermittent work available that project will dominate when it has work and drop off when it does not. If all projects are new then they are already balanced at zero resource debt (rDbt) and will move up together.

Since the available CPU time is different on each CPU, and project work availability will affect the queue, and work unit processing time varies, it can be expected that the host will have to run a new project for 1 to 4 weeks before they will experience a change in the work load balancing. There is no way to effect a work effort "jump-start" by changing one host's resource allocation to one project first and then changing the resource allocations for the other projects.

A project reset also resets the CPU time so a reset project will cause a project to behave as if it is a new project.

==========

Boundary conditions (and expected behavior of BOINC for each condition):

1) The Host has *NOT* been attached to any projects.

No action is performed and BOINC will be in a "sleep" state until the user successfully attaches to a project and work is entered into the queue.

2) The Host has been involved with an attempt to attach to one project but the host cannot process the project's WU(s) within the defined deadline.

An error condition is returned to the user of the host indicating that this project has greater resource needs than can be provided by that host. If there are other projects attached to this host BOINC will try to get work from them.

3) The Host has been attached to one project and there is work available, and the host can process the project's WU(s) within the defined deadline.

The queue is filled to the initially calculated full extent with the queue "high-water mark" gradually decreasing if the host is not activly processing 24/7.

Expected normal behavior of BOINC and all of the attached project's clients. Allocation of CPU processing time to projects will be performed using the Resource Debt (rDbt) method as previously described.

4) The Host has been attached to one or more projects but currently there is no work available for any of the projects.

BOINC will test for work for all projects using exponential back-off until the back-off interval exceeds maximum or it finds work.

As described above BOINC will get work from exactly one project. It contacts the projects in resource debt order (rDbt), and takes work from the first one that has available work that this client can complete. Once work is found or new work is downloaded, no work is downloaded again until the queue's low water mark is reached.

This is a normal and expected behavior where we transition from this state to the state described in boundary condition #3.

5) The Host has been attached to one or more projects and currently there is work available for one or more of the projects and the host can complete queued WU for all projects for which there is work queued.

Expected normal behavior of BOINC and all of the attached project's clients.

Allocation of CPU processing time to a specific project will be performed using the Resource Debt (rDbt) project selection method as previously described. Selection of the specific work unit to be processed is performed using the nearest deadline method.

6) The Host has been attached to one or more projects and currently there is work available for one or more of the projects and the host can *NOT* complete queued WU for one or more projects.

Allocation of CPU processing time to projects will be performed using the Resource Debt (rDbt) project selection method as previously described.

Work Units within the selected project that cannot be completed will be immediately marked as "expired" and this information will be returned to the project's work unit server when the next communication action occurs (note that the event that triggers a communication action may be for a different project). (3)

It is not anticipated that this will occur in normal operation.

7) The Host has been attached to one or more projects and currently there is work available for one or more of the projects and the host can complete the currently queued WU for all projects and the host is involved in an attempt to attach to an additional project and the host will be able to complete all queued WU for all projects (including the new project).

This is a slight change from condition #5

Expected normal behavior of BOINC and all of the attached project's clients.

Allocation of CPU processing time to projects will be performed using the Resource Debt (rDbt) project selection method as previously described.


8) The Host has been attached to one or more projects and currently there is work available for one or more of the projects and the host can complete queued WU for all projects and the host is involved in an attempt to attach to an additional project and the host will no longer be able to complete all queued WU for all projects (including the new project).

This is a slight change from condition #6

Allocation of CPU processing time to projects will be performed using the Resource Debt (rDbt) project selection method as previously described.


9) The Host has been attached to one or more projects but currently all projects have been suspended (assuming that this requested feature is added).

To Be Defined (TBD)

**************

Notes:

1) Invalid

however, I think these still are still valid question/objections/what the heck...

1a) The exponential back off is zeroed for a specific project when it is sucessfully contacted. Other projects will still have to wait out their back off period before they can be contacted.

1b) is there a "hard" cap on the magnitude of the back-off time to prevent a user from not ever getting work because of misses on the windows where work is available?

1c) Should it not make an exponential back off until a hard cap of, say, 24 hours (or user defined interval varying between a min max of 24 hours and a max max of one month?).

2)

Ooohhhh...

I was missing this point also in my ruminations on the scheduler. Each CPU on each host is NOT coupled with the other CPUs. Each CPU completes a WU and then, INDEPENDENTLY of all other CPUs will calculate the EXISTING rDbt to determine the project that will be selected and THEN schedule its next WU to process based upon the deadline for the specific WUs in the queue.

3) The communication transactions are a little out of the scope of this so I did not amplify more.

4) ok, what the hell are "Master" fetches? A master fetch retrieves basic project information like where to contact the sheduling and data servers.

6) There is a problem with using the nearest deadline that has to do with a combination of projects with long crunch times, projects with short crunch times, multiple CPUs and having the long crunch time project only having work occasionally. The scenario: the host has a resource debt for ClimatePrediction, and contacts that server, and actually gets one WU. The other CPUs have to be fed, and there are not enough WUs to keep the other CPUs crunching, so the host contacts SETI, and gets some work. Now the SETI deadline is in 2 weeks, and the CP deadline is in 6 months. Assume that the CP project does not have any more work available for this client for the next 6 months. Assume that the SETI project always has work for the next 6 months. The SETI WUs will get preference on the CPUs until two weeks before the CP WU is due. At this point, there is no hope that the CP WU will be completed before the deadline. I propose that the queue be strict FIFO (first in first out), the first WU downloaded is the first WU crunched. etc. This solves the problem nicely.

***edit***

There are similar problems with 6,7,and 8.

CPU1

CPU2

Queue

---