Message boards :
Number crunching :
Hopefully...
Message board moderation
Author | Message |
---|---|
Send message Joined: 19 Apr 08 Posts: 7 Credit: 3,067 RAC: 0 |
Hi, Now to the immediate problem of short deadlines and d/l too much work....remember everyone when you think of dumping some....they have to be resent by the server ....then crunched......which gives you even more time to report before your resend does .....and yours gets credit if reported 1st.......so those teetering on the edge of deadlines should get you credit anyways :) Don't be too quick to abort! Some people are playing a similar game every Wednesday and Saturday. It's called Lotto ;-) Regards, Carsten |
Send message Joined: 7 Jun 08 Posts: 464 Credit: 56,639,936 RAC: 0 |
Again, thanks for all the feedback guys. LOL... No problemo! ;-) I was relieved to hear that even slugs (like mine) do perform useful science here at MW. I was kind of concerned given that I recently wandered over and haven't had the time to fully absorb how the modeling and simulation actually works, and whether antiques were helping or hurting the project in the grand scheme of things. The part I liked about MW is it supports PPC Mac's running less than Leopard (Tiger?, Macs aren't my strong suit), and the runtimes were still in the range older CPU's can handle and still let you run more than one project smoothly. One thing to think about was given today's range of host capability, on the old work, 5 days made the project fairly loose in terms of deadline tightness factor. I'm pretty sure this had a lot to do with the constant pounding on the backend for new work by the hosts. Even my old timers were pestering the project for work far more than they really needed to. I would suggest trying something like 2 weeks for the new deadline as a starting point. This should tighten project significantly for the fast hosts, but not make it so tight that MW hogs the machine for slow hosts running more than one project with even resource splits. As far as credit rate goes, MW is pretty new and the natural evolution of host speed caused some significant 'credit deflation' in the early days of BOINC when Benchmark-Time was the primary scoring methodology. I'm pretty sure this is the root cause of a lot of the credit 'soapboxing' which goes on from time to time. So in my case, I don't have a problem when the newer projects set their rates somewhat higher than SAH or EAH for example. I've argued the case there that they should have made a rate increase to get back to what the rates were when they first went production, rather than de-rate to what the projects were currently running which hadn't implemented a more constant scoring system than BM-T. Alinator |
Send message Joined: 4 Oct 07 Posts: 43 Credit: 53,898 RAC: 0 |
Again, thanks for all the feedback guys. I do apologize for the suddenness of the longer WUs, but weighing all the problems with the server and the lack of work I figured it was worth the risk. As has been mentioned the server is performing much better than before, which was a big problem when you couldn't even connect to the site for how bogged down it was. As was commented on by someone above, we seem to have found a happy place with the length of the WUs now, so there shouldn't be any more "big" instances in time change like this. To address a couple of the comments above: yes the science will benefit, we will gets increased accuracy within all of our numerical calculations. Yes slower machines still contribute a lot to the project. Some tests have shown that even the slowest machines have a relatively high chance of their work bettering the population thereby improving the results. The quickness of the WUs past the 50% mark I believe is phenomenon associated with the code: I believe that the first 50% is the calculation of the integral and the other half of the WU is the calculation of the actual likelihood given the data (the final result of your crunching): the problem with this is that there are about 100,000,000 calculations in the integral now, and... about 100,000 for the data. You can see the speed issue here. Again, this is just my theory given what I've seen and the structure of the code, but it seems to fit. We'll get the delays and deadlines fixed as soon as I'm able to talk to Travis. Probably, tomorrow (Wednesday). Keep up the good work guys! ~Nate~ |
Send message Joined: 30 Mar 08 Posts: 50 Credit: 11,593,755 RAC: 0 |
Just 2 cents: Econo fix is quick and dirty. Legacy code is to be treated as a "quaint" tourist attraction. Consider it a free memento of an optimistic past . Shoe strings are cheap and often break. Voltron |
Send message Joined: 27 Mar 08 Posts: 5 Credit: 2,232,048 RAC: 0 |
Just 2 cents: If the crunching time is 3 hours at least, then having that 20 minutes buffer time to fetch more WUs doesn't make much sense, does it? I mean: there is a 20 WU limit, and if the machine asks for more, the server will tell it to sit back and wait for 20 minutes before asking again for more work. If the machine already has 20 WUs, there is no way that after only 20 minutes (each WU takes over 3 hours...) the machine will be able to download something. So, in order to decrease the number of pointless connections to the servers, why not increase this amount of buffer time to, say... 3 hours? :D |
Send message Joined: 9 Nov 07 Posts: 151 Credit: 8,391,608 RAC: 0 |
wow It has taken 4hr 38min 05sec (16685 secs) to reach the 50% mark and just 4hr 38min 26 sec (16706 secs) to complete a dif. of only 21 sec for the second 50% AMD x2 Dual Core 6000+ Win XP SP3 32bit 2GB DDR2 667 MHz RAM |
Send message Joined: 22 Mar 08 Posts: 65 Credit: 15,715,071 RAC: 0 |
Finally snagged a 382 series from the host I quoted above before it purged. So just to sum up: 6,206 sec for a 382 resulting in 139.29 credits 11,658 sec for the 282 series equals 260 and 194 seconds for the 182s with 4.06 granted. These are all from the same host. It is an X2 5000+ at 3.2g running 6.2.11 under Linux 64. Peace and happy crunching! |
Send message Joined: 11 Nov 07 Posts: 41 Credit: 1,000,181 RAC: 0 |
Got a gs_3730382 completed and it took 2h 38min, the gs_3720282 used 5h. Both fine with me. AMD X2 2.8gig/Linux. |
Send message Joined: 7 Jun 08 Posts: 464 Credit: 56,639,936 RAC: 0 |
Well with cosmology still down I've had no choice but to run Milkyway constantly on my one machine so all's good ;) LOL... Yep, I had almost forgotten about the 'thrill of the hunt' on Beta projects. Guess I had gotten too complacent crunching away on the production ones. You know how it goes... Download a bunch of new work, then turn around and complain about falling RAC. Next, reply to some other comment and get banned! :-D Personally, I prefer this kind of 'sport'. ;-) Alinator |
Send message Joined: 2 Apr 08 Posts: 32 Credit: 1,017,362 RAC: 0 |
Well with cosmology still down I've had no choice but to run Milkyway constantly on my one machine so all's good ;) And for a beta project you've got to give these guys a hand... Just keep in mind a little forewarning beforehand would be nice...I imagine quite a few people are perplexed at the suddenly exponentially longer WU's -Stefan- |
Send message Joined: 7 Jun 08 Posts: 464 Credit: 56,639,936 RAC: 0 |
I am at least very happy my hosts are no longer jammed by MW and the length makes no difference to me as long as the pay rate is the same as someone else said..... LOL... Agreed, that's why I'm waiting to get a feel for the new runtimes before I start thinking about 'punching out'! :-) I've played this game before, and I really hate wasting my hosts time, but don't like not running the work I was assigned either unless there isn't any other choice. ;-) Alinator |
Send message Joined: 8 Oct 07 Posts: 289 Credit: 3,690,838 RAC: 0 |
Double Post |
Send message Joined: 8 Oct 07 Posts: 289 Credit: 3,690,838 RAC: 0 |
I am at least very happy my hosts are no longer jammed by MW and the length makes no difference to me as long as the pay rate is the same as someone else said..... Now to the immediate problem of short deadlines and d/l too much work....remember everyone when you think of dumping some....they have to be resent by the server ....then crunched......which gives you even more time to report before your resend does .....and yours gets credit if reported 1st.......so those teetering on the edge of deadlines should get you credit anyways :) Don't be too quick to abort! |
Send message Joined: 7 Jun 08 Posts: 464 Credit: 56,639,936 RAC: 0 |
My only suggestion would be when you make a change like that, and aren't sure all BOINC oriented run parameters are in the ballpark, would be to not just pull the rabbit out of the hat and drop him in our laps first thing Monday morning. :-D LOL... Yep, If I had advanced warning, I would have rolled the cache setting way back. I wasn't having any trouble getting stuff pushed through any of my hosts at 1.25 days before the new stuff came out. But I've just finished running some numbers by hand with the new mix, and picture is somewhat grim for a couple of them. :-) I've pretty much decided I would run out the original run length stuff first, then start plowing away at as much of the new stuff I can get done before deadline, and start dumping some of the excess new stuff once I have feel for them. OTOH, I really don't mind. This is the first time in a long time I really had to take matters into hand manually! Like maybe since the really early days of SAH on BOINC! :-D Alinator |
Send message Joined: 9 Jul 08 Posts: 85 Credit: 44,842,651 RAC: 0 |
My only suggestion would be when you make a change like that, and aren't sure all BOINC oriented run parameters are in the ballpark, would be to not just pull the rabbit out of the hat and drop him in our laps first thing Monday morning. :-D Yeah, I'm not positive all of the content of the conversation tomorrow between Nathan and Travis, but I'm reasonably sure at least two elements will be: Travis: "You did WHAT?!" Nathan: "They were screaming for new work, so I gave it to 'em" Due to the law of unintended consequences, you'll quickly learn that in the BOINC world no good deed goes unpunished, Nathan. ;) All I can say is that it's so nice to have the site responsive and the server not constantly giving timeout errors that I'd forgive just about anything at this point. :D |
Send message Joined: 7 Jun 08 Posts: 464 Credit: 56,639,936 RAC: 0 |
Thanks for all the great feedback guys. LOL... Well, I can deal with the runtimes either way (as long as the pay rates stay the same). My only suggestion would be when you make a change like that, and aren't sure all BOINC oriented run parameters are in the ballpark, would be to not just pull the rabbit out of the hat and drop him in our laps first thing Monday morning. :-D Perhaps announce it on Monday morning, and then drop the 'bomb' the next day. :-) I know I may have to punt some of the last batch my slugs DL'ed once I get a feel for what they can handle on the new stuff. Alinator |
Send message Joined: 7 Sep 07 Posts: 444 Credit: 5,712,523 RAC: 1 |
My fastest host jumped from 6m33s to 6h38m - and it's Duration Correction Factor (DCF) is now around 51.6. So from now on the estimates will be reasonably close, but it would have been nicer if the estimate had been adjusted, rather than allowing the DCF to take care of it. But as quoted above, it's a beta project - I'm not complaining, just offering ideas for the future. Regards Rod |
Send message Joined: 9 Jul 08 Posts: 85 Credit: 44,842,651 RAC: 0 |
do you guys like this length of WU or do you want to see the time dropped back a little bit? It seems like it's a really good time on the good machines, but the slower machines seem to be suffering. So my question to you is: if I reduce the time how much do you want it reduced? I've not actually finished any of the new WU's yet, but based on the progress on a few machines so far, I'd say the length even on the '372' WU's is just fine. Longer than SETI units, but still shorter than Einstein ones. I'd call that a "Goldilocks Zone" for WU length. :) Heck, I normally crunch Einstein and Climate Prediction WU's primarily, so MW WU's always seemed ludicrously short to me! ;) The only real problem is that since there was no increase in the estimated time to completion, I now have several computers with queues so filled that they have little hope of finishing them for weeks, but it's a beta project, so mistakes are going to happen. If you learned a good estimate of how much your increases in precision will equate to increased run-times (and probably credit values as well), then something valuable came out of this. My only real question is whether the science value of the WU's is going to be maintained if a slower computer that may only have 20% (as an example) to MW takes 2-3 days to return it. Yes? No? |
Send message Joined: 8 Apr 08 Posts: 45 Credit: 161,943,995 RAC: 0 |
I am happy with the times but I have a fast comp currently No.5 The credit is good . The pressure on the server is reduced everyone gets a steady flow of work. The services that people like to take advantage of like credit reporting can be re-enabled and the purge time can be set at perhaps an hour or two now.. all in all a lot better regime. Please however consider the slower machines I know what that was like and still have a few connected. Regards, Ross, Perth W. Australia OWN every thing I need EARN.. enough to live !!! WANT a solar array on the roof so I can run a BOINC farm( DREAM on!!) NO wife NO kids NO troubles |
Send message Joined: 12 Apr 08 Posts: 621 Credit: 161,934,067 RAC: 0 |
It looks to me like the length was almost a "linear" extension. Old ws 3 min 30 seconds and new is 3 hours 30 min ... I do not mind either way. If I WAS to lean one way or another it would be to longer running tasks, especially if the end result for you is better science. I cannot answer that question ... On my Pro I should have no trouble finishing the work assigned in that it is on my 8 core machine and I have MW at 100 share meaning it should be running a task at all times if not two. Oh, I did not yet look, but this should be a news item if it is not already ... |
©2024 Astroinformatics Group