So is the Philmor server being reconfigured to serve as either upload or download server (so Kryten's load is divided)? I assume some gateway or router can be configured to split the traffic appropriately? By the looks of it, the Kosh server could be another candidate for re-deployment if really need be (and validation can keep up on the remaining two validation processes). I can imagine that moving tasks from one machine to another is far from trivial in a running environment, with many scripts and programs running in concert. So to the people at seti: stay cool, despite the sometimes heated discussions here.

---

Maybe it would be good if they set up a protocol so setiqueue can work again. Just like in seti classic, the main servers can't handle all the load at many times. It was determined that Setiqueue was helpful in lowering connect problems with main servers.

---

Ya just think we would have heard something by now.
Maybe they are home reading Harry Potter.

LOL!

---

Ya just think we would have heard something by now.
Maybe they are home reading Harry Potter.

Waiting to upload:

62 - waiting to go up now.

Uploads completed:

15th 10 went up
16th 10 went up
17th 35 went up
18th (so far) 17 went up

Downloads completed:

suspended new work for some days 15th -17th

18th 86 downloaded.

seti was suspended overall for periods as I thought about what to do and gave the time to lhc and cpdn. All back now though.

---

Back to topic...

on the 15th, I uploaded 32
16th: 34
17th: 29
18th: 16 (partial day)...

I grant that I have 53 pending upload success another 41 in flight, and 4 pendig download... but... Paul says that work is getting back ...

This was a "hand tally" so, the results may be off a bit. As I suspended more work download I may be able to know more tomorrow ... we shall see ...

on my top machine which completes about 24 WU/day:

15th: 20 uploaded
16th: 16 uploaded
17th: 18 uploaded

my last one today went through 6 hours ago. backload went from about 12 on friday to 40 right now. boinc is averaging less than 2 mins between retries without me provoking it. downloads do not seem to be a problem. my first deadline passes on the 25th (even on the slower machines) so nothing at this end is critical yet.

Finally I loaded up most outstanding results today (yes!) by using a proxy see previous posting http://setiweb.ssl.berkeley.edu/forum_thread.php?id=16939#138257 and increased the priority of the other projects. Hope its getting better in the next days, trusting in the seti-team or a miracle, whichever comes first ;-)

Have a nice day and good luck!

---

Back to topic...

on the 15th, I uploaded 32
16th: 34
17th: 29
18th: 16 (partial day)...

I grant that I have 53 pending upload success another 41 in flight, and 4 pendig download... but... Paul says that work is getting back ...

This was a "hand tally" so, the results may be off a bit. As I suspended more work download I may be able to know more tomorrow ... we shall see ...

---

Each block is split into 256 bands. Each of these is sent out 4 times so the answer is n * 256 * 4 where n is the number of blocks on a tape.

i believe you forgot that each block is only 1.7 seconds long.... shouldn't the formula be

n*(256/48)*4 ??

Each block is split into 256 bands. Each of these is sent out 4 times so the answer is n * 256 * 4 where n is the number of blocks on a tape.

Thanks for the explanation. John......do you know exactly what has happened/ is happening. Its a pretty hot topic here right now and most of what we discuss is based on little (actually NO) information.

Thanks.
Ian

---

Each block is split into 256 bands. Each of these is sent out 4 times so the answer is n * 256 * 4 where n is the number of blocks on a tape.

---

BOINC WIKI

where are we at now, figuring out if the problem is being 'repaired' by limiting new work? that's silly, they would have shut off downloads. even that's silly, people have up to 10 days cache, there would be 2-3 weeks of users being completely idle to catch up at this rate

After reading and re-reading, i'm not sure if I can answer your question. I'm not sure if the splitter divides the 48 blocks into 256 WU or if each block is divided up into 256 WU. The first time I read it I interpreted it as each block has 256 WU. The second time, however, i'm not so sure.

Either way, there is a lot of blocks to be split and WU's to be sent out.

Each wu is roughly 107 seconds long, but there is some overlap between wu to make sure all possible signals is detected. Since each block is 1.7 seconds, it's fairly apparent this means 48 blocks is used to generate 256 wu.

A quick calculation reveals it can be roughly 48k blocks left to split, this means 256k wu, and this again means 1M results when finished splitting.

With 216k ready now, and 4h transitioner-backlog, maybe upto 1.3M results, but can also be much less...

After reading and re-reading, i'm not sure if I can answer your question. I'm not sure if the splitter divides the 48 blocks into 256 WU or if each block is divided up into 256 WU. The first time I read it I interpreted it as each block has 256 WU. The second time, however, i'm not so sure.

Either way, there is a lot of blocks to be split and WU's to be sent out.

Jim

Just check my maths but guess there are about 1.13M WUs on the tapes still being processed?

EDIT: Hmmm....might be more as the terminology is not leaping out as clear to me...perhaps that * 256?

48 blocks => 256 work units => 1024 results (what we download)

AH ok thanks. I got lost twice reading it as I interpretted a couple of ways. Thanks for that clarity.

---

After reading and re-reading, i'm not sure if I can answer your question. I'm not sure if the splitter divides the 48 blocks into 256 WU or if each block is divided up into 256 WU. The first time I read it I interpreted it as each block has 256 WU. The second time, however, i'm not so sure.

Either way, there is a lot of blocks to be split and WU's to be sent out.

Jim

Just check my maths but guess there are about 1.13M WUs on the tapes still being processed?

EDIT: Hmmm....might be more as the terminology is not leaping out as clear to me...perhaps that * 256?

48 blocks => 256 work units => 1024 results (what we download)

---

https://youtu.be/iY57ErBkFFE

#Texit

Don't blame me, I voted for Johnson(L) in 2016.

Truth is dangerous... especially when it challenges those in power.

After reading and re-reading, i'm not sure if I can answer your question. I'm not sure if the splitter divides the 48 blocks into 256 WU or if each block is divided up into 256 WU. The first time I read it I interpreted it as each block has 256 WU. The second time, however, i'm not so sure.

Either way, there is a lot of blocks to be split and WU's to be sent out.

Jim

Just check my maths but guess there are about 1.13M WUs on the tapes still being processed?

EDIT: Hmmm....might be more as the terminology is not leaping out as clear to me...perhaps that * 256?

---

I think we are going to start seeing this problem correct itself. After reading someone else's post, I took a look at the server status page. There are no more tapes qued to be split. One splitter is already shut down, so only 4 are left running. I can only assume that they have done this intentionally.

Jim

Can I add a further refinement.

If each boinc client indicated how low it was on work the ucb dl server could say yes or no to requests quite quickly. This would see cpu time and bandwidth reserved for upload and only give work to nearly dry clients.

I guess the same scheme could be applied to upload also. That way there is a balancing of the ul/dl server to meet demands plus urgent running dry situations.

Just check my maths but guess there are about 1.13M WUs on the tapes still being processed?

EDIT: Hmmm....might be more as the terminology is not leaping out as clear to me...perhaps that * 256?

---

Some results are still uploaded to the server, but the rate of sucessfull is lousy.

By the way, I have to revise my statement from ago: the network seems to be clear, so the packet drops must caused by the server.

---

I think we are going to start seeing this problem correct itself. After reading someone else's post, I took a look at the server status page. There are no more tapes qued to be split. One splitter is already shut down, so only 4 are left running. I can only assume that they have done this intentionally.

Jim

Can I add a further refinement.

If each boinc client indicated how low it was on work the ucb dl server could say yes or no to requests quite quickly. This would see cpu time and bandwidth reserved for upload and only give work to nearly dry clients.

I guess the same scheme could be applied to upload also. That way there is a balancing of the ul/dl server to meet demands plus urgent running dry situations.

---

I have not gotten any results uploaded yet, but that don't mean anything. The people at Berkley are probably currently working on the issue at hand and trying to get it working again. Just gotta sit back and wait. All the more reason so just let the computer do its work, and eventually they will get through. Looking at this shows that the data is going in and out, so it appears to be working, but probably like others have said, it may be that the servers have reached capacity. Never know till Berkley tells us. :-)

Jeremy

---