Sanity is over rated. But stress is over rated too.

---

Janice

The extended outages are not just server related but sanity related. It's nice to have several days a week where it doesn't matter what the systems are doing and we can get other work done. That said, I think if things are turning out well we can certainly reduce our regular outages.

- Matt

How much and which kind of server/s is/are needed for to let run SETI@home and 'background work' 24/7?

Maybe the 3rd new server could do this?
Or a 4th or more new server/s is/are needed?

---

Would be a 'Dell PowerEdge 2800, 2x (2x 2.8 GHz) XEON' helpful, or not well/useful for SETI@home?

I don't have this server, but I know someone - maybe he would donate this server..

---

Job Stress I can relate to. Its also something I hadnt thought of for seti. Before reading Matts response, I was thinking maybe we could donate for a dedicated nitpckr server so we wouldnt have to go thru anymore 3 day outages.

I could deal with another 3 day outage as long as we didnt get ghosts.

---

[/quote]

Old James

I can not imagine any kind of system admin without stress.

Having worked in a 24/7 environment(for Sutaru) they would need absolute full redundancy, being able to switch back and forth ALL servers at the first glitch, full battery strings plus backup generator..

When they have the first extra million laying around they might be able to start thinking about it. In which case it would be some time after they find E.T.

If they need 3 days, 3 days is reasonable. If they can cut it back to 2.5(off tuesday morning, on thursday night) that would be awesome. There is still some fine tuning between the last servers going in. And more work is ahead.

---

Janice

Job Stress I can relate to. Its also something I hadnt thought of for seti. Before reading Matts response, I was thinking maybe we could donate for a dedicated nitpckr server so we wouldnt have to go thru anymore 3 day outages.

I could deal with another 3 day outage as long as we didnt get ghosts.

Resend is on, that should significantly help with the ghosts.

---

I can not imagine any kind of system admin without stress.

Having worked in a 24/7 environment(for Sutaru) they would need absolute full redundancy, being able to switch back and forth ALL servers at the first glitch, full battery strings plus backup generator..

When they have the first extra million laying around they might be able to start thinking about it. In which case it would be some time after they find E.T.

If they need 3 days, 3 days is reasonable. If they can cut it back to 2.5(off tuesday morning, on thursday night) that would be awesome. There is still some fine tuning between the last servers going in. And more work is ahead.

You worked for me?
I guess - you meant SUBARU, or? ;-)

---

...
It's nice to have several days a week where it doesn't matter what the systems are doing ...

hehe

I quite believe it.

In the same way the Stress on YOU Guys lowers - in the same Way the Stress on US increases. :D

Helli

---

A loooong time ago: First Credits after SETI@home Restart

We're back to shoveling out workunits as fast as we can. I mentioned in another thread that the gigabit link project is still alive. In fact, the whole lab is interested in getting gigabit connectivity to the rest of campus, which makes the whole battle a lot easier (we'll still have to buy our own bits and get the hardware to keep them separate). Still, it's slow going due to campus staff cutbacks and higher priorities.

Now that, at least temporarily, the balance between server power and communications has swung towards the servers, would it be worth re-considering the compression of MB workunit files before transmission? Not much to be gained (and nothing at all for the incompressible AP files), but every little helps - and it would give Oscar something to do when he's bored ;-)

We're back to shoveling out workunits as fast as we can. I mentioned in another thread that the gigabit link project is still alive. In fact, the whole lab is interested in getting gigabit connectivity to the rest of campus, which makes the whole battle a lot easier (we'll still have to buy our own bits and get the hardware to keep them separate). Still, it's slow going due to campus staff cutbacks and higher priorities.

Now that, at least temporarily, the balance between server power and communications has swung towards the servers, would it be worth re-considering the compression of MB workunit files before transmission? Not much to be gained (and nothing at all for the incompressible AP files), but every little helps - and it would give Oscar something to do when he's bored ;-)

ROFLMAO....
We wouldn't want Oscar to get bored, now would we?

---

"Time is simply the mechanism that keeps everything from happening all at once."

We're back to shoveling out workunits as fast as we can. I mentioned in another thread that the gigabit link project is still alive. In fact, the whole lab is interested in getting gigabit connectivity to the rest of campus, which makes the whole battle a lot easier (we'll still have to buy our own bits and get the hardware to keep them separate). Still, it's slow going due to campus staff cutbacks and higher priorities.

Now that, at least temporarily, the balance between server power and communications has swung towards the servers, would it be worth re-considering the compression of MB workunit files before transmission? Not much to be gained (and nothing at all for the incompressible AP files), but every little helps - and it would give Oscar something to do when he's bored ;-)

I don't know how compressable the data is, but it might well be worth the effort to save the bandwidth.

I don't know if anyone has ever written a lossless compression algorithm for CUDA, but I'd think it might actually be a very good match, and might allow any of the modern servers in the closet that can add a video card to do a significant chunk of compression, while using a GPU rather than a CPU.

Well worth considering after the hardware is sorted out and working efficiently again.

We're back to shoveling out workunits as fast as we can. I mentioned in another thread that the gigabit link project is still alive. In fact, the whole lab is interested in getting gigabit connectivity to the rest of campus, which makes the whole battle a lot easier (we'll still have to buy our own bits and get the hardware to keep them separate). Still, it's slow going due to campus staff cutbacks and higher priorities.

Now that, at least temporarily, the balance between server power and communications has swung towards the servers, would it be worth re-considering the compression of MB workunit files before transmission? Not much to be gained (and nothing at all for the incompressible AP files), but every little helps - and it would give Oscar something to do when he's bored ;-)

I don't know how compressable the data is, but it might well be worth the effort to save the bandwidth.

I don't know if anyone has ever written a lossless compression algorithm for CUDA, but I'd think it might actually be a very good match, and might allow any of the modern servers in the closet that can add a video card to do a significant chunk of compression, while using a GPU rather than a CPU.

Well worth considering after the hardware is sorted out and working efficiently again.

Not sure exactly what the current situation is, but I questioned Eric before the new servers were ordered about the CPU power they were considering.
He told me that the main bottleneck was with I/O, and that the CPUs would probably be loafing most of the time.
So there may be a lotta CPU time itself available for such a scheme.

---

"Time is simply the mechanism that keeps everything from happening all at once."

I don't know if anyone has ever written a lossless compression algorithm for CUDA, but I'd think it might actually be a very good match, and might allow any of the modern servers in the closet that can add a video card to do a significant chunk of compression, while using a GPU rather than a CPU.

In general, and where space is available, that might be a useful facility.

The trouble is that extreme-density 2U rackmount servers like Oscar and Carolyn (photos) have very little spare space, and cooling air is at a premium, too. The graphics (card? chip?) in such a server is usually a very minimal spec, to save power and space - all it needs to handle is basic engineering and management displays. You don't want to watch DVDs or play games in a server closet.

You don't want to watch DVDs or play games in a server closet.

Then again, it might give them some entertainment with as much time as they've been spending in there lately! :)

Well....
The pipe is no longer maxxed out.

Could the limits be raised now so some of us can do a bit of cache filling before the already announced 3 day outage coming up on Tuesday?

Pleeeeeeeeez?

---

"Time is simply the mechanism that keeps everything from happening all at once."

You don't want to watch DVDs or play games in a server closet.

Then again, it might give them some entertainment with as much time as they've been spending in there lately! :)

OK, your employer / Finance Director (the one who did the deal to buy the server) doesn't want you to be watching DVDs or playing games - ever!

You don't want to watch DVDs or play games in a server closet.

Then again, it might give them some entertainment with as much time as they've been spending in there lately! :)

OK, your employer / Finance Director (the one who did the deal to buy the server) doesn't want you to be watching DVDs or playing games - ever!

Yeah, but they're stick-in-the-muds! ;)

Meanwhile, we are wasting bandwidth.

Let's get them limits raised or lifted.

---

"Time is simply the mechanism that keeps everything from happening all at once."

Compressing the data is a waste of time. The radio signals are random noise.
If you want to compress the WUs, then it would require another boinc project for it!

Like concrete vs a sponge - there are no holes to squeeze out because there are no patterns to match. This is what we are doing - looking for patterns so tiny that it needs petaflops of work.

The only sensible option we have is to change the transport encoding in the workunit from:

<data length=354991 encoding="x-setiathome">
4!06>[Z"^-=U3F &)+L2$%3?N:MQZ$SS TZQ^'.U9D>EB5$3-NBBHZ<V[$:M]6FX
#AN(80/"%'!3)31Q[&HH$A]9[2*LIH274ITL'/(B%LN7]B[+C$N6J X(TXT\21CQ
+BEJ;]PXG9'$#3@7S]GI83NXJ-$C\35<7@TJG=_,=J)R>/DSEV3C^4%DHT$,%W"R
...

to raw CDATA octets.

Base64 encoding increases the size of the raw data by about 37%, and is unnecessary because XML supports binary octets as CDATA.
Why not use it? The WUs don't have to go through ancient mailservers, and transfer is point to point, so there are no barriers apart from will.

Compressing the data is a waste of time. The radio signals are random noise.
If you want to compress the WUs, then it would require another boinc project for it!

Like concrete vs a sponge - there are no holes to squeeze out because there are no patterns to match. This is what we are doing - looking for patterns so tiny that it needs petaflops of work.

The only sensible option we have is to change the transport encoding in the workunit from:

<data length=354991 encoding="x-setiathome">
4!06>[Z"^-=U3F &)+L2$%3?N:MQZ$SS TZQ^'.U9D>EB5$3-NBBHZ<V[$:M]6FX
#AN(80/"%'!3)31Q[&HH$A]9[2*LIH274ITL'/(B%LN7]B[+C$N6J X(TXT\21CQ
+BEJ;]PXG9'$#3@7S]GI83NXJ-$C\35<7@TJG=_,=J)R>/DSEV3C^4%DHT$,%W"R
...

to raw CDATA octets.

Base64 encoding increases the size of the raw data by about 37%, and is unnecessary because XML supports binary octets as CDATA.
Why not use it? The WUs don't have to go through ancient mailservers, and transfer is point to point, so there are no barriers apart from will.

Exactly as has been done with Astropulse workunit files, since the very start of that sub-project.

It's entirely up to the lab staff how they handle it, but either compression or raw CDATA for MB would shave ~30% off that part of the project's download requirements. Whether modifying the splitter code to generate CDATA format, or post-processing the existing format with compression, I'll leave to them. I'll only mention that post-processing would also compress the (non-trivial) XML header, whereas CDATA would not.