Message boards :
Number crunching :
About Deadlines or Database reduction proposals
Message board moderation
Previous · 1 . . . 8 · 9 · 10 · 11 · 12 · 13 · 14 . . . 16 · Next
Author | Message |
---|---|
W-K 666 ![]() Send message Joined: 18 May 99 Posts: 19490 Credit: 40,757,560 RAC: 67 ![]() ![]() |
I'm going to say, I believe the terminology used on the Server Staus page is correct, and therefore must reject your theory. Couldn't agree more, but in this case, without confirmation, one way or the other, by person(s) I can trust, I couldn't say I know that the terminology on the SS screen is correct. It is not the validators that are the problem. it is the ~800 tasks that have been validated before 18:00 29th Feb, 24 hours ago, but not yet purged, which normally happens. https://setiathome.berkeley.edu/results.php?userid=8083616&offset=220&show_names=0&state=4&appid=29, therefore my assumption is that there is a blockage between Validation and the end of the purging process. |
juan BFP ![]() ![]() ![]() ![]() Send message Joined: 16 Mar 07 Posts: 9786 Credit: 572,710,851 RAC: 3,799 ![]() ![]() |
If you are not worried about RAC then get rid of those excess ~10000 tasks and live with the 150 tasks per GPU. Why? If my host crunch all of them in less than 1.5 days? Give me a valid reason, not just because you not like that! But as i posted before: RAC is totally out of topic! Please respect that! This thread is About Deadlines or Database reduction proposals You and anybody could start your own thread about RAC. ![]() |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 ![]() ![]() |
Actually, your Host is showing a Turnaround time of over a Day, Average turnaround time: 1.22 days Testing has shown any Task over the Daily production just adds Bloat to the Database, increases the turnaround time, and basically doesn't help matters. It would be best if Everyone lowered their cache to a Day or lower. If the cache is Lower than a Day it doesn't matter if the Cache is small or large, the machine will produce the same amount of work with either, and that is the number which effects the Database. My suggestion to expedite the clear of this WU's is to send them only to the top 100 hosts (or whatever number needed to manage this retries) with the lowest possible APR with a very small dateline (lees than a week, maybe 3-5 days only). They will clear that very fast an squeeze the db. This hosts are very stable but of course some could crash, the WU still could not been validated after the new crunch (non canonical result), etc. In this case the small dateline will make the WU been send to another fast host to rinse & retry. |
Richard Haselgrove ![]() Send message Joined: 4 Jul 99 Posts: 14687 Credit: 200,643,578 RAC: 874 ![]() ![]() |
Actually, your Host is showing a Turnaround time of over a Day, Average turnaround time: 1.22 daysAnd the average turnround time for the project as a whole (MB v8 tasks, on SSP) is 30.46 hours, or 1.269 days. He's pretty much on the button for reporting at the same time as the average wingmate, which is the most efficient of all. |
juan BFP ![]() ![]() ![]() ![]() Send message Joined: 16 Mar 07 Posts: 9786 Credit: 572,710,851 RAC: 3,799 ![]() ![]() |
Actually, your Host is showing a Turnaround time of over a Day, Average turnaround time: 1.22 daysAnd the average turnround time for the project as a whole (MB v8 tasks, on SSP) is 30.46 hours, or 1.269 days. He's pretty much on the button for reporting at the same time as the average wingmate, which is the most efficient of all. Thanks Richard for that info. If i understand that correct i'm fine with my settings. ![]() |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 ![]() ![]() |
Yes, and if everyone lowered their cache to a Day, the Turnaround Time would probably drop significantly. I'd guess most people out there have their cache set a 10 days. Imagine if they All dropped it to a Day... |
Richard Haselgrove ![]() Send message Joined: 4 Jul 99 Posts: 14687 Credit: 200,643,578 RAC: 874 ![]() ![]() |
Yes. If you spot any host in the database with a 10 day average turnround, please let us know. I'll start the ball rolling with host 8873865 (average turnround 62.14 days) - that's gone up from 53.85 days when I first saw it. |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 ![]() ![]() |
Strawman.... I was referring to Cache size, Not Turnaround Time. Although lowering the Cache size usually lowers the Turnaround time. |
![]() ![]() ![]() Send message Joined: 29 Apr 01 Posts: 13164 Credit: 1,160,866,277 RAC: 1,873 ![]() ![]() |
So we should start a new thread titled "Hosts with excessive cache settings" or something like we have for the "Invalid Host Messaging" thread and begin a PM campaign to contact those hosts to reduce their cache settings to one day. Correct? Seti@Home classic workunits:20,676 CPU time:74,226 hours ![]() ![]() A proud member of the OFA (Old Farts Association) |
juan BFP ![]() ![]() ![]() ![]() Send message Joined: 16 Mar 07 Posts: 9786 Credit: 572,710,851 RAC: 3,799 ![]() ![]() |
This WU is a perfect example why the deadline must be reduced: https://setiathome.berkeley.edu/workunit.php?wuid=3808664962 It's from Dec 27 and the deadline is 4 Mar and the second host not respond any valid WU, so it will need to be resent. The wingmen host never return a valid WU all his WU ends on Timed out - no response. So it's stay for almost 3 months on the DB. ![]() |
Kevin Olley Send message Joined: 3 Aug 99 Posts: 906 Credit: 261,085,289 RAC: 572 ![]() ![]() |
I got one like that https://setiathome.berkeley.edu/workunit.php?wuid=3715153965 Crunched it 29th Oct it will roll over again on 17th Mar Got 20+ from Dec Kevin ![]() ![]() ![]() |
juan BFP ![]() ![]() ![]() ![]() Send message Joined: 16 Mar 07 Posts: 9786 Credit: 572,710,851 RAC: 3,799 ![]() ![]() |
I got one like that An that is even worst... the new wingmen host also ends on time outs. ![]() |
Kevin Olley Send message Joined: 3 Aug 99 Posts: 906 Credit: 261,085,289 RAC: 572 ![]() ![]() |
Looking at the tail end of our pendings is not a pretty sight:-( Kevin ![]() ![]() ![]() |
W-K 666 ![]() Send message Joined: 18 May 99 Posts: 19490 Credit: 40,757,560 RAC: 67 ![]() ![]() |
This one is from 24th Dec, https://setiathome.berkeley.edu/workunit.php?wuid=3804671429, the first wingman timed out on the 15th Feb. Was then sent out to the 3rd computer, with new deadline of 8th April, but it looks like the last contact was when it downloaded the task. Lets hope wingman #4 can complete it rapidly. |
rob smith ![]() ![]() ![]() Send message Joined: 7 Mar 03 Posts: 22666 Credit: 416,307,556 RAC: 380 ![]() ![]() |
No it is NOT, I've just gone through ALL the tasks on my cruncher, only 5 have been resent as a result of time-outs, but something around 140 are the results (that is on ~2700 tasks total of in-work, pending, inconclusive and valid. As I said earlier the solution is to get rid of the backlog, and that CANNOT be done by sending out more tasks, but by clearing the not inconsiderable backlog of tasks. Then VERY SLOWLY start to allow users to have new tasks, and for EVERY user to live within the allowances set. Bob Smith Member of Seti PIPPS (Pluto is a Planet Protest Society) Somewhere in the (un)known Universe? |
juan BFP ![]() ![]() ![]() ![]() Send message Joined: 16 Mar 07 Posts: 9786 Credit: 572,710,851 RAC: 3,799 ![]() ![]() |
Looking at the tail end of our pendings is not a pretty sight:-( My pendings are in the range of 6900 WU, about 15% are in this category "scary WU". That is why i believe if they reduce the deadline will reduce the DB size by at least 10%. ![]() |
Kevin Olley Send message Joined: 3 Aug 99 Posts: 906 Credit: 261,085,289 RAC: 572 ![]() ![]() |
|
Darrell Wilcox ![]() Send message Joined: 11 Nov 99 Posts: 303 Credit: 180,954,940 RAC: 118 ![]() ![]() |
Suggestion for NOW: Reduce the number of tasks per CPU being sent. This is EASY and FAST to do by the SETI stafff by changing the <max_wus_in_progress>. I suggest maybe 10 to start. Reduce the number of tasks per GPU being sent also. This is EASY and FAST to do by the SETI stafff by changing the <max_wus_in_progress_gpu>. I suggest 100 to start. BEFORE the stones and arrows start flying, this is a temporary change suggested. It does NOT require a longer term software change to implement some of the other suggestions, and it doesn't require a fund raiser, purchase, install, transition for a bigger, faster server. It is FAST and EASY, and can be done TODAY for the maintenance outage tomorrow, since it does require a restart of the software (not a reboot). <analogy> Right now we have 13 or 14 seats on our 20 seat bus being occupied by people who won't get off. We are still able to use the remaining 6 or 7 seats until we can get them off, one by one, as their bus passes expire. And no one is being left behind, not even granny who can barely walk up the bus ramp (and who also pays taxes to support the Metro). </analogy> |
Grant (SSSF) Send message Joined: 19 Aug 99 Posts: 13884 Credit: 208,696,464 RAC: 304 ![]() ![]() |
Suggestion for NOW:And will be of no benefit in reducing the database size in any significant or meaning full way, so why even do it? The problem is the Results returned and awaiting validation number, not the Work in progress number. Why fiddle with something that isn't going to have any effect on the actual problem??? Grant Darwin NT |
Grant (SSSF) Send message Joined: 19 Aug 99 Posts: 13884 Credit: 208,696,464 RAC: 304 ![]() ![]() |
I'm going to say, I believe the terminology used on the Server Staus page is correct, and therefore must reject your theory.What i posted isn't a theory, it's a statement of facts as they presently stand. If you wish to contribute anything of value to this discussion, you need to understand what the problem is, and how it came about. And that requires understanding what is being discussed, which means understanding what the terms mean & apply to. Since you chose to ignore the facts, then any input you continue to provide on this subject will not be of any relevance or use. Grant Darwin NT |
©2025 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.