Alternative Instead Of BOINC v7.6.9?

Message boards : Number crunching : Alternative Instead Of BOINC v7.6.9?
Message board moderation

To post messages, you must log in.

AuthorMessage
Profile Sutaru Tsureku
Volunteer tester

Send message
Joined: 6 Apr 07
Posts: 7105
Credit: 147,663,825
RAC: 5
Germany
Message 1730270 - Posted: 30 Sep 2015, 6:06:28 UTC

BOINC v7.4.42 could cause invalid results at Milkyway.

v7.6.9 have a fix, but isn't 'perfect' still - AFAIK. Or this version would be the 'best' solution of all BOINC versions currently?

Which older BOINC version don't cause invalid results at Milkyway?
It looks like this happens since v7.4.42, right?

v7.2.42 would be an alternative?

Thanks.
ID: 1730270 · Report as offensive
rob smith Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer moderator
Volunteer tester

Send message
Joined: 7 Mar 03
Posts: 22158
Credit: 416,307,556
RAC: 380
United Kingdom
Message 1730283 - Posted: 30 Sep 2015, 7:16:35 UTC

It would be far better to ask this question on the Milkyway forum as there will be people there who will know the issues that are specific to that project.
Note - BOINC does not do any calculation, it only provides a control environment in which the project applications operate.
Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?
ID: 1730283 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14649
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1730293 - Posted: 30 Sep 2015, 8:20:33 UTC - in response to Message 1730283.  

I think Dirk is fully aware of the issue at MilkyWay - he posted in the discovery thread there where Keith Myers and I explored the causes of the validate errors, and persuaded David Anderson to incorporate a fix - first released in v7.6.6

As MilkyWay have posted in their front page News,

BOINC has released a new version of the BOINC client (7.6.6) which fixes a known bug causing ~3% validation errors on MilkyWay@home and other projects. Please update your clients soon to fix this issue.

(though they failed to mention that the fix is required for Windows only)

There were bugs in other parts of v7.6.6 - hence the quick update to v7.6.9 - and of course there are still issues being resolved there too (no software is ever complete - new features have been added, and corrected, in the last 24 hours).

Dirk, if you have reason to think that v7.6.9 isn't fit for purpose, please report the specific problems, either here or via the official channels. Otherwise, it's the best and only choice in town for MilkyWay participants running Windows.
ID: 1730293 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1730302 - Posted: 30 Sep 2015, 9:29:33 UTC - in response to Message 1730293.  
Last modified: 30 Sep 2015, 9:33:52 UTC

...
BOINC has released a new version of the BOINC client (7.6.6) which fixes a known bug causing ~3% validation errors on MilkyWay@home and other projects. Please update your clients soon to fix this issue.

(though they failed to mention that the fix is required for Windows only)
...


Also, Fully aware they (Milkyway) probably aren't software engineers, I'd just like to point out that the language used is a little imprecise. (Which I happen to know can throw some people for loops, especially if there is a language barrier):

The original problematic (At least on Windows) implementation was as designed, therefore not a bug. Second,, it appears to be not a 'design level fix' but a workaround. Not trying to be nitpicky, just more concerned with root causes than symptoms at this point.

Some totally different symptoms appear with 7.4.42 on Mac OSX, that seem possibly connected to the same or similar design issues, but more research is needed on my part before putting forward suggestions.
"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.
ID: 1730302 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14649
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1730308 - Posted: 30 Sep 2015, 10:38:58 UTC - in response to Message 1730302.  

I think the main design level problem is communicating between two separate computer programs - the science app and the BOINC core client - by writing to a mechanical device, namely a hard disk drive. That's the computer equivalent of snail mail, and you have to ensure that the delivery is complete before acting on the contents - otherwise you miss the PS.
ID: 1730308 · Report as offensive
Profile William
Volunteer tester
Avatar

Send message
Joined: 14 Feb 13
Posts: 2037
Credit: 17,689,662
RAC: 0
Message 1730312 - Posted: 30 Sep 2015, 11:03:50 UTC

And as previously discussed ad nauseam, the OSs no longer work sequentially but on different threads and different priorities which to some extent are not under the control of the user/applications .
Actually I think what is needed is a firm handover tag IN THE FILE. Something like a 'complete' tag.

But that would require changes to both applications and client - the applications to write the tag, the client to read it, and client to deal with 'old app, doesn't write such a tag'. [I think here the app could put an 'I'm giong to tag when this file is complte' tag at the beginning'

And now we reached level of complexity that is simply not going to happen.

We can get stuff done to the client, but we can't tell the projects what to do.
A person who won't read has no advantage over one who can't read. (Mark Twain)
ID: 1730312 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1730313 - Posted: 30 Sep 2015, 11:08:27 UTC - in response to Message 1730308.  

Yeah, I'd say that's a fairly accurate assessment. as one of the two occasions on the Mac that I spotted odd behaviour, the GUI had lost contact with the client, for reasons unknown. Being clear, that's happened once since I setup the Mac Pro ~2 months or so ago.

Having used all three platforms I'm pretty convinced they are all 'as good' as one another with their own purposes in mind, but that one size fits all level solutions are likely to be problematic, when you're trying to use low level mechanisms (like IO and interprocess communications).
"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.
ID: 1730313 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1730314 - Posted: 30 Sep 2015, 11:14:39 UTC - in response to Message 1730312.  

yeah the threading/sequence/syncing thing fits into the same problems as the IO and IPC, with OS dependance in each case. Flags *might* work to some extent, though I suspect leveraging C++'s features capable of hiding different implementations under the same interfaces would be better. Then best practices could be followed on each platform. That raises other design choices/issues though, to do with mixing object oriented and non object oriented code. To me that mix is the biggest stumbling block.
"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.
ID: 1730314 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1730317 - Posted: 30 Sep 2015, 12:23:22 UTC - in response to Message 1730312.  

We can get stuff done to the client, but we can't tell the projects what to do.


Had to think about this for a bit in various contexts. An 'ideal' (unrealistic) solution would involve both the application and client behaving exactly as expected. I say unrealistic because we know there are and always will be misbehaving applications, and known buggy clients in circulation.

So I 'feel' that a more tolerant client solves a lot of problems. For a trivial example, why not an adjustable file open timeout in cc_config ? (as opposed to hard wired 5 seconds magic number, it can still default to 5 seconds)

From the point of view of getting projects or users to update anything, well a rule of thumb I try to use is make something 'twice as good' in some metric (or combination of metrics). Small frequent manual updates can be good and all, for those that have the time, but it seems to me placing the cost of fixes onto the customer might be unreasonable in a lot of circumstances. The extra time up front can be worth it, and I'm not really comfortable with the apparent trend to using the public as alpha testers, particularly with mission critical software.
"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.
ID: 1730317 · Report as offensive

Message boards : Number crunching : Alternative Instead Of BOINC v7.6.9?


 
©2024 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.