Message boards :
Number crunching :
Panic Mode On (76) Server Problems?
Message board moderation
Previous · 1 . . . 10 · 11 · 12 · 13 · 14 · 15 · 16 . . . 20 · Next
Author | Message |
---|---|
Speedy Send message Joined: 26 Jun 04 Posts: 1639 Credit: 12,921,799 RAC: 89 |
As I type parts of the SSP are 206 hours behind. [As of 23 Aug 2012 | 8:30:04 UTC] SSP was behind before this weeks outage. How are the As of* times set? |
juan BFP Send message Joined: 16 Mar 07 Posts: 9786 Credit: 572,710,851 RAC: 3,799 |
A .vlar WU would mean x ~ 10.8 longer than a normal AR WU. Wasted performance. I teory thats ok, but when crunching the vlar with Nvidia GPU your entire system turn dificult to use, the cursor flicks, a lot of wierd problems start to apears with the video interface, so you almost loose the host for any other use until this WU is processed, so processing Vlars with NVidia GPU in a non dedicated crunchig host realy is a waste of resources. Lets the vlars running in the CPUS and all others on the GPUs. |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14649 Credit: 200,643,578 RAC: 874 |
I teory thats ok, but when crunching the vlar with Nvidia GPU your entire system turn dificult to use, the cursor flicks, a lot of wierd problems start to apears with the video interface, so you almost loose the host for any other use until this WU is processed, so processing Vlars with NVidia GPU in a non dedicated crunchig host realy is a waste of resources. Lets the vlars running in the CPUS and all others on the GPUs. Exactly. From the project's point of view, they couldn't care less if the tasks run fast or slow. We're probably (collectively) supplying more processing power than they want or need at the moment - provided the work comes back, it's been processed accurately, and it doesn't hang around for too long (i.e. weeks), that'll be fine for them. The screen lag, and not being able to use the machine for anything else, is the big no-no for a volunteer project. If that happens, 99% of volunteers just uninstall BOINC and walk away, cursing. Not only is their resource lost to SETI, it's lost to all the other BOINC projects too - and the person behind the computer is lost to science and scientific research. That's what SETI can't be seen to do. |
Link Send message Joined: 18 Sep 03 Posts: 834 Credit: 1,807,369 RAC: 0 |
From the project's point of view, they couldn't care less if the tasks run fast or slow. Well, project like that would never get me to crunch for them. Such thinking from the project staff was a reason why I didn't join Milkyway earlier (those days when they had highly inefficent applications themselves, didn't except anonymous platform and all the other things they did back than). I want my resources to be used as efficently as possible by the project (hence I use opt apps), if I have more than my main project can use, there are other projects, who are happy to get what's over. |
tullio Send message Joined: 9 Apr 04 Posts: 8797 Credit: 2,930,782 RAC: 1 |
I am crunching both a SETI vlar and a BOINC_VM Virtual Machine from CERN on this CPU, an AMD APU E-450 at 1.67 GHz, which is not a speed champion but uses only 18 W, so it can take the heat wave we have in Italy (33 C now, no AC) while I had to shut down the SUN WS with its fans going full speed. Tullio |
juan BFP Send message Joined: 16 Mar 07 Posts: 9786 Credit: 572,710,851 RAC: 3,799 |
From the project's point of view, they couldn't care less if the tasks run fast or slow. Please don´t missunderstud what I and Richard says, SETI is a project that is spected to runs DECADES before any spected success could be achived (unless of course our little green mens give us a hand), so "fast or slow" is relative to that, the difference from a 12 min WU (GPU) to a 1 1/2 hour (CPU) makes little difference to the 50 Years or maybe more project. Any help is wanted, just don´t need to be worried on that particular point, we are just warning because the video lag could be a serius problem if you need to use a not crunching only host. |
kittyman Send message Joined: 9 Jul 00 Posts: 51468 Credit: 1,018,363,574 RAC: 1,004 |
I think the thing to keep in mind here is that the batch of VLARs sent out to Nvidia GPU hosts was an unintended error, not a change in policy. Several of my best rigs have been crippled in output by the VLARs that have risen to the top of their caches and are now being tackled by the GPUs, although very slowly. Watching my best rig struggle through 2 per GPU on very capable cards is painful to see...LOL. But, the kitties have resigned themselves to letting the rigs work through it, and this too shall pass. I am not seeing any problems in the way of errors, just painfully slow processing. "Freedom is just Chaos, with better lighting." Alan Dean Foster |
juan BFP Send message Joined: 16 Mar 07 Posts: 9786 Credit: 572,710,851 RAC: 3,799 |
I agree with you Mark, this was an unintended error and is fixed now. For now... "Vlars to NVidia GPUs - Never Again"... unless someone find a way to bypass the problem with maybe some black magic... A task for our Master Guru Jason and his team... |
Link Send message Joined: 18 Sep 03 Posts: 834 Credit: 1,807,369 RAC: 0 |
Please don´t missunderstud what I and Richard says, SETI is a project that is spected to runs DECADES before any spected success could be achived (unless of course our little green mens give us a hand), so "fast or slow" is relative to that, the difference from a 12 min WU (GPU) to a 1 1/2 hour (CPU) makes little difference to the 50 Years or maybe more project. I wasn't talking about the progress of SETI@Home, as Richard pointed out we donate more resources to them than they can use ATM, I was talking about efficient usage of our resources by all projects and SETI is one, that can easily use nVidia GPUs more efficiently by not assigning VLAR tasks to them. The more the project care about efficient usage of our resources, the more science we get done, not necessarily for SETI (since they just can't send out more WUs than they are already doing now) but for other projects out there. |
bill Send message Joined: 16 Jun 99 Posts: 861 Credit: 29,352,955 RAC: 0 |
A .vlar WU would mean x ~ 10.8 longer than a normal AR WU. Wasted performance. |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14649 Credit: 200,643,578 RAC: 874 |
Please don´t missunderstud what I and Richard says, SETI is a project that is spected to runs DECADES before any spected success could be achived (unless of course our little green mens give us a hand), so "fast or slow" is relative to that, the difference from a 12 min WU (GPU) to a 1 1/2 hour (CPU) makes little difference to the 50 Years or maybe more project. I don't think we're disagreeing here. Fortunately, not sending VLARs to NVidia is a win-win problem. The solution satisfies both the efficiency and the volunteer satisfaction criteria. I was merely saying that, from the project's point of view, not alienating volunteers is the stronger argument. I don't think we'd have got the "don't send" solution coded in the first place, if we'd had to argue on the efficiency criterion alone. |
kittyman Send message Joined: 9 Jul 00 Posts: 51468 Credit: 1,018,363,574 RAC: 1,004 |
Please don´t missunderstud what I and Richard says, SETI is a project that is spected to runs DECADES before any spected success could be achived (unless of course our little green mens give us a hand), so "fast or slow" is relative to that, the difference from a 12 min WU (GPU) to a 1 1/2 hour (CPU) makes little difference to the 50 Years or maybe more project. Well, if you recall back then, there were also 'VLAR killer' opti apps that would just toss them back to the servers. Thus increasing the server load with no additional work being done. The kitties never agreed with this and looked on those apps as 'cherry picking' at the time. I think the present solution of not sending VLARs to hosts that cannot as effectively process them ended up being win-win for both the users and the project. "Freedom is just Chaos, with better lighting." Alan Dean Foster |
Link Send message Joined: 18 Sep 03 Posts: 834 Credit: 1,807,369 RAC: 0 |
Sure, a GPU doing a VLAR might be better than an idle GPU (depending from your point of view), The GPU does not need to be idle, it's just a matter of BOINC configuration: large enough cache and if that does not help backup project (probably necessary anyway with the current load on S@H's internet connection). Your idle GPU issue is something that the user can fix. Also such GPU might do more for the project if it's idle for a while and than gets again suitable WUs to work on. Blocking it for hours or even days with a bunch of VLARs might indeed lead to less job done at the end of the day/month/year/whatever. So yes, an idle GPU for a while might be better unless the servers would send just 1 VLAR in case they have nothing else and the GPU is idle. |
Grant (SSSF) Send message Joined: 19 Aug 99 Posts: 13720 Credit: 208,696,464 RAC: 304 |
I've been getting a lot of "No tasks sent" messages lately, and haven't been able to get any work for about an hour and a half. Grant Darwin NT |
kittyman Send message Joined: 9 Jul 00 Posts: 51468 Credit: 1,018,363,574 RAC: 1,004 |
I believe a shorty storm may be keeping the feeder rather dry. Lots of other comments about not getting work lately. "Freedom is just Chaos, with better lighting." Alan Dean Foster |
Claggy Send message Joined: 5 Jul 99 Posts: 4654 Credit: 47,537,079 RAC: 4 |
Lots of VLARs out there (as in there are tasks that can't be sent to my Nvidia GPU, but can be sent to my CPU if i choose to accept them): 23/08/2012 18:36:45 | SETI@home | [sched_op] Starting scheduler request After about another 5 requests, i did get 58 Cuda tasks. Claggy |
Link Send message Joined: 18 Sep 03 Posts: 834 Credit: 1,807,369 RAC: 0 |
I don't think we're disagreeing here. Fortunately, not sending VLARs to NVidia is a win-win problem. The solution satisfies both the efficiency and the volunteer satisfaction criteria. Sure, fixing issues like unusable systems or even driver crashes are more important than efficiency, however I think efficiency is one of the volunteer satisfaction criteria. Just think about all the complaints about falling RAC caused by pendings which led alredy to several discussions about shorter deadlines. And there is nothing lost, the credit is just awarded little later. So complaints about GPUs doing just a small fraction of what they are capable to do would happen probably more often and I'm pretty sure many would leave the project because of that. |
bill Send message Joined: 16 Jun 99 Posts: 861 Credit: 29,352,955 RAC: 0 |
Sure, a GPU doing a VLAR might be better than an idle GPU (depending from your point of view), You do realize you just contradicted yourself? Reread your last line. I don't care how others run their pc, so long as they are not aborting work that does not does not cause errors. Just because it takes longer is not an excuse to off load work units onto other people. That's cherry picking. |
Josef W. Segur Send message Joined: 30 Oct 99 Posts: 4504 Credit: 1,414,761 RAC: 0 |
Every time VLARs are discussed I remember The Attack of the Killer 58.7s. In that late 2006 time frame with only CPU crunching and coarser chirp resolution, that was the granted credit rate for VLARs. Conceptually, assigning work in a manner such that each host is most productive is obviously desirable. The .vlar exclusion for CUDA does align with that and is definitely needed as long as the 6.08 and 6.09 stock applications are in use on older CUDA cards. My impression is that when SETI@home v7 is released here, both CUDA and NV OpenCL implementations should be capable of doing VLARS without excessive screen lags, etc., and with less time penalty. An adjustment of the basic splitter estimate could be used to better balance credit grants. The fact remains that VLAR tasks are harder to divide into small enough parts to take full advantage of the parallel nature of GPU crunching. Newer GPUs do have the capability to be subdivided so that only part of the GPU would be working on the least divisible parts of the task, but that's another layer of software complexity and there would be issues with validation on result_overflow tasks. That brings this discussion back toward the "Server problems" subject area. Joe |
shizaru Send message Joined: 14 Jun 04 Posts: 1130 Credit: 1,967,904 RAC: 0 |
Please don´t missunderstud what I and Richard says, SETI is a project that is spected to runs DECADES before any spected success could be achived (unless of course our little green mens give us a hand), so "fast or slow" is relative to that, the difference from a 12 min WU (GPU) to a 1 1/2 hour (CPU) makes little difference to the 50 Years or maybe more project. And when we (or our children, or our chilren's children) DO find the elusive little fraks, I'm sure the project will have all the funding and support it needs to last another 500 years. You know, so we can find the next race, and then the next one, and then the next one... :) |
©2024 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.