The credit rate for MB and AP was approximately the same, when calculated for the default applications, and before CUDA was introduced.
The MB credit is now down a significant amount because CUDA does not claim correctly or report the time correctly. This AFAIK is a BOINC not a Seti problem.
And the perceived AP credit rate is very high because the optimised app is 3 to 4 times quicker than the default app, this will probably be corrected when the default app is more mature.

The credit rate for MB and AP was approximately the same, when calculated for the default applications, and before CUDA was introduced.
The MB credit is now down a significant amount because CUDA does not claim correctly or report the time correctly. This AFAIK is a BOINC not a Seti problem.
And the perceived AP credit rate is very high because the optimised app is 3 to 4 times quicker than the default app, this will probably be corrected when the default app is more mature.

My point is........those that care about credits are usually running opti......

And if opti AP pays better than opti MB.....guess what the kitties will run???

Ya want me to run MB.......raise the bar so I am not taking a hit to do so.

---

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

The credit rate for MB and AP was approximately the same, when calculated for the default applications, and before CUDA was introduced.
The MB credit is now down a significant amount because CUDA does not claim correctly or report the time correctly. This AFAIK is a BOINC not a Seti problem.

Eric had admitted a while ago that AP was at a higher credit multiplier than MB, thus granted higher credit than MB.

The problem with CUDA is not that it underclaims; its that it overclaims. This will not drag down the MB granted credit at all, except when its paired with a CPU app, but then the problem merely "fixes" itself because the lower will get granted, and in this case, the lower is the right credit.

And the perceived AP credit rate is very high because the optimised app is 3 to 4 times quicker than the default app, this will probably be corrected when the default app is more mature.

The optimized apps do not claim more credit, they simply allow more work to be done in the same amount of time, thus, if you look at it from a credit/hr perspective, they grant more credit, but the optimized app claims the same amount of credit when compared to stock apps.

---

The credit rate for MB and AP was approximately the same, when calculated for the default applications, and before CUDA was introduced.
The MB credit is now down a significant amount because CUDA does not claim correctly or report the time correctly. This AFAIK is a BOINC not a Seti problem.
And the perceived AP credit rate is very high because the optimised app is 3 to 4 times quicker than the default app, this will probably be corrected when the default app is more mature.

My point is........those that care about credits are usually running opti......

And if opti AP pays better than opti MB.....guess what the kitties will run???

Ya want me to run MB.......raise the bar so I am not taking a hit to do so.

This goes back into the discussion about credit inflation. Raise MB so that more people do it for the credit and you start veering off from the standard that has been set for Cobblestones. It would be better to fix AP's credit granting so things are on par again.

...and optimized AP does not pay better. See my last post; optimized AP does not claim more, so therefore it does not "pay" better, despite what has been read around here. Optimized AP simply allows more work to be done, thus granting more credit/hr but the claimed credit is the same.

Its the same story of optimized SETI vs. stock SETI. Optimized does not pay better, it simply allows more work to be done, but it claims the same as stock.


So essentially, what you guys are really saying is: "do away with optimized apps so that the illusion of higher paid credit goes away and everyone is on the same playing field and no one gets a higher credit per hour than anyone else", though you may not realize this at first.

---

[quote}So essentially, what you guys are really saying is: "do away with optimized apps so that the illusion of higher paid credit goes away and everyone is on the same playing field and no one gets a higher credit per hour than anyone else", though you may not realize this at first.
[/quote]
Next, we will need to do away with all the OC systems, and does pesky 4Gz CPU. Also those Nvidia cards are just too fast.

[quote}So essentially, what you guys are really saying is: "do away with optimized apps so that the illusion of higher paid credit goes away and everyone is on the same playing field and no one gets a higher credit per hour than anyone else", though you may not realize this at first.

Next, we will need to do away with all the OC systems, and does pesky 4Gz CPU. Also those Nvidia cards are just too fast.[/quote]
Arrrrrrrrghhhhhhhhhhh.........this is getting tired......

The kitties have their kibble bowls full.......all is good, I am going to sleep now........

Enough.

---

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

I see two major problems currently with the Seti project.

First.............New crunchers sign up, download a lot of work then dissappear, never to be heard from again. I would propose a window that pops up when downloading Boinc that explains. "This is a long term science project and requires a long term commitment by you and your computer. If you do not intend to be a long term participant then perhaps distributed computing is not for you and your computer. Boinc will make use of ALL the spare cycles of the CPU and possibly the GPU and this is by design. The ramifications of that can be excessive heating of the CPU and or GPU if adequate cooling is not in place before installing Boinc."

Second............Excessive delay's in granted credits for AP work. I would propose that new crunchers be limited to MB work only. The option to crunch AP should NOT be granted automatically to new crunchers. They should be able to make the selection once they know and understand the requirements of AP and 30 days have elapsed since joining Seti.

---

Boinc....Boinc....Boinc....Boinc....

I see two major problems currently with the Seti project.

First.............New crunchers sign up, download a lot of work then dissappear, never to be heard from again. I would propose a window that pops up when downloading Boinc that explains. "This is a long term science project and requires a long term commitment by you and your computer. If you do not intend to be a long term participant then perhaps distributed computing is not for you and your computer. Boinc will make use of ALL the spare cycles of the CPU and possibly the GPU and this is by design. The ramifications of that can be excessive heating of the CPU and or GPU if adequate cooling is not in place before installing Boinc."

Second............Excessive delay's in granted credits for AP work. I would propose that new crunchers be limited to MB work only. The option to crunch AP should NOT be granted automatically to new crunchers. They should be able to make the selection once they know and understand the requirements of AP and 30 days have elapsed since joining Seti.

Excuse me, but I have had a few drinks tonight and I am getting a little snarky............


PLEASE..quit bringing up the delay in credit granting.....it has beaten quite to death.......you will get them sooner or later.........

---

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

I see two major problems currently with the Seti project.

First.............New crunchers sign up, download a lot of work then dissappear, never to be heard from again. I would propose a window that pops up when downloading Boinc that explains. "This is a long term science project and requires a long term commitment by you and your computer. If you do not intend to be a long term participant then perhaps distributed computing is not for you and your computer. Boinc will make use of ALL the spare cycles of the CPU and possibly the GPU and this is by design. The ramifications of that can be excessive heating of the CPU and or GPU if adequate cooling is not in place before installing Boinc."

Second............Excessive delay's in granted credits for AP work. I would propose that new crunchers be limited to MB work only. The option to crunch AP should NOT be granted automatically to new crunchers. They should be able to make the selection once they know and understand the requirements of AP and 30 days have elapsed since joining Seti.

Excuse me, but I have had a few drinks tonight and I am getting a little snarky............


PLEASE..quit bringing up the delay in credit granting.....it has beaten quite to death.......you will get them sooner or later.........

Please............I've been around here long enough to understand the granting of credits. My concern right now is the expense of carrying these old pending credits in the data base for months and months. The bloated DATA BASE is the problem.

---

Boinc....Boinc....Boinc....Boinc....

I see two major problems currently with the Seti project.

First.............New crunchers sign up, download a lot of work then dissappear, never to be heard from again. I would propose a window that pops up when downloading Boinc that explains. "This is a long term science project and requires a long term commitment by you and your computer. If you do not intend to be a long term participant then perhaps distributed computing is not for you and your computer. Boinc will make use of ALL the spare cycles of the CPU and possibly the GPU and this is by design. The ramifications of that can be excessive heating of the CPU and or GPU if adequate cooling is not in place before installing Boinc."

Second............Excessive delay's in granted credits for AP work. I would propose that new crunchers be limited to MB work only. The option to crunch AP should NOT be granted automatically to new crunchers. They should be able to make the selection once they know and understand the requirements of AP and 30 days have elapsed since joining Seti.

Excuse me, but I have had a few drinks tonight and I am getting a little snarky............


PLEASE..quit bringing up the delay in credit granting.....it has beaten quite to death.......you will get them sooner or later.........

Please............I've been around here long enough to understand the granting of credits. My concern right now is the expense of carrying these old pending credits in the data base for months and months. The bloated DATA BASE is the problem.

I agree with You G@P.

---

Savoir-Faire is everywhere!
The T1 Trust, T1 Class 4-4-4-4 #5550, America's First HST

Hi,
Just curious how long the AP splitters have been down?

---

Hi,
Just curious how long the AP splitters have been down?

Since they ran out of raw data to split - or about 17:00 UTC today, according to Scarecrow's daemon history.

Hi,
Just curious how long the AP splitters have been down?

Since they ran out of raw data to split - or about 17:00 UTC today, according to Scarecrow's daemon history.

Good thing the kitties have filled their AP caches.........meowooooooo

---

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

Please............I've been around here long enough to understand the granting of credits. My concern right now is the expense of carrying these old pending credits in the data base for months and months. The bloated DATA BASE is the problem.

Is it?

Do we know how many work units have the first result returned and are waiting for a second?

---

Please............I've been around here long enough to understand the granting of credits. My concern right now is the expense of carrying these old pending credits in the data base for months and months. The bloated DATA BASE is the problem.

Is it?

For the moment it may be.
AstroPulse Work Units aren't being assimilated- the queue just keeps gettting bigger. And a few minutes ago the network traffic took a dive & appears to be staying down.
Even though there's plenty of MB work ready to send all i'm getting are
31/05/2009 8:22:51 SETI@home Message from server: (Project has no jobs available)
messages.

---

Grant
Darwin NT

The bloated DATA BASE is the problem.

Is it?

For the moment it may be.

... or it could be some other unrelated slowdown.

I'm not trying to be argumentative, I'm just observing that there are lots of things that can cause problems, and we can't always see enough to know why.

---

The bloated DATA BASE is the problem.

Is it?

For the moment it may be.

... or it could be some other unrelated slowdown.

I'm not trying to be argumentative, I'm just observing that there are lots of things that can cause problems, and we can't always see enough to know why.

Yep.

---

Grant
Darwin NT

Even though there's plenty of MB work ready to send all i'm getting are
31/05/2009 8:22:51 SETI@home Message from server: (Project has no jobs available)
messages.

Matt made a comment the other day that was kind-of interesting.

The scheduler has a small queue of 100 work units that are available for assignment. Apparently, space is reserved for each application, so if there are 40 slots reserved for AP (and I don't know, it could be divided equally) then the queue is only 60 Multibeam.

... and if the queue can't be replenished faster than the scheduler assigns work, then we get where we are today: lots of "no jobs available" messages because the feeder can't quite keep up.

---

Even though there's plenty of MB work ready to send all i'm getting are
31/05/2009 8:22:51 SETI@home Message from server: (Project has no jobs available)
messages.

Matt made a comment the other day that was kind-of interesting.

The scheduler has a small queue of 100 work units that are available for assignment. Apparently, space is reserved for each application, so if there are 40 slots reserved for AP (and I don't know, it could be divided equally) then the queue is only 60 Multibeam.

... and if the queue can't be replenished faster than the scheduler assigns work, then we get where we are today: lots of "no jobs available" messages because the feeder can't quite keep up.

Whatever..........the kitties seem to have the caches filled up.............

---

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

Even though there's plenty of MB work ready to send all i'm getting are
31/05/2009 8:22:51 SETI@home Message from server: (Project has no jobs available)
messages.

Matt made a comment the other day that was kind-of interesting.

The scheduler has a small queue of 100 work units that are available for assignment. Apparently, space is reserved for each application, so if there are 40 slots reserved for AP (and I don't know, it could be divided equally) then the queue is only 60 Multibeam.

... and if the queue can't be replenished faster than the scheduler assigns work, then we get where we are today: lots of "no jobs available" messages because the feeder can't quite keep up.

Indeed. And so far as we can tell, it is "equally" (BOINC server default), despite Josef's stirling efforts to tell the staff

a) this isn't optimal
b) it is configurable

There are glimmers of hope that the penny may be beginning to drop in the 2nd. par of message 900643. But how long it will be before that understanding is translated into config files, history alone will tell.