I have noticed that my rac has been dropping so i decided to look at some of my results.
http://setiathome.berkeley.edu/results.php?userid=7987639&offset=120

Why is it now taking me 14000+ seconds to complete a WU that gives me 63 credits, despite me claiming 75? It used to take 9000-10000 seconds and i would get around 63 credits. Why is it taking so much longer, and what is with these oddly large WUs worth over 100 credits??

---

I have noticed that my rac has been dropping so i decided to look at some of my results.
http://setiathome.berkeley.edu/results.php?userid=7987639&offset=120

Why is it now taking me 14000+ seconds to complete a WU that gives me 63 credits, despite me claiming 75? It used to take 9000-10000 seconds and i would get around 63 credits. Why is it taking so much longer, and what is with these oddly large WUs worth over 100 credits??

You've not been doing much reading in this forum lately, have you? LOL.
You are getting 63 credits rather than 75 because that is the correct credit claim.
The credit multiplier for the project was recently reduced to try to bring Seti into parity with the other Boinc projects. There has been much discussion lately as to exactly what it is doing to Seti.
Anyway, you are still runnning the old 2.2b Chicken app, you need to update to the corrected 2.4 Chicken app so you are claiming the correct credit amounts.
And the change in crunch times is due to the changeover to the new MB (MultiBeam) data that is now being issued. It take longer to process than the old linefeed work units, and the crunch times seem to vary over a wider range with a greater variance in credit (including a few in the 3 digit range) than the old linefeed work.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

I have noticed that my rac has been dropping so i decided to look at some of my results.
http://setiathome.berkeley.edu/results.php?userid=7987639&offset=120

Why is it now taking me 14000+ seconds to complete a WU that gives me 63 credits, despite me claiming 75? It used to take 9000-10000 seconds and i would get around 63 credits. Why is it taking so much longer, and what is with these oddly large WUs worth over 100 credits??

You've not been doing much reading in this forum lately, have you? LOL.
You are getting 63 credits rather than 75 because that is the correct credit claim.
The credit multiplier for the project was recently reduced to try to bring Seti into parity with the other Boinc projects. There has been much discussion lately as to exactly what it is doing to Seti.
Anyway, you are still runnning the old 2.2b Chicken app, you need to update to the corrected 2.4 Chicken app so you are claiming the correct credit amounts.
And the change in crunch times is due to the changeover to the new MB (MultiBeam) data that is now being issued. It take longer to process than the old linefeed work units, and the crunch times seem to vary over a wider range with a greater variance in credit (including a few in the 3 digit range) than the old linefeed work.

O.
I have been enlightened :P

---

I have noticed that my rac has been dropping so i decided to look at some of my results.
http://setiathome.berkeley.edu/results.php?userid=7987639&offset=120

Why is it now taking me 14000+ seconds to complete a WU that gives me 63 credits, despite me claiming 75? It used to take 9000-10000 seconds and i would get around 63 credits. Why is it taking so much longer, and what is with these oddly large WUs worth over 100 credits??

You've not been doing much reading in this forum lately, have you? LOL.
You are getting 63 credits rather than 75 because that is the correct credit claim.
The credit multiplier for the project was recently reduced to try to bring Seti into parity with the other Boinc projects. There has been much discussion lately as to exactly what it is doing to Seti.
Anyway, you are still runnning the old 2.2b Chicken app, you need to update to the corrected 2.4 Chicken app so you are claiming the correct credit amounts.
And the change in crunch times is due to the changeover to the new MB (MultiBeam) data that is now being issued. It take longer to process than the old linefeed work units, and the crunch times seem to vary over a wider range with a greater variance in credit (including a few in the 3 digit range) than the old linefeed work.

O.
I have been enlightened :P

No problem...if you have the time and read some of the threads of the last week or so, you will find that some of the discussion on these topics has been, shall we say, rather animated. But never be afraid to ask, that's what these forums are for.
HTH,
Mark.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

I have noticed that my rac has been dropping so i decided to look at some of my results.
http://setiathome.berkeley.edu/results.php?userid=7987639&offset=120

Why is it now taking me 14000+ seconds to complete a WU that gives me 63 credits, despite me claiming 75? It used to take 9000-10000 seconds and i would get around 63 credits. Why is it taking so much longer, and what is with these oddly large WUs worth over 100 credits??

You've not been doing much reading in this forum lately, have you? LOL.
You are getting 63 credits rather than 75 because that is the correct credit claim.
The credit multiplier for the project was recently reduced to try to bring Seti into parity with the other Boinc projects. There has been much discussion lately as to exactly what it is doing to Seti.
Anyway, you are still runnning the old 2.2b Chicken app, you need to update to the corrected 2.4 Chicken app so you are claiming the correct credit amounts.
And the change in crunch times is due to the changeover to the new MB (MultiBeam) data that is now being issued. It take longer to process than the old linefeed work units, and the crunch times seem to vary over a wider range with a greater variance in credit (including a few in the 3 digit range) than the old linefeed work.

O.
I have been enlightened :P

No problem...if you have the time and read some of the threads of the last week or so, you will find that some of the discussion on these topics has been, shall we say, rather animated. But never be afraid to ask, that's what these forums are for.
HTH,
Mark.

Problem solved, i installed the new app. I'm sure ill read the threads someday, but right now im going to bed.

---

Problem solved, i installed the new app. I'm sure ill read the threads someday, but right now im going to bed.

Thank you for doing the update!

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

You'll lose RAC anyway, as the balance in the quorums swings.

If you switch now, you may lose RAC, but you'll gain the respect of the majority of the crunching community.

I know which I'd prefer to have.

There's a lot of credit disparity with the current setup and units, about four-to-one. That is, the credits-per-hour claimed varies that much. In my case it takes from 75 to 300 seconds for my PD950s to gain one credit, depending on the workunit. In my case, 19-credit units are sweet, 25-to-40-credit units are excrement. The averaging effect mitigates a lot of this variation. Simons latest (2.4) claims the correct credit, which is less than before, but it also goes a little faster than the superseded 2.2B.

---

There's a lot of credit disparity with the current setup and units, about four-to-one. That is, the credits-per-hour claimed varies that much. In my case it takes from 75 to 300 seconds for my PD950s to gain one credit, depending on the workunit. In my case, 19-credit units are sweet, 25-to-40-credit units are excrement. The averaging effect mitigates a lot of this variation. Simons latest (2.4) claims the correct credit, which is less than before, but it also goes a little faster than the superseded 2.2B.

Yep, I've been seeing that in my data logs too. Most likely because the spectrum of AR's run in Beta was not as comprehensive as we see here on the main project.

What I'm seeing develop is the mid range ones are low compared to the high and low ends. I'm sure Eric will look at this carefully when he gets back from vacation.

Alinator

...
What I'm seeing develop is the mid range ones are low compared to the high and low ends. I'm sure Eric will look at this carefully when he gets back from vacation.

Alinator

Mid range from 0.4 to 0.8 is bad, 0.8 to 1.127 is putrid, but 0.2258 to 0.4 is decent. VLAR's from 0 to 0.05 (63.98 credits) are somewhat better than than the dread 58.7 equivalents in Line feed work, 0.05 to 0.225 increasingly good as the high end is approached. VHAR's of 1.13 and above can be good for newer systems and bad for older.

I too hope the project will use the adjustable credit rate (once it's in the apps) to equalize rates, but I doubt it will be a high priority effort.

                                                                 Joe

Mid range from 0.4 to 0.8 is bad, 0.8 to 1.127 is putrid, but 0.2258 to 0.4 is decent. VLAR's from 0 to 0.05 (63.98 credits) are somewhat better than than the dread 58.7 equivalents in Line feed work, 0.05 to 0.225 increasingly good as the high end is approached. VHAR's of 1.13 and above can be good for newer systems and bad for older.

I too hope the project will use the adjustable credit rate (once it's in the apps) to equalize rates, but I doubt it will be a high priority effort.

                                                                 Joe

Thanks for that input, Joe. I'm sure you have far more data to work with than my pitiful collection of 'junk' has been able to collect so far since the rollout.

Just one question about the AR spectrum. Does the .2258 to .4 range correspond roughly to the previous mainstream 'sweet spot' we were seeing with the old LF data? I know you talked about this over on Beta, but I couldn't put my finger on the exact thread when I went looking for it.

Alinator

I've got about 150 logged so far (sticking to the stock application only), and my 'sweet spot' is around 0.28: some of the ones above 1.17 are good, but that range seems to be very variable.

I agree with Joe that most of 0.8 to 1.127 is putrid: in fact, mine start going seriously downhill from about 0.49 - but I've got a little (relative) spike at 0.93. The 1.08 ones themselves are abysmal, and the worst by a long way.

I'm getting quite a lot of good data from Crunch3r's optimisation now, so it might be fun to plot it alongside. Not done yet, but I'll try and post the graphs in a few days when hopefully some more of the gaps will have been filled in.

I've got about 150 logged so far (sticking to the stock application only), and my 'sweet spot' is around 0.28: some of the ones above 1.17 are good, but that range seems to be very variable.

I agree with Joe that most of 0.8 to 1.127 is putrid: in fact, mine start going seriously downhill from about 0.49 - but I've got a little (relative) spike at 0.93. The 1.08 ones themselves are abysmal, and the worst by a long way.

I'm getting quite a lot of good data from Crunch3r's optimisation now, so it might be fun to plot it alongside. Not done yet, but I'll try and post the graphs in a few days when hopefully some more of the gaps will have been filled in.

Are you referrng to the latest revision to get 32 bit to work on Vista? That would be good news indeed.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

Are you referrng to the latest revision to get 32 bit to work on Vista? That would be good news indeed.

Look at the bulletin board at lunatics.at: I think he's just put it into public Beta.

Are you referrng to the latest revision to get 32 bit to work on Vista? That would be good news indeed.

Look at the bulletin board at lunatics.at: I think he's just put it into public Beta.

Looks like I got home in good time. I'm on my way over there now.

...
Just one question about the AR spectrum. Does the .2258 to .4 range correspond roughly to the previous mainstream 'sweet spot' we were seeing with the old LF data? I know you talked about this over on Beta, but I couldn't put my finger on the exact thread when I went looking for it.

Alinator

The very common Line feed angle ranges near 0.426 with 62.4 credits correspond to a Multibeam angle range of about 0.256, if that answers the question. And 0.664 Line feed corresponds to 0.4 Multibeam.

                                                                 Joe

...
Just one question about the AR spectrum. Does the .2258 to .4 range correspond roughly to the previous mainstream 'sweet spot' we were seeing with the old LF data? I know you talked about this over on Beta, but I couldn't put my finger on the exact thread when I went looking for it.

Alinator

The very common Line feed angle ranges near 0.426 with 62.4 credits correspond to a Multibeam angle range of about 0.256, if that answers the question. And 0.664 Line feed corresponds to 0.4 Multibeam.

                                                                 Joe

Yep, that answered the question, thanks.

Alinator

Joe, how come they've reduced the "most common angle range"? I see the reduction is by about 40 percent. Does that mean that the study period has been reduced from 107 seconds to about 64 seconds? Thanks.

---

Joe, how come they've reduced the "most common angle range"? I see the reduction is by about 40 percent. Does that mean that the study period has been reduced from 107 seconds to about 64 seconds? Thanks.

This is the answer Joe gave in Beta post 11097 about the change in beamwidth of MB compared to the old line feed receiver/antenna;

Compensating for the changed beam width, 0.481 * 1.66 = 0.798 AR. Here's your result 1090785 at 0.7826, which seems to have very similar CS/h rate.

It is slightly unfortunate that the drop in credit rate where Pulse finding ends for the 8K fft length which was at 0.664 is now at 0.4 AR. But keep in mind that 5.17 has a 13.7% credit boost over 5.15. That should help if the move to the main project can coordinate so ALFA work and 5.17 arrive at the same time.

I think you'll find VHAR and VLAR units about the same as the old WUs. 0 times 1.66 is still 0, and for VHAR time and credits are dominated by FFTs, Chirping, and Spike finding which haven't changed materially.

Joe

Joe, how come they've reduced the "most common angle range"? I see the reduction is by about 40 percent. Does that mean that the study period has been reduced from 107 seconds to about 64 seconds? Thanks.

The "most common angle range" of about 0.426 for Line feed work was when the antenna was parked and not being used for active observations. The receiver for the Line feed was left on, the data was recorded, so it was available for crunching. We've covered that narrow strip of the Arecibo sky very thoroughly.

The Multibeam recorder is taking input from the ALFA receiver system in the Gregorian housing, that receiver system is only used for some observations so is off at other times and the recorder stops recording then. Long-term I think we can expect a different pattern of "most common angle range" than we've seen so far. Sky survey work for which the ALFA receiver system is intended should largely consist of either drift scans with angle ranges from 0.34 to 0.45 or basketweave scans with angle ranges above 1.5. But the ALFA receiver system is very sensitive and low noise so other kinds of observations for which its frequency range are appropriate will also use it.

                                                               Joe