Posts by niterobin

1) Message boards : Number crunching : 2.8 p4 running 50% crunching 1 wu-why? (Message 34766) Posted 22 Dec 2009 by niterobin Post: I read somewhere ages ago (sorry for my bad memory) that BOINC won't multi-thread on tasks, so running just one WU will only use one core. I think that's right - I'm open to correction on this. Regards, Rob.
2) Message boards : Number crunching : Posting restrictions (Message 20220) Posted 23 Apr 2009 by niterobin Post: This makes a lot of sense, and thanks for it. However, I do have one comment: If someone joins the project and has difficulties setting up Milkyway, they won't be able to post any questions they have. Would it be worth having a stickied new user thread, so that anyone with problems setting up the project can post there and there only? In that way, they could either be given help directly or pointers to existing threads which answer their questions. Of course, this thread would then be open to spam, but it would be one thread only, and presumably easier to monitor for anti-spam purposes that all the boards.
3) Message boards : Number crunching : particle swarm searches -- ps_X (Message 10768) Posted 15 Feb 2009 by niterobin Post: I just saw a PS work unit go through ok running at 7:57 compared to 7:47 for NM wus, so hardly any difference in time there. I'm running the SSE3 optimised app (0.16) which Ice so kindly hosted at zslip. HTH, Rob.
4) Message boards : Number crunching : Little help for those using opti apps. (Message 10384) Posted 12 Feb 2009 by niterobin Post: That's what happened to me last week. BOINC showed SSE2 for my PC and CPU-Z showed SSE3. I tried the SSE3 optimised app and it works very well indeed.
5) Message boards : Number crunching : workunit limit increased (Message 9591) Posted 3 Feb 2009 by niterobin Post: Thank you :-)
6) Message boards : Number crunching : Is anyone glad with the project? (Message 9342) Posted 29 Jan 2009 by niterobin Post: I am.
7) Message boards : Number crunching : app v12 (Message 8846) Posted 22 Jan 2009 by niterobin Post: 0.13 is giving me times of 36 - 37 minutes on X86-64/XP Pro 64-bit, which is what 0.7 was doing. Nice one. :-)
8) Message boards : Number crunching : App v0.10 (Message 8729) Posted 20 Jan 2009 by niterobin Post: 0.10 is running at about 50 - 52 minutes per work unit, 0.07 was running at about 35 - 37 minutes per work unit. That's an an Athlon 4200 dual-core, clocked at 2.75 GHz and running Windows XP Pro 64-bit. HTH, Rob.
9) Message boards : Number crunching : app v12 (Message 8728) Posted 20 Jan 2009 by niterobin Post: 0.12 is running at about 57 minutes per woek unit, 0.07 was running at about 55 minutes per work unit. That's on an Athlon XP 3000+ clocked at 2.17 GHZ running Kubuntu 8.04.1 HTH, Rob.
10) Message boards : Number crunching : Vote for the MilkyWay favicon! (Message 8189) Posted 4 Jan 2009 by niterobin Post: Number 7 for me.
11) Message boards : Number crunching : Unusual..........time to completion (Message 7816) Posted 17 Dec 2008 by niterobin Post: <edit> @ niterobin: Yes, in this case a detach (or reset) helps fix the problem because this will reset the TDCF to 1 (it also resets the debts for the project to zero). However, for most modern hosts this is just a partial fix, since the actual TDCF will ultimately end up less than 0.5 ( a lot less in some cases). ;-) Thanks for the info - that explains why it works. :-) Truth be told, I just didn't know what else to try, and I don't like changing stuff in the config files as I'm not too sure what I'm doing there.
12) Message boards : Number crunching : Unusual..........time to completion (Message 7787) Posted 16 Dec 2008 by niterobin Post: The way I fixed this was to set MW to no new work to run the cache out, update the project to upload all the completed work units, detach and then reattach. This still gave a high time to completion figure, but it was a lot lower than before and, after a couple of days, it adjusted to the correct time to completion. Before that, three of my four boxes were running MW at high priority all the time; afterwards, the MW work units ran at normal priority. It's not very elegant, I know, but it did work. :-) HTH, Rob.
13) Message boards : Number crunching : post milkyway_windows_x86_64 problems here (Message 6466) Posted 23 Nov 2008 by niterobin Post: I just had a second test work unit, which completed in 10min 30sec. The older app was taking about 5hr 15min per work unit on average. I'm impressed. One small problem - the progress bar in BOINC manager went back to zero when the work unit was half completed and then stepped all the way across to 100%. I know that's purely cosmetic, but just to let you know. :-) Rob.
14) Message boards : Number crunching : post milkyway_windows_x86_64 problems here (Message 6442) Posted 22 Nov 2008 by niterobin Post: My first test work unit 53631584 failed with a Compute Error: 22/11/2008 13:27:17\|Milkyway@home\|Output file nm_test0_33_1227318083_0_0 for task nm_test0_33_1227318083_0 absent ------- <core_client_version>5.10.45</core_client_version> <![CDATA[ <message> - exit code -1 (0xffffffff) </message> <stderr_txt> Error reading into background_parameters </stderr_txt> ]]> Computer is 8787: AMD Athlon 3400 dual core CPU clocked to 2.75 GHz, 8 GB RAM 2 x 500 GB SATA 300 hard disks 1 GB NVidia GForce 85000 video card BOINC has its own 10GB partition, and I'm running MW and Einstein on this box. O/S: Windows XP Pro 64-bit, SP3
15) Message boards : Number crunching : Short deadlines-High priority-suspend Milkyway (Message 5209) Posted 11 Sep 2008 by niterobin Post: Thing is, it's looking like 12 hours or more to complete the first, albeit I'm basing this on 26.6% in just under 3.5 hr; I had to manually suspend all other projects and it will still expire on most of the WUs. Yes it takes time to sort itself out; but such is life when the initial estimates are off by a factor > 10:1. That's of course assuming the running WU is representative and others won't exit early. Current rate, 6 will complete; unless there's a lot of early abortions, or an optimized client one can throw on to make it complete those faster. The work units complete very quickly after they reach 50%. I would guess that the one you mention will finish in about 7 hours. As a rough guide, there are three types of work units, which you can indetify by the first three digits of the work unit number: 371 - these are the shortest 372 - these are the longest 373 - these are somewhere in the middle The 372 units take about 60 times the 371s; the 373 units take about 30 times the 371s (about half the time of the 372s). HTH, Rob.
16) Message boards : Number crunching : Question about Data Units (Message 5135) Posted 31 Aug 2008 by niterobin Post: Hmmm... The only catch is once you give the participants the choice, you might end up not getting enough horsepower to run a search efficiently due to runtime length or other concerns. It seems like the experience at SAH has folks increasingly looking for a way to opt out of AP due to run length, tightness factor, and concerns about that other issue, for example. ;-) Good point. :-) Two possible refinements: 1 - Make it an opt out - long work units are enabled ny default and anyone having problems meeting deadlines can choose not to receive them; I don't actually know if the second one is possible :-) 2 - Have the work allocator check the computer speed in some way and then allocate accordingly. Two more thoughts... :-)
17) Message boards : Number crunching : Question about Data Units (Message 5112) Posted 30 Aug 2008 by niterobin Post: Hmmm...that's a good point. I didn't really think about some machines being able to meet some deadlines and not others. Maybe we'll have to set a hard line for requirements for each workunit type and leave it up to the users to decide if it's worth not meeting some deadlines. I'm not meaning to over-complicate things here, but... ClimatePrediction has a feature in its account settings to enable one to pick which length of work unit to run. Maybe it would be possible to do this purely for the longest work units - then people with slower computers could leave it blank and not get them. I guess it'd have to be well 'publicised' to make sure everyone knows about it, so that those who can run the longest work units don't miss out. Just a thought... :-)
18) Message boards : Number crunching : New WU Length? (Message 4234) Posted 18 Jul 2008 by niterobin Post: Over here, the old work units were taking about 7 minutes and the newer ones (gs 3720282) are taking about 7 hours. That's a 60-fold increase by my reckoning. I've yet to crunch any of the shoter new work units; I'll report back on the times when I get some. I've had one of the shorter length work units on my Athlon - gs_3730382 series - and it finished in 3h 46m 39s, making it about 32 times longer than the old work units. My slowest machine - a Duron - is running the long work units at 12h 40m or thereabouts, which is about 57 to 58 times longer than the short ones. I've set the cache to two days on that box, which is keeping it nicely in work with a bit of leeway for the deadlines in case anything untoward happens. I've just had a quick glance back through the logs for both boxes, and there appears to be no problems with server contact whatsoever. So, it looks like everything is working nicely. Rob.
19) Message boards : Number crunching : New WU Length? (Message 4126) Posted 15 Jul 2008 by niterobin Post: Over here, the old work units were taking about 7 minutes and the newer ones (gs 3720282) are taking about 7 hours. That's a 60-fold increase by my reckoning. The last work unit crunched took 7h 03m 26s to 50% and then 33s to 100% for a total of 7h 03m 59s. I've yet to crunch any of the shoter new work units; I'll report back on the times when I get some. Just to let folks know. :-) Rob.
20) Message boards : Number crunching : No new WU (Message 4027) Posted 9 Jul 2008 by niterobin Post: I'm really sorry about this. I'm the only one running searches at the moment and I've been sick the past few days, and the searches I started before the weekend died out before I could start more. I just started 2 more searches 3710182 and 3711182. Again, sorry. Thank you for sorting things out as quickly as you could.

Next 20