http://milkyway.cs.rpi.edu/milkyway/CPU
and
http://milkyway.cs.rpi.edu/milkyway/GPU
?

The only thing that bothers me is having the credits seperated. I'm spending a lot of money buying cards and electric bills. I was trying to get near the top in the standings and it means I'll be half way down both. Yes I am a credit hog and proud ;o). Thats just me being greedy and wanting what I want though. I'll happily go with the flow as in the end it's the same for all.

---

Click here for The Clangers forum!

IMO..
WUs should be separate. But not the credits. Just make the apps two different applications and folks can decide which they want to run. Why should they be different if it is the same project.
With PS3grid, they split the website in two ps3/gpu, but the credits are still the same.

---

IMO..
WUs should be separate. But not the credits. Just make the apps two different applications and folks can decide which they want to run. Why should they be different if it is the same project.
With PS3grid, they split the website in two ps3/gpu, but the credits are still the same.

That is what I thought. Decide how seperate you want to make the projects. It might cause double the work.

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

Hopefully it's just a selection in Milkyway Preferences. Be even better if the same machine could do both CPU and GPU.

Hopefully it's just a selection in Milkyway Preferences. Be even better if the same machine could do both CPU and GPU.

Like they did on SETI with the CUDA apps, right?

Good idea...

---

Click to help Seti City.

westsail wrote:

IMO..
WUs should be separate. But not the credits. Just make the apps two different applications and folks can decide which they want to run. Why should they be different if it is the same project.
With PS3grid, they split the website in two ps3/gpu, but the credits are still the same.

I disagree.
Surely this is why a 2 league table would be preferable in order to show an individuals contribution to the project as a direct comparison to there counterparts, i.e. CPU vs CPU and GPU vs GPU.

I think a 'like for like' Leader board would be preferable.

Credits are a users indication of there contribution to a given project.
I doubt if there are many users who don't see the credits race as a guide to how well they are doing against there nearest rival! and the league table is the guide. a user who doesn't see any improvement is likely to go to another project where advancement is more likely. If you include the GPU's as a comparison it is more likely that users will leave.

Both PoorBoy (RAC 383,000+) and CampaignforLiberty (RAC 1m+) have expressed there right to hide there computers from view, I suspect that if you exclude the ATI's that they seem to obviously use, what would the RAC be? I'm sure that it would be at a more reasonable level.

Travis wrote:

The GPU version of milkyway is going to farm more complex calculations to the application (gradient/hessian/line search calculations) which will let them do more "local" searches. This should increase the WU size of the GPU application by 300-1000 times what they currently are, significantly decrease server load, and also reduce the network usage of these clients.

This explanation indicates that GPU's will not be doing the same 'work' as CPU's, how can there NOT be a separate table?

---

IMO..
WUs should be separate. But not the credits. Just make the apps two different applications and folks can decide which they want to run. Why should they be different if it is the same project.
With PS3grid, they split the website in two ps3/gpu, but the credits are still the same.

I disagree.
Surely this is why a 2 league table would be preferable in order to show an individuals contribution to the project as a direct comparison to there counterparts, i.e. CPU vs CPU and GPU vs GPU.

I think a 'like for like' Leader board would be preferable.

Credits are a users indication of there contribution to a given project.
I doubt if there are many users who don't see the credits race as a guide to how well they are doing against there nearest rival! and the league table is the guide. a user who doesn't see any improvement is likely to go to another project where advancement is more likely. If you include the GPU's as a comparison it is more likely that users will leave.

Both PoorBoy (RAC 383,000+) and CampaignforLiberty (RAC 1m+) have expressed there right to hide there computers from view, I suspect that if you exclude the ATI's that they seem to obviously use, what would the RAC be? I'm sure that it would be at a more reasonable level.

Again I think that there should be a separate 'Leader' board for GPU only crunching.

Sorry but for my 2p's worth I disagree. What next, the single core users wanting their own table from the dual and quad cores? This is why I hate BOINC's scoring system over the old seti@home style. Because I'm willing to spend a bit of extra money on hardware I have to be pigeon-holed with all the other people who want to run GPU's. Same project, same science.

Renata and Neal Chantrill wrote:

Sorry but for my 2p's worth I disagree. What next, the single core users wanting their own table from the dual and quad cores? This is why I hate BOINC's scoring system over the old seti@home style. Because I'm willing to spend a bit of extra money on hardware I have to be pigeon-holed with all the other people who want to run GPU's. Same project, same science.

I point out what Travis says'

Travis wrote:

The GPU version of milkyway is going to farm more complex calculations to the application (gradient/hessian/line search calculations) which will let them do more "local" searches. This should increase the WU size of the GPU application by 300-1000 times what they currently are, significantly decrease server load, and also reduce the network usage of these clients.

Surely this states that the GPU's are doing different work? i.e. not the same as CPU's?

---

What you mean is the more complicated work that CPU's would take ages to do. I'll pop over to seti and tell them that they need to split their tables as they do different calculations too. I might just as well turn the GPU off and run only CPU or get a card for each of my machines. I for one will be doing one or the other, not both.

What you mean is the more complicated work that CPU's would take ages to do. I'll pop over to seti and tell them that they need to split their tables as they do different calculations too. I might just as well turn the GPU off and run only CPU or get a card for each of my machines. I for one will be doing one or the other, not both.

I think what he (Travis) is stating is that GPU's will be doing work that the CPU's don't do

---

I think what he is stating is that GPU's will be doing work that the CPU's don't do

I think it's more that they would take longer and hasn't been the priority for the project yet.

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

I think what he is stating is that GPU's will be doing work that the CPU's don't do

I think it's more that they would take longer and hasn't been the priority for the project yet.

(Until GPU's came along) CPU speeds increased, 'to keep a lid on things', Seti@Home would increase the range of calculations that the application would perform in order to slow down server usage and take advantage of increased CPU power.

I'm not really bothered either way! The majority of users want fairness and I think some sort of level playing field to see how they compare!

If your not 'doing the same work' how can you compare?

---

So whats fair about putting all the people that have spent good money on GPU cards to get an advantage(Which is availble to everyone)into a league of their own? What about one for people that don't run the optimised client? Not everyone knows how to install it.

I think what he is stating is that GPU's will be doing work that the CPU's don't do

I think it's more that they would take longer and hasn't been the priority for the project yet.

(Until GPU's came along) CPU speeds increased, 'to keep a lid on things', Seti@Home would increase the range of calculations that the application would perform in order to slow down server usage and take advantage of increased CPU power.

I'm not really bothered either way! The majority of users want fairness and I think some sort of level playing field to see how they compare!

If your not 'doing the same work' how can you compare?

I'm fine either way for now. It would be interesting to have seperate charts for cpu's and gpu's as well as combined. If the projects put the info out, I'm sure the stats sites will pick up on it. It's not too hard to tell who uses gpu's, they have more zeros at the end. :p

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

So whats fair about putting all the people that have spent good money on GPU cards to get an advantage(Which is availble to everyone)into a league of their own?

What's fair is that it is comparing 'like for like'. It's well documented that AMD suffers to Intel at Astropulse - what's fair about that?

What about one for people that don't run the optimised client? Not everyone knows how to install it.

Anyone who installs an opp. app. has the information (available at the relevant site) at hand! They just need to follow the simple instructions.

---

So whats fair about putting all the people that have spent good money on GPU cards to get an advantage(Which is availble to everyone)into a league of their own? What about one for people that don't run the optimised client? Not everyone knows how to install it.

I think before working oneself into a tizzy, one might consider seeking clarification about what Travis meant by this from the home page:

"Also, before a credit firestorm erupts again, we have no plans to award less credit/work to the GPU applications, so you don't need to worry about that."

It's called technology and it moves on. We had single core processors then dual and quad and so on and so forth. Now we have GPU, just move along. I'd hardly call my AMD 2500 Barton like for like with my quad but hey, it's a sign of the times.

I'm not going to post anymore as I can't see the point as you have your view and I have mine and we're not going to agree.

---

Click here for The Clangers forum!

We haven't received an explanation yet on what doing more 'local' searches actually means, so this is just what I imagine it means.

We'll have two types of work - a general search, and one that goes into -much- more detail for smaller search spaces. CPUs would take ages to do this work so it makes sense to use GPUs - they'll still take longer than on current WUs and this will save the server some trouble. However, this more specialized search is dependent on the results obtained by the more general search. If a lot of people put GPUs on Milkyway because it helps the project out more or simply because they want more credits, the specialized search will quickly get ahead of the general search and would run out of work to do - so the project puts some of these GPUs to work on the general search to balance things out. Credits for both searches are equal, so it doesn't affect your RAC, and more GPUs will still be of great use to the project - they're just put to better use.

So whats fair about putting all the people that have spent good money on GPU cards to get an advantage(Which is availble to everyone)into a league of their own? What about one for people that don't run the optimised client? Not everyone knows how to install it.

I think before working oneself into a tizzy, one might consider seeking clarification about what Travis meant by this from the home page:

"Also, before a credit firestorm erupts again, we have no plans to award less credit/work to the GPU applications, so you don't need to worry about that."

Upon reading Travis' post I figure he will use the calculation of cerdit that the current wu's are based on only multiplying it to work out for the amount of work do with the gpu wu's. So equal credit per amount of work done.

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.