AFAIK, SETI@home Enhanced (MB) have min. 7 day deadline.
So normally enough time for UL and REPORT.


@ Richard

Well evening in the pub and Cheers! ;-)

---

So far, I've waited since Sunday.

Don't know why that should be the case.
From what i can recall on Sat, Sun & most of Monday there were no problems with uploads. Late Monday (for reasons unknown) the upload server went off line & it only came back online a couple of hours ago (if that).

Yes, I understand about traffic - just want to know what the average number of days one should wait for a job to upload.

Even when things are congested, most uploads will go through in a few hours. If it's really bad it might take 12-24hrs. Usually thay go through on the first attempt.

---

Grant
Darwin NT

I wish I could turn off networking, but I have another project that needs networking active.

Hopefully soon they add in per-project networking options.

---

I wish I could turn off networking, but I have another project that needs networking active.

Hopefully soon they add in per-project networking options.

I'll second that. I didn't want to interupt my other projects, especially when it looked like I might run out of SETI.

When I had the time over the last few days, I would turn off network activity until one of my non-SETI jobs had some uploading or downloading to do, and then turn it back on long enough for the other project to get new work. It would be nicer if BOINC could handle this without my attention.

Note to those who run BOINC - this may look like a SETI specific request today, but the other projects could get into the same situation as SETI someday, if they are lucky ;).

---

Agreed -- SETI isn't the only project that could use a project specific network off switch.

My own read with the upload server (opinion only) is that with the large backlog of upload requests from the past 48 to 72 hours, even if it is running well at the server level, it is simply getting swamped big time. Sort of like the typical Tuesday outage congestion (with a typical server outage of 4 to 6 hours, I expect a congestion problem of 8 to 12 hours), only since the upload outage was so long, recovery will be proportional to that. Perhaps it will clear by the weekend, perhaps by Monday in time for the next outage.

I wish I could turn off networking, but I have another project that needs networking active.

Hopefully soon they add in per-project networking options.

---

I'm going to turn networking off and go out to the pub.

Now that's the smartest idea I've seen all day! :)

---

Join the PACK!

Agreed -- SETI isn't the only project that could use a project specific network off switch.

My own read with the upload server (opinion only) is that with the large backlog of upload requests from the past 48 to 72 hours, even if it is running well at the server level, it is simply getting swamped big time. Sort of like the typical Tuesday outage congestion (with a typical server outage of 4 to 6 hours, I expect a congestion problem of 8 to 12 hours), only since the upload outage was so long, recovery will be proportional to that. Perhaps it will clear by the weekend, perhaps by Monday in time for the next outage.

I wish I could turn off networking, but I have another project that needs networking active.

Hopefully soon they add in per-project networking options.

That would be a nice feature for Boinc, Then I could tell S@H to stop wasting My other projects bandwidth instead of suspending the project(a waste of time that could be better spent crunching) which amounts to using a sledgehammer to swat a fly with. Doing NNT doesn't really cut It.

---

The T1 Trust, PRR T1 Class 4-4-4-4 #5550, 1 of America's First HST's

Actually, other projects have run into problems for which a project specific network activity off switch would have reduced connect error messages at the user level and reduced network traffic to the specific project. I've seen outages over the years at Climate, Einstein, Rosetta, Spinhenge and others. These are outages where completed work (or in Climate's case trickles), is stuck in transfer mode and suspending the project won't stop the client from trying to connect. Further there are cases where you want to continue processing for a project (you still have a queue) but don't want to generate traffic to a specific project.

Note to those who run BOINC - this may look like a SETI specific request today, but the other projects could get into the same situation as SETI someday, if they are lucky ;).

---

Note to those who run BOINC - this may look like a SETI specific request today, but the other projects could get into the same situation as SETI someday, if they are lucky ;).

One of the incredibly cool things about BOINC is that it costs almost nothing to do distributed computing.

So it is entirely possible for an individual to run a fair sized project, funded out of their own pocket, on a home internet connection.

If you do that, on small servers with a cheap DSL line, it is very possible to run into exactly the same corner, just on a dramatically smaller scale.

---

I think I understood SETI uploads problems. We must let time for time.
Basically how can I interrupt SETI network communications without interrupt all BOINC network communications.
I make that manually but now I want to go to bed.

---

just a poet

Actually, other projects have run into problems for which a project specific network activity off switch would have reduced connect error messages at the user level and reduced network traffic to the specific project. I've seen outages over the years at Climate, Einstein, Rosetta, Spinhenge and others. These are outages where completed work (or in Climate's case trickles), is stuck in transfer mode and suspending the project won't stop the client from trying to connect. Further there are cases where you want to continue processing for a project (you still have a queue) but don't want to generate traffic to a specific project.

Note to those who run BOINC - this may look like a SETI specific request today, but the other projects could get into the same situation as SETI someday, if they are lucky ;).

Hic!

Being a little dis-inhibited, I'm going to reveal that when I turned off networking before going to the pub, I turned off networking for this project only: the code exists (no, I didn't write it) and I'm testing it. I found another (small, cosmetic-only) bug this week, which I haven't reported to the author yet, but apart from that I believe it's nearly ready to submit to BOINC as a ready-made patch. When that time comes, I hope you'll all lobby for trac [trac]#139[/trac] to be actioned. It really helps.

I would like to hereby officially lobby for Trac 139 to be actioned.

---

Samdani 15 Jul 2009 16:52:34 UTC

It certainly makes sense but how about relaxing the linking rule under special circumstances like this. Would that be a feasible option?

Samdani 15 Jul 2009 17:14:34 UTC

Ok. I give up. There seems no room for any creative ideas :)

Don't give up so quickly or easily. The responses you got all assumed by "relaxing" you meant "rescinding".

There are certainly reasons to think about that 2X CPUs uploading threshold which was hard coded into BOINC 5.8.6 and hasn't changed since. Now BOINC supports CUDA and multithreaded processing, 5.8.6 didn't.

Even without that, 2X is a compromise measure which probably doesn't fit any project particularly well. For S@H, upload bandwidth needed is about 5% of download bandwidth (but work requests also use the pipe into SSL). Since I've never seen more than 30 MBits/sec used going to SSL, any problems on that side have to be ascribed to transaction rates rather than bandwidth.

Making the 2X adjustable per project might be useful, though it could also allow a user willing to edit client_state.xml a way around any restriction. Using a more complex formula which counts GPUs as well as CPUs, perhaps even checks the result sizes against the WU sizes in the project folder, might be another way to improve.

Any way it is modified it will still impact hosts which normally are most productive before the older, slower hosts.

                                                                 Joe

Actually, other projects have run into problems for which a project specific network activity off switch would have reduced connect error messages at the user level and reduced network traffic to the specific project. I've seen outages over the years at Climate, Einstein, Rosetta, Spinhenge and others. These are outages where completed work (or in Climate's case trickles), is stuck in transfer mode and suspending the project won't stop the client from trying to connect. Further there are cases where you want to continue processing for a project (you still have a queue) but don't want to generate traffic to a specific project.

Note to those who run BOINC - this may look like a SETI specific request today, but the other projects could get into the same situation as SETI someday, if they are lucky ;).

Hic!

Being a little dis-inhibited, I'm going to reveal that when I turned off networking before going to the pub, I turned off networking for this project only: the code exists (no, I didn't write it) and I'm testing it. I found another (small, cosmetic-only) bug this week, which I haven't reported to the author yet, but apart from that I believe it's nearly ready to submit to BOINC as a ready-made patch. When that time comes, I hope you'll all lobby for trac [trac]#139[/trac] to be actioned. It really helps.

Thank You, Thank You, Thank You, Thank You.

---

The T1 Trust, PRR T1 Class 4-4-4-4 #5550, 1 of America's First HST's

I would like to hereby officially lobby for Trac 139 to be actioned.

I second the motion.

---

The T1 Trust, PRR T1 Class 4-4-4-4 #5550, 1 of America's First HST's

erik

Just let it run (if you normally do overnight). It will recover with time.

I think I understood SETI uploads problems. We must let time for time.
Basically how can I interrupt SETI network communications without interrupt all BOINC network communications.
I make that manually but now I want to go to bed.

Regards

---

Please consider a Donation to the Seti Project.

I would suggest that Seti contacts Pacific Internet Exchange:

Pacific Internet Exchange
200 Paul Ave. Ste. M-200
San Francisco, CA 94124

It's a 35 mins drive from Seti.
Arrange hosting and data at that location (could even be free) and put their name on the Seti site. Setup an VPN or VLAN between Seti and PIE and host the big data eating servers their. This way allot of the probs disappear.

They could even drive over to that data enter and bring project on a external HD for 150$ or so.

Off course i don't know the details about the seti system but this can not continue as it is now, for Seti and the Crunchers.

Just an idea.

I would suggest that Seti contacts Pacific Internet Exchange:

Pacific Internet Exchange
200 Paul Ave. Ste. M-200
San Francisco, CA 94124

It's a 35 mins drive from Seti.
Arrange hosting and data at that location (could even be free) and put their name on the Seti site. Setup an VPN or VLAN between Seti and PIE and host the big data eating servers their. This way allot of the probs disapear.

They could even drive over to that datacenter and bring project on a external HD for 150$ orso.

Offcourse i don't knwo the details about the seti system but this can not continue as it is now, for Seti and the Crunchers.

Just an idea.

Thank you for the idea. I've brought this to the attention of Matt and asked him to comment directly when he's able.

---

Did my part to ease upload traffic late last night... ;)

NOTE: Hopefully someone can learn from my mistake..

I've heard it said a smart man can learn from his mistakes while a genius learns from others..

Anyways, so was trying to get some video stuff working right on my Tesla workstation for someone else; was late and in a hurry..
I shutdown the boinc core client to install different driver version.
Nvidia tells me drivers are older than currently installed do I want to reboot..yes yes whatever, hurry up..etc etc

So machine reboots, (I can hear folks groaning knowing whats coming) drivers install all is fine. About this time I load up BM only to all at once realize I needed to disable the service from restarting. When the puter rebooted with no vid drivers I lost ~600 completed WU'S instantly. This machine shares a single ethernet cable with another machine that is always plugged in, for now. So I have to manually plug it in and up/report/download 1-2 times a day. With recent difficulties It had been accumulating WU's for a number of days. Was my whole cache that were pending upload with network suspended. Currently the CPU is still working on it's ~100 MB's. lol

Opps!?!....Kida forgot as I wasn't really thinking about boinc, I was trying to make a rendering program work correctly.

Oh well, operator error, we live to crunch another day. Speedy and pleasant recovery to everyone. Keep crunching!

edit to add:
Just catching up on the thread...Here Here Richard good show; best idea I have heard yet! Chalk us up!

---

"The most exciting phrase to hear in science, the one that heralds new discoveries, is not Eureka! (I found it!) but rather, 'hmm... that's funny...'" -- Isaac Asimov

Actually, other projects have run into problems for which a project specific network activity off switch would have reduced connect error messages at the user level and reduced network traffic to the specific project. I've seen outages over the years at Climate, Einstein, Rosetta, Spinhenge and others. These are outages where completed work (or in Climate's case trickles), is stuck in transfer mode and suspending the project won't stop the client from trying to connect. Further there are cases where you want to continue processing for a project (you still have a queue) but don't want to generate traffic to a specific project.

Note to those who run BOINC - this may look like a SETI specific request today, but the other projects could get into the same situation as SETI someday, if they are lucky ;).

Hic!

Being a little dis-inhibited, I'm going to reveal that when I turned off networking before going to the pub, I turned off networking for this project only: the code exists (no, I didn't write it) and I'm testing it. I found another (small, cosmetic-only) bug this week, which I haven't reported to the author yet, but apart from that I believe it's nearly ready to submit to BOINC as a ready-made patch. When that time comes, I hope you'll all lobby for trac [trac]#139[/trac] to be actioned. It really helps.

Thank You, Thank You, Thank You, Thank You.

I agree that is a great thing.
2nd topic. Just found out that I will be going away for the weekend tomorrow. I had not planed to be away and now I will have stacked up downloads from this week that I can only hope to get in before next tuesdays outage. I have some shorties that time out on the 21st. oh well. I will be shutting down at 7AM EDT I have about 12h to upload them.

---