Message boards :
Technical News :
VLAR change
Message board moderation
Previous · 1 · 2 · 3 · Next
Author | Message |
---|---|
perryjay Send message Joined: 20 Aug 02 Posts: 3377 Credit: 20,676,751 RAC: 0 |
Current I can't post some examples of my E7600, because the new Cr.-System isn't finished balanced. Basically, all they are doing is making the rescheduler and the VLARKiller program obsolete. All the VLARs will come out of the box as 6.03s no adjustments necessary. The best thing about this I can see is that you won't have to worry about messing up your DCF by transferring VLARs from the GPU to the CPU and vice versa. PROUD MEMBER OF Team Starfire World BOINC |
Geek@Play Send message Joined: 31 Jul 01 Posts: 2467 Credit: 86,146,931 RAC: 0 |
I see this as a plus for everybody. Those crunchers without GPU's will continue on as before. No change. Those crunchers with GPU's don't have to worry about the VLAR wu anymore. They will be assigned to the CPU by the Berkeley server. No more rescheduler required and no more killer apps required. (killer apps can still run but they won't be getting anything to kill) Boinc is left to assign work without the confusion of reassigned work by the crunchers. VLAR work is assigned to and done by the CPU without user intervention. Boinc....Boinc....Boinc....Boinc.... |
James Sotherden Send message Joined: 16 May 99 Posts: 10436 Credit: 110,373,059 RAC: 54 |
Its a win win. The first 3 day outage I was running VLARkill. Could not fill up the cache . The second 3 day outage I had installed the no kill version. Quess what I got allmost all VLAR on my GPU. Couldnt fill my GPU up for 3 days. Maybe Goldilocks has finally found the right porridge? :) [/quote] Old James |
Geek@Play Send message Joined: 31 Jul 01 Posts: 2467 Credit: 86,146,931 RAC: 0 |
I wish they would bring this change online tomorrow! Boinc....Boinc....Boinc....Boinc.... |
Miep Send message Joined: 23 Jul 99 Posts: 2412 Credit: 351,996 RAC: 0 |
I wish they would bring this change online tomorrow! What and have all the complaints over 'not properly tested at Beta' all over again? No thanks. Rather give them an extra week for testing purposes. Carola ------- I'm multilingual - I can misunderstand people in several languages! |
Link Send message Joined: 18 Sep 03 Posts: 834 Credit: 1,807,369 RAC: 0 |
Actually after my calculations VLARs are the best paid WUs on CPU. Here example for my AthlonXP 2000+: Well, the credit you get for the WU tells how much science you actually did (or at least it should). So by comparing how many seconds you need on different ARs for 1 Cr you simply find out, on which of them your CPU or GPU is most effective. As I have only CPUs the numbers are posted are not helping me with moving WUs between CPU and GPU, I just had them still from the time I was testing which SEE opt app is best for this CPU. But I also can tell from them, that if this change will lead to more VLARs for this machine (by decreasing the probability of getting the other ARs), that's only good, because it be crunching what it's most effective on (while the GPUs be crunching what they are most effective on). |
Jeff Cobb Send message Joined: 1 Mar 99 Posts: 122 Credit: 40,367 RAC: 0 |
The changes are up and running in beta. If anyone here runs in the beta project, now would be a great time to do so. Beta is getting very little traffic and the moment. Thanks. |
Claggy Send message Joined: 5 Jul 99 Posts: 4654 Credit: 47,537,079 RAC: 4 |
The changes are up and running in beta. If anyone here runs in the beta project, now would be a great time to do so. Beta is getting very little traffic and the moment. Thanks. It would help if we could connect, isn't Seti Beta down for the outage, the same as Seti Main? 15/07/2010 19:14:37 SETI@home Beta Test update requested by user 15/07/2010 19:14:38 SETI@home Beta Test [sched_op_debug] Starting scheduler request 15/07/2010 19:14:38 SETI@home Beta Test Sending scheduler request: Requested by user. 15/07/2010 19:14:38 SETI@home Beta Test Requesting new tasks for GPU 15/07/2010 19:14:38 SETI@home Beta Test [sched_op_debug] CPU work request: 0.00 seconds; 0.00 CPUs 15/07/2010 19:14:38 SETI@home Beta Test [sched_op_debug] NVIDIA GPU work request: 0.00 seconds; 0.00 GPUs 15/07/2010 19:14:38 SETI@home Beta Test [sched_op_debug] ATI GPU work request: 518400.86 seconds; 1.00 GPUs 15/07/2010 19:14:54 Project communication failed: attempting access to reference site 15/07/2010 19:14:54 SETI@home Beta Test Scheduler request failed: Couldn't connect to server 15/07/2010 19:14:54 SETI@home Beta Test [sched_op_debug] Deferring communication for 2 min 7 sec 15/07/2010 19:14:54 SETI@home Beta Test [sched_op_debug] Reason: Scheduler request failed 15/07/2010 19:14:56 Internet access OK - project servers may be temporarily down. Claggy |
Josef W. Segur Send message Joined: 30 Oct 99 Posts: 4504 Credit: 1,414,761 RAC: 0 |
Of course, this change will mean that we non-GPUers' will suffer, won't it? The credit for VLAR under CreditNew will generally be close to the credit for ~0.43 angle range tasks. Depending on CPU type and memory bandwidth, some hosts will be faster or slower at one than the other, simply look at some of the individual host time vs. AR distributions in Estimates and Deadlines revisited. As to the effect of CUDA getting more of the midrange and VHAR, I agree that will happen to some extent. For the big-picture view, say CUDAs are getting 20% of all tasks and that there are about equal numbers of L (VLAR), M (midrange), and H (VHAR) tasks. CUDAs would get 30% of the M and H tasks, CPUs would get 70% of the M and H tasks, 100% of the L tasks. Assuming all the work all hosts need to fill their caches for the next outage can be delivered, that may be a reasonable approximation. But if work delivery can't get all caches filled, the way mb_splitters work and the way Arecibo observing time is allocated may modify the distribution. The "tapes" often consist of very similar work since they represent about 1.5 hours of observing time and the telescope time is given out in largish chunks to minimize reconfiguring for the next observations, etc. The splitters have a very bursty delivery of new tasks. Basically the splitter has to load 256M samples (with radar removal while loading), convert those samples to a 2GB array of complex floating point values, perform forward and reverse FFTs on the array, then reconvert to a 2 bit value for each sample. After that packing into 256 WUs with headers is quick, so happens in a burst. Then the Transitioner creates 512 "Results ready to send" for those WUs. Those 512 could be mixed with 512 from another splitter, but I think typically will not be. If the Astropulse splitters are producing work, there might be 2 or 4 AP tasks mixed in. When the Feeder gets to that part of the ready to send, what it will be telling the Scheduler about is all identical AR for 5 or 6 Feeder runs, and if that is VLAR work GPU work requests will simply not get any tasks then. A series of such failures could lead to backoffs such that the GPU doesn't get enough work to last through the outage. I do not know how likely that is, but perhaps it would only be a problem if 2 or more of the 4 mb_splitters were doing channels full of VLAR work. And I'll say that testing at SETI Beta cannot be expected to clarify the issue at all. Joe |
Jeff Cobb Send message Joined: 1 Mar 99 Posts: 122 Credit: 40,367 RAC: 0 |
The changes are up and running in beta. If anyone here runs in the beta project, now would be a great time to do so. Beta is getting very little traffic and the moment. Thanks. Seems to be working now. I just stopped/restarted both the feeder and apache. |
Claggy Send message Joined: 5 Jul 99 Posts: 4654 Credit: 47,537,079 RAC: 4 |
The changes are up and running in beta. If anyone here runs in the beta project, now would be a great time to do so. Beta is getting very little traffic and the moment. Thanks. I've restarted Boinc, But no change here, can still connect to other projects O.K, Laptop can't upload or connect to Beta eithier, Suspect Beta is too closely linked to Seti Main, generally if Seti Main is down, so is Beta, Seti Beta's server status page doesn't help eithier, for months it hasn't reflected reality :-( Claggy |
DJStarfox Send message Joined: 23 May 01 Posts: 1066 Credit: 1,226,053 RAC: 2 |
Thanks for the excellent work, Jeff. Let us know what value of AR you decide on; hopefully, you'll find the sweet spot while in Beta (even if 0.12 is not it). |
Sutaru Tsureku Send message Joined: 6 Apr 07 Posts: 7105 Credit: 147,663,825 RAC: 5 |
The changes are up and running in beta. If anyone here runs in the beta project, now would be a great time to do so. Beta is getting very little traffic and the moment. Thanks. Not possible. 15/07/2010 19:39:19 (UTC) SETI@home Beta Test Scheduler request failed: Couldn't connect to server |
Jeff Cobb Send message Joined: 1 Mar 99 Posts: 122 Credit: 40,367 RAC: 0 |
The changes are up and running in beta. If anyone here runs in the beta project, now would be a great time to do so. Beta is getting very little traffic and the moment. Thanks. Well, I see the problem and I don't like it. Our router is invisible outside of our data closet. The router itself is up - I just logged into it from within the closet (ie, from our side of the router). Now I have to track down the trouble spot. |
Sutaru Tsureku Send message Joined: 6 Apr 07 Posts: 7105 Credit: 147,663,825 RAC: 5 |
Basically, all they are doing is making the rescheduler and the VLARKiller program obsolete. All the VLARs will come out of the box as 6.03s no adjustments necessary. The best thing about this I can see is that you won't have to worry about messing up your DCF by transferring VLARs from the GPU to the CPU and vice versa. Only this one thing? If VLAR WUs only to CPUs - the project get the max performance of all hosts out there. Also from members which don't read this forum and don't know about ReSchedule tool and CUDA VLARkill app. I think this is the most important thing. :-) |
Josef W. Segur Send message Joined: 30 Oct 99 Posts: 4504 Credit: 1,414,761 RAC: 0 |
Jeff Cobb wrote: Seems to be working now. I just stopped/restarted both the feeder and apache. Not yet. The first new created workunit today still has both results in "Unsent" status. With the older S@H Enhanced work cancelled, successful work requests should be hitting there. Also Astropulse tasks previously created remain Unsent. Joe |
hiamps Send message Joined: 23 May 99 Posts: 4292 Credit: 72,971,319 RAC: 0 |
I know I asked before but maybe others need to know the correct process for connecting Boinc to Beta...I have an account but it is not an option. Official Abuser of Boinc Buttons... And no good credit hound! |
Claggy Send message Joined: 5 Jul 99 Posts: 4654 Credit: 47,537,079 RAC: 4 |
I know I asked before but maybe others need to know the correct process for connecting Boinc to Beta...I have an account but it is not an option. You go: attach to project, put in Beta's Url, and set eithier new or existing user, put in email address and password, then click next, ;-) Claggy |
Sutaru Tsureku Send message Joined: 6 Apr 07 Posts: 7105 Credit: 147,663,825 RAC: 5 |
I know I asked before but maybe others need to know the correct process for connecting Boinc to Beta...I have an account but it is not an option. http://setiweb.ssl.berkeley.edu/beta ;-) |
Jeff Cobb Send message Joined: 1 Mar 99 Posts: 122 Credit: 40,367 RAC: 0 |
Never mind trying to connect to beta. We have a serious connectivity problem. If we don't get it fixed soon, I will put out a news item about it. This does not bode well for putting the main servers on line tomorrow. |
©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.