Posts by dcdc

1) 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...
2) 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.
3) 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
4) 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?
5) 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).
6) 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.
7) 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!
8) 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.
9) 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...
10) 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?
11) 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?
12) 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...
13) 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 ;)
14) 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 ;)
15) 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.
16) 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
17) 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...)
18) Message boards : Current tests : New crediting system (Message 2119)
Posted 16 Aug 2006 by dcdc
Post:
I think as long as overall it will average out to within a reasonable margin after running a few WUs then that's good enough for anyone. Do we need a reasonably large scale test of this or can the testing be done on Rosetta concurrent with the current system?

Cherry-picking will not be possible because you will only know how many models you completed _after_ you crunched your WU.


Cherry-picking will be possible unfortunatley, but it would take a bit of work to set up and I'm not going to say how ;) It will also be identifiable!
19) Message boards : Current tests : New crediting system (Message 2106)
Posted 16 Aug 2006 by dcdc
Post:
As I haven't processed that much over @ the Rosetta Project for awhile I can't wait for the Fire Storm to hit the Project when & if it's done, I don't think the Dev's know what their letting themselves get into if thats implemented ... ;)


I think you're probably right. The most vocal group might be the winners on this, but as FC says, this might be the best result for the project if fewer leave.

I'd like to see what the effect on the data would be though as I expect it'd bring the top teams a bit closer together which'd be great for competition!
20) Message boards : Current tests : New crediting system (Message 2099)
Posted 16 Aug 2006 by dcdc
Post:
We have the opportunity to back date this to make the credit system consistent and fair throughout. If you've crunched more than me, you'll have more credit than me.

dcdc
New member
Joined: Aug 15, 2006
Posts: 3
ID: 1699
Credit: 0
RAC: 0
---

I can see why it wouldn't matter if the Credits are Back Dated to somebody that has 0 Credit 0 RAC & at the moment doesn't even have a Computer attached to the Project ... 0_o

...

Who stands to gain the most from this Back Dating, the people with 0 Credit & 0 RAC I would suspect ... As a side NOTE when the Ralph Project started it was made clear the Credits were not important, In fact the Mods even made that clear a few times, now all of a sudden apparently the Credits are important ... Go Figure


I have no Ralph credits but we're discussing Rosetta.
[edit]i think there's a misunderstanding here - we're (or at least I'm) not taking about back-dating Ralph credits - this is about Rosetta credits[/edit]


With data base loses, bad application releases, WU's Erring out for no apparent reason not just at this Project but across all the Projects I've lost an enormous amount of Credits already so whats another 50,000 to 100,000 or more lost Credits.

I'll be the first to admit to using optimized clients that inflate the credits, but the Project said nor did nothing to curtail that practice. Now like a few people have said already the rules are going to be changed & lets back date it.


I know it's annoying to loose credits for work done, and I don't know about any of the other projects, but I don't know of any lost any data on Rosetta. Also, I know it didn't happen from the start, but you should have been credited for any WU errors for the last four months or so.

If you're being given credit for the work done I wouldn't consider that 'losing' credits though. You'd get the right credits for the amount of work completed.


Next 20



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