LHC@home

The server is now running with new BOINC scheduler components. They have been tested on the Alpha site but they still might have problems. If so, please report in this thread.

If I have understood correctly our physics team, new work will be released very soon (tomorrow I hope).

---

Markku Degerholm
LHC@home admin

> The server is now running with new BOINC scheduler components. They have been
> tested on the Alpha site but they still might have problems. If so, please
> report in this thread.
>
> If I have understood correctly our physics team, new work will be released
> very soon (tomorrow I hope).
>
>
Does LHC Staff still recommend 4.19 Boinc Client? Or 4.25? Or the latest 4.4x branch?

I assume when reporting problems, you want us to post the Boinc Version used as well.. (hint to everyone else posting here)

---

Thankyou for keep us up to date.

The question of the boinc client is becoming a central focused thing.

A lot of people are right now passing alived nightmares, only due the new clients.

The outlook of new work from LHC, is like honey for our poor souls.


Basically, isn't there a way to proceed the sixtrack family without the need to use a boinc architecture/clients?

Perhaps one day, there will be a special LHC-NIX or cernix doing the same job.

Or even using DOS 3.11 it would be ok;)

> Basically, isn't there a way to proceed the sixtrack family without the
> need to use a boinc architecture/clients?

Ric,

I think you are confusing the Scheduler on the server side with the Work Scheduler on the Client side ... They updated the server side code, but if you are running an earlier version of the BOINC Client Software then you should not see a difference.

Much of the ado over the new Work Scheduler has to do with people getting used to the way it used to work even though that was not how it was supposed to work. Now that JM VII is making the changes so that it works the way it always should have worked, well, we have angst now ...

I am running a mixed bag of versions, 4.25, 4.3, 4.43, and 4.44 and aside from some interesting problems with the Predictor@Home not working right and CPDN not starting on the Macintosh 4.43 version, I have seen little or no problems.

---

> Much of the ado over the new Work Scheduler has to do with people getting used
> to the way it used to work even though that was not how it was supposed to
> work. Now that JM VII is making the changes so that it works the way it always
> should have worked, well, we have angst now ...

So the way it should have worked is to not allow modem users to top off their cache when they're online? It makes more sense to log off when you only have half a WU to complete before you run dry? I guess that makes sense to a computer, but as is often the case, the human mind is a bit better at looking ahead and deciding whether or not absolutes are the best course of action. Does a half hour really make that much difference in when new work is downloaded? Not to a machine I'm sure, but if I need to log off and can't wait a half an hour to do so, it makes quite a difference to me.

It's what I have termed a CC induced project outage. If I cannot get the work I need before I have to log off, the CC is doing the project in question a disservice because I will not be processing until I get logged on again...

Not very useful in my opinion.

Now granted, I do have work on my machine from other projects so I'm not sitting idle, but that's not the point. And yes, I understand how the long term debt system works, so I know that the CC will attempt to run that project more to catch up when I get more work, in order to meet my resource share settings. The point is, it shouldn't have to play catch up. The project had work to give, I simply was unable to request more when I was connected due to the schedulers choke hold.

> Now granted, I do have work on my machine from other projects so I'm
> not sitting idle, but that's not the point. And yes, I understand how the long
> term debt system works, so I know that the CC will attempt to run that project
> more to catch up when I get more work, in order to meet my resource share
> settings. The point is, it shouldn't have to play catch up. The project
> had work to give, I simply was unable to request more when I was connected due
> to the schedulers choke hold.

This has also been one of my points this whole debate, since what happens when the modem user goes to connect next time and the project in question has an outage and you can't get work (again).

I currently have the situation were BOINC has completed all Einstein work and for some reason I have none in my cache and it only takes 11hrs to go a wu and with the resource share I have set up it should be completed within 24hrs of real time. I still say go figure and this situation is rediculous. Currently I only have predictor wu's and am impatiently waiting for LHC work.

Live long and crunch!

---

Paul
(S@H1 8888)
BOINC/SAH BETA

If I have understood correctly our physics team, new work will be released very soon (tomorrow I hope).
==========

Woot ... It must tomorrow, I recieved 32 LHC WU's the last few hours ... hahaha ... :P

> If I have understood correctly our physics team, new work will be released
> very soon (tomorrow I hope).
> ==========
>
> Woot ... It must tomorrow, I recieved 32 LHC WU's the last few hours ...
> hahaha ... :P
>
As I have stated in another thread....there are names for people like you PoorBoy! ;P The most common starts with B and ends with d.

Lucky bugger...live long and crunch!

Paul.

> As I have stated in another thread....there are names for people like you
> PoorBoy! ;P The most common starts with B and ends with d.

Big Lad? ;)

This is also off topic, but I agree that the client scheduler is going the wrong way. I want to control my systems, not some dumb software component. I know if I'm going away for the weekend, the BOINC client does not.

Silly example, but very real.

---

Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.

> As I have stated in another thread....there are names for people like you
> PoorBoy! ;P The most common starts with B and ends with d.

Boinc survived?

----------------------.-------------------------.----------------------
usualy this host (cl 4.44 m$, 3.5 GHz HT) is getting one single Unit form a project, when letting the local scheduller doing the job itself. Then the finished work is sitting a while on the host, finaly it downloading another single WU. but just one. The resulting share for every project is at least 10%-33%

but there is hope:


Klick to show larger image.
(BSK!)
The scheduler is working "excellent", if the client has something to do..




There is a proverb here in Europe, I don't know if it's known everywhere

german: wenn der Prophet nicht zum Berge kommt, geht der Berg zum Proheten

"bad English":
When the prophet is not going to the mountain, the mountain is going to the prophet.


Happy contribution to science

> > Much of the ado over the new Work Scheduler has to do with people getting
> used
> > to the way it used to work even though that was not how it was supposed
> to
> > work. Now that JM VII is making the changes so that it works the way it
> always
> > should have worked, well, we have angst now ...
>
> So the way it should have worked is to not allow modem users to top off their
> cache when they're online? It makes more sense to log off when you only have
> half a WU to complete before you run dry? I guess that makes sense to a
> computer, but as is often the case, the human mind is a bit better at looking
> ahead and deciding whether or not absolutes are the best course of action.
> Does a half hour really make that much difference in when new work is
> downloaded? Not to a machine I'm sure, but if I need to log off and can't wait
> a half an hour to do so, it makes quite a difference to me.
>
> It's what I have termed a CC induced project outage. If I cannot get the work
> I need before I have to log off, the CC is doing the project in question a
> disservice because I will not be processing until I get logged on again...
>
> Not very useful in my opinion.
>
> Now granted, I do have work on my machine from other projects so I'm
> not sitting idle, but that's not the point. And yes, I understand how the long
> term debt system works, so I know that the CC will attempt to run that project
> more to catch up when I get more work, in order to meet my resource share
> settings. The point is, it shouldn't have to play catch up. The project
> had work to give, I simply was unable to request more when I was connected due
> to the schedulers choke hold.
>
Unfortunately, there is major tension between honoring resource share over the long term, and getting work for all projects all of the time. There is also a bug (that I believe still exists in 4.44) where duals and HT machines would stop requesting work too early and only get a half a cache full sometimes. For this, I have submitted a fix.

---

BOINC WIKI

> Unfortunately, there is major tension between honoring resource share over the
> long term, and getting work for all projects all of the time. There is also a
> bug (that I believe still exists in 4.44) where duals and HT machines would
> stop requesting work too early and only get a half a cache full sometimes.
> For this, I have submitted a fix.

That's my point though... I've had no problem in the past honoring resource shares and keeping work for all my projects without blowing past deadlines. I should be able to request the work I want, when I want, because I've got my settings tuned properly for the speed of my machine. I never download more work than I can complete.

I've mentioned the need for a dumb*** filter that only kicks in the overzealous scheduler if you are obviously having trouble meeting your commitments. What is so wrong with this idea? Someone else had an idea for an 'advanced settings' section that would allow someone who knows what they're doing to override the scheduler. This is also a nice idea. Granted, it could be abused by someone not knowing what the settings do, but then the dumb*** filter should kick in and save themselves from their own dumb***.

Currently, BOINC is not very fun for dial up users. I think you seriously need to rethink allowing us to get work on demand if you wish to keep us. This is a major issue with the functionality of the software. I'm giving it a few more revisions and if things don't change, I'm finished with BOINC. Not everyone can afford a broadband always on connection, which is what BOINC is favoring more and more these days...

---

I'm giving it a few more revisions and if things don't change, I'm finished with BOINC.
==========

:O ... :(

> I'm giving it a few more revisions and if things don't change, I'm finished
> with BOINC.

You could always revert to 4.25 after which all the things you are complaining about have been introduced... I haven't upgraded my CC after I read all the stuff about 4.3x and 4.4x clients, and I'm quite happy and content with what I've got. I can suspend and resume projects and individual WUs, and with the help of BoincView (which is faaar better then the vanilla Boinc Manager IMHO!) I have the option not to request work for a particular project. AND the client scheduler doesn't get in the way with the way you work. This is all you need to run your "self scheduler" if you know what you are doing.

It seems that I will stick with 4.25 for a loooong time to come...

> The server is now running with new BOINC scheduler components.

Well, I'm sure there are many new features which are beneficial to us and the project people, but I like it that my credits are updated even if there is no work. :-)

I agree with Heffed entirely. A Dumb*** filter, (I'll use that elsewhere - consider it stolen!), is a good suggestion for the participants that drop in, sign up, then forget all about it and let it do it's own thing. It is not correct to paint all users as dumb though. An "Advanced" option correctly implemented could work.

I know my schedules, where I'm going what I'm doing. It doesn't matter how smart you make the scheduler, unless I have to start entering my day to day calendar into BOINC, it will never know as much as I do about what I want from where. I know what I need from where to keep everything busy without missing schedules.

>>> I will stick with 4.25 for a loooong time to come...

I run 4.25, but can see a situation soon where 4.4x will be the minimum requirement, so this is not a long term option. Already BURP recommends 4.41+, but I don't run BURP.

---

Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.

>
> I run 4.25, but can see a situation soon where 4.4x will be the minimum
> requirement, so this is not a long term option.
>

Adrian,

Do you know which project(s) will require 4.4x?

>>> Do you know which project(s) will require 4.4x?

As bugs are found and fixed, I expect all of them will ultimately have a minimum requirement higher then 4.25. I saw this on BURP's site...

"You are encouraged, although not forced, to upgrade your BOINC core client to version 4.41 or above - as this and later versions have several bugfixes aimed specifically at BURP."

... which indicates there are still known and probably unknown bugs in the earlier cores.

Certainly a good number of the projects have had erratic behaviour. Consider the problems we've had here and that Predictor has had over the last week.

The cost of making things compatible with legacy code becomes excessive and the clients take the cheaper/easier/secure route of stopping support for the old ones.

It's a bit like most core software, Windows for example, as time goes by, the older versions drop out of use/support and ultimately become unstable as the clients are further developed to use facilities not present in older core versions.

---

Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.

> That's my point though... I've had no problem in the past honoring resource
> shares and keeping work for all my projects without blowing past deadlines. I
> should be able to request the work I want, when I want, because I've got my
> settings tuned properly for the speed of my machine. I never download more
> work than I can complete.
>
I've always wondered why there's no "Connect Immediatly" button in BOINC. I don't use dial-up, so it's not a personal concern, but it just seems stupid that you can't tell BOINC you'd like to top yourself off...

John mentioned tension between honoring resource share and getting work from all projects all the time. However, why must one get into this situation with a connection button? The scheduler can honor debt and require downloads at the same time.

From what I've read about the latest scheduler, there are two scheduling modes and three work-fetch modes. Of the two schedule modes, panic mode can be set off by either a) short deadlines or b) tight deadlines.
   If the scheduler is panicking due due a short deadline, the documentation itself says "Having the CPU scheduler in panic mode for a short deadline will not preclude the downloading of work. If the work unit is due today, but the work otherwise is not in time trouble, there is no reason not to download some more work." -- Force work-fetch to "download required" mode on clicking the button.
   If the scheduler is panicking due due a tight deadline, new work may obviously miss the deadline. -- Warn user that forcing a work-request may result in work missing it's deadline. If the user is sure this is OK, force work-fetch into "download required" mode.
   If the scheduler is not panicing at all, there's no harm in downloading more work. Instead of waiting a few more days, just connect right now for more work. -- Force work-fetch into "download required" mode.

Again according to the documentation, "The work fetch will always be done in order of highest long term debt." Forcing a work-fetch then would still honor resource share because it would initially attempt to download new work from a project which needs to be run more. A line between resource share and downloading from everybody does not have to be walked with the implementation of a cache refill button, since it would use the the very same debt calculations any other work-fetch would.


Puffy

---