And if my Aunt had wheels shed be a wagon. Scotty, star trek TOS.

---

[/quote]

Old James

Upload server now open for business!

Just uploaded/reported all my results on the first try. :)

Upload server now open for business!

Just uploaded/reported all my results on the first try. :)

Same here, Yay!

Yep, inbound traffic went from next to nothing to 24Mb/s almost instantly.

---

Grant
Darwin NT

Not at all, scheduled outages are one (and for SETI) significant set of outages. Knowing when they are would (in my opinion) be useful.

It would be quite useful. Beyond the obvious maintenance outages, if they knew an outage was coming they could probably avoid it altogether.

It Might prove a bit useful to us PEONS to be told yes - the upload is paralyzed deliberately on Friday BECAUSE - but NO - just flip the switch and let the devil take hindermost. IMHO I've HAD IT - SETI has a reputation in my experience of waiting till Monday to fix Friday's FauxPas - to be followed by Tuesday's OUTAGE! Giving us 2 days of KWITCHERBELIAKIN!

---

Classic WU= 7,237 Classic Hours= 42,079

Well I guess things are a little back to normal until we get the flip side of the coin again ?

---

Not at all, scheduled outages are one (and for SETI) significant set of outages. Knowing when they are would (in my opinion) be useful.

It would be quite useful. Beyond the obvious maintenance outages, if they knew an outage was coming they could probably avoid it altogether.

It Might prove a bit useful to us PEONS to be told yes - the upload is paralyzed deliberately on Friday BECAUSE - but NO - just flip the switch and let the devil take hindermost. IMHO I've HAD IT - SETI has a reputation in my experience of waiting till Monday to fix Friday's FauxPas - to be followed by Tuesday's OUTAGE! Giving us 2 days of KWITCHERBELIAKIN!

From the Cricket Graphs, it appears that whatever happened to take out the upload server happened at 3:00am local time in Berkeley.

So, I guess what you're saying is that someone set their alarm clock, got up in the middle of the night, "flipped the switch" and went back to sleep.

Seems unlikely to me.

---

I can understand the angst. I know Matt tries to keep all abreast of whats going on, but from what i gather hes not there on fridays.
But just a little blurb saying we have such and such going on ,were working on it. Would do wonders for moral.
As for me with 6.6.36 telling me i cant get any milkyway because they wont finish in time while seti wont upload just twists my tighty whities.

---

[/quote]

Old James

Get rid of .36, I use .20 with no problems on SETI and MW.

---

Not at all, scheduled outages are one (and for SETI) significant set of outages. Knowing when they are would (in my opinion) be useful.

It would be quite useful. Beyond the obvious maintenance outages, if they knew an outage was coming they could probably avoid it altogether.

It Might prove a bit useful to us PEONS to be told yes - the upload is paralyzed deliberately on Friday BECAUSE - but NO - just flip the switch and let the devil take hindermost. IMHO I've HAD IT - SETI has a reputation in my experience of waiting till Monday to fix Friday's FauxPas - to be followed by Tuesday's OUTAGE! Giving us 2 days of KWITCHERBELIAKIN!

From the Cricket Graphs, it appears that whatever happened to take out the upload server happened at 3:00am local time in Berkeley.

So, I guess what you're saying is that someone set their alarm clock, got up in the middle of the night, "flipped the switch" and went back to sleep.

Seems unlikely to me.

A couple of possibilities occur to me, such as Matt getting home after a gig about that time and seeing a problem, or a script set to disable upload_handler when a set of bad indications occur. Neither of those could be called a "scheduled outage".

OTOH, a cron job could have been set to disable uploads at that time, no need for someone to set an alarm clock, etc.

                                                              Joe

Not at all, scheduled outages are one (and for SETI) significant set of outages. Knowing when they are would (in my opinion) be useful.

It would be quite useful. Beyond the obvious maintenance outages, if they knew an outage was coming they could probably avoid it altogether.

It Might prove a bit useful to us PEONS to be told yes - the upload is paralyzed deliberately on Friday BECAUSE - but NO - just flip the switch and let the devil take hindermost. IMHO I've HAD IT - SETI has a reputation in my experience of waiting till Monday to fix Friday's FauxPas - to be followed by Tuesday's OUTAGE! Giving us 2 days of KWITCHERBELIAKIN!

From the Cricket Graphs, it appears that whatever happened to take out the upload server happened at 3:00am local time in Berkeley.

So, I guess what you're saying is that someone set their alarm clock, got up in the middle of the night, "flipped the switch" and went back to sleep.

Seems unlikely to me.

A couple of possibilities occur to me, such as Matt getting home after a gig about that time and seeing a problem, or a script set to disable upload_handler when a set of bad indications occur. Neither of those could be called a "scheduled outage".

OTOH, a cron job could have been set to disable uploads at that time, no need for someone to set an alarm clock, etc.

                                                              Joe

Yes, there are ways that SETI staff could do actual work to make the project less stable.

What I find so incredibly tiring is the recurring "they're doing this to us on purpose" -- as if the project existed solely to discourage volunteers.

If something is off, it either broke, or turning it off helps with some other issue.

... and the constant "I've had it, these guys are idiots" pot shots from the peanut gallery is not productive.

---

Hey

What the heck is going on ????? I was exspecting the usual 12 hours on 12 hours off thing and I get this ????? ------ Who is responsible for this with the
Seti Team ????? I guess someone deserves a pat on the back but then again am I speaking to soon ????


John G

Besides non so short a wu will get that long time to complete.
And there is that change in time completed as I mentioned. But I'm going to sleep.Will read tomorrow more about this phenomenon.

OK, I missed the fact that your machine returned the -9. But this is a standard 0.4x Angle Range WU so it doesn't warrant a short turn-round time - and it didn't have one as the line in my previous post is the target date from your host. So far as I can see, your host got to the limit of 30 spikes/etc. and bailed out early. I can't see any way that it can have shown previously on the Tasks page as taking ~3000 sec.

F.

Thank you for folowing this up.

A was quite sleepy last night and I had another mistake somewhere else so I'm not sure anymore about that change of time completed altough I realy think I didn't see a below 2xxx sec in the previous day's, but I'm pretty sure I never saw any wu getting a 6 weeks time to complete before this year.
I might oversee more things . Anyway I let go.

Besides non so short a wu will get that long time to complete.
And there is that change in time completed as I mentioned. But I'm going to sleep.Will read tomorrow more about this phenomenon.

OK, I missed the fact that your machine returned the -9. But this is a standard 0.4x Angle Range WU so it doesn't warrant a short turn-round time - and it didn't have one as the line in my previous post is the target date from your host. So far as I can see, your host got to the limit of 30 spikes/etc. and bailed out early. I can't see any way that it can have shown previously on the Tasks page as taking ~3000 sec.

F.

Thank you for folowing this up.

A was quite sleepy last night and I had another mistake somewhere else so I'm not sure anymore about that change of time completed altough I realy think I didn't see a below 2xxx sec in the previous day's, but I'm pretty sure I never saw any wu getting a 6 weeks time to complete before this year.
I might oversee more things . Anyway I let go.

LOL. I was quite sleepy myself by then - that's why I hadn't checked which machine had already reported.

F.

---

I'm not panicing, I'm just leaving Seti until I think I will get more than 1 AP every 2 months. So, altough far more less credits Einstein@home will get my time.
I mean I tried again this week and I got one AP and now it's MB's only again. My hart is at Seti but I don't think there is much chance MB will find ET. Same for AP ofcourse but that has this little extra ( pulsars ) that's why .
Not much lost cos I do only 5.5 hours a day. Sometimes a little more.

My hart is at Seti but I don't think there is much chance MB will find ET.

MB is Seti, AP is just an extra project.
So if you heart is with Seti, you would crunch MB like everyone else that's looking for life out there.

---

Grant
Darwin NT

I'm puzzled by the bad luck of those looking for AP_v505 work. Of 116 tasks my laptop did in July, 7 were AP_v505. I also got another earlier today. Preferences are set to accept anything and I of course have an app_info.xml and optimised apps to do them.

I'm on dial-up, so only enable network activity once or twice a day, and I first take a look at the Cricket graph and the server status to avoid bad periods. The cache on the host is 1.375 days, so requests could generally be fulfilled by ten or fewer MB tasks, typically more like 3 to 5 non-doubled tasks and it'll average less with the new doubled ones.

AFAICT there should be nothing causing my host to get more than its share other than the laws of chance.

                                                                Joe

I'm puzzled by the bad luck of those looking for AP_v505 work. Of 116 tasks my laptop did in July, 7 were AP_v505. I also got another earlier today. Preferences are set to accept anything and I of course have an app_info.xml and optimised apps to do them.

I'm on dial-up, so only enable network activity once or twice a day, and I first take a look at the Cricket graph and the server status to avoid bad periods. The cache on the host is 1.375 days, so requests could generally be fulfilled by ten or fewer MB tasks, typically more like 3 to 5 non-doubled tasks and it'll average less with the new doubled ones.

AFAICT there should be nothing causing my host to get more than its share other than the laws of chance.

                                                                Joe

OK. That's one end of the spectrum. I can't tell you how many tasks I've crunched in July, or what percentage were AP, but my quaddie with 4 overclocked cores and a GTX295 gets through a lot with the optimised apps. I run a 3-day cache and my preferences are set to AP but anything else if no AP available. Unlike Joe, I'm permanently connected but echo his experience of getting my share of v505's when AP's are available. In fact, I've returned 4 of them in the past day and am currently munching on a fifth.

F.

---

My hart is at Seti but I don't think there is much chance MB will find ET.

MB is Seti, AP is just an extra project.
So if you heart is with Seti, you would crunch MB like everyone else that's looking for life out there.

Actually, SETI is SETI, it just comes in more than one flavor.

---

I'm still getting both MB and AP at the ratio expected (30-50:1), so yes, APs will be rarer compared to previously (when a huge AP bubble was allowed to developed until there was like 40+ tapes where AP was completed and MB had to catch up).

AP is still ahead now but it is much closer. Ideally they should be at parity, but still some way to go considering the additional work asked of the latest MB task.

By the way, now MB have a longer deadline compared to AP. I'm just waiting for people to complain about the build up of pending credit again ;-)

---