Index  | Recent Threads  | Unanswered Threads  | Who's Active  | Guidelines  | Search
 

Quick Go »
No member browsing this thread
Thread Status: Active
Total posts in this thread: 18
Posts: 18   Pages: 2   [ 1 2 | Next Page ]
[ Jump to Last Post ]
Post new Thread
Author
Previous Thread This topic has been viewed 2928 times and has 17 replies Next Thread
NixChix
Veteran Cruncher
United States
Joined: Apr 29, 2007
Post Count: 1187
Status: Offline
Project Badges:
Reply to this Post  Reply with Quote 
35 WU Limit too Small

The 35 WU per core limit is much too small. I have moved into OET while still trying to finish out FAAH. 35 WUs on my old machine is just 6 hours of crunching OET at 15 min/WU. It is probably only a few minutes with one of the newer more powerful crunchers. This is taking all the enjoyment out of crunching! I don't have time to touch the computer every 6 hours. I am very upset with this. Why was something was wasn't broke changed to make it unusable?

Cheers coffee
----------------------------------------

[Jun 18, 2015 6:20:23 AM]   Link   Report threatening or abusive post: please login first  Go to top 
Former Member
Cruncher
Joined: May 22, 2018
Post Count: 0
Status: Offline
Reply to this Post  Reply with Quote 
Re: 35 WU Limit too Small

"I don't have time to touch the computer every 6 hours."

Can you explain this bit. Don't have to 'touch' anything, it's either the max In Progress allowed or the buffer size setting in days, which ever is smaller, the client requesting backfilling whenever there's a gap.

edit: To underscore, the 35 active core is an overall limit, not per science at WCG. While not being adverse to a higher number, there's greater reluctance [over caching and panic mode kick-in risks] due the variability of the run-times. This is a reason why WCG already locked the Duration Correction Factor to a 1.0 to prevent clients recalculating actual TTC's based on latest completed, the servers taking care of assigning a most recent -average- runtime on latest returned work [which has a lapse time of X].

Last adjustment was in February from 25 to 35: https://secure.worldcommunitygrid.org/forums/wcg/viewpostinthread?post=484358
----------------------------------------
[Edit 1 times, last edit by Former Member at Jun 18, 2015 8:32:59 AM]
[Jun 18, 2015 7:02:45 AM]   Link   Report threatening or abusive post: please login first  Go to top 
KLiK
Master Cruncher
Croatia
Joined: Nov 13, 2006
Post Count: 3108
Status: Offline
Project Badges:
Reply to this Post  Reply with Quote 
Re: 35 WU Limit too Small

sellect other projects also...WCG is Umbrella project, so it will always try to force users to crunch other DATA also!

d minimum is 2 projects selected...
btw, mine computers works just fine with OET & UGM projects selected...crunching only that NOW! wink
----------------------------------------
oldies:UDgrid.org & PS3 Life@home


non-profit org. Play4Life in Zagreb, Croatia
[Jun 18, 2015 8:18:01 AM]   Link   Report threatening or abusive post: please login first  Go to top 
NixChix
Veteran Cruncher
United States
Joined: Apr 29, 2007
Post Count: 1187
Status: Offline
Project Badges:
Reply to this Post  Reply with Quote 
Re: 35 WU Limit too Small

"I don't have time to touch the computer every 6 hours."

Can you explain this bit. Don't have to 'touch' anything, it's either the max In Progress allowed or the buffer size setting in days, which ever is smaller, the client requesting backfilling whenever there's a gap.
Rob,
At the moment I'm trying to "babysit" my little crunch farm to catch enough FAAH resends to make it to 5 years. I didn't give up when the end was announced because I thought I could make it. The SOP for that used to be to queue up a day or 2 of other work and then reset preferences for FAAH. That doesn't work when a 35-WU limit is just 6 hours of OET work. (Someone I know didn't appreciate that limit either and found a work-around to queue up lots of FAAH before the end) That is the reason why I said I needed to "touch" the computer every 6 hours.

If, as you wrote in your reply, the server "knows" the runtime of a WU based on my recent returned work, then it is possible to limit my queue based on expected duration rather than an arbitrary cap of 35. 35 WUs could be anywhere between , which could vary between 6 hours and 1 month! If work is being sent with a 9-day deadline, then I should be able to queue up 9 days of work, right (though I never went above 5 days).

One way I could get around this is to *forgo* my exclusive relationship with WCG and crunch for another project as well. Is that what WCG wants me to do? I am certainly interpreting this decision as sending that message. I have always tried to play by WCG's rules and this is a real insult to me. I searched the forums and couldn't find any explanation from WCG or discussion (this is a community) of the merits first.

Cheers coffee
----------------------------------------

[Jun 18, 2015 6:53:23 PM]   Link   Report threatening or abusive post: please login first  Go to top 
Former Member
Cruncher
Joined: May 22, 2018
Post Count: 0
Status: Offline
Reply to this Post  Reply with Quote 
Re: 35 WU Limit too Small

This goes back to decision making during HCMD2, when runtime fluxed from minutes to 12 hours [IIRC the hard cap cut-off] in a mixed stream. Posts would be by knreed or uplinger. The -average- computed has a lapse time, don't know how much, so that time is often still running behind the facts. Client 7 got the </don't use dcf> tag listen function that <=v6 doesn't, mitigating the issue. All in all, it's really up to WCG when they want all or part of volunteer's resource share, but having no cap and pulling N days at 2 minutes a pop which then proof to be 6 hours, seriously upset the distribution system, the clients, the batch completion... an endless stream of overdue and panic mode and server hammering for more... sort of the picture I have with what is/was happening.

The 10 days deadline was more with the [very] part-time [few hours a day/week] in mind. It's no suggestion that buffering 10 days is OK. It -WAS- a hard limit code in the client, not a must "I can so I will". Just my interpretation [and as you know used the trick box too, because I knew how to do, until it becomes too popular and gets killed in the next client].
----------------------------------------
[Edit 1 times, last edit by Former Member at Jun 18, 2015 8:10:28 PM]
[Jun 18, 2015 7:21:20 PM]   Link   Report threatening or abusive post: please login first  Go to top 
NixChix
Veteran Cruncher
United States
Joined: Apr 29, 2007
Post Count: 1187
Status: Offline
Project Badges:
Reply to this Post  Reply with Quote 
Re: 35 WU Limit too Small

I don't blame you, but one shouldn't have to reach into a bag of tricks to get serious work done. I would have tried something like that had I realized that I was so close to not making 5 years on FAAH. If I had been able to fill up my queue to more than 1 day of FAAH work, I might have gotten enough to finish out 5 years before the work steam dried up. I didn't notice this 35-day limit until that time. It hadn't caused me a problem until then. I had likely done "babysittin'", but the workunits weren't so small as to run into the limit.

Cheers coffee
----------------------------------------

----------------------------------------
[Edit 1 times, last edit by NixChix at Jun 19, 2015 6:02:19 PM]
[Jun 18, 2015 9:22:36 PM]   Link   Report threatening or abusive post: please login first  Go to top 
Eric_Kaiser
Veteran Cruncher
Germany (Hessen)
Joined: May 7, 2013
Post Count: 1047
Status: Offline
Project Badges:
Reply to this Post  Reply with Quote 
Re: 35 WU Limit too Small

I wonder that 35 wu for oet is only 6 hours.
The limit is 35 wu per core. I assume that oet has same runtimes as fah (~30 minutes/wu. In my case: i7-3930@3.2GHz or i7-980x@3.3GHz). That results in >17 hrs per core.
----------------------------------------

----------------------------------------
[Edit 1 times, last edit by Eric_Kaiser at Jun 19, 2015 6:57:29 AM]
[Jun 19, 2015 6:55:35 AM]   Link   Report threatening or abusive post: please login first  Go to top 
pcwr
Ace Cruncher
England
Joined: Sep 17, 2005
Post Count: 10903
Status: Offline
Project Badges:
Reply to this Post  Reply with Quote 
Re: 35 WU Limit too Small

The way round it, as I'm sure you know, would be select FAAH and CEP2. CEP2 is there to keep the computer ticking over while asking for more FAAH WUs to fill the spare cache.

Patrick
----------------------------------------

[Jun 19, 2015 6:58:08 AM]   Link   Report threatening or abusive post: please login first  Go to top 
NixChix
Veteran Cruncher
United States
Joined: Apr 29, 2007
Post Count: 1187
Status: Offline
Project Badges:
Reply to this Post  Reply with Quote 
Re: 35 WU Limit too Small

I wonder that 35 wu for oet is only 6 hours.
The limit is 35 wu per core. I assume that oet has same runtimes as fah (~30 minutes/wu. In my case: i7-3930@3.2GHz or i7-980x@3.3GHz). That results in >17 hrs per core.

I am getting much shorter run times than FAAH. I was getting 1.5 hour jobs on FAAH. Now my queue adds up to 24 hours (via BOINCtasks) for a 4-core cruncher on OET; 6 hours per core. They are between 10 and 15 minutes duration.

Cheers coffee
----------------------------------------

[Jun 19, 2015 5:50:01 PM]   Link   Report threatening or abusive post: please login first  Go to top 
NixChix
Veteran Cruncher
United States
Joined: Apr 29, 2007
Post Count: 1187
Status: Offline
Project Badges:
Reply to this Post  Reply with Quote 
Re: 35 WU Limit too Small

The way round it, as I'm sure you know, would be select FAAH and CEP2. CEP2 is there to keep the computer ticking over while asking for more FAAH WUs to fill the spare cache.

Patrick

Good idea Patrick. However I am quite done with CEP2. It caused havoc on my crunchers. I would only go back to the CEP2 project only if I have crunched 5 years for all other active projects.


Cheers coffee
----------------------------------------

[Jun 19, 2015 5:56:46 PM]   Link   Report threatening or abusive post: please login first  Go to top 
Posts: 18   Pages: 2   [ 1 2 | Next Page ]
[ Jump to Last Post ]
Post new Thread