Thank you Jeff: thank you one and all.
That is some really special work!
Just looking forward to reporting a few tasks and maybe collecting some new ones ;-)

---

I work in a data center as a critical site engineer.
Without the AC working 100% all the servers would crash within an hour or sooner.
The added cost of electricity and AC maintenance to keep the place cool is figured in for most cases. Unexpected AC break-downs happen unfortunately.

---

Cool Jeff !
Thanks for the update :)

---

is it still down as i request updates but just getting deferred
06 00 16th jan 13

is it still down as i request updates but just getting deferred
06 00 16th jan 13

It's not"down" just after an outage of this length (project was down for a day before this) there are thousands of machines all trying to report completed work and request new work, could take a few days before things settle down.

---

Is there a reason that work units download so very slow from Seti?
Downloads run 10 to 15 times faster on Rosetta.
This has been going on for months.
Rosetta downloads at 500 to 1200 KBps and Seti downloads at
2.49 to 9.78 KBps
Am I doing something wrong?

---

Am I doing something wrong?

No, definitively not!
After the outage there is simply a gigantic traffic jam! The easiest way you can see it is http://fragment1.berkeley.edu/newcricket/grapher.cgi?target=%2Frouter-interfaces%2Finr-250%2Fgigabitethernet2_3;view=Octets;ranges=d%3Aw%3Am%3Ay
The green part of the graphics is outgoing from SETI, this is maxed out (no more traffic possible)!
Patience, please!

I understand the traffic jam after a few days of being offline.

It's a shame that a lot of bandwidth is probably wasted though, because currently I only seem to get partial downloads. Work units download anywhere between 0.94% and 96.73%. Tons are stuck in download, and only a few made it to 100% today.

I also noticed that a lot of workunits (that didn't download btw) are for my GPU with an estimated run time of 2,5 minutes. So if they would have downloaded, it would create even more congestion in a matter of minutes.

Of course I have no idea what is and isn't possible with the scheduler, but wouldn't it be better to schedule a few long running work units after you've been offline, so you don't get bothered by those machines for a few hours and can tend to the rest of the clients?

---

Wow tons of bandwidth being used! Hopefully it's an influx of new users trying to help out

I keep getting a message. Won't get news tasks. Hoping this will change.

yea check out http://fragment1.berkeley.edu/newcricket/grapher.cgi?target=%2Frouter-interfaces%2Finr-250%2Fgigabitethernet2_3;view=Octets;ranges=d%3Aw%3Am%3Ay


they are having a severe network load right now...

I understand the traffic jam after a few days of being offline.

It's a shame that a lot of bandwidth is probably wasted though, because currently I only seem to get partial downloads. Work units download anywhere between 0.94% and 96.73%. Tons are stuck in download, and only a few made it to 100% today.

I also noticed that a lot of workunits (that didn't download btw) are for my GPU with an estimated run time of 2,5 minutes. So if they would have downloaded, it would create even more congestion in a matter of minutes.

Of course I have no idea what is and isn't possible with the scheduler, but wouldn't it be better to schedule a few long running work units after you've been offline, so you don't get bothered by those machines for a few hours and can tend to the rest of the clients?

a) the "stuck downloads" syndrome is common for the servers when there's a "Traffic jam": It's normal, and will work itself out.

B) The folks at Berkeley don't necessarily know what type of WU (workunit) a "tape" will produce. Sometimes a 'tape' starts with normal WU's and about halfway through, starts producing shorties. It depends on what the Aracibo telescope is doing while the "tape" is being produced: sometimes that changes while the "tape" is running. The GPU's run time estimates are often wrong - it depends on what kind of WU's you've previously processed. (With an estimate of 2.5 minutes, you must have high-end nVidia Keppler(s)!)

---

.

Hello, from Albany, CA!...

yea check out http://fragment1.berkeley.edu/newcricket/grapher.cgi?target=%2Frouter-interfaces%2Finr-250%2Fgigabitethernet2_3;view=Octets;ranges=d%3Aw%3Am%3Ay


they are having a severe network load right now...

I'd appreciate it if someone in the know would explain the chart. It says it's a chart for a gigibit eithernet controller. That's 1,000 megabits, yet the graph shows it's being utilized at less than 100 megabits. So what's the problem?

---

The easy bit first...
The 1Gb bandwidth has been throttled to 100Mb by "campus politics"

Next the less easy bits
The green mass is the data rate from S@H to the rest of the word (confusingly called "in")
The blue line is the data rate into S@H (and confusingly called "out")

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Thanks for taking the time to explain it, Bob. It makes sense now!

a) the "stuck downloads" syndrome is common for the servers when there's a "Traffic jam": It's normal, and will work itself out.

B) The folks at Berkeley don't necessarily know what type of WU (workunit) a "tape" will produce. Sometimes a 'tape' starts with normal WU's and about halfway through, starts producing shorties. It depends on what the Aracibo telescope is doing while the "tape" is being produced: sometimes that changes while the "tape" is running. The GPU's run time estimates are often wrong - it depends on what kind of WU's you've previously processed. (With an estimate of 2.5 minutes, you must have high-end nVidia Keppler(s)!)

Thanks for this insight, I didn't know it was depending on what material is being delivered. I thought the data stream was just being chopped up in shorter and larger parts for slower and faster systems and some made compatible for GPU processing rather than CPU.

I recently upgraded to a manufacturer overclocked GTX670 (I just plugged it in, didn't change anything about it), so you guessed right about the high end keppler. Most of the estimated 2,5 minute WUs ended up taking a bit longer than 3,5 minutes though. But to be fair I had never seen such small WUs before, so estimates are bound to be off.

---

I've had nothing for 10 days,

just the usual "got 0 new tasks" nonsense...

I guess my other projects get all the cpu time !

I've had nothing for 10 days,

just the usual "got 0 new tasks" nonsense...

I guess my other projects get all the cpu time !

Looks like you just got some

---

It seems that the Seti Project is dying.

The bandwith cap to 100Mb is probably the first step.

I havn't recieved any new WU´s to process.

If this will continue for much longer i will
delete my SETI account on all my computers.

---

It seems that the Seti Project is dying.

The bandwith cap to 100Mb is probably the first step.

I havn't recieved any new WU´s to process.

If this will continue for much longer i will
delete my SETI account on all my computers.

If you haven't received any work then I suggest that you check your settings at your end as work has been flowing freely if a bit slow.

Cheers.

---