LHC@home

I admit, it's my fault! Every now and then I get tired of the long message page full of
e.g.

4/4/05 9:12:00 AM|LHC@home|Requesting 86400.00 seconds of work
4/4/05 9:12:00 AM|LHC@home|Sending request to scheduler: http://lhcathome-sched1.cern.ch/scheduler/cgi
4/4/05 9:12:12 AM|LHC@home|Scheduler RPC to http://lhcathome-sched1.cern.ch/scheduler/cgi succeeded
4/4/05 9:12:12 AM|LHC@home|Message from server: No work available

and I suspend LHC. Inevitably a few dozen WU are released during this time.

---

Questions? Answers are in the BOINC Wiki.

Boinc V6.10.56 Recommended
WinXP C2D 2.1G 3GB

Everybody switched ? ! ?

I did;-)

---

for getting work from any kind of project, it might be not the most effective way, to suspend the project.

Why do you reduce the chances to get work (..and contribute to science..)
and suspend LHC it?

the boinc client was build and stable enough to handle those "a-lot-of-messages".

Also running several projects, one is the burb. So far I got one time work for a few hours and since then no more. This happens weeks ago.

I let play the clients. From time to time they are asking for work --and you what the returning message are.

In my eyes, there is no other way.

Duron!
Still having the cpu and a fitting mainboard, but no longen operating.
had two of them, a duron 850 and a duron 1300. The duron 850 could operate stable at 935 MHz and the duron 1300 was running fine at 1375 MHz.

The duron 1300 was just a little below the daily rate of a AMD 1400, but both where quicker than *my* P4 1.8 GHz.

Do you want the retunal of smile on your face? just don't detach/suspend projects!

If it's stronger than you, take a walk ouside, look at the nature growing, listen to the bird's sing and be happy.

--> just don't grope the clients...

Messages are still free of charge

> the boinc client was build and stable enough to handle those
> "a-lot-of-messages".

The problem is that with all of the "noise" with these messages, important ones can easily get lost in the shuffle.

When you have more than one or two computers it is almost impossible to see the really important ones.

Making it worse is the fact that many of the "status" type messages are shown as red errors when displayed in BOINC Manager. No work from project, and deferring are really not important level messages ... yet they show up as errors.

Just as bad, the messages should be spooled to different files (one with all, one with just the errors, one with status, etc.) so that you could go to look at real errors, the whole thread (sometimes important for troubleshooting)...

---

Paul (as usual) you are right.

Lets say that, internal, so far I'understanding, there are error levels of messages, some are informative (minor important), some are high level error
(in the newer GUIs shown red colored)

So basically it's prepared to enable a kind of filtering.
But this must be a function of the GUI not a function of the "crunching" application. The last one only collects datas.

Might in further client releases this filering will be activated, not sure if it was request by user

I assume, you know what a NETView console is... (long time ago!)
there, depending the severity of error message, they had to be acklowledged/to be confirmed) bevor they could be deleted. Those messages stayed on the console screen.


(when you get the messages over rpc from a remote client, it must be specified

original text found:
Returns a list of messages to be displayed to the user. Each message has a sequence number (1, 2, ...), a priority (1=informational, 2=error) and a timestamp. The RPC requests the messages with sequence numbers greater than 'seqno', in order of increasing sequence number.)

> Paul (as usual) you are right.
>
> Lets say that, internal, so far I'understanding, there are error levels of
> messages, some are informative (minor important), some are high level error
> (in the newer GUIs shown red colored)
>
> So basically it's prepared to enable a kind of filtering.
> But this must be a function of the GUI not a function of the "crunching"
> application. The last one only collects datas.
>
> Might in further client releases this filering will be activated, not sure if
> it was request by user

You can see the differences if you look at the messages in BOINC View vs. BOINC manager ...

In my lists I do:

Information
Status,
Warning,
Error ....

The no work would be information/status ... warning are those like ... if thid persists detach and attach ... errors are those like "Exception!" :)

---