Message boards :
Number crunching :
When will the deadline be extended?
Message board moderation
Author | Message |
---|---|
Send message Joined: 12 Nov 07 Posts: 2425 Credit: 524,164 RAC: 0 |
Being this is not my main project the deadline is too short for the runtime. Doesn't expecting the unexpected make the unexpected the expected? If it makes sense, DON'T do it. |
Send message Joined: 29 Aug 07 Posts: 20 Credit: 2,710,089 RAC: 0 |
Not to worry. BOINC will give this project extra time so that it can meet the deadline. Then it will avoid getting more work from this project until the extra time is paid back to your other projects. BOINC WIKI BOINCing since 2002/12/8 |
Send message Joined: 12 Nov 07 Posts: 2425 Credit: 524,164 RAC: 0 |
Not to worry. BOINC will give this project extra time so that it can meet the deadline. Then it will avoid getting more work from this project until the extra time is paid back to your other projects. I know that. That was not the question. When will TRAVIS or any other admin. extend the deadline? Doesn't expecting the unexpected make the unexpected the expected? If it makes sense, DON'T do it. |
Send message Joined: 30 Mar 08 Posts: 50 Credit: 11,593,755 RAC: 0 |
When will TRAVIS or any other admin. extend the deadline? My best estimate is right after you lose that P4 single core and upgrade to at least a dual. Voltron |
Send message Joined: 12 Nov 07 Posts: 2425 Credit: 524,164 RAC: 0 |
My best estimate is right after you lose that P4 single core and upgrade to at least a dual. I won't loose it, I don't run it hard. The deadline was going to be changed like everything else that was also going to get fixed and this program has basically been abandoned by the admins. Doesn't expecting the unexpected make the unexpected the expected? If it makes sense, DON'T do it. |
Send message Joined: 30 Mar 08 Posts: 50 Credit: 11,593,755 RAC: 0 |
If you ran it hard you might make the deadline. Voltron Vcore...Vcore...gotta make it sweat to score. |
Send message Joined: 27 Aug 07 Posts: 85 Credit: 405,705 RAC: 0 |
The administrators need the tasks returned promptly. The one thing that ensures this is a fairly tight deadline. Not all projects are suitable for all computers. BOINC WIKI |
Send message Joined: 12 Nov 07 Posts: 2425 Credit: 524,164 RAC: 0 |
If you ran it hard you might make the deadline. I can make the deadlines just fine. I never mentioned I couldn't. Doesn't expecting the unexpected make the unexpected the expected? If it makes sense, DON'T do it. |
Send message Joined: 7 Jun 08 Posts: 464 Credit: 56,639,936 RAC: 0 |
In any event, John's reply is the correct response. Given the peculiarities of the genetic search algorithm they use here, and the desire to have the search not 'wander' off in 'undesirable' ways due to having the results from the tasks coming back too late to be of use for the next iteration, then MWAH should be a tight deadline project. The advantage would be they would not have to put that 'artificial' limit to the number of tasks pulled on any given work request. The disadvantage is that the project will seem to hog the host when it's turn comes up to run, and then go idle while BOINC gives the other projects time to 'catch up'. This invariably starts a whole new round of "BOINC (or your Project) is junk because it isn't following what I told it to do right down to the last nanosecond..." posts, even though it will do exactly what you told it to do over the long haul (except for certain boundary cases, and of course when things happen which are not under the CC's control, like outages, malfunction, user mistakes, and stuff like that) and accommodate the needs of the widest spectrum of projects and hosts. I imagine this was the main reason for the kludgey approach of limiting the work requests along with a 'loose' deadline in the first place. Another downside is it would tend to raise the floor for what type of hosts can participate. In any event, I don't really expect them to lengthen the deadline any, even when they do get a chance to post with what's going on, due to my first comment. Even with the long work, my slugs are still getting their fair share of work and making the deadline without a problem. Alinator |
Send message Joined: 30 Aug 07 Posts: 2046 Credit: 26,480 RAC: 0 |
instead of lowering the deadline, we lowered the work queue to be closer to what we really want it to be at. probably not the answer that'll make everyone happy, but it's really the best for what we're trying to do here. i've been talking to dave anderson about being able to have the work queue be 1 (maybe 2) WU per processor in a way that people will always have WUs available. hopefully we can get something working like this soon. |
Send message Joined: 7 Jun 08 Posts: 464 Credit: 56,639,936 RAC: 0 |
instead of lowering the deadline, we lowered the work queue to be closer to what we really want it to be at. probably not the answer that'll make everyone happy, but it's really the best for what we're trying to do here. Hmmm... Well, unless I'm missing something here or just read your intentions wrong, this sounds like your looking to have your cake and eat too. You need to be low latency due to the given constraints of the project. This means you have to a high tightness factor by setting the short deadline. You also have set a contact session quota, which in essence overrides the user cache setting to further enforce the low latency. So for the folks who run MW only, there never has been a problem other than they can't carry a lot of MW work at one time and the limited outage 'reserve' protection. If your host can meet the deadline, then you're in the game. OK, so what happens for the slower hosts or ones which run a number of projects? Due to the givens above, MW already goes to the head of the line for execution time if needed whenever there is work for it onboard, due to the tightness factor. It also results in it getting to the top of the next work fetch list for the CC fairly quickly due to the session quota. Now you seem to be asking for a way to sidestep the CC's debt system to enforce resource share and always have 'one' in the bullpen so to speak. For low latency projects, the possibility of intermittent work flow for the hosts and limited 'outage' reserve protection is the 'price' you have to pay for the 'privilege' of getting higher execution priority when there is work onboard. So this isn't really a 'problem' for you per se. It's the old users expectations (desires) not being within the bounds of the rules of the game problem. Alinator |
Send message Joined: 30 Aug 07 Posts: 2046 Credit: 26,480 RAC: 0 |
instead of lowering the deadline, we lowered the work queue to be closer to what we really want it to be at. probably not the answer that'll make everyone happy, but it's really the best for what we're trying to do here. AFAIK, the deadline right now is 5 days (at least thats what's being set on the workunit). which should be more than enough time. in fact if a WU takes 5 days to get back to us theres a high probability it wont be very useful at all. While increasing the deadline might be nice for some peoples credit, for the most part it's probably just wasted CPU cycles. |
Send message Joined: 7 Jun 08 Posts: 464 Credit: 56,639,936 RAC: 0 |
Agreed and understood, but that wasn't my point. I am not suggesting you need to increase the deadline, you need to shorten it even if that means you restrict the host population which can participate. The reason is that to ensure low latency, you have to limit the ability of the CC to defer running your work if that is what short term debt says should happen. This is what setting a tight deadline factor does (ratio of runtime to deadline). As Tightness Factor goes to one, the execution priority goes from round robin to 'real time'. If you don't limit to how far that can go with long term debt to compensate for the higher execution priority, thus shutting work fetch down periodically, I don't see how the host can maintain resource share. IOW, if you need to have the work back within a X number of hours or less of issuing it to be useful, then that is what you should set the deadline at. Anything else ends up giving the CC the option to put off running your work if it's local conditions say that is what it has to do to meet the requirements of other work it has on board and the users global and project specific preferences. I took '...always having WU's available.', as having a way to trump LTD and force the the host to take on an MW task (similar to the way suspending all the other projects on a host manually would) automatically, even if LTD says you should not be eligible for a work fetch at that point in time. Alinator |
Send message Joined: 3 Feb 08 Posts: 6 Credit: 6,055,000 RAC: 0 |
It's obvious that the admin's aren't aware of something called dial up internet connections and a 3 day weekend. This new 2 day deadline just killed my active participation with 6 hosts at work as I am gone 2.75 days over the weekend and can't dial up until Monday morn's. Oh well, if the science dictates the shorter deadlines, then I'll accept it and choose another favorite project to crunch. |
Send message Joined: 7 Jun 08 Posts: 464 Credit: 56,639,936 RAC: 0 |
Hmmm... Ahhh... OK, I hadn't passed through the home page to see the announcement of the change in deadline. Since my last work fetch at 05:30 UTC today was still a 5 day deadline I wasn't aware of that. However, that doesn't change the point about 'short circuiting' LTD to keep work in the cache when LTD says it shouldn't be there. Alinator |
Send message Joined: 30 Aug 07 Posts: 2046 Credit: 26,480 RAC: 0 |
It's obvious that the admin's aren't aware of something called dial up internet connections and a 3 day weekend. This new 2 day deadline just killed my active participation with 6 hosts at work as I am gone 2.75 days over the weekend and can't dial up until Monday morn's. what is a "dial up connection"? is that something from like, before the interwebs? just kidding :D how about 2.5 days? that should allow WUs that started sometime on friday to be finished up sometime monday morning and reported? |
Send message Joined: 7 Jun 08 Posts: 464 Credit: 56,639,936 RAC: 0 |
Hmmm... It's been awhile since I played with pushing the deadline envelope on my dialup backup connection, and I know this will be the tightest deadline project I have ever experimented with. My gut feeling says that 2 1/2 days would probably open up the 'window of opportunity' to beat the deadline coming back some, but the conservative 'fudge factors' builtin to BOINC would probably mean a host could still miss the deadline and get shut out of credit by getting beaten by the reissued host. The only thing you might be able to do at your end would be to make sure a reissue goes at the end of the feeder queue. However, you don't carry a very big one, so it's arguable how much help that would be ultimately. I guess it comes down to nothing ventured, nothing gained, so go ahead and give it a shot. ;-) Alinator |
Send message Joined: 3 Feb 08 Posts: 6 Credit: 6,055,000 RAC: 0 |
Friday afternoon to Monday morning is about 2.75 days, that's my story and I'm sticking to it!!! LOL Don't think 2.5 days will quite cut it, remember with dial up it may take an hour on the u/l and d/l with 6 hosts and many wu's. Thanks for the reply, hope 2.75 can be made. |
Send message Joined: 27 Aug 07 Posts: 647 Credit: 27,592,547 RAC: 0 |
Have a look at the front page news... deadline has been increased to 3 days now! :-)) Lovely greetings, Cori |
Send message Joined: 9 Jul 08 Posts: 85 Credit: 44,842,651 RAC: 0 |
I'd honestly say that no matter if it causes problems for SOME volunteers, you need to set this where the SCIENCE needs it set. Modem users can set their computers to auto-dial (at least on every OS that I know of) and the BOINC client already has all the settings built in to accomplish this completely unattended. If this is impossible for some of them, then a low-latency project like this just isn't for them. For office computers that are completely shut down over the weekend... they're going to be shut off at ~5pm on Friday and not come back on until ~9am Monday. That's more than 2.5 days right there and some of them are going to need as much as .5 days AFTER they're turned back on to complete work (admittedly only the stuff that arrived right before they were shut down). Again, this may or may not mean that MW just isn't an appropriate project. I wish I had a good idea how many computers crunching MW are in this situation, but ultimately you're going to have to decide if it's worth losing however many there are or if it's better to get less data that remains closer to the genetic algorithm. [edit]Um... disregard all of that. I type too slow and don't read the front page often enough. ;) If the project can live with 3 days, then I think that should satisfy everyone![/edit] |
©2024 Astroinformatics Group