Optimized BOINC Client Discussion Thread

in the meantime i have seen on trux homepage that this is a known bug..but no fix announced. :-(

...yes, your suggestion is a valid workaround if you have a stable network connection and the serverside is runnig well.

But if you'r runnig Boinc on a Laptop that was used as such, you are in trouble. In my case its a pentium mobile, runnig at home over night with inet access. Over day its with me...most of the time in office, happily crunching but without network access, so network in boinc is disabled. Sometimes i have to take it with me in a meeting or to visit a customer. Then boinc is disabled at all, cause it makes no sense if runnig on battery. Back at home it uploads the results and get a new 24 h cache. This works fine with the standard client.

As pointed out above i am forced at least once a day to stop boinc with Results in upload queue. As stopping boinc is bad in such a case with trux i tried to avoid that. So i suspend instead of shutting down the mobile. This is no good. Chances are great that the Result in flight will be messed up. OK, lets stop the whole application befor suspend. No joy..cause another bugs comes up. If you stop the app AND you have Results in upload queue it ignores your disable network setting and tries to upload. To quiesce networking again you have to restart boinc. And in office i have to disable networking of boinc cause the firewall prevents success anyway and the try will be logged and treaten as an misuse of corporate net. Catch22.

Are there any other optimised BOINC core clients (for Windows) other than Trux's that work best for Einstein....?

I'm assuming you in fact mean client (like boinc.exe), and not science ap (like albertxxxx.exe).

Before I started used trux's tx36 calibrating client, I used crunch3r's client. So far as I know, it simply drops in heavily optimized benchmark code in place of the standard, and leaves the rest the same. If so, it should be bug-for-bug compatible with the stock client.

See ths page for crunch3r client for your x86/WinXP machines

http://www.guntec.de/Crunch3r/boincx86.html

I don't spot an offering on his part for your Mac.

As even crunch3r's heavily optimized benchmark speeds up the benchmark by less than the later akosf science aps (certainly S-39L and better) improvement ratio, it still will underclaim, but by much less than the stock client.

If the only other project you run is SETI, and you use crunch3r's SETI ap, then this client will put you close to, but a bit under fair claim by most definitions for both projects. If you run yet other projects, then you would be overclaiming on them by a rather substantial margin. I'll leave the moral balance between the fault of underclaiming and the fault of overclaiming to your own sense (my own take is that both are modestly bad, so moderate effort to get fair claim is the thing to do).

[tongue in cheek]
Several:
#1 - Credit doesn't matter anyway. Crunch and ignore it. Life's too short etc... this evaporates that issue. You contribute therefore on some other grounds: love of science, fun, boredom, whatever. Many deem this as unsatisfactory hence.......
#2 - How do you actually measure utility to the project from a user's contributions? Since this whole distributed computing area was pioneered by SETI, alot of it's features seem to be derived from that experience, and no doubt those days were simpler. I believe then it was only WU count that mattered, a credit proxy really, as there was little/nothing to really distinguish WU's from the point of view of either the user or the project. Now we have many projects, the ability to switch and apportion between them, multiple WU types and actual applications used, not to mention totally divergent scientific aims. So now 'value' here becomes suffused with a whole raft of judgements, and those largely within the mind of the user volunteering their resources. Pick an assumption and you'll get the corresponding conclusion from it. It's not actually impossible to get consensus on this, but I think close to it ( I can't rule it out... ).
#3 - Have credit, by whatever means, but use it purely as a 'technical metric'. Forget any value stuff, but still compare performance issues in the way we often do in Cruncher's. That is necessarily imperfect due to it's usage across a vast permutations of devices, operating systems, preference choices etc. But it is still pretty good enough to exhibit that progress is being made and make future choices based on that ( Akosf's work is the example par excellence of this ). Keep in mind that some discussions I've seen here have implied some intellectual handling of 1st, 2nd, even 3rd derivatives of credit! We are blessed with a vast amount of contributing talent here that such 'arcane minutiae' can be sensibly manipulated. And what challenging fun it is for a fellowship of tool-twiddlers! :-)
#4 - Use credit, and pretend that it matters. This way people who really, really care about credit can have the opportunity to do some science too...... :-)
#5 - Combo's of the above.
#6 - Something else entirely.
[/tongue in cheek]
Cheers, Mike

Not logical, because - under that system, you are claiming credit solely upon your time spent crunching, which has not increased, so, no more credit in the long or any other run.

Credit was meant to be (and is) apportioned according to how productively we crunch, not how much raw time we crunch, benchmark x time, and so it remains, and correctly so. The problem lies with the fact that the optimized apps skew the value far downward because the increased crunchng efficiency is not reflected in an increased benchmark. Thus the optimized client, (and here I mean Truxoft's calibrating client, because it only brings the benchmarks up to the average for that particular length WU) more accurately reflects the increased efficiency. NOT USING the calibrated client while using the optimized app tends to devalue the work, for the entire quorum, increasingly so as more begin using the Akosf apps, and in devaluing the work, we impact the entire quorum. This may not bother you, but what about those who are not able to use Akosf's apps, the Macs and Linux crunchers there, whose work is not not only relatively slower, but also risking being devalued by up to 75%? I am strongly in favor of maintaining a set value for each WU, depending solely upon length, and Truxoft's calibrating client does this best.

Thank you for asking for counterviews. I hope that I've adequately expressed mine. :-)

Respects,

Michael R.