same here. more than 30 WU waiting in upload queue.

---

Can't report either. If they do magage to upload, will I be able to get new downloads without the others reporting? I did get some downloads earlier but they all haven't downloaded yet.

---

Can't report either. If they do magage to upload, will I be able to get new downloads without the others reporting? I did get some downloads earlier but they all haven't downloaded yet.

Reporting and work fetch are done in a sched_request, usually they'll either both be successful or neither.

During the outage they found at least one more file to be split for AP, and adding that to the nearly full pipe caused by MB 'shorties' has saturated things for now. I'll guess about 5 hours before the APs are all out, or if some longer MB work turns up the difficulties could end sooner.

                                                               Joe

Ok, thanks. Patiently waiting,hoping for the best.

---

OK thanks for this info, switched on this morning and one wu could not upload. Usual after an outage so I too will wait it out

---

During the outage they found at least one more file to be split for AP, and adding that to the nearly full pipe caused by MB 'shorties' has saturated things for now. I'll guess about 5 hours before the APs are all out, or if some longer MB work turns up the difficulties could end sooner.

                                                               Joe

All the AP tapes have gone from the server status page - presumably split at maximum possible speed by all four splitters working at once, with the biggest possible impact on bandwidth - yup, Scarecrow's daemon history page confirms that. And they finished just as the new daily quota kicked in. Be a while before the mammoths move on from the watering hole, and the rest of us can take a sip.

Finally got the earlier DL's to go thru, and after waiting some more, got the uploads to go thru.
Now
SETI@home Message from server: (Project has no jobs available)
Seems to be the theme of my messages :P

Getting a few shorties though so I'm still plugging along.

---

During the outage they found at least one more file to be split for AP, and adding that to the nearly full pipe caused by MB 'shorties' has saturated things for now. I'll guess about 5 hours before the APs are all out, or if some longer MB work turns up the difficulties could end sooner.

                                                               Joe

All the AP tapes have gone from the server status page - presumably split at maximum possible speed by all four splitters working at once, with the biggest possible impact on bandwidth - yup, Scarecrow's daemon history page confirms that. And they finished just as the new daily quota kicked in. Be a while before the mammoths move on from the watering hole, and the rest of us can take a sip.

That's the West coast mammoths probably. For us Europeans that do not run 24/7, we probably switch off before Matt, et al, finish work, and then the AP tasks are all taken before we switch back on the following morning.

During the outage they found at least one more file to be split for AP, and adding that to the nearly full pipe caused by MB 'shorties' has saturated things for now. I'll guess about 5 hours before the APs are all out, or if some longer MB work turns up the difficulties could end sooner.

                                                               Joe

All the AP tapes have gone from the server status page - presumably split at maximum possible speed by all four splitters working at once, with the biggest possible impact on bandwidth - yup, Scarecrow's daemon history page confirms that. And they finished just as the new daily quota kicked in. Be a while before the mammoths move on from the watering hole, and the rest of us can take a sip.

That's the West coast mammoths probably. For us Europeans that do not run 24/7, we probably switch off before Matt, et al, finish work, and then the AP tasks are all taken before we switch back on the following morning.

Do mammoths ever sleep?

Servers seem slow but i did get some work for this new i7. And was able to return some work from the other two crunchers.

---

[/quote]

Old James

Hi, I received a lot of work on 3 QUAD's, but saw some ERROR's too, all MB WU's ending after 1 second.
I'll have a look into it.

---

Hi, I received a lot of work on 3 QUAD's, but saw some ERROR's too, all MB WU's ending after 1 second.
I'll have a look into it.

VLAR WU (AR: 0.010580 )detected... autokill initialised
SETI@home error -6 Bad workunit header

Looks like VLAR kill so far with the ones returned recently.

---

Four new tapes loaded, four AP splitters running, downloads maxxed out, uploads stalled - we're back to the good old days, before the doubled sensitivity (and the new data disks don't seem to have arrived from Arecibo yet - it's all old data).

And the Assimilators haven't assimilated anything for the last few days.
Log jam approaching.

---

Grant
Darwin NT

Four new tapes loaded, four AP splitters running, downloads maxxed out, uploads stalled - we're back to the good old days, before the doubled sensitivity (and the new data disks don't seem to have arrived from Arecibo yet - it's all old data).

One thing I just thought of..and maybe this has been mentioned before..

Is there any reason why we have to have four splitters running for AP? I know they work really well when they work on the same tape, whereas MB works better on separate tapes.. but I noticed that with the 97:3 ratio for the feeder cache, AP is still burning through tapes much faster than MB. So if they were to cut back to just one splitter..would that help anything?

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

Looks like Anakin is having problems currently as I cannot even report finished uploads right now.

---

Four new tapes loaded, four AP splitters running, downloads maxxed out, uploads stalled - we're back to the good old days, before the doubled sensitivity (and the new data disks don't seem to have arrived from Arecibo yet - it's all old data).

One thing I just thought of..and maybe this has been mentioned before..

Is there any reason why we have to have four splitters running for AP? I know they work really well when they work on the same tape, whereas MB works better on separate tapes.. but I noticed that with the 97:3 ratio for the feeder cache, AP is still burning through tapes much faster than MB. So if they were to cut back to just one splitter..would that help anything?

Sure it would. The four ap_splitter processes together manage to produce about 0.6 tasks per second, even dropping to two would halve that and reduce the average amount of download bandwidth for AP from ~42 MBits/second to ~21 MBits/second. Reducing the number of mb_splitter processes to three then might be enough to let "Results ready to send" queues empty out. After that, work delivery would be just what the splitters could produce between each Feeder run. To the extent the download saturation is directly responsible for difficulty in uploading and contacting the Scheduler that should help a lot. We'd get a lot of "(Project has no work available)" responses to work requests, but that's better than no response at all.

The mb_splitter processes each work on a different file as an attempt to avoid getting all 'shorty' work, which doesn't always work. Both kinds of splitters use the same routine to get data from a tape channel, it probably doesn't make a lot of difference if those channels are from the same file or different files, though having fewer files in play at one time would obviously be at least slightly less system load.

                                                              Joe

Four new tapes loaded, four AP splitters running, downloads maxxed out, uploads stalled - we're back to the good old days, before the doubled sensitivity (and the new data disks don't seem to have arrived from Arecibo yet - it's all old data).

One thing I just thought of..and maybe this has been mentioned before..

Is there any reason why we have to have four splitters running for AP? I know they work really well when they work on the same tape, whereas MB works better on separate tapes.. but I noticed that with the 97:3 ratio for the feeder cache, AP is still burning through tapes much faster than MB. So if they were to cut back to just one splitter..would that help anything?

Sure it would. The four ap_splitter processes together manage to produce about 0.6 tasks per second, even dropping to two would halve that and reduce the average amount of download bandwidth for AP from ~42 MBits/second to ~21 MBits/second. Reducing the number of mb_splitter processes to three then might be enough to let "Results ready to send" queues empty out. After that, work delivery would be just what the splitters could produce between each Feeder run. To the extent the download saturation is directly responsible for difficulty in uploading and contacting the Scheduler that should help a lot. We'd get a lot of "(Project has no work available)" responses to work requests, but that's better than no response at all.

The mb_splitter processes each work on a different file as an attempt to avoid getting all 'shorty' work, which doesn't always work. Both kinds of splitters use the same routine to get data from a tape channel, it probably doesn't make a lot of difference if those channels are from the same file or different files, though having fewer files in play at one time would obviously be at least slightly less system load.

                                                              Joe

I was thinking of some sort of chron job that looked at the progress splitting AP, and the progress splitting MB, and maybe stopped three of the AP splitters if they got well-ahead of MB.

That could be done without modifying BOINC.

---

Still no assimilating by the Assimilators.

---

Grant
Darwin NT

Network traffic's taken a dive, even though there's work ready to send & the splitters are still running.

---

Grant
Darwin NT