| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Completed Research
Forum: AfricanClimate@Home
Thread: I am desperate for one of these workunits |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 41
|
|
| Author |
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Hello Kremmen,
Here is a post I made earlier today about ACAH on the Mac: http://www.worldcommunitygrid.org/forums/wcg/viewthread?thread=16748#132660 Lawrence |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
How far does Homogeneous Redundancy go? Is there any difference in calculations made on a Mac or a Linux box on Intel architecture? I would really doubt it, so they shouldn't be kept apart. There should be plenty of Linux machines to take up enough workunits.
Or is there some previously unmentioned problem with Linux users, such as myself, getting WUs from this project? |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
I've now received a WU ... with a 24-hour time limit, which the machine it's been allocated to will not be able to achieve!
|
|||
|
||||
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
How to get them? Somewhere posted the recipe but in nutshell
----------------------------------------- set the Connect time short.... 0.0100 days - Additional buffer.... 0.0000 days (only BOINC 5.10 andd up) - Keep the machine permanently attached to the internet and On - Select AC@H as main project - Select the 'If there is no work option... give me something else to do' at bottom" of device or the My Projects profile If 24 hours is not enough to do a rush backup job of AC@H with machine always on, filling in the difference for work that did not validate from others, you should consider to not select AC@H for the Device Profile. And *No* forget about the 'should not be kept apart'. The outcome is effected by both the CPU *and* the OS regardless the stability. No absolute equality of results, no science validation.
WCG
Please help to make the Forums an enjoyable experience for All! |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Hi Kremmen,
How far does Homogeneous Redundancy go? Is there any difference in calculations made on a Mac or a Linux box on Intel architecture? I would really doubt it, so they shouldn't be kept apart. There is a big difference between a Linux x86 compiler and a Mac OS X x86 compiler. For that matter, just changing the switches on a compiler (selecting types of optimizations) will change the order to evaluate sub-expressions, which will change floating point results slightly. Each such change produces a new bin for results (a new homogenous redundancy class). Which is why we do as little of that as possible. Lawrence |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
If 24 hours is not enough to do a rush backup job of AC@H with machine always on, filling in the difference for work that did not validate from others, you should consider to not select AC@H for the Device Profile. I'm afraid I question that. When the original jobs have failed or been inconclusive after 3-4 days, it's just bad luck that the server chose a slower (but reliable) machine to fill in the gap. If it had chosen that machine 5 days ago, everything would be fine and it might not need to send out additional WUs at all. [Edit 1 times, last edit by Former Member at Oct 16, 2007 8:09:09 AM] |
||
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
Sure, if you think it acceptable to generate a 'no reply' / 'too late' result causing the distribution from yet another extra copy.
----------------------------------------Consider there are only 82 work units send out in quorums of 10 (total 820) spread over different operating systems and 27 cycles over the whole project. There are thousands of machines who said 'Yes' to AC@H and are able to process timely. Each delay of a quorum, causes the next cycle, dependent on the previous cycle to stall. That's why WCG already cancelled work send to Macs because it was holding up the project to progress to the next 14 day prediction period.
WCG
Please help to make the Forums an enjoyable experience for All! |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Hi Sek et al.
The linear time frame problem, as expressed in regard to the parallel world of Distributed Cmpting projects... In layman's terms, the old square peg in the round hole trick.  Cheers. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
There are thousands of machines who said 'Yes' to AC@H and are able to process timely. A number of the results in the unit I've got were received 3-4 days after they were sent out. Clearly, many machines are not processing these units within 24 hours. Now, if the server was sensible, it would either not have such a short limit on the extra job or choose the client more wisely. It can tell the memory and bandwidth limits -- can't it tell the CPU benchmarks? If it's going to give out a job to a machine that may not finish in time, then treat it as late when it's about 90% complete, then go give the job to another machine, then that sounds like a stupid configuration to me. By the way, what will happen if the result is really close to the time ... ie. if it goes over, but the first time it contacts the server past the time limit it has finished? Will the server take the result, or will it discard it even though it's complete? [Edit 1 times, last edit by Former Member at Oct 16, 2007 1:59:17 PM] |
||
|
|
Jean-David Beyer
Senior Cruncher USA Joined: Oct 2, 2007 Post Count: 339 Status: Offline Project Badges: 
|
"Now, if the server was sensible, it would either not have such a short limit on the extra job or choose the client more wisely. It can tell the memory and bandwidth limits -- can't it tell the CPU benchmarks?"
----------------------------------------I do not know the answer to other issues, but in my case, the BOINC client cannot tell my bandwidth limit. I have Verizon FiOS which gives 20 Megabits per second download, and almost 5 Megabits per second upload. This is apparently not believed by the BOINC client or the BOINC server because they consistently report my speeds as about Average upload rate 12.81 KB/sec Average download rate 38.11 KB/sec Now if I run Speakeasy's speed test from here (near NYC) to Washington DC, I get: Download Speed: 20538 kbps (2567.3 KB/sec transfer rate) Upload Speed: 4485 kbps ( 560.6 KB/sec transfer rate) And to Atlanta, I get: Download Speed: 12864 kbps (1608 KB/sec transfer rate) Upload Speed: 4220 kbps ( 527.5 KB/sec transfer rate) So BOINC is unable to determine my upload and download speeds because they are much higher than the authors could believe.  |
||
|
|
|