Happy birthday Juan ! Don't toast too much now ;-)

---

You are in this case, you're running a Boinc without OpenCL detection:

Another reason not to run Einstein anymore.
OpenCL app without own OpenCL detection.

No, OpenCL support done the way it should be done - collaborating with BOINC, letting each part of the system play its proper part in the overall picture.

Taking OpenCL detection down a level to the science application layer (instead of the infrastructure layer) was a useful stopgap when the science app was ready before the infrastructure caught up, but that's history now. Time to grow up.

Wrong way of thinking.
Einstein ignores thousands of users who wont use Boinc 7.
Their loss not mine.
Build in OpenCL detection wouldn`t hurt.

Actually Mike I have no problems myself with Einstein and BOINC 6, but then I'm nvidia equiped only here though I also have the same aversion to BOINC 7. ;-)

Cheers.

You are in this case, you're running a Boinc without OpenCL detection:

Another reason not to run Einstein anymore.
OpenCL app without own OpenCL detection.

No, OpenCL support done the way it should be done - collaborating with BOINC, letting each part of the system play its proper part in the overall picture.

Taking OpenCL detection down a level to the science application layer (instead of the infrastructure layer) was a useful stopgap when the science app was ready before the infrastructure caught up, but that's history now. Time to grow up.

Having OpenCL detection in the science application also facilitates standalone application testing. An init_data.xml file can be used instead, but the BOINC WIKI AppDebug page doesn't even mention that. The Einstein developers of course have enough experience to do whatever is necessary to alpha test their applications, but a new project might not.

BOINC is a prerequisite for doing SETI@home work, and I accept that. It will never be ideal for any specific project simply because there are too many conflicting needs. For my dial-up situation it is getting worse and worse, of course, and sometime I'll need to start paying an additional 500 USD per year for the kind of anemic broadband now available where I live.

                                                                  Joe

Hi Wiggo,

What perzakkerly are the problems with BOINC 7.x.xx with E@H?

I [touch wood] haven't had any with my rig running 7.2.42 or now 7.4.27.

I run both GPU & CPU tasks ok, no errors, no invalids, so far at any rate.
Or is it an ATI problem? I only run NV GPU's.

Regards,

---

Cliff,
Been there, Done that, Still no damm T shirt!

You shouldn't have any problems Cliff.

It's only when you have AMD/ATi GPU's combined with older v6 versions of BOINC that you'll have problems there.

So you have nothing to worry about. ;-)

I just don't like the BOINC versions above 6.10.60.

Cheers.

Having OpenCL detection in the science application also facilitates standalone application testing. An init_data.xml file can be used instead, but the BOINC WIKI AppDebug page doesn't even mention that. The Einstein developers of course have enough experience to do whatever is necessary to alpha test their applications, but a new project might not.

I'm pretty certain that a new project would be desperate not to have to bother with all the detection gubbins in their first-ever GPU app. If BOINC provides all of that for free - let's run with it. They probably test by setting up a closed BOINC server on their lab network (no mean feat by itself, but useful practice), and run the apps there.

Someone mentioned that their RAC doesn't seem to be falling/is frozen. I can see where you get that idea.. from your hosts page. Mine still shows my main cruncher as having 3637.38, whilst my overall is reported as 696.75. In fact, I just opened up the statistics XML file and took a look, and the useraverage has been steadily falling, but the host average has been static/frozen since the 7th.

The single-core machine that still gets some occasional MB re-sends has a constantly-changing RAC because it is still getting work.

I know the AP database has been down a while, but.. shouldn't RAC still function correctly even though all the reported work is still waiting for validation?

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

Someone mentioned that their RAC doesn't seem to be falling/is frozen. I can see where you get that idea.. from your hosts page. Mine still shows my main cruncher as having 3637.38, whilst my overall is reported as 696.75. In fact, I just opened up the statistics XML file and took a look, and the useraverage has been steadily falling, but the host average has been static/frozen since the 7th.

The single-core machine that still gets some occasional MB re-sends has a constantly-changing RAC because it is still getting work.

I know the AP database has been down a while, but.. shouldn't RAC still function correctly even though all the reported work is still waiting for validation?

Well on my best machine according to the statistics XML file on the 15th November the user RAC was 38032, today 16122, the host avg was 11503 and now 4694.

So it does seem to be falling!!

---

Someone mentioned that their RAC doesn't seem to be falling/is frozen. I can see where you get that idea.. from your hosts page. Mine still shows my main cruncher as having 3637.38, whilst my overall is reported as 696.75. In fact, I just opened up the statistics XML file and took a look, and the useraverage has been steadily falling, but the host average has been static/frozen since the 7th.

The single-core machine that still gets some occasional MB re-sends has a constantly-changing RAC because it is still getting work.

I know the AP database has been down a while, but.. shouldn't RAC still function correctly even though all the reported work is still waiting for validation?

My AP only machines have had a flat RAC for weeks. The ones doing MB work have changed accordingly.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

My AP only machines have had a flat RAC for weeks. The ones doing MB work have changed accordingly.

That makes sense because APs have not been updated for a long time.

---

Hi Wiggo,

Ahh, OK
Wont bother too much then:-)

BTW I got another whole 1 WU, resend.. lasted about 26mins:-)

Regards,

---

Cliff,
Been there, Done that, Still no damm T shirt!

My AP only machines have had a flat RAC for weeks. The ones doing MB work have changed accordingly.

That makes sense because APs have not been updated for a long time.

The calculation of RAC has a built in decay value every 7 days. While the processes to calculate RAC could be part of one of the app processes that wouldn't make complete sense. Once a host has all of it's tasks purged. Which app process would take control of handling the RAC calculation?
Perhaps it is handled by the app processes for the last task the host completed. Which might be make retiring app processes for older versions tricky. As it would leave numerous hosts at a static level of the processes was retired.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

My AP only machines have had a flat RAC for weeks. The ones doing MB work have changed accordingly.

That makes sense because APs have not been updated for a long time.

The calculation of RAC has a built in decay value every 7 days. While the processes to calculate RAC could be part of one of the app processes that wouldn't make complete sense. Once a host has all of it's tasks purged. Which app process would take control of handling the RAC calculation?
Perhaps it is handled by the app processes for the last task the host completed. Which might be make retiring app processes for older versions tricky. As it would leave numerous hosts at a static level of the processes was retired.

RAC is defined to have a 7-day decay half-life, but credit and RAC aren't actually calculated on a timed basis: they are simply updated by whatever fraction is appropriate every time a 'credit related event' occurs - i.e. when new credit is granted.

At the moment, people who have crunched MB in the past should still be getting new credit fairly regularly, as the long tail of pending results trickle in, and their RAC will be reasonably accurate. People who crunch AP only will see their RAC unchanged since the last time the AP validator ran and granted them credit. Ironically, the first thing that will happen when the AP validators start up again is that RAC will be recalculated with the first task validated, and all of that pent-up decay will drive RAC sharply downwards.

All credit calculations are done on the server, and what you see on the statistics tab in BOINC Manager (or in the project stats XML file) is simply the state of play as reported by the server the last time your client contacted to server to request work.

The question of what happens to a retired host after its last task is validated and purged is an interesting one. Most of mine have RAC below 0.1, but some have 0.00 - so some other decay mechanism must be in place. I don't know what that is, but I might have a look around.

Down to one in-process job. Now have Einstein running on several of my "best" machines in the interim. I did have a problem with it on my work Win7 desktop -- a quad-core i7 (with hyper-threading) with 4 GB of RAM. It spawned eight tasks of 400 MB each, and sent the machine into swap territory! I eventually managed to regain enough control to be able to set local preferences to "use at most 50% memory" but it took a while! I'm away, imminently, for the next five weeks so I'm not overly concerned about interactive response for the nonce.

---

Off topic but would induce panic. What is wrong with the threads? It's not sorted by time anymore.

---

Ok so I signed up for Beta, of course until the new motherboard is online in Jan 2015 I can't do any beta gpu work, since I lack a large enough case, an Azza GT1 is needed, the driver is too old and the motherboard power regulators are nearly shot.

---

The T1 Trust, PRR T1 Class 4-4-4-4 #5550, 1 of America's First HST's

Not a lot of tasks left on my main rig:( The GPU isn't crunching anymore...

---

rOZZ
Music
Pictures

Off topic but would induce panic. What is wrong with the threads? It's not sorted by time anymore.

That can happen if your browser history/cookies are cleared.

---

Grant
Darwin NT

Praying for Bruno... (and some cash=>for the project)

---

rOZZ
Music
Pictures

I wonder if the people that provide the Internet data/bandwidth for the work units to go out and come back on wondered what had happened and why the connection wasn't using terabytes/petabytes of data. It would be interesting to know how much data has been saved while the project has been only sending out resends. I bet when the project comes fully back online there will be a traffic jam for some time. On a very quick calculation if 1000 AP units were sent out an hour that is saving of just over 196 gig more like terabyte a day. I got this by going 1024×8 = 8192 × by 24 =196608 divided by 24=196.608

---