That's the way I took it too.

I don't think either one of us cares what the number is.

I don't even care that they are comparable between AP and MB because I don't know if the "work done" is comparable.

I would like to think that "credits" were related to something real. Pick a thing and make it a reference. FLOPS? Fine. Time on machine? Fine. Number of work units completed? Fine.

Numbers based on a formula that only tells you what you get when you run numbers through the formula? Not-fine.

I'd prefer the FLOP-count, but maybe that's too hard to-do.

In my opinion FLOP-count is just another meaningless indication, so we should go back to the way it was back in the good old days:

SETI@home classic workunits: 12,226
SETI@home classic CPU time: 76,480 hours

Use separate entries for AP/MB and separate entries for CPU/GPU and thats it.
I know you can't compare 1 hour of processing on a high end CPU/GPU with 1 hour of processing on a low end CPU/GPU, but the number of workunits processed will be an indication of what was used. I also know there is a (sometimes quite big) difference between MB tasks depending on the angle, but as everyone gets a fair share of all angles in the long, run this should not matter much.

I hope Astropulse v7 will be made available here soon. It will solve the wasted CPU/GPU time on tasks with (havy) blanking. I just had a personal worst ever (percent blanked: 99.02):

http://setiathome.berkeley.edu/result.php?resultid=3651886409

Tom

---

That's the way I took it too.

I don't think either one of us cares what the number is.

I don't even care that they are comparable between AP and MB because I don't know if the "work done" is comparable.

I would like to think that "credits" were related to something real. Pick a thing and make it a reference. FLOPS? Fine. Time on machine? Fine. Number of work units completed? Fine.

Numbers based on a formula that only tells you what you get when you run numbers through the formula? Not-fine.

I'd prefer the FLOP-count, but maybe that's too hard to-do.

The kitties have no complaints....
They feast on AP when it is available and then dutifully crunch away at the MB cache to help the servers towards the next batch of AP.

It would be nice if the credits were normalized between the two types of work though.

AstroPulse v7 will probably do that. It is current being tested on Beta.

Most likely the wrong direction though.

That's the way I took it too.

I do not see much difference between credits granted for AP v6 over here and AP v7 over on beta. Still big differences between workunits that cannot be explained by exiting early because of 30/30 signals found.

You can check my results for yourself if you like:

http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=58935&offset=0&show_names=0&state=0&appid=

Tom

---

The kitties have no complaints....
They feast on AP when it is available and then dutifully crunch away at the MB cache to help the servers towards the next batch of AP.

It would be nice if the credits were normalized between the two types of work though.

AstroPulse v7 will probably do that. It is current being tested on Beta.

Most likely the wrong direction though.

That's the way I took it too.

---

"Learn from yesterday. Live for today. Hope for tomorrow." Albert Einstein
"With cats." kittyman

The kitties have no complaints....
They feast on AP when it is available and then dutifully crunch away at the MB cache to help the servers towards the next batch of AP.

It would be nice if the credits were normalized between the two types of work though.

AstroPulse v7 will probably do that. It is current being tested on Beta.

Most likely the wrong direction though.

---

The kitties have no complaints....
They feast on AP when it is available and then dutifully crunch away at the MB cache to help the servers towards the next batch of AP.

It would be nice if the credits were normalized between the two types of work though.

AstroPulse v7 will probably do that. It is current being tested on Beta.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the BP6/VP6 User Group today!

The kitties have no complaints....
They feast on AP when it is available and then dutifully crunch away at the MB cache to help the servers towards the next batch of AP.

It would be nice if the credits were normalized between the two types of work though.

---

"Learn from yesterday. Live for today. Hope for tomorrow." Albert Einstein
"With cats." kittyman

Dear Juan,
I know from what has been written here what is being tested and tried to fix the credit madness. And my best wishes goes to them.
This would obviously be the best and final thing. Granted.

What I was discussing (and I think also the others) is what to do and what may be best in the meantime. Meantime that I fear will be rather long.

Cheers!
Sleepy

The simple answer to eliminate this problem is fix creditscrew. Then MB & AP work will "pay" the same number of "meaningless" credits and then, only then, the work balance MB vs AP will be restored since will make no diference to do any of both works.

Actualy there are few who is working hard to try to do, you could follow them at albert@home.

---

I still think if we cut the number of AP splitters down to one or two instead of 6, AP splitting would slow down closer to the speed of MB splitting and then we wouldn't end up with these huge backlogs of waiting

Though I would find it some kind of elegant solution, I fear that many would start complaining about difficulties in downloading AP WUs, which would be generalised and source for headaches for the staff to manage.
The way it is done now is a nuisance for those few of us going 100% AP and consistently checking the systems. We know what is happening, we may not like it entirely and complain once in a while, but that's it and everything goes on smoothly.
In other words, this is a nuisance for few informed people.
The way you suggest may end in problems to many more less informed people who would find themselves in unexpected problems.

Therefore, I think the present solution is wiser.

Though I always look with terror when I see 600 channels loaded at the same time! :-) ;-)

My 2 cents.

Sleepy

I still think if we cut the number of AP splitters down to one or two instead of 6, AP splitting would slow down closer to the speed of MB splitting and then we wouldn't end up with these huge backlogs of waiting for MB to catch up...but I guess the staff doesn't see a problem with the way things are and it seems to work fine..it just kind of annoys some of us crunchers, but it makes no difference to the science. *shrug*

At the moment there are only 5 of the 7 MB splitters working with the other 2 being disabled and they have been for some time now. It would improve things some what if/when they were put back online.

The 5 MB splitter are generally more than fast enough to keep up with demand. They actually cycle off every so often as the amount of work RTS is large enough. If there is an error it takes a bit of time to catch up.
Some time ago, shortly after moving to the CoLo IIRC, it was mentioned that they limit the speed/amount of the splitters because they were hitting a disk i/o limit with the storage array.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the BP6/VP6 User Group today!

I still think if we cut the number of AP splitters down to one or two instead of 6, AP splitting would slow down closer to the speed of MB splitting and then we wouldn't end up with these huge backlogs of waiting for MB to catch up...but I guess the staff doesn't see a problem with the way things are and it seems to work fine..it just kind of annoys some of us crunchers, but it makes no difference to the science. *shrug*

At the moment there are only 5 of the 7 MB splitters working with the other 2 being disabled and they have been for some time now. It would improve things some what if/when they were put back online.

---

I don't buy computers, I build them!!

ops ! i'll have to hide me puters next time forgot everyone can see ....:):)

---

You can have more AP when you finish with all of your MB!

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the BP6/VP6 User Group today!

Dag nab it just as 1 machine starts to show a real remaning time we run out of AP's grrr

FEED US MORE ......HUNGRY .......HUNGRY.......HUNGRY

---

APs are gone now we have to live on resends or something else for a real long time.

---

Bah! You jinxed us....

:)

---

APs being much more available in the past was also do to the feeder proportions, as well. Used to be 97 MBs and 3 APs in every load of 100 tasks for the feeder. So that limited the number of APs that were available to the scheduler every 2 (?) seconds to being 3. So.. 10,000 APs in RTS queue would last a while. Now it's just kind of a free-for-all and they go fast.

Plus all of the advancements in processing speed doesn't help, either.

I still think if we cut the number of AP splitters down to one or two instead of 6, AP splitting would slow down closer to the speed of MB splitting and then we wouldn't end up with these huge backlogs of waiting for MB to catch up...but I guess the staff doesn't see a problem with the way things are and it seems to work fine..it just kind of annoys some of us crunchers, but it makes no difference to the science. *shrug*

---

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

APs are not being split and it looks like it will be a long time before they start up again.

---

Paradoxically, this present bonanza can mean a long starvation when the AP splitters will stop for medium to high capacity crunchers.

 Which may not be in line with your happyness.

 Though things are actually generally going much better (I would say very well) since colo transfer.

Yeah, there is that dreadful drought that keeps popping up, but with the addition of my new toy, it make those periods more bearable.

---

I don't buy computers, I build them!!