Limits |
![]() |
| log in |
Message boards : Number crunching : Limits
Previous · 1 · 2
| Author | Message |
|---|---|
So is this 100 WU limit per a computer or per an account? Yes, but note that it's a limit on tasks in progress. If you report 5 completions, you can get 5 new tasks to replace them. Most of the highly productive hosts are in that mode. It's not fair that the limits are really only affecting the top 8000 or so hosts, of course. Joe | |
| ID: 1316239 · | |
So is this 100 WU limit per a computer or per an account? Unless you consider the top 8000 hosts are the problem. Well probably only the top 1000. At least that's what Eric's explanation sounds like, large queues, fast crunchers, especially during a shorty event. My modest cruncher is currently in the 4500-5000 range of hosts, depending if you look at RAC or credits per month. I use to have a 6 day cache, the current limits are now about 3 1/2 days so it's not someone like me who's affected during downtime Tuesdays. Looking at the fastest, by RAC, host out there I see it's fetching 12-14 GPU units every five minutes. That puts it's GPU unit processing rate at over 4000 per day. A 1000 unit limit would still mean less than 3 hours of cache for that system. Now the devs can't affect the number of waiting for validation results in everyone's host's results table other than driving the cache size down. They can't affect the valid results because that's mainly governed by the speed of the cruncher. They can affect the number pending as that is set by cache size. So they are taking the only measures they can to reduce everyone's host table size. Now when I look at my pending list, eliminating those who look to have joined for a week never to return, I'm still seeing a number of wingmen who still have thousands of units queued up but seemingly forgotten about. But they are examples of people who let their crunchers queue a metric ton of units but when there's a problem at their end, they end up clogging up their wingmen's waiting for validation queue. The smaller the queue, the less people they screw. Give it a little longer to shake out these forever waiting for validation units to flush out and then look at bumping the numbers up, slowly and waiting a week or two to see how it's shaping up and then upping it again, etc. because when it goes bad, it goes bad for everyone, not just the top crunchers. ____________ "Life is just nature's way of keeping meat fresh." - The Doctor | |
| ID: 1316258 · | |
|
| |
| ID: 1316346 · | |
I wish that was true. My two oldest pending currently have a wingman (2nd wingman), whose host has a RAC in the 40,000-50,000 range but 1600 units dated between Oct 27th and Nov 4th that's been "forgotten". So those two units will be pending through a 3rd wingman starting the day after Mayan doomsday. And when I bother to look at my units old waiting for my wingman that are over 30 days old, I frequently see exactly the same thing, a host with 1000s of units "forgotten". Or have hundreds of errors. Or hundreds of false overflows so I'm stuck in inconclusive-ville. These are cluttering everyone's list of units assigned to each host and are not affected by the performance of the host or its desired queue size (or queue size as currently dictated). Currently 1/3rd of my units waiting for a wingman are over 30 days old. The current limits at least limit the damage caused by hosts having "technical difficulties", clogging the pipes to the point the scheduler hiccups. ____________ "Life is just nature's way of keeping meat fresh." - The Doctor | |
| ID: 1316392 · | |
So is this 100 WU limit per a computer or per an account? I had an idea a while back how a weighted task value, based on the AR, could help prevent overloading a machine when it had nothing but VLAR tasks to work with in its queue. That would probably add even more complexity to the client. So probably not the best idea. However a weighted value tracked on the server end might be a easier solution to making the workunits larger. To prevent very fast machines from acquiring a large number of tasks when VHAR's are being generated a predetermined value could be applied to a task which would be applied towards that task limit of the machine. I was thinking something along the lines of a 1/x, but it might want to be centered on the "normal" AR. So .42/x might work better, but I don't know if a task with an AR of .03 should count as 14. ____________ SETI@home classic workunits: 93,865 CPU time: 863,447 hours Join the BP6/VP6 User Group today! | |
| ID: 1316427 · | |
|
If the limits are still on, how come this happens. | |
| ID: 1320211 · | |
If the limits are still on, how come this happens. Dunno, but I wish I could get it to happen here. ____________ ****** "Ask not, what your kitty can do for you. Ask what you can do for your kitty." As it is kitten, so shall it be done. | |
| ID: 1320217 · | |
If the limits are still on, how come this happens. BOINC version 6.6.28 Claggy | |
| ID: 1320220 · | |
If the limits are still on, how come this happens. Thanks | |
| ID: 1320221 · | |
If the limits are still on, how come this happens. You have a lotta company in that regard Mark. ____________ BSG Anthem My Facebook page | |
| ID: 1320223 · | |
|
Well one interesting side effect of the 100 unit limit per device on MB is that it makes it relatively simple to calculate your process rate, assuming your rig is set to run 24/7. | |
| ID: 1320703 · | |
Message boards : Number crunching : Limits
| Copyright © 2013 University of California |