Posts by Odysseus

21) Message boards : News : Failing workunits (Message 43438) Posted 3 Nov 2010 by Odysseus Post: Still getting errors on my G4 Macs; a small mercy is that the tasks bomb right away, so the time-wastage is negligible. Have set the project to NNT on all three until a new app becomes available.
22) Message boards : News : PPC mac version for separation workunits (Message 43081) Posted 22 Oct 2010 by Odysseus Post: Just to confirm, the OS is v10.3 (with the last update available—.9 I believe). It also has a pretty old version of BOINC, running as a service. I could try updating it, but I haven’t had much luck with newer BOINC versions on my Panther/G4s: most recently I tried a v6 on a slightly older machine, but it wouldn’t run (although installed without apparent problems) and I had to revert to a late v5.x.
23) Message boards : News : PPC mac version for separation workunits (Message 43054) Posted 21 Oct 2010 by Odysseus Post: Thanks! My G5 seems to be doing OK with v0.41, but I have a G4 that’s producing nothing but errors. <message> process got signal 5 </message> <stderr_txt> dyld: milkyway_0.41_powerpc-apple-darwin Undefined symbols: milkyway_0.41_powerpc-apple-darwin undefined reference to _statvfs expected to be defined in /usr/lib/libSystem.B.dylib milkyway_0.41_powerpc-apple-darwin undefined reference to _uselocale expected to be defined in /usr/lib/libSystem.B.dylib
24) Message boards : News : updated the CPU applications (Message 42672) Posted 8 Oct 2010 by Odysseus Post: The PPC Mac applications appear to have been removed: Thu 7 Oct 21:51:11 2010 Milkyway@home Message from server: No work sent Thu 7 Oct 21:51:11 2010 Milkyway@home Message from server: MilkyWay@Home N-Body Simulation is not available for your type of computer. Thu 7 Oct 21:51:11 2010 Milkyway@home Message from server: MilkyWay@Home is not available for your type of computer.
25) Message boards : MilkyWay@home Science : Is it posible that the universe are colapsing at this very moment? (Message 41295) Posted 6 Aug 2010 by Odysseus Post: Well, according to Roger Penrose, “We can imagine that for a sufficiently massive and concentrated body, the escape velocity could exceed even the velocity of light! When this happens, we have a black hole.” Reverse engeneering, anything caught by that particular black hole would be sucked in at a speed exceeding the speed of light. Correct me if Roger Penrose isn't saying this. No, he’s not. Consider that the escape velocity from the surface of the Earth is about 11 km/s. This means that no (unpowered) projectile can get free of the planet’s gravity unless it’s going at least that fast. That doesn’t mean that falling objects must travel at that speed or faster.
26) Message boards : MilkyWay@home Science : 2012 (Message 34748) Posted 21 Dec 2009 by Odysseus Post: What makes the whole notion preposterous to me on its face is that the disc of the Galaxy is some thousands of parsecs thick; the solar system has spent its entire history in the disc, having made a couple dozen orbits since it was formed. The galactic equator has no more physical significance than Earth's -- less, as a matter of fact, because it's pretty arbitrarily defined, more like the constellation boundaries, and certainly not an 'object' that we'll 'pass through'.
27) Message boards : Number crunching : Deadline problem (Message 34685) Posted 19 Dec 2009 by Odysseus Post: If you are not running an optimised app you really are "cutting your nose off to spite your face". Even when there isn't one available for your platform?
28) Message boards : Number crunching : Cruncher's MW Concerns (Message 34656) Posted 18 Dec 2009 by Odysseus Post: My older G4 Macs are in the same boat. But the only remedy that might be considered is bringing the WU size back down a bit; the deadlines are already maxed as far as the admins are concerned. See under Deadline problem.
29) Message boards : Number crunching : Deadline problem (Message 34655) Posted 18 Dec 2009 by Odysseus Post: But the project will have to consider how many hosts they will lose, when deciding to leave the deadline at 3 days, or to increase it. AIUI, and as others have implied, the deadlines are 'non-negotiable' because the computations are iterative: the results from one batch of tasks provide the inputs for succeeding batches. This cycle is already as slow as the project scientist(s) will tolerate, so the only 'free parameter' is the size of WU.
30) Message boards : Number crunching : Deadline problem (Message 34601) Posted 17 Dec 2009 by Odysseus Post: My G4 Macs will be hard-pressed just to make the deadlines. I don't begrudge the high priority the MW app needs to have a hope of finishing on time, because I know the LTD accounting will ‘keep it fair’ WRT my resource shares, but it looks like the older systems will need more than 72 hours of CPU-time … in which case they’ll have to drop out.
31) Message boards : Number crunching : Cruncher's MW Concerns (Message 33789) Posted 27 Nov 2009 by Odysseus Post: FWIW my Macs’ credit-productivity appears to be near the benchmark these days, the PPCs doing better than the Core2. It used to be much higher, more like what they earn from the optimized SETI@home apps, but I’ve no cause to complain. I wouldn’t be happy to see further cuts, though; my only “concern” is that any calibration of the project’s granting formula that’s based on the productivity of the GPU apps shouldn’t result in undervaluation of the contributions from us CPU-only participants.
32) Message boards : Number crunching : credit comparison to other projects (Message 7413) Posted 4 Dec 2008 by Odysseus Post: It can be hard to catch results around here (and I still havenâ€™t gotten my, er, act together regarding automated BOINC data collection), so I have more a general impression than hard data â€¦ Anyway, the credit production per unit time from my Macs, both PPC and Core2, appears to be about the same with MW@h Optimized vv0.3â€“0.6 as it was with MW@h v1.2. This rate is (and has been) somewhat more than double the hostsâ€™ benchmark-based or nominal productivityâ€”or what they get from Einstein@homeâ€”in fact itâ€™s very similar to Alex Kanâ€™s optimized SETI@home apps. Early indications from MWO v0.7 are that itâ€™s earning a good 10% more than previously, on both CPU types.
33) Message boards : Number crunching : No Work ? (Message 6069) Posted 11 Nov 2008 by Odysseus Post: The Macs could run the fast code using Windows under Bootcamp. The ones with Intel CPUs could, but thatâ€™s not the case for the PowerPC-based systems.
34) Message boards : Number crunching : No Work ? (Message 6065) Posted 10 Nov 2008 by Odysseus Post: [â€¦] Here, the ONLY current work units are 5 minute work units [â€¦] I donâ€™t know what kind of hosts you have, but itâ€™s all my older Macs can do to complete their tasks within deadlineâ€”even in â€˜panic modeâ€™. I donâ€™t think Iâ€™ve seen any recent tasks taking less than thirty hours; even a fairly small increase in running time would prevent these hosts from participating.
35) Message boards : Number crunching : Credit limits apparently exist ... (Message 5865) Posted 3 Nov 2008 by Odysseus Post: Why bow down to SETI@HOME on the credit issue. If they (and any other project were worried about crunchers, then why don't they raise their credit system to the level of Milkyway@home. AFAICS itâ€™s not about deferring to S@h, but of preserving the ratio of credit granted to Flops performed. This may be a pipe dream, but the idea is that one should be able to calculate the computational throughput of a project from the amount of credit it grantsâ€”indeed, many project and stats websites report their performance in TFlop/s, based solely on the credit figures AFAICT. Personally, I wouldnâ€™t object to a â€˜floating cobblestoneâ€™, leaving it to the stats sites to work out â€˜exchange ratesâ€™ for cross-project comparisons, but I can also see the advantages of standardization from an administrative POV, theoretically allowing each project to derive a reasonable estimate of the available computing resources directly from its credit stats.
36) Message boards : Number crunching : Compute errors (Message 5220) Posted 13 Sep 2008 by Odysseus Post: 2.) Shutdown BOINC and then open client_state.xml in Notepad. Not on a Mac: that would be TextEdit (or any other word-processor capable of saving plain text).
37) Message boards : Number crunching : Connectivity (Message 5168) Posted 4 Sep 2008 by Odysseus Post: Just a â€œme-tooâ€ from my Macs, various BOINC versions, with the http errors. They donâ€™t mind: they know this is a test project. :p
38) Message boards : Number crunching : Short deadlines-High priority-suspend Milkyway (Message 4739) Posted 16 Aug 2008 by Odysseus Post: If you donâ€™t want to change your resource shares, BOINC will still try to honour them and, given enough time, usually succeeds. Although MW@h tasks may seem to be â€˜hoggingâ€™ your CPU, itâ€™s just because BOINC had underestimated the necessary time to complete themâ€”the recent jump in WU size here threw a lot of hosts off for a while. Apparently the server-supplied estimates werenâ€™t adjusted to match; such is life in a test project â€¦ BOINC adapts to events like this over time, by adjusting the hostâ€™s Duration Correction Factor for the project, and its averages are biased to avoid downloading more work than it can handle. Anyway, your BOINC client will be taking note of the extra CPU-time MW@h is using, and once it gets through the work itâ€™s downloaded it will refrain from asking for more until the other projects have caught up. This behaviour is managed with Long Term Debt, which you can read from the client_state.xml file or monitor with a BOINC add-on.
39) Message boards : Number crunching : Milestones (Message 3972) Posted 1 Jul 2008 by Odysseus Post: A couple of days ago I passed the 100,000 marker.
40) Message boards : MilkyWay@home Science : SDSS Stripe 82 searches (Message 3720) Posted 11 Jun 2008 by Odysseus Post: What are we searching for? AIUI we're not searching for anything, but modelling interactions between stars (or clusters or associations thereof) and comparing the results to observations of stellar distribution within our Galaxy.

Previous 20 · Next 20