This whole SETI bandwidth thing is really beginning to suck...

[Poof]

Assimilator1 -
Poof
You left me for some one else?





I haven't left ya. But then again, I haven't seen you much!

And if this bandwidth crunch gets any worse, I expect we'll see a 3..04 client. :| But they would need to code it (not too difficult for what they would plan to do), and change their filters to only accept 3.04. And at that point, it would be tricky because they'd need to eventually do it with all the clients and that might take some more time. Then they'd have to put a deadline in place for when earlier clients won't be accepted anymore...

It's a mess all around. :disgust:

 

[JWMiddleton]

6 jw.middleton 27,666 45

LOL...45 WUs got me into 6th place today! So, it looks like everyone is having problems!

 

[RaySun2Be]

Poof,
The hot-tubbing, run to the bushes SETI Babe......

 

[Poof]

LOL@Ray!!!!

And JWMiddleton - I had maybe 3 or 4 out of almost 30 (some left over from the day before) that managed to upload over a 7 hour period (from 3am EST - 10am EST). Sigh...

 

[Logix]

This whole bandwidth ordeal is a bit befuddling. Just in case anyone was wondering, the student ResHall network is a separate 40Mbps network from the general campus's 70Mbps that S@H uses. So, it's hard to pinpoint the cause of the bandwidth problems. It's not the students in their dorms. The recent increase in bandwidth usage must be coming from the general campus.

There's been a newsgroup discussion going on about the general network problems. It also explains why blocking file-sharing programs like Morpheus isn't feasible.

 

[Robor]

"o Increase the amount of computation per work unit. Doubling the CPU time per work unit - by looking at more chirp rates, for example - will reduce bandwidth by 50%. There is scientific justification for doing this, although the law of diminishing returns applies. This will also require a new version of the client software. (This is what many of us are afraid will happen as it did in Jan 01.)"

:| I don't like that idea at all. :| We went through this before and all it did was cause questions, problems, and a lot of extra administration (especially for those that manage large fleets).

"The long-term solution is to allow work units to be sent from servers outside UC Berkeley. This could be done, for example, by sending work units to servers at organizations - companies and universities - that are willing to donate part of their outgoing network bandwidth to SETI@home. In addition to solving the current problem, this could greatly increase our overall data capacity, enabling us to search for ET signals in a wider frequency band."

Finally! I'm willing to bet that there'd be companies and/or universities that would be willing to donate bandwidth for the SETI project.

"This solution represents a significant change to our software; we will use this approach in our next-generation software. We are seeking funding to develop this software, and it won't be ready for at least 6 months."

This would be another new client but I'd be willing to accept the necessary administration involved if the end result was no more bandwidth problems. Also, an auto-updating client would be pretty sweet.

 

[Assimilator1]

I too hope they don't introduce a slower client ,I remember the last one ,though TA didn't loose too many members as a result ,we still lost some (+ some ships were just de-commisioned because they were considerd too slow ,so the overall Team slow down was greater than the increase in WU times)MURC suffered a devasting loss of members & the once strong rival to us never recovered.

Poof
I havent forgotten 'our' times together

Btw here's an unpleasant thought ,unless they find 1 particular culprit for the bandwidth problems soon ,it is only going to get worse as more & more people upgrade there machines...................

 

[Migroo]

<< Btw here's an unpleasant thought ,unless they find 1 particular culprit for the bandwidth problems soon ,it is only going to get worse as more & more people upgrade there machines................... >>



Very good point. Everyone seems to be buying an Athlon Xp at the moment...

 

[Russ]

I'm now sitting with 550 results and growing. At current rates, I'll have all results and none waiting in about three days. If it gets to that point, I'm shutting it down.

Russ, NCNE

 

[Assimilator1]

Is it no good connecting during the night? (after about midnight ,California time, seems to work for me)

 

[Poof]

Is it no good connecting during the night? (after about midnight ,California time, seems to work for me)

That has usually been an okay time for me too, except that this past weekend and early morning today, it made no difference.

Poof
I havent forgotten 'our' times together

 

[SlowBones]

I've just set my SetiDriver cache to around a week and assume it will flush and fill over the weekend. So far, so good.

 

[networkman]

There just isn't any reason why work units couldn't be distributed out to other places!! :|

Consider some of the founding members like SUN and SGI - would they consider providing some bandwidth? What about other companys in the network industry? Surely, some of them may be interested as well - I know I'd reconsider my purchasing decisions if faced with a choice between Intel and 3Com network cards and Intel was providing bandwidth for SETI!

BTW, I used the example above because nearly all the nics in my organization are either one brand or the other already.

Lastly, I gotta believe there's other universities that would jump at the chance for an opportunity like this - don't tell me the money ain't there - there's a lot of dough being paid out to get stars for sports teams.

 

[conjur]

Here's a copy of the email I just sent to the executive producer of cnet.com (from a zdnet.com Contact Us link):

Good evening, Sir.

Having just read a very recent article on your site:

http://zdnet.com.com/2100-1105-840652.html

I was struck by the following paragraph:

Heartened by the phenomenal success of the SETI@Home distributed computing application, which crunches radio telescope data to look for intelligent patterns, Baranowski decided to add a screensaver to the program.



Well, the SETI project may be in trouble. Bandwidth issues for the last month or so (and extremely bad the last few days) is beginning to cause people to leave the project in droves. Berkeley's answer:



Short-term solutions We're working on several short-term solutions:

o Increase the bandwidth of UCB's network connection. We hope to "expand the pipe" by about 10 Mbps - enough to ease, but not eliminate, the crisis. The issue is money - bandwidth costs about $300 a month per megabit, and neither SETI@home nor the university has budgeted for this cost.

o Send data more efficiently. Currently work units are encoded as text. By sending them in binary, we can shrink them by about 25%. (Note: data compression isn't effective for our data, which is primarily random noise). This change will require a new version of the client software.

o Increase the amount of computation per work unit. Doubling the CPU time per work unit - by looking at more chirp rates, for example - will reduce bandwidth by 50%. There is scientific justification for doing this, although the law of diminishing returns applies. This will also require a new version of the client software. (This is what many of us are afraid will happen as it did in Jan 01.)

Long-term solutions
The long-term solution is to allow work units to be sent from servers outside UC Berkeley. This could be done, for example, by sending work units to servers at organizations - companies and universities - that are willing to donate part of their outgoing network bandwidth to SETI@home. In addition to solving the current problem, this could greatly increase our overall data capacity, enabling us to search for ET signals in a wider frequency band.

This solution represents a significant change to our software; we will use this approach in our next-generation software. We are seeking funding to develop this software, and it won't be ready for at least 6 months.



is a cry for help. Is there anything your publication could do to help spur interest in government/corporate funding for bandwidth or collaborations to provide mirror sites?

If not, I would at least like to thank you for taking the time to read this letter.

Sincerely yours,

Jerry D. Turner

Join Team AnandTech SETI
http://www.teamanandtech.com/faqs/seti/

 

[ishmael2k]

I agree, I am setting on WUs at each of my Qs.. Getting disheartening but I ain't quitting... Even if I have to burn them on a cd and snail mail them to Berkley...


conjur, well written email.

Rb

Oh yah and it looks like I am finally going to get my 2nd 800eb soon so I will also up my production a little to push the bandwidth problems a little harder..

 

[A5]

It's hard finding team queues that have WUs in them...anyone have any tips on which ones are stocked?

 

[Evadman]

<< Even if I have to burn them on a cd and snail mail them to Berkley... >>


Amen brotha'

 

[Shuxclams]

<< This whole SETI bandwidth thing is really beginning to suck... >>




DUH!



A5, keep an eye on the TeAm Queue thread I have quite a few, but I cant flush. I go through 133 Wu's a day average right now and I am only able to trickle the completed Wu's to Berkeley.





SHUX

 

[m2kewl]

Damn man, I'm screwed - didn't cache enough wus and now my pc are dormant waiting to send them home...

Have problems connecting to setiq's also...oh well, to sleep I go.

 

[CADsortaGUY]

<< It's hard finding team queues that have WUs in them...anyone have any tips on which ones are stocked? >>



I think what you are saying is that you try to connect but can't download from them, which will happen until berkely can fill your "queue" on the SetiQ. To "solve" the problem you'll have to PM or email the "Queue-Master" since bezerkely is suck, so they can move some WUs into your acct manually on their Queue once you "connect" by uploading a result to them. I try to keep tabs on mine since I have the Federation Queue redirected through mine at the moment.

CADkindaGUY

[EDIT] who ever is adsl-65-64-125-39.dsl.kscymo.swbell.net, I have a queue on my SetiQ that is stocked(a couple anyway )
[/EDIT]

 

[Eponymous]

Hmmm,

Back of the envelope calculations indicate at the current rate my private stash should tap out about 10pm Friday.

I sure hope things get better soon.

 

[Shuxclams]

<< To "solve" the problem you'll have to PM or email the "Queue-Master" since bezerkely is suck, so they can move some WUs into your acct manually on their Queue >>



Actually you need or should send a user_info.sah so they can create a Q and then move Wu's into that Q.









SHUX

 

[conjur]

I just got one PC back up to a full 10 WU cache (about 3 days' worth) and my laptop is inching its way back up to its 2-day cache.

I'm gonna try and get the other machines up-to-snuff and hit the hay soon.

 

[sduguid]

I moved about half of my daily production away from OK's server but I've still run out of WU's there :Q

I assume others using OK's queue are in the same position.


I hope Berkeley does something to alleviate this problem soon :|

I really don't want to continue losing WU's on my remote fleet due to lack of bandwidth....:|

Even if OK gets a night or two of decent connection time, it looks like it'll be hard to catch up.

 

[Grin]

Can't connect to seti server in the morning - can't connect to seti server by noon - can't connect to seti server early in the evening - can't connect to seti server around midnight - kick'em all to hell I say! Fungus hell! Where the green fungus grows! (the issues)

'Black windows of pain,
I scratch with nails!
I see others; just like me,
Why do they not try to escape??
They bring out the older ones,
They pointed my way!
They come with the flashing lights,
And take my family away!!