Message boards :
Number crunching :
Alternative Instead Of BOINC v7.6.9?
Message board moderation
Author | Message |
---|---|
Sutaru Tsureku Send message Joined: 6 Apr 07 Posts: 7105 Credit: 147,663,825 RAC: 5 |
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. |
rob smith Send message Joined: 7 Mar 03 Posts: 22205 Credit: 416,307,556 RAC: 380 |
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? |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14650 Credit: 200,643,578 RAC: 874 |
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. |
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 |
...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. 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. |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14650 Credit: 200,643,578 RAC: 874 |
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. |
William Send message Joined: 14 Feb 13 Posts: 2037 Credit: 17,689,662 RAC: 0 |
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) |
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 |
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. |
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 |
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. |
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 |
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. |
©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.