. . <smirk>

mb_splitter/ap_splitter: Reads tapes (or tape images on disk) containing raw telescope data and creates SETI@home (multi-beam) or Astropulse workunits for the BOINC/SETI@home clients. At least one needs to be running to produce work, and that's usually enough.

. . nuff said :)

Stephen

:)

I noticed that gbt_splitter#4 got briefly pulled from duty. Now back. I wonder if it was hanging up the output. Really frustrating that my Linux box is still unable to get any appreciable work while my slow Windows7 boxes have mostly full caches.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Really frustrating that my Linux box is still unable to get any appreciable work while my slow Windows7 boxes have mostly full caches.

I noticed that as well... I'm sure some would disagree but I see it with my own eyes: even with a zero resource share, if E@H has minimal work (one WU per slot running and zero cached) and SETI@Home is empty, BOINC often stops asking for SETI@Home work (has zero work units and it's just sitting with no countdown timer to next scheduler request) and I have to hit Update manually to remind it. Well I did that with six fast Linux machines and they got zilch and the seventh was my wife's slower SoG Win7 box and presto... 130 tasks. Just the luck of the draw (I hope.)

---

I noticed that gbt_splitter#4 got briefly pulled from duty. Now back. I wonder if it was hanging up the output. Really frustrating that my Linux box is still unable to get any appreciable work while my slow Windows7 boxes have mostly full caches.

The guys are probably trying to break up the congregation of splitters working on the 1st GBT file in the list (still looks to be a half dozen splitters still working on the 1 file when you zoom in on it) and get them working on other files instead and you just caught them in the act. ;-)

Cheers.

I noticed that gbt_splitter#4 got briefly pulled from duty. Now back. I wonder if it was hanging up the output. Really frustrating that my Linux box is still unable to get any appreciable work while my slow Windows7 boxes have mostly full caches.

. . Ironic as it may be for once I have the opposite experience. Both Linux boxes received nearly full caches (over many requests) while the Windows box got work right away for the GPU but struggled over many many attempts before getting any work for the CPU. I had to reschedule WUs from the GPU Q.

Stephen

? ?

I finally had to shut off gpu work entirely for the project and wait through 4 request cycles before the servers finally decided to send me 40 cpu tasks on the Linux machine. I haven't had any cpu tasks from Seti for 2 days now on that machine until just now.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

I noticed that gbt_splitter#4 got briefly pulled from duty. Now back. I wonder if it was hanging up the output. Really frustrating that my Linux box is still unable to get any appreciable work while my slow Windows7 boxes have mostly full caches.

. . Ironic as it may be for once I have the opposite experience. Both Linux boxes received nearly full caches (over many requests) while the Windows box got work right away for the GPU but struggled over many many attempts before getting any work for the CPU. I had to reschedule WUs from the GPU Q.

Stephen

? ?

I'm absolutely convinced that the project ignores Ryzen machines for work requests. Couldn't get work on the Windows Ryzen either.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Creation time is at 72 a second at the moment. That's the highest I've ever seen it. Most of my machines have a full cache - a couple of them I did have to kick start though.

0 results ready to send and number of units received in the last hour is at 55k but I would imagine those numbers will return to normal in the next few hours.

---

~Chris

Hard to say exactly what the state of play is with the replica being over an hour behind the master....

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

....from the number of tasks on my crunchers it looks as if the splitters are spluttering again :-(

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

I'd allowed one of my single GPU machines to help Einstein for a while. I've just given it a prod to restore normal service, and got the full 100 at the first request. As somebody said, it's the luck of the draw.

Caches are full and RAC is steadily dropping
............everything back to normal and the Credit Screw is turning as usual.

---

"Sour Grapes make a bitter Whine." <(0)>

Caches are full and RAC is steadily dropping...

Indeed... the lack of work accelerated the fall to where it was going to end up anyways; ripping off the proverbial bandage.

---

Those who use Einstein as a backup project should take note and have a sufficient cache next Tuesday or they may very well run out of work.
Einstein has decided to join the fun by stating

We are going to shut down the project next Tuesday, Jan 23rd at around 10 AM CET for an upgrade of our database backend systems to make them ready for the years to come. We're going to upgrade hardware parts, operating systems as well the databases themselves, which is why we need to shut down the entire project, including the BOINC backend and this very website.

We should have the pleasure of a double outrage.

---

Those who use Einstein as a backup project should take note and have a sufficient cache next Tuesday or they may very well run out of work.
Einstein has decided to join the fun by stating

We are going to shut down the project next Tuesday, Jan 23rd at around 10 AM CET for an upgrade of our database backend systems to make them ready for the years to come. We're going to upgrade hardware parts, operating systems as well the databases themselves, which is why we need to shut down the entire project, including the BOINC backend and this very website.

We should have the pleasure of a double outrage.

Yeah, it is a shame about the scheduling. Any other day would have sufficed ...

---

Can always choose another backup project. I'll have MilkyWay and GPUGrid.net as backups also. Though if I build a big enough cache of Einstein work, that shouldn't be an issue either.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Yeah, it is a shame about the scheduling. Any other day would have sufficed ...

But a double outrage is something to behold.

---

Can always choose another backup project. I'll have MilkyWay and GPUGrid.net as backups also. Though if I build a big enough cache of Einstein work, that shouldn't be an issue either.

Last time I crossed swords with MilkyWay, it was appallingly badly managed. And GPUGrid is giving me RSI in the mouse-click finger, because I run it but have extreme difficulty snagging new work.

Can always choose another backup project. I'll have MilkyWay and GPUGrid.net as backups also. Though if I build a big enough cache of Einstein work, that shouldn't be an issue either.

Last time I crossed swords with MilkyWay, it was appallingly badly managed. And GPUGrid is giving me RSI in the mouse-click finger, because I run it but have extreme difficulty snagging new work.

MilkyWay?? Badly managed?? Wow, very different experience here.. MW is the most set and forget project I have run. I never have to micromanage it at all. I love the hard limit of 80 tasks per gpu at any one time. Never a chance of getting too much work and never any chance of running out. I only crunch gpu tasks so that means I have run the Binary Pulsar Search while it lasted and now run the Gamma Ray Pulsar Search. The only issues I have seen with the project is the occasional bad work unit that promptly gets tossed out very quickly. The servers seem to stay up for very long times, months at a time in fact.

Yes, I have just recently joined GPUGrid.net and the gpu work availability is very spotty and random. The tasks when they are made available are quickly gobbled up by many fingers bashing the update button. The cpu work for Linux hosts has had work available pretty much all the time. No problem getting cpu work for the Linux host. We are asking the project scientists to make the cpu work available for Windows too.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Well, I found it necessary to make Post 58550. Read through to Post 58572, and note his titles.