From the info provided on the SSP down at the bottom of the page "(each file contains data for 14 channels)" but that doesn't answer your question.

I don't know the exact number of tasks per file other than guessing that 52.45GB ÷ 703KB per task = 74608 tasks. But how much overhead is involved with each task generation is unknown.

. . Well I am thinking a couple of Kb maybe for the file header and EOF, plus a small overlap for piecing the jigsaw puzzle back together, so the nett size from the original channel file might be somewhat smaller than the 703Kb, maybe as low as 675-680 Kb. So 52.45 /0.000675 would still be less than 78K tasks per tape, giving approx. 5,500 WUs per channel. But that is purely guesswork obviously.

Stephen

? ?

From the info provided on the SSP down at the bottom of the page "(each file contains data for 14 channels)" but that doesn't answer your question.

That's a leftover from the old Arecibo only days. ;-)

It's also about time that the MB V7 part was put to sleep too.

Cheers.

. . But the stats page says there are still some out there ... :)

Stephen

:)

From the info provided on the SSP down at the bottom of the page "(each file contains data for 14 channels)" but that doesn't answer your question.

That's a leftover from the old Arecibo only days. ;-)

It's also about time that the MB V7 part was put to sleep too.

Cheers.

. . But the stats page says there are still some out there ... :)

Stephen

:)

There have been none "out there" for over a year now and it just requires manual purging of the 71 results that have been sitting there waiting for that to be done. ;-)

Cheers.

That's a leftover from the old Arecibo only days. ;-)
It's also about time that the MB V7 part was put to sleep too.

. . But the stats page says there are still some out there ... :)

There have been none "out there" for over a year now and it just requires manual purging of the 71 results that have been sitting there waiting for that to be done. ;-)

Cheers.

. . Getting rid of that unnecessary part of the status page would free up some space for the display ...

Stephen

:)

I am purely Seti@Home.
I started out on a work computer with my boss's permission for a short while back on July 9th 2000. Just for few months.
Then I started to build my own rigs, and every kibblestone since has been crunched right here in the kitty crunching den in my home.

---

"Time is simply the mechanism that keeps everything from happening all at once."

Until CreditScrew is abolished, and AP is available every day again, my RAC will be just around 400.
I will only run one 4-Watt Android tablet.

This one will level out at around RAC 400. when run 24/7:
https://setiathome.berkeley.edu/show_host_detail.php?hostid=7944083

Now, it's just at around RAC 75, because it's been running full time on Beta.
No more Beta at all, with any of my computers, or the tablet.
Fix the credit, and fix AP availability, and I may reconsider the decision.....

But then, who cares, when Seti@home nowadays have evolved into Seti@datacenters, and/or Seti@My_Own_Nuclear_Power_Station ?

. . Hi Tut,

. . Your messages look odd without your usual avatar/picture

. . But the thing is that, even though there is some competitiveness over RAC, this project is about overall co-operative productivity. There are a lot of straws to sift through in this haystack and we all need to make the maximum effort to get through them. The farms out there with 187 hosts ( a little poetic licence there, the biggest I have seen only had 129 hosts :) ) are a bit intimidating but we are all working towards the same goal. I focus on the number of tasks I can process in a day as the measure of my contribution, not RAC. I am certainly no fan of CreditScrew but I won't let it obscure the reason I am taking part in this project.

Stephen

:)

+1

Well Said Stephen

You can buy lots of lotto tickets to win the big one, but it only takes one ticket to win!!

Something is weird with the SSP. It's shows:

Current result creation rate **	/sec	/sec	/sec

With no numeral on all 3 columns.

---

I noticed that as well.
Eric told me has was looking into the poor creation rate and falling RTS.
That does not necessarily mean he can fix it immediately or find the root problem instantly.
I also let him know about those nulls on the SSP.

Meowsigh.

---

"Time is simply the mechanism that keeps everything from happening all at once."

Great, splitter issues. And here I was thinking I would be able to verify my estimate of how many channels are necessary to make it week to week on outage Tuesday with no project upsets in between.

I was thinking my previous estimate was right on the mark.

---

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

A proud member of the OFA (Old Farts Association)

Well, I see that the splitters barely managed to keep some RTS in queue overnight.
I am sure Eric (or Jeff) will be looking at the meager splitter output later this morning.
And he told me he didn't think he ever saw that null for the splitter output on the SSP either.
(It's only 5:30AM in Berkeley right now.)

Meow!

---

"Time is simply the mechanism that keeps everything from happening all at once."

Well, that 'meagre' splitter output replaced a steady 120,000 returned tasks per hour (over 30 tasks per second), and still managed to increase the RTS slightly - not too shabby when they're not feeling well.

Well, that 'meagre' splitter output replaced a steady 120,000 returned tasks per hour (over 30 tasks per second), and still managed to increase the RTS slightly - not too shabby when they're not feeling well.

Yes, after watching them for a few hours last night before I retired, I was pleasantly surprised this morning to see that they had kept their heads above water.

---

"Time is simply the mechanism that keeps everything from happening all at once."

Creation rates are back.

Cheers.

Glad the staff was able to fix that without more upset. Very helpful to know the creation rate, RTS buffer and tasks returned per hour to know whether the splitters are able to keep up with demand.

There is still something wrong with the transitioner though. Haveland transitioner graph has been flatlined for a day.

---

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

A proud member of the OFA (Old Farts Association)

Glad the staff was able to fix that without more upset. Very helpful to know the creation rate, RTS buffer and tasks returned per hour to know whether the splitters are able to keep up with demand.

There is still something wrong with the transitioner though. Haveland transitioner graph has been flatlined for a day.

. . And the last time I looked it was 422,000 hours behind ... ???

Stephen

??

There is still something wrong with the transitioner though. Haveland transitioner graph has been flatlined for a day.

. . And the last time I looked it was 422,000 hours behind ... ???

Stephen

??

That only adds up to a little over 48 years

---

Sometimes I wonder, what happened to all the people I gave directions to?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SETI@home classic workunits 4,321
SETI@home classic CPU time 22,169 hours

I wonder if the transitioner backlog error was somehow tied to the missing creation rate values for most of yesterday. Those got fixed late in the day but the transitioner reporting is still out to lunch.

---

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

A proud member of the OFA (Old Farts Association)

Sounds likely. 422,146 hours backlog is something over 48 years, which takes us back to early 1970. Sound familiar? Unix time zero?

Sounds likely. 422,146 hours backlog is something over 48 years, which takes us back to early 1970. Sound familiar? Unix time zero?

I think you have likely deduced the issue Richard.

---

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

A proud member of the OFA (Old Farts Association)