mork
mork |
|
| log in |
Message boards : Technical News : mork
Previous · 1 · 2
| Author | Message |
|---|---|
Just curious to hear from the lab.. do you guys think the bubble gum will hold? Or do you need more black tape? With two servers to spec, order, receive, install, burn in, hammer on unexpected gremlins, swapping around remaining servers/hardware < and hammering on those attendant gremlins >, plus it's the holiday season time of year; I would guess at late January to early February for the lab boys to look at that. That's if it doesn't get fixed as a byproduct of the above process. Patience, folks, patience. Rome wasn't built in a day. Heck, it took at least week to burn down. | |
ID: 1042826 ·  | |
With the new servers on the way, I was wondering about our 3 day outage. I am under the impression that 2 of the 3 days are for the The Near-Time Persistency Checker, because it needs exclusive database access. I was wondering if a third database backup could be created and use that as the The Near-Time Persistency Checker database? Log the changes then on the database maintenance day, use a log to make changes to the master database then resynchronize the 3rd DB with the new results from the week. I hope I explained my idea good enough, I am a truck driver and only dabble in computers. I like to assemble components and see if I can make them work. There have been lots of Hints (Tech News). The last most recent was by Matt stating that the query against the Science DB was a 1 gigabit of data. If we extrapolate as a "Result" is roughly 31K in size, that would mean they are attempting to grab (close math) 1000000000 / 31000 = 32258.06 results for comparision This is a bit more complicated in that they would target on an area is space and then try to fill in the around that area. So what happens next is NITPCKR attempts to insure that the pixel number is assigned for the area of space and look to see if any other results have been returned from the same area. So the first part is assigning the catalog (pixel number) and what was found. One other hint is the Science Status Page That Matt started ages ago. In a conversation with Eric about two years ago was that it would take about 3 years for a single computer to work through all the results (Seti Classic and Seti Multibeam). The other part of the discussion is freshly returned work would take precedence over the older returned results as they can shift through the DB. What this means, is that when they run the query against the millions and millions of returned results (I can not recall when Matt announced that there were over a billion results returned). It takes some major power to "grab" a small section that is focused on one area. Then the analysis starts to happen for the area. The only visualization I can think of is something like you go to the beach. With a pair tweezers you pick up a single grain of sand and place it in a zip lock bag (so you do not lose it). Then you take a large cup and scoop up a large amount of sand from the same area. You place that in a large bag so you do not lose any grains. Then You have two computers do an analysis on the first grain of sand. You have other computers do analysis on the other grains of sand. Each grain of sand as all are analyzed twice you one pick as the best result. NITPCKR then analyzes all the results from the saved results. Anyway you look at it is going to take time and computer resources/horsepower. The other part is a signal might show up in one pixel (because it is moving like stars or spacecraft do) it will show up in the pixel next to it. So not only are we chasing the needle in the haystack, we now know that it can move (celestial mechanics). While todays technolgy is not the best, we do have hope that with "time" we can move through this. With time, Moore's law means that the time required for the search can decrease. This also means that currently "fewer users" at Seti can place increased stress on the servers to a point where the older (yes they are older than two years old) can cause them to choke. Patience on your part and consideration for others is all that anyone can hope for. David Anderson built the mousetrap over a decade ago. Who would have known how successful it might or might not be. Regards ____________ Please consider a Donation to the Seti Project. | |
| ID: 1042994 · | |
|
<not impatient.. just concerned.. poor mork. | |
| ID: 1043136 · | |
<not impatient.. just concerned.. poor mork. With the two new servers on their way maybe they can load them up and assign Mork to some lesser workload task. Something easy that wont put so much strain on him. He's been a good workhorse, he deserves a break. ____________  PROUD MEMBER OF Team Starfire World BOINC | |
| ID: 1043159 · | |
|
Seems that poor mork is still a sick puppy. | |
| ID: 1043207 · | |
|
Not sure Mork is reliable enough to even take on a lesser load. His reliability took a real nose dive. I think it may be better to put Mork out to pasture. | |
| ID: 1043271 · | |
|
just set mork to run Boinc clinet :) | |
| ID: 1043518 · | |
it ran 24/7 without crashing/rebooting while BOINC was running the CPUs full tilt. If BOINC was closed the random reboots would start again. Yeah I was thinking for a time that maybe one, or more, of the xeon CPUs was going kaput. However after trying each of the 4 CPUs, and VRMs, one at a time in the chassis I ruled that out. The only thing left would be the main board in the system. ____________ SETI@home classic workunits: 93,865 CPU time: 863,447 hours Join the BP6/VP6 User Group today! | |
| ID: 1043566 · | |
|
I hope Mork keeps on running Ok. The last thing Seti needs is more server failures and costs... | |
| ID: 1045052 · | |
|
Too late for that now Julie, Mork is on his last legs. Not sure if he's finally completely dead or just so far gone as to be pretty much worthless to the project now. That's why we are down while waiting for the new servers. Jocelyn just couldn't carry the load all by herself. :-( | |
| ID: 1045054 · | |
|
Sorry to hear that:{ | |
| ID: 1045075 · | |
Message boards : Technical News : mork
| Copyright © 2013 University of California |
