Welcome to MilkyWay@home

Posts by Martin P.

1) Message boards : Number crunching : Milkyway GPU on Mac? (Message 46310)
Posted 19 Feb 2011 by Martin P.
Post:
What graphiccard can I use and where can I buy it?

Thanks!
2) Message boards : Number crunching : v 0.26 and 0.03: Less than 20 Cr./hour on Nehalem! (Message 43242)
Posted 29 Oct 2010 by Martin P.
Post:
??????

Milkyway 0.21 (WIN-CPU) takes appr. 8,000 seconds on a Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz [Family 6 Model 23 Stepping 10](4 processors) while Milkyway 0.31 (MAC-CPU) takes 30,000+ seconds on my Nehalem Intel(R) Xeon(R) CPU X5550 @ 2.67GHz [x86 Family 6 Model 26 Stepping 5](16 processors.

BTW: Since a few days the Mac-version 0.31 hangs at 0% for hours.

Any news on this? The Win-CPU app is still 4 times faster than the Mac-CPU-app (on comparable machines).

It's also been mentioned that they're working on a new type of search that might not be as GPU-friendly (though that remains to be seen). With GPUs working so well here at the moment it's probably best to focus your CPU on other projects until they get that search underway. I realize that's not technically what the topic is about, but ...



Actually with the app updates, the Win-CPU app is actually twice as slow as the Mac and Linux CPU apps.

3) Message boards : Number crunching : v 0.26 and 0.03: Less than 20 Cr./hour on Nehalem! (Message 43222)
Posted 28 Oct 2010 by Martin P.
Post:
Any news on this? The Win-CPU app is still 4 times faster than the Mac-CPU-app (on comparable machines).

It's also been mentioned that they're working on a new type of search that might not be as GPU-friendly (though that remains to be seen). With GPUs working so well here at the moment it's probably best to focus your CPU on other projects until they get that search underway. I realize that's not technically what the topic is about, but ...

4) Message boards : Number crunching : v 0.26 and 0.03: Less than 20 Cr./hour on Nehalem! (Message 39299)
Posted 30 Apr 2010 by Martin P.
Post:
Even worse: Windows v0.19 takes only 2 hours and grants the same amount of credit on a much slower machine!
5) Message boards : Number crunching : v 0.26 and 0.03: Less than 20 Cr./hour on Nehalem! (Message 39298)
Posted 30 Apr 2010 by Martin P.
Post:
Just finished the first WUs with 0.26 and 0.03 on Mac OS X and a 8-core 2.66 GHz Nehalem: less than 20 credits/hour! Not worth the electricity.
6) Message boards : Number crunching : Big issue : Milkiway doesn't work on Mac OS X. (Message 39283)
Posted 29 Apr 2010 by Martin P.
Post:
Zydorg,

this discussion is about Milkyway3, but I see the same problem with Milkyway 0.26!
7) Message boards : Number crunching : Mac application???? (Message 35198)
Posted 8 Jan 2010 by Martin P.
Post:
Top computers: less than 100 sec. for 214 credits (CUDA)
My 4-core Windows machine (Core 2 Quad, 2.83 GHz): 7,000 sec. for 214 credits (CPU)
My new 8-core Mac (Nehalem, 2.66 GHz): 26,000 sec. for 214 credits (CPU, no CUDA available)

Sorry, but I will not waste any more computation power and electricity bill for this. Bye.
8) Message boards : Number crunching : 100,000 credits lost?!?!?!?!?!? (Message 28517)
Posted 29 Jul 2009 by Martin P.
Post:
What is going on?????? From yesterday to today 100,000 credits just disappeared from my account!

9) Message boards : Number crunching : Not receiving any work from Milkyway!! (Message 27799)
Posted 15 Jul 2009 by Martin P.
Post:
Brian,

the primary problem is, that Milkyway requests GPU-tasks although I neither have the hardware for it nor did I enable GPU-work.
And the error about finishing-time appears only in Milkyway, although I run 6 projects simultanously. I never a saw this message before, both in Milkyway or any other project. It only started with BOINC 6.6.36.

So please don't blame us being too stupid to understand BOINC scheduling when this is obviously a Milkyway-problem!
10) Message boards : Number crunching : Not receiving any work from Milkyway!! (Message 27308)
Posted 8 Jul 2009 by Martin P.
Post:
I recently added the Milky Way project which is supposed to run at 50% of the time with the currently running SETI project, switching every 60 minutes between projects. I received WUs for the CPU, but no GPUs on the first day and nothing since. Any ideas why.


First, you didn't get any GPU tasks because the project does not support CUDA at this time... The message from the BOINC client is a generic one. It will make the same GPU request from any project you're attached to, no matter if the project has an application for GPUs or not...

As for the cpu side of things, which is where the "won't finish in time" message came from, right offhand I'd say that the 1250ish tasks that you have assigned to that host over at SETI that are currently "in progress", some of which are due in 4-6 days, is likely the issue...


Brian,

I have the same problem as the original poster: Milkyway requests GPU workunits, which do not exist. Only at the third try it will request CPU workunits. However, I receive the same warning message as mentioned above.

Only when I suspend all other projects and retry for exactly 3 times I will receive CPU workunits - which ofcourse do finish fine within the given deadline.
11) Message boards : Number crunching : ATI Crunchers dominate top 100 list (Message 16928)
Posted 26 Mar 2009 by Martin P.
Post:

That list shows top users for multiple projects,

users participate in two or more projects with a resource share of 5% or more.



I see nothing wrong with this - seems that many have found a way to do work faster, and get rewarded for that work. As it should be.


Well, I do think this is unfair since there are no GPU-versions for e.g. MacOS X. My brand-new 8-core Nehalem MacPro needs more than 1,000 seconds, although it does have an ATI Radeon 4870. Turned down Milkyway to 10% until this issue is solved.
12) Message boards : Number crunching : post milkyway_powerpc-apple-darwin problems here (Message 6895)
Posted 27 Nov 2008 by Martin P.
Post:
Just finished another few, this time app version 0.04. They are a little shorter than the 0.02 units.

Still the same stderr out

<core_client_version>6.2.18</core_client_version>
<![CDATA[
<stderr_txt>
APP: error reading checkpoint (opening file)
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
called boinc_finish

</stderr_txt>
]]>
13) Message boards : Number crunching : post milkyway_powerpc-apple-darwin problems here (Message 6721)
Posted 25 Nov 2008 by Martin P.
Post:
O.k., first work-unit finished and validated after 1,355.74 seconds (appr. 22.5 minutes) on a G5 Dual 2.7GHz with MacOS X 10.4.11. Claimed credit is 6.57, granted credit is 9.97.
Task ID 55082109
Name nm_test24_210_1227638440_0
BOINC manager estimated 52 hours(!).

Task details:
stderr out

<core_client_version>6.2.18</core_client_version>
<![CDATA[
<stderr_txt>
APP: error reading checkpoint (opening file)
APP: error writing checkpoint (flushing checkpoint file) 0
APP: error writing checkpoint (flushing checkpoint file) 0
APP: error writing checkpoint (flushing checkpoint file) 0
APP: error writing checkpoint (flushing checkpoint file) 0
APP: error writing checkpoint (flushing checkpoint file) 0
APP: error writing checkpoint (flushing checkpoint file) 0
APP: error writing checkpoint (flushing checkpoint file) 0
APP: error writing checkpoint (flushing checkpoint file) 0
APP: error writing checkpoint (flushing checkpoint file) 0
APP: error writing checkpoint (flushing checkpoint file) 0
APP: error writing checkpoint (flushing checkpoint file) 0
APP: error writing checkpoint (flushing checkpoint file) 0
APP: error writing checkpoint (flushing checkpoint file) 0
APP: error writing checkpoint (flushing checkpoint file) 0
APP: error writing checkpoint (flushing checkpoint file) 0
APP: error writing checkpoint (flushing checkpoint file) 0
APP: error writing checkpoint (flushing checkpoint file) 0
APP: error writing checkpoint (flushing checkpoint file) 0
APP: error writing checkpoint (flushing checkpoint file) 0
APP: error writing checkpoint (flushing checkpoint file) 0
APP: error writing checkpoint (flushing checkpoint file) 0
APP: error writing checkpoint (flushing checkpoint file) 0
APP: error writing checkpoint (flushing checkpoint file) 0
APP: error writing checkpoint (flushing checkpoint file) 0
APP: error writing checkpoint (flushing checkpoint file) 0
APP: error writing checkpoint (flushing checkpoint file) 0
APP: error writing checkpoint (flushing checkpoint file) 0
APP: error writing checkpoint (flushing checkpoint file) 0
APP: error writing checkpoint (flushing checkpoint file) 0
APP: error writing checkpoint (flushing checkpoint file) 0
called boinc_finish

</stderr_txt>
14) Message boards : Number crunching : post milkyway_powerpc-apple-darwin problems here (Message 6716)
Posted 25 Nov 2008 by Martin P.
Post:
I just received my first Test-units. However, in the BOINC client it says "work unit aborted by project" but the WUs get deleted from the server so quickly that I did not have a chance to check the details in the work-unit ID.
15) Message boards : Number crunching : Connectivity (Message 5160)
Posted 3 Sep 2008 by Martin P.
Post:
I'm sure Dave is giving his best to solve the problem.

No need to put more pressure on him.


Hey, I love those cheerleaders! They always give you a comfortable feeling - even when everything goes down around you.
16) Message boards : Number crunching : Short deadlines-High priority-suspend Milkyway (Message 5056)
Posted 27 Aug 2008 by Martin P.
Post:
The nature of their methodology dictates the requirement. They use what is known as a "genetic" algorithm. What this means is that the output from the results you return TODAY influence the parameters of the work generated TOMORROW. It would be IDEAL for the science of the project if no core kept more than one task ready to work at any given time, but they've extended it to 3 days so that certain computers can have a chance to contribute results, even if they're not quite as valuable as those that are returned/refreshed quickly.


Thanks Thunder! This is the first time I receive some usefull information about WHY things are like that. However, in this case it would be a nice feature if I could define the number of WUs that are downloaded by each host. If my hosts downloaded fewer work-units all problems were gone. Unfortunately my PowerMac Dual 2.7GHz insists in downloading 2 work-units every time it returns one and my Mac Pro 8x3 GHz always downloads the maximum number of 20 work-units (I already suspended this project on the other computers). Due to this fact both machines run Milkyway in high-priority mode. If I could limit the number of WUs downloaded to 1 and 10 respectively all problems were gone. Currently I have to use this workaround: Let it download work, set Milkyway to "No new work" and manually abort some work-units until the rest runs in normal mode.
17) Message boards : Number crunching : Short deadlines-High priority-suspend Milkyway (Message 5045)
Posted 26 Aug 2008 by Martin P.
Post:
... how did you keep your Computer running for more than 2 & 1/2 days though. I have Backup UPS's but they are only good for 20 minutes or so, any longer than that and they shut the Box's off ... :)


PoorBoy,
electricity was back appr. 2 hours later and my computer is configured to automatically restart after a power failure. However, the servers and switches were down and therefore I had no network and internet access until my IT-department could fix everything this morning (small company, took 2 days to replace the broken switch). In the meantime my computers were happily crunching the projects and WUs that were in the cache before the power failure.
18) Message boards : Number crunching : Short deadlines-High priority-suspend Milkyway (Message 5043)
Posted 26 Aug 2008 by Martin P.
Post:
They all wind up running MW at high priority. I even have a machine with 10 days of queue and it still finds it necessary to run at "High Priority"


Well, I hate to say this because it might seem obvious to some, but if you're asking the BOINC client to keep 10 days worth of work for a project that requires results to be returned in 3 days, then you're forcing it to run all of the tasks at high priority. You're forcing it into a situation in which it believes >2/3rds of the tasks cannot be completed in time.

The project can't set the deadlines any longer or they're not going to be producing anything scientifically useful. You'd be getting a lot of credit, but the work would only be "flogging a dead horse". As much as I hate to discourage anyone from any project, if the other projects you volunteer for require you to keep a 10 day cache, then you're just not going to be able to run this project as well.

I used to wonder why I kept hearing about everyone having high-priority problems when I never seemed to have any on even old computers with a relatively low resource share. The answer is simply that I never try to cache a lot of work. I have my cache set to "0" (always connected) with the "additional" at the default of .25 days. I almost never have results waiting to run on any project unless it's 6 hours or less from finishing the prior task. All the projects that I work for that are in a "normal" status do just great this way on 17 different computers and have for as long as I can remember. (Yes, I do have a full-time connection for all of them and I understand that modem connection users need to do things a bit differently)


Thunder,

I have set my cache to 3 days for some good reasons. One of them is the situation I had this weekend: On Friday night our electricity broke down and it took until this morning until all servers were up and running again. My 3 days cache kept my computer running and all projects produced valid results with just one exception: Milkyway@Home. Due to the short deadlines I lost 15 workunits which were completed properly but reported too late to validate.

Besides that I see no reason why longer dealines (e.g. 5 days instead of 3) should lead to useless results. The stars are here for several billion years now, so why should a delay of 2 days change the scientific outcome? This sounds like a very cheap excuse.
19) Message boards : Number crunching : Short deadlines-High priority-suspend Milkyway (Message 4884)
Posted 21 Aug 2008 by Martin P.
Post:
In other words...

Short answer: When the tasks you have finish, you won't download any more work until your other projects have been given their fair share.

I'm going to guess that you had your work cache set for several days or this wouldn't have happened. (Only because I've not had a similar problem happen on any of mine, but it doesn't take a stretch of the imagination to figure out how)


Still the same problem. I let it run without intervention for a week now, but on my slower computers (G5 Dual 2.7GHz) it still downloads 2 WUs and runs them in "High priority" mode. My work cache is set to 3 days so that I can compensate for the frequent server problems on most BOINC projects (presently there are quite a few problems with SETI@Home, no work for Cosmology@Home and Pirates@Home, new science cruncher for Einstein@Home, etc).
I have suspended Milkyway on my slower machines and wait until they figured out how to handle this problem.
20) Message boards : Number crunching : Short deadlines-High priority-suspend Milkyway (Message 4737)
Posted 15 Aug 2008 by Martin P.
Post:
Due to the extremely short deadlines all my computers run Milkyway@Home WUs at "High-priority" level all the time. All other projects do not receive any CPU time anymore. Therefore I will suspend Milkyway@Home until this issue gets resolved.


Next 20

©2019 Astroinformatics Group