Blitzed Again (Jul 02 2009) |
![]() |
| log in |
Message boards : Technical News : Blitzed Again (Jul 02 2009)
1 · 2 · 3 · 4 . . . 5 · Next
| Author | Message |
|---|---|
|
Looks like we're back in another noisy period, or at least the bandwidth is maxed out enough that it's constraining both downloads and uploads. Let's just try to ride this storm out - it should hopefully clear up on its own. | |
| ID: 913347 · | |
|
Thanks for the update. Things just keep plugging along until the dam breaks. | |
| ID: 913358 · | |
|
But..........I thought changes had been made at Berkeley so that noisy work being split out could not overwhelm the system. | |
| ID: 913365 · | |
But..........I thought changes had been made at Berkeley so that noisy work being split out could not overwhelm the system. By noisy I mostly meant "chaotic and busy." Yes, there are mechanisms in place to work on multiple raw data files simultaneously to avoid getting deluged with one particularly noisy data file. It's not perfect, though. I'm not exactly sure what's going on currently but I've been busy with other things to do much sleuthing. We're currently pegged on our network - that means workunits are being downloaded as fast as we possibly can send them - so there's not much I can do. - Matt ____________ -- BOINC/SETI@home network/web/science/development person -- "Any idiot can have a good idea. What is hard is to do it." - Jeanne-Claude | |
| ID: 913389 · | |
[quote]We're currently pegged on our network - that means workunits are being downloaded as fast as we possibly can send them - so there's not much I can do. Good evening, why do you not send out "bigger" workunits of all applications, lets say 4 times the size you did in the past, to get rid of the pressure to Seti´s network capacity? If you dont want to send such bigger WU´s to all participants, make it an option in the account settings, as long as you give fair credits, most of the participants with good hardware will crunch this bigger WU´s and the guys with older hardware are able to crunch the "normal" WU´s in time. ____________ Am Ende ist nur Verwirrung | |
| ID: 913393 · | |
But..........I thought changes had been made at Berkeley so that noisy work being split out could not overwhelm the system. Thanks for taking the time to answer me and thanks for your hard work there at Berkeley. ____________ Boinc....Boinc....Boinc....Boinc.... | |
| ID: 913395 · | |
|
| |
| ID: 913417 · | |
|
It seems to me that the log jams and bottlenecks in the system are ever increasing and are not going to go away. | |
| ID: 913711 · | |
It seems to me that the log jams and bottlenecks in the system are ever increasing and are not going to go away. Keep in mind that the SETI Institute may not want to help, for political reasons. SETI@Home likely could move equipment out of their closet at SSL, and put it at the other end of the wire. The problem is that the splitters need to write to the download server(s), and the validators need to pull from the upload server(s) -- all it really does is move the bottleneck from one end of the current wire to the other. There might be an advantage in doing that, but it might not be the advantage we all really want. ____________ | |
| ID: 913743 · | |
|
i believe they are paying for a gigabit line yet because the proper cables havent been installed, they are only able to use 100mbit. that's what 12 megabytes a second? most hard drives today easily top 50 megabytes/second, so i would understand why the cricket graph stays pegged for days. | |
| ID: 913782 · | |
|
I think there is merit to the idea of sharing the SETI@Home database to data servers across the Internet and leveraging the distributed servers' bandwidth. P2P networks are very good at demonstrating the power of collective bandwidth for spreading information from a single source :) | |
| ID: 913784 · | |
I think there is merit to the idea of sharing the SETI@Home database to data servers across the Internet and leveraging the distributed servers' bandwidth. P2P networks are very good at demonstrating the power of collective bandwidth for spreading information from a single source :) The problem is you still have to get that data from & too the Seti Servers. And that is where the present network bottlneck is. ____________ Grant Darwin NT. | |
| ID: 913787 · | |
I think there is merit to the idea of sharing the SETI@Home database to data servers across the Internet and leveraging the distributed servers' bandwidth. P2P networks are very good at demonstrating the power of collective bandwidth for spreading information from a single source :) Actually it doesn't require trustworthy machines, because the work still has to validate. The problem is that the work is split at the Space Sciences Lab, and to distribute SETI@Home, you'd still have to move work in and out of the Lab. Sooner or later, the existing bandwidth runs out. ____________ | |
| ID: 913788 · | |
maybe it's time to trench the lawn and install that gigabit cable. i know its expensive and labour consuming. too bad berkley is 4 time zones away. i have a 300hp trenching machine. It's more than a short trench, it's a good distance from the lab to main campus. The other problem: gigabit-capable routers and interfaces. ____________ | |
| ID: 913789 · | |
maybe it's time to trench the lawn and install that gigabit cable. i know its expensive and labour consuming. too bad berkley is 4 time zones away. i have a 300hp trenching machine. If my memory serves me properly, I thought it was somewhere near a mile? I know it's quite a way uphill. ____________ Linux laptop uptime: 1484d 22h 42m Ended due to UPS failure, found 14 hours after the fact | |
| ID: 913829 · | |
|
| |
| ID: 913831 · | |
maybe it's time to trench the lawn and install that gigabit cable. i know its expensive and labour consuming. too bad berkley is 4 time zones away. i have a 300hp trenching machine. IIRC there is a dark fiber already in place for the run. But it belongs to the campus though not SETI@Home. There is some considerable politics so it isn't just hardware and cash. As to the bandwidth I don't know how much is being chewed by VLAR killers, but I think the project needs to be tuned to direct those machines to their backup projects or get the owners to remove the VLAR killer and instead use a re-scheduler to turn the CUDA task into a GPU task. Bandwidth is too important to waste. For the future BOINC may need a re-write so it simply sends the task and the user side decides if it is a CUDA or GPU. May need to send a hint along with the data. Failing that the splitters would need to be re-written so they split CUDA/GPU better based on expected task length. But that is a per-project fix rather than a BOINC wide fix. Looks like it going to be a crunch 'em if you've got 'em weekend. And Happy Birthday USA. ____________ | |
| ID: 913847 · | |
I second this =) ____________ Nobody is nobody. Everyone has something to offer | |
| ID: 913849 · | |
Since connectivity on campus is provided by the IST department (the folks who brought you Cricket) they have to maintain it. ... and if there isn't a good clean line-of-sight from the lab to the right building(s) on Campus, then RF isn't a good choice. ____________ | |
| ID: 913854 · | |
maybe it's time to trench the lawn and install that gigabit cable. i know its expensive and labour consuming. too bad berkley is 4 time zones away. i have a 300hp trenching machine. I think it is just hardware and cash. IST is willing to do it, but they don't have the money in their budget -- they want SETI (or SSL) to fund it. ... at least that's what has been said here in the past. ____________ | |
| ID: 913856 · | |
Message boards : Technical News : Blitzed Again (Jul 02 2009)
| Copyright © 2013 University of California |