Posts by dcdc

1) Message boards : Current tests : New app in VirtualBox (Message 7457)
Posted 18 Dec 2023 by dcdc
Post:
Interesting! Looks like you got one of not many tasks - 70 in total.
2) Message boards : Current tests : New app in VirtualBox (Message 6957)
Posted 20 Feb 2021 by dcdc
Post:
Any idea why these tasks are for Linux vbox?

I would have thought the Linux and Windows vbox would be the same as far as the tasks running in the VM are concerned.
3) Message boards : Current tests : New app in VirtualBox (Message 6953)
Posted 14 Feb 2021 by dcdc
Post:
I've upgraded to the vbox version of BOINC and added Ralph on one machine. Will add more as I get around to it unless any tasks appear, in which case I can add a few quickly.
4) Message boards : RALPH@home bug list : Tasks not running on Android 10 (Message 6715)
Posted 10 Apr 2020 by dcdc
Post:
It's working now. I have no idea what I changed. Running BOINC 7.4.53. Turned off battery optimisation for BOINC in the Android App settings. Not sure if I did something else too...
5) Message boards : RALPH@home bug list : Tasks not running on Android 10 (Message 6679)
Posted 5 Apr 2020 by dcdc
Post:
Ok - thanks. It's useful to know it's not an Android 10 issue. Maybe OnePlus are doing something strange that's stopping BOINC or the task from running, unless it's just my device. I've turned off battery optimisation for BOINC, but that hasn't helped.
6) Message boards : RALPH@home bug list : Tasks not running on Android 10 (Message 6658)
Posted 2 Apr 2020 by dcdc
Post:
My phone (OnePlus 7T - Android 10) won't run Ralph tasks and I don't think it will run any other projects either. My old OnePlus 3 (Android 9) runs everything that it downloads. This phone will download tasks but they sit at 1 or 2 seconds forever.

I am wondering if it is an Android 10 issue as posted here: https://github.com/BOINC/boinc/issues/3290
Specifically, it seems that Android 10 needs the tasks built with a newer SDK.

Specifically this post:

So this issue is happened because since BOINC Android 7.16.3 target SDK version was increased to 28. In order to support newer devices (with Android 10) and latest version of BOINC Android, applications should be rebuilt with newer toolkit (28).


Is anyone else experiencing this?

I understand it won't (and shouldn't) be high priority.

D
7) Message boards : Number crunching : Ralph and SSEx (Message 5946)
Posted 28 Dec 2015 by dcdc
Post:
My understanding is that Rosetta is made up of modules, so is the sensible thing to do to take one of the smaller/most commonly used modules and have a look at optimising the code there?
8) Message boards : RALPH@home bug list : Rosetta mini beta and/or android 3.61-3.83 (Message 5922)
Posted 20 Oct 2015 by dcdc
Post:
I would exit BOINC and restart it in that situation rather than aborting them.


Is that because there is the possibility for them to complete and you get the information about the run and the cruncher gets the credit?


Yes exactly, although flagging it up as an issue is useful as it obviously shouldn't happen and something needs fixing (whether that's in Rosetta or BOINC or elsewhere).
9) Message boards : RALPH@home bug list : Rosetta mini beta and/or android 3.61-3.83 (Message 5920)
Posted 20 Oct 2015 by dcdc
Post:
I would exit BOINC and restart it in that situation rather than aborting them.
10) Message boards : RALPH@home bug list : Rosetta mini beta and/or android 3.61-3.83 (Message 5913)
Posted 12 Oct 2015 by dcdc
Post:
You just replied to one!
11) Message boards : RALPH@home bug list : Rosetta mini beta and/or android 3.61-3.83 (Message 5896)
Posted 9 Oct 2015 by dcdc
Post:
Eliminating an non-SSE2 version of Rosetta would eliminate Pentium 3 and Athlon XP or earlier CPUs, so I'd guess less than 0.1% of output.
12) Message boards : RALPH@home bug list : Beta 5.98 downloaded (Message 4633)
Posted 1 Feb 2009 by dcdc
Post:
Yes I know it's a still used application.
I would like to know what it is able to do this version better than the new mini 1.54... Shouldn't all the code had been ported from Fortran to C?

my guess would be that some of the devs are using mini but some are still working on code that hasn't been ported yet...
13) Message boards : RALPH@home bug list : Beta 5.98 downloaded (Message 4615)
Posted 30 Jan 2009 by dcdc
Post:
I've just stuck a virtual machine on ralph (so if it goes wrong rosetta will pick up the slack on the real pc) and it downloaded 5.98 but i can't see any mention of that app on the msgboards - is it right or should it've downloaded rosetta mini?
14) Message boards : RALPH@home bug list : minirosetta 1.14 bug thread (Message 3951)
Posted 22 Apr 2008 by dcdc
Post:
same error, but additionally, the ralph quota per day seems to be set at 13, so my comp isn't downloading any more work - can you change this?
15) Message boards : RALPH@home bug list : Bug reports for 5.66-5.68 (Message 3202)
Posted 15 Jun 2007 by dcdc
Post:
Yes, the failures do attempt to connect directly back to the project to report additional traces. And unfortunately with ZA, each version of Ralph AND Rosetta must be enabled. Please enable the current v5.68 by clicking the program control, and then the add button and selecting the .exe from your BOINC/projects folder

On Windows, the default path would be:
/Program Files/BOINC/Ralph.bakerlab.org/rosetta_beta_5.68_windows_intelx86

zonealarm used to have a 'changes frequently' option that you could give to a program so it always allowed internet access. Don't know if that was just ZA Pro or not though...
16) Message boards : Number crunching : unable to upload (Message 2204)
Posted 21 Aug 2006 by dcdc
Post:
Hi Conan

You can force the Wu to be uploaded by marking the wu

then press try agin now.

Hope this helps

Anders n

Thanks Anders n, I can't seem to find a "try again now" button. Is that on the latest version of Boinc Manager? as I have 5.2.13.
I rebooted the machine and that got it reporting. Possibly a IP/DNS problem when hey moved Ralph and they have forgotten to tell us things would change. I have lost about 7 WU's due to this problem. Only affected Ralph and I have 4 other projects on the same computer that had no problem.

Is there a 'Retry Communications' option under one of the menus? If so, try that ;)
17) Message boards : Number crunching : unable to upload (Message 2203)
Posted 21 Aug 2006 by dcdc
Post:
Hi Conan

You can force the Wu to be uploaded by marking the wu

then press try agin now.

Hope this helps

Anders n

Thanks Anders n, I can't seem to find a "try again now" button. Is that on the latest version of Boinc Manager? as I have 5.2.13.
I rebooted the machine and that got it reporting. Possibly a IP/DNS problem when hey moved Ralph and they have forgotten to tell us things would change. I have lost about 7 WU's due to this problem. Only affected Ralph and I have 4 other projects on the same computer that had no problem.

Is there a 'Retry Communications' option under one of the menus? If so, try that ;)
18) Message boards : Current tests : New crediting system (Message 2184)
Posted 19 Aug 2006 by dcdc
Post:
I think it is way easier to fake the numbers of decoys generated than to fake the internal benchmark. So the currently tested system is not fake-proof either.


I'd be very suprised if that were true, but I'd like to hear DK's thoughts on the subject.
19) Message boards : Current tests : New crediting system (Message 2182)
Posted 19 Aug 2006 by dcdc
Post:
I'll throw something else in here. One advantage of the proposed new credit system over any that use benchmarks is credit-crunching alignment, which is the very thing we've been requesting here. Benchmarks are rarely perfectly aligned with the work to be done. As one example, the size of CPU cache may play a large part in crunching ability, but it is rarely a factor that influences benchmarks as they tend to be small and quick.

By not using a benchmark, or rather using a whole decoy as a benchmark, the credits are exactly aligned with the credit system. The only issue remaining is that there is variation in time taken to produce decoys on any given machine, but no variation in credit awarded. If this averages accurately, then I believe it to be the best system. If someone tweaks their computer by, say increasing the FSB, which removes a CPU-RAM bottleneck, this is unlikely to be picked up in any benchmark, but will show up in this system.

The other option of course is to try and make the benchmark realistic. This is difficult, because of the size and variation in algorithms used within the WUs. The 'new credit system' includes for this.

My final point regards the golden machines used. I've posted somewhere - here or at Rosetta - that the makeup of the golden machines needs to reflect the wild population for the following reason:

If the golden machines are 10 AMDs running Windows, which are very good at 2 in 10 WUs (as they fit into a small cache), but take much longer with the remaining 8 (as they are slightly larger than the AMD cache) then the first 2 WUs will be assigned little credit, while the remaining 8 will be assigned more. In the wild, although a Pentium isn't affected by the difference between the WUs sizes due to its larger cache, it will still get the credits that reflect how the AMDs crunched them.

This may be a minor point with regard to CPU cache sizes (or it may not), but there are a great number of factors that could influence this, including whetstone performance, dhrystone performance, CPU cache size, FSB/HyperTransport speeds, RAM availability etc...

The place that matches the wild population of computers the most is, of course, the wild population! Thats my current take on a credit system.

I can see that a well aligned benchmark can be more accurate in the short term, which is good for those wanting to push their computers, but after a week or two of crunching I'd be suprised if this system didn't prove more accurate.

cheers
Danny
20) Message boards : Current tests : New crediting system (Message 2158)
Posted 16 Aug 2006 by dcdc
Post:
prior to the currently in-testing credit system, I thought that flops counting was the ideal, with the benchmark as either a library to be included in the BOINC code during compilation (don't know if it'd be possible to create a moduel that isn't 'tamperable'), or a standard benchmark to be included in the project apps. Infact I remember my very first DC post over at UD said the very same thing back in 99 or 2000! I haven't seen anything that says that this is an accurate system though- as Ethan says, what value to you assign to FPU operations over Integer operations etc. There is some arbitration even in that system isn't there? (I might be wrong - my understaning of programming is pretty minimal beyond VB...)


Next 20



©2024 University of Washington
http://www.bakerlab.org