Up (Dec 07 2010) |
![]() |
| log in |
Message boards : Technical News : Up (Dec 07 2010)
Previous · 1 · 2 · 3 · 4 · 5 · Next
| Author | Message |
|---|---|
|
Another quick note instead of a new thread: | |
| ID: 1054106 · | |
|
LOL nice 1 - starting to get a bit of VFM... | |
| ID: 1054112 · | |
|
got some WU for my pc. shame my server missed them all as thats now idle. i've left it with no tasks now so i can get right back to the search :) | |
| ID: 1054114 · | |
Hope you had some money left in the donations for a drink. Its on us. Tomorrow we'll quadruple the buffer space from where they are now. Mwha ha ha ha. Sounds like they've started already - and as a donor, I don't begrudge them a drop. Cheers, Matt! | |
| ID: 1054131 · | |
|
Thanks for the info guys, I'm finally back in the project, at full speed :). Cheers! | |
| ID: 1054134 · | |
|
Hot damn! I finally received some numbers to crunch. | |
| ID: 1054148 · | |
No need for an announcement. The BOINC software was written to take care of sites that have no work for an extended period. Look at LHC@home. The thing is, there was no reason to set it to NNT. As stated, BOINC is designed to automatically handle times of no work available. I set both Seti and Einstein to NNT when I started having trouble, but that was because I didn't really know what my problem was (and in fact I still don't know if Seti will also be a problem, but tonight I have to go down to the basement to do some laundry, so I'll start Seti then). That said, I am glad an announcement was made, almost as much as I'm glad the project is back up! David ____________ David Sitting on my butt while others boldly go, Waiting for a message from a small furry creature from Alpha Centauri. | |
| ID: 1054266 · | |
|
Thanks to every body for this very good job. | |
| ID: 1054273 · | |
|
What incredible timing. I was just talking to Cisco engineer yesterday. He was telling me about a really kick but server they have developed that has more ram slots than you can shake a stick at. The idea was a low cost system that let an administrator load all the slots with lower cost memory (smaller sizes) then upgrade later as costs fall. I really don't know much about the hardware but when he started tell me about the blades, the first thing that came to mind was SETI and it's update status. | |
| ID: 1054436 · | |
|
One more minor update: We continue to beat up on oscar - long story short we're finding our biggest hurdle in utilizing the server to its maximum potential is probably the stripe size on the raid subsystem (which is set to the factory default as it's hard to predict these bottlenecks until everything is turned on). I think I can adjust it live - and we'll try these sort of tests/updates early next week. In the meantime, more testing with what we got... | |
| ID: 1054438 · | |
One more minor update: We continue to beat up on oscar - long story short we're finding our biggest hurdle in utilizing the server to its maximum potential is probably the stripe size on the raid subsystem (which is set to the factory default as it's hard to predict these bottlenecks until everything is turned on). I think I can adjust it live - and we'll try these sort of tests/updates early next week. In the meantime, more testing with what we got... If you can change it live, that's quite a trick. Thanks for the progress report. ____________ | |
| ID: 1054457 · | |
|
Thank you for all the work. I had just built three new FreeBSD(old) machines for seti when the project went off line. Lol, timing is everything. I thought I had done something wrong with setting up seti because I had no wu's for those machines. | |
| ID: 1054499 · | |
|
Matt. if you need to take anything down, no worries. It is if it crashes unexpectedly we start to cringe. We spend a lot of time and energy re-arranging those 0's and 1's.. hate to see them scattered on the floor. | |
| ID: 1054501 · | |
|
Okay, I know I'll get a lot of flack for this question, but since I don't know the WU system flow, I'll ask it. | |
| ID: 1054509 · | |
|
Actually I do not see a slow creation or assimilation rate. The "tapes" are only going to put out work units so fast. The assimilation is not seriously backlogged, the queries are not out of line on Carolyn, and Jocelyn seems to be keeping up just fine. The results in the field are going up at a fair rate, and turn around time is not out of line. Can they do better? Probably, but give them a chance to tune it. The biggest thing is, we are working again, have not crashed, do not seem to be over-stressing the servers yet. | |
| ID: 1054511 · | |
Siran, I've spent most of a day and a half of "work" time reading your thread at Einstein. I'll make a more detailed response there when I finish it (almost done). However, let me say here that I finally started BOINC last night. I sat and watched it get no tasks for about half an hour before I gave up and went upstairs. My status shows I got three tasks 10 minutes after that, one 5 minutes later, and two more in the wee hours of the morning. None has been returned yet, but I just checked my radioreference.com feed and it's still online after over 16 hours of crunching Seti. That's not a definitive proof of no problem, though. I'll be satisfied when it exceeds 36 hours of uptime. One thing jumped out at me in your Einstein thread: you use Avira as your antivirus. I use Avira on this one computer, because it came preinstalled. I do, however, have an unused license for Bitdefender (which I use on my 2 laptops), so maybe I'll install that. I have a theory that Seti sort of regulates Einstein. That is, the Einstein problem builds up over time, and when BOINC switches from Einstein to Seti, it clears up whatever the problem is so it never builds up to a large enough degree to cause a freeze/crash. I think tomorrow morning, I'll try letting it have another Einstein unit to test this theory (assuming it hasn't crashed on Seti before then). This theory is based on the crashes first starting to happen at about the time Seti went offline. (Otoh.... I never had a problem during the regular 3-day Seti outages, so maybe this theory is not even worth the effort I've put into typing it.) David ____________ David Sitting on my butt while others boldly go, Waiting for a message from a small furry creature from Alpha Centauri. | |
| ID: 1054721 · | |
Actually I do not see a slow creation or assimilation rate. The "tapes" are only going to put out work units so fast. The assimilation is not seriously backlogged, the queries are not out of line on Carolyn, and Jocelyn seems to be keeping up just fine. The results in the field are going up at a fair rate, and turn around time is not out of line. Can they do better? Probably, but give them a chance to tune it. The biggest thing is, we are working again, have not crashed, do not seem to be over-stressing the servers yet. Sorry to disagree, but the current WU creation rate of 10 or 12 per second is much slower than the 30 to 40 per second that we used to see. As for assimiliation, it has always been slow, unable to keep up with validated work, and catch-up assimiliation took about a week after SETI went to sleep for the month. Look at the Scarecrow graph. Pending assimiliations are growing unabated, and SETI isn't even going full speed yet. The benefit we are getting from the slow WU creation (and the longer period between "connect" (5 minutes instead of 10 seconds)) is that the internet link is not saturated, and downloads are proceeding extremely well. Probably, there are no (or very few) ghosts being created. But no one answered the main thrust of my question. All you did was pick apart my contention that there is some slowness to work out. My question was, "My logic tells me that the BOINC database server (Carolyn) is where the WUs are assigned among all the client computers (and probably affects the creation rates), while the Science database (Oscar) only comes into play at the time of assimiliation. So, am I correct in the belief that tinkering with Oscar's DB settings would affect the assimiliation speed, and tinkering with Carolyn's DB settings would affect the WU creation rate (and deletions, purges, etc)?" Thanks again for your responses. | |
| ID: 1054747 · | |
The benefit we are getting from the slow WU creation (and the longer period between "connect" (5 minutes instead of 10 seconds)) is that the internet link is not saturated, and downloads are proceeding extremely well. Probably, there are no (or very few) ghosts being created. Don't underestimate the value of this particular benefit. If I worked in the lab, I would have spent the last month trying to find a way to slow things down so that 200,000 hosts don't max out the bandwidth just hammering for more work. BOINC-equipped computers make an incredible botnet, and there is no real difference between hungry hosts and a DoS attack. It seems like holding down the work creation rate is doing that nicely. It could just be a happy accident, or it could be intentional. Either way, it seems to be working. ... and I think there is more to the answer to your other questions than just pointing at Carolyn or Oscar. | |
| ID: 1054769 · | |
|
Apparently all seems to work well, since 1 work request, all 3 QUAD's | |
| ID: 1054776 · | |
|
The Berkeley Boys have found the magic cure! | |
| ID: 1054828 · | |
Message boards : Technical News : Up (Dec 07 2010)
| Copyright © 2013 University of California |