Welcome to MilkyWay@home

@MW staff: credit limit and credit level

Message boards : Number crunching : @MW staff: credit limit and credit level
Message board moderation

To post messages, you must log in.

Previous · 1 · 2 · 3 · Next

AuthorMessage
ChinookFoehn

Send message
Joined: 10 Dec 07
Posts: 36
Credit: 5,152,242
RAC: 0
Message 6274 - Posted: 19 Nov 2008, 1:02:36 UTC - in response to Message 6273.  

... There maybe some things that are needed so that all platforms can run it that will slow it down. That's fine by me if everyone has to use the same app...

Why would anyone want to do any scientific research slower than is possible? The faster the process, the more research that can be done.

-ChinookFöhn

ID: 6274 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile banditwolf
Avatar

Send message
Joined: 12 Nov 07
Posts: 2425
Credit: 524,164
RAC: 0
Message 6275 - Posted: 19 Nov 2008, 1:04:39 UTC - in response to Message 6274.  

... There maybe some things that are needed so that all platforms can run it that will slow it down. That's fine by me if everyone has to use the same app...

Why would anyone want to do any scientific research slower than is possible? The faster the process, the more research that can be done.

-ChinookFöhn



I agree 10000%.
Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.
ID: 6275 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Brian Silvers

Send message
Joined: 21 Aug 08
Posts: 625
Credit: 558,425
RAC: 0
Message 6276 - Posted: 19 Nov 2008, 2:05:58 UTC - in response to Message 6274.  
Last modified: 19 Nov 2008, 2:07:27 UTC

... There maybe some things that are needed so that all platforms can run it that will slow it down. That's fine by me if everyone has to use the same app...

Why would anyone want to do any scientific research slower than is possible? The faster the process, the more research that can be done.

-ChinookFöhn



There is actually a valid reason to do the research slower than is "possible". If the project is unable to handle the increased load, then throttling is a valid step to take.

Now, come to think of it, it would be just as easy to throttle based on limiting the number of tasks per day rather than slowing down the app.

Throttling to keep people happy about credits is not a valid reason though. If people are prepared to state that it is a valid reason, then SETI needs to immediately make the same move and declare all external apps as no longer valid OR implement the improvements that the independent developers have come up with and design a cpu capability switcher application that runs first to determine the feature flags of the cpu and then picks the appropriate optimization level. The second option is what Einstein has worked on / is working on.

Yes, I'm sure the impulse will be to state that SETI doesn't have the budget or resources. You know what, TOUGH. They shouldn't be allowed to have it both ways... So long as they're allowed to get by with it, then all squawking about "Cross-Project Parity" is a load of bull...

Who said that? I said that...
ID: 6276 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
ChinookFoehn

Send message
Joined: 10 Dec 07
Posts: 36
Credit: 5,152,242
RAC: 0
Message 6277 - Posted: 19 Nov 2008, 2:38:47 UTC - in response to Message 6276.  

There is actually a valid reason to do the research slower than is "possible". If the project is unable to handle the increased load, then throttling is a valid step to take.

I disagree with this but then I agree, if required, with your next statement.

Now, come to think of it, it would be just as easy to throttle based on limiting the number of tasks per day rather than slowing down the app...

Only if all else fails. If it is within the university's budget, then upgrading the hardware... the internet connection... changing the connection requests to every 30 minutes instead of every minute or, as often is in my case, every 2½-3 hours when all the tasks then have been processed and 20 to 40 are uploaded at once... doubling the length of the tasks to, at least 15 minutes, if not 30 minutes...

-ChinookFöhn

ID: 6277 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Brian Silvers

Send message
Joined: 21 Aug 08
Posts: 625
Credit: 558,425
RAC: 0
Message 6278 - Posted: 19 Nov 2008, 3:31:20 UTC - in response to Message 6277.  

doubling the length of the tasks to, at least 15 minutes, if not 30 minutes...


Well, that has me wondering if the "new" app is really NEW, in that it includes significantly more actual work. If it does include significantly more actual work, then even Milksop's app should show a significant increase in the length of time. Otherwise, making the tasks "run longer" is just going to mean putting in stalling loops, which is just a throttle mechanism...
ID: 6278 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
ChinookFoehn

Send message
Joined: 10 Dec 07
Posts: 36
Credit: 5,152,242
RAC: 0
Message 6280 - Posted: 19 Nov 2008, 4:04:30 UTC - in response to Message 6278.  

... Otherwise, making the tasks "run longer" is just going to mean putting in stalling loops, which is just a throttle mechanism...

How do you figure that? The administrators wrote it to do some sort of calculation. So, if they double the work calculated, it should increase the length of the tasks. Probably not by twice as long, but longer.

It really depends upon what they are researching and how the broke up their research to create tasks. At present, each new task issued is based upon the calculations of the old tasks. Perhaps, then it is already at an optimal length for their calculations - in which case there is not much to be done on our end except to keep doing calculations, preferably using the more efficient application by Milksop as this increases the speed of the research.

However, the galaxy is large, there are many objects/structures that need to be researched and this does not mean that other issued tasks will be of this length.

Who knows, maybe the tasks are too large and should be made smaller and then maybe a limit might be 100+ per core. Of course, if this were the case, then they'd have to ensure the MW computers and broadband connection are up to the task of handling the increased workload.

Building any delay into any task and/or application would be a useless exercise for all involved.

-ChinookFöhn

ID: 6280 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile petros
Avatar

Send message
Joined: 3 Aug 08
Posts: 89
Credit: 255,801
RAC: 0
Message 6284 - Posted: 19 Nov 2008, 14:15:04 UTC

'''...to the general credit level to stay more in line with other BOINC project if you feel this is important (personally I would). As my app is generally a factor of 50 to 60 faster than the old one, I suggested already 2 weeks ago a division by that. That means about 4 to 5 credits per WU.''

Translation:

It's not important if we can produce 50 or 60 times more work.
It's not important if we cam run 50 or 60 times faster than the other BOINC projects.

If the other BOINC projects don't have a way or they can't find a way to run exactly so fast as now MW can ,then the project MUST drop the payment and penalize himself and the crunchers for the work they do for MW. This is the so called FAIRNESS some people around talking about the whole time.

Great !!!

I guess important is ,every time these Germans start complaining or crying around to start rethink the way the project works!

ok folks let us now celebrate the Germanization of MW !

ID: 6284 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Travis
Volunteer moderator
Project administrator
Project developer
Project tester
Project scientist

Send message
Joined: 30 Aug 07
Posts: 2046
Credit: 26,480
RAC: 0
Message 6285 - Posted: 19 Nov 2008, 14:18:50 UTC - in response to Message 6278.  

doubling the length of the tasks to, at least 15 minutes, if not 30 minutes...


Well, that has me wondering if the "new" app is really NEW, in that it includes significantly more actual work. If it does include significantly more actual work, then even Milksop's app should show a significant increase in the length of time. Otherwise, making the tasks "run longer" is just going to mean putting in stalling loops, which is just a throttle mechanism...


The new version of the application allows Nate to take a wedge of the sky and remove different slices from it that contain bad data (which happens a lot in astronomy -- cloudy nights, large clusters of stars that can throw off the calculation, etc); which will allow him to run our app on a much wider range of data.

Another part of the new app allows another undergrad to do his research, basically instead of looking at wedges of the sky that are "nice" where the stream of stars passes perpendicular to our view, this code will let us fit streams that are more parallel to our view.

The first involves calculating the integral (the expensive part), and then multiple other integrals for the areas of the sky that are removed, which on these types of wedges could increase WU crunch time by quite a bit.

The second involves entirely new calculations, so we'll see how this plays out.

ID: 6285 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
sandro

Send message
Joined: 17 Oct 08
Posts: 16
Credit: 16,783
RAC: 0
Message 6291 - Posted: 19 Nov 2008, 15:10:36 UTC - in response to Message 6284.  
Last modified: 19 Nov 2008, 15:11:34 UTC



I guess important is ,every time these Germans start complaining or crying around to start rethink the way the project works!

ok folks let us now celebrate the Germanization of MW !

Congrats to the most stupid post i ever read here ;)

btw you know that both, Milksoap and crunch3r are german do you?
ID: 6291 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
John Clark

Send message
Joined: 4 Oct 08
Posts: 1734
Credit: 64,228,409
RAC: 0
Message 6292 - Posted: 19 Nov 2008, 15:17:36 UTC - in response to Message 6285.  

The new version of the application allows Nate to take a wedge of the sky and remove different slices from it that contain bad data (which happens a lot in astronomy -- cloudy nights, large clusters of stars that can throw off the calculation, etc); which will allow him to run our app on a much wider range of data.

Another part of the new app allows another undergrad to do his research, basically instead of looking at wedges of the sky that are "nice" where the stream of stars passes perpendicular to our view, this code will let us fit streams that are more parallel to our view.

The first involves calculating the integral (the expensive part), and then multiple other integrals for the areas of the sky that are removed, which on these types of wedges could increase WU crunch time by quite a bit.

The second involves entirely new calculations, so we'll see how this plays out.


Good afternoon Travis

From my reading of your comments, quoted above. The new client, although much faster than the original client, is doing significant additional work than the old client was capable of. To the extent it also allows different streams of results to fit research different people are concentrating on, as well as cleaning up the observations to just look at clear sky areas.

Excellent, and despite this considerable additional work the client is still in the order of 8x to 9x faster than the old client under the Linux OS.

I hope I am translating your comments correctly?

If so, then this answers my questions to your comments in the other thread here.
ID: 6292 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
alpina

Send message
Joined: 28 Aug 08
Posts: 1
Credit: 5,023
RAC: 0
Message 6294 - Posted: 19 Nov 2008, 15:24:03 UTC - in response to Message 6284.  

'''...to the general credit level to stay more in line with other BOINC project if you feel this is important (personally I would). As my app is generally a factor of 50 to 60 faster than the old one, I suggested already 2 weeks ago a division by that. That means about 4 to 5 credits per WU.''

Translation:

It's not important if we can produce 50 or 60 times more work.
It sure is important.
It's not important if we cam run 50 or 60 times faster than the other BOINC projects.
A completely irrelevant comment since every single BOINC project is doing something different. You can't compare "the speed" of the different projects. The only thing you can compare is the CPU time spent on the different projects.

To me it only seems fair that all projects award about the same amount of credits per CPU time spent. It is the only way the BOINC system can work in the long run so this is important for me.

If the other BOINC projects don't have a way or they can't find a way to run exactly so fast as now MW can ,then the project MUST drop the payment and penalize himself and the crunchers for the work they do for MW. This is the so called FAIRNESS some people around talking about the whole time.
Can't you see your statements don't make any sense at all? If a project(Milkyway) first uses a terribly inefficient application which later is upgraded to a much faster one then all of a sudden this project should be able to award 50 times more credit then a project which has been using an efficient application all along?

Great !!!

I guess important is ,every time these Germans start complaining or crying around to start rethink the way the project works!

ok folks let us now celebrate the Germanization of MW !
Yeah, make it a narrow-minded fight of the nations. Great!
ID: 6294 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Sailor

Send message
Joined: 10 Feb 08
Posts: 32
Credit: 13,227,191
RAC: 0
Message 6296 - Posted: 19 Nov 2008, 16:00:37 UTC

Dont feed the trolls, comes to my mind :D
ID: 6296 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile petros
Avatar

Send message
Joined: 3 Aug 08
Posts: 89
Credit: 255,801
RAC: 0
Message 6298 - Posted: 19 Nov 2008, 16:35:29 UTC - in response to Message 6294.  


''A completely irrelevant comment since every single BOINC project is doing something different. You can't compare "the speed" of the different projects. The only thing you can compare is the CPU time spent on the different projects.''

Thats correct, if you believe for example an astronaut should be paid exactly the same with the a guy or a girl who works in McDonalds. Both , the Astronaut and the guy/girl work their 8 hours average per day , why not should be paid equally??
Are you kidding me???

''To me it only seems fair that all projects award about the same amount of credits per CPU time spent''

You have 2 Ferraris each one with 500 PS motor power , the first from 1985 (e.g) and the second one from 2008. Your comment's sense says both are the same!

''If a project(Milkyway) first uses a terribly inefficient application which later is upgraded to a much faster one then all of a sudden this project should be able to award 50 times more credit then a project which has been using an efficient application all along?''

Is that a Joke right? Following your logic all projects Administrations they should drop the credit per wu as the computation power grows rapidly in order to keep a FAIR comparison to those who have had crunched with cyrix at 166 MhZ.

''Yeah, make it a narrow-minded fight of the nations. Great!''

The same clique of people, from the same forum and from the same country (Germany) are the one who opens discussions and posts demands like '' do this ,or otherwise'' (entweder oder).
Well i love astronomy projects like all of you and if i think something must or have to be change im trying to do it friendly and polite form like all crunchers do on this earth all the time at all boinc projects. When someone do things the way these guys do , i don't like it at all and i don't like them when they act like this.


ID: 6298 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
John Clark

Send message
Joined: 4 Oct 08
Posts: 1734
Credit: 64,228,409
RAC: 0
Message 6300 - Posted: 19 Nov 2008, 17:27:41 UTC

All this bickering is completely answered by looking at Travis's comments to my questions, here.

What is not answered is the credit given for the old client, the Milksop client and the new client release sometime today (I believe).

However, this will be sorted by the new client once the tweaks have been implements, as a result of user experience and feedback.

NOTE: Once the new client becomes bedded down, and work for the old client/Worksop client is done, returned and cycled, then these clients will no longer work.

The credit bickering will then be simple and around that credit given for work using the new faster client (but not as fast as Milksop's).
ID: 6300 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Travis
Volunteer moderator
Project administrator
Project developer
Project tester
Project scientist

Send message
Joined: 30 Aug 07
Posts: 2046
Credit: 26,480
RAC: 0
Message 6303 - Posted: 19 Nov 2008, 17:50:09 UTC - in response to Message 6300.  

Once we see how the new application is performing, we'll adjust credit so it's in line with other BOINC projects out there. If someone takes our new code and further optimizes it then there's two options:

1. They're nice and let us in on the optimizations and it's possible to have these in the stock application (ie. they aren't platform independant). In this case we'll update our application and adjust credit accordingly (again to keep it in line with other BOINC projects).

2. They're not nice or it's not possible to have the optimizations in our stock application. In this case we'll still have the speed limit -- which will let these apps get more credit within reason.

We're also have a strategy in the works to check results (without redundancy), which will flag suspicious clients for further examination. With this if we see any apps generating bad results we'll stop awarding them credit.
ID: 6303 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
j2satx

Send message
Joined: 3 Nov 07
Posts: 13
Credit: 122,114,444
RAC: 0
Message 6305 - Posted: 19 Nov 2008, 18:15:49 UTC - in response to Message 6303.  


We're also have a strategy in the works to check results (without redundancy), which will flag suspicious clients for further examination. With this if we see any apps generating bad results we'll stop awarding them credit.


Better to stop giving them WUs.
ID: 6305 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
John Clark

Send message
Joined: 4 Oct 08
Posts: 1734
Credit: 64,228,409
RAC: 0
Message 6306 - Posted: 19 Nov 2008, 18:34:04 UTC

Excellent, Travis. We look forwards to the new look MW project and credit system, after things have had time to bed down and become steady.
ID: 6306 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Alinator

Send message
Joined: 7 Jun 08
Posts: 464
Credit: 56,639,936
RAC: 0
Message 6309 - Posted: 19 Nov 2008, 19:08:56 UTC - in response to Message 6303.  
Last modified: 19 Nov 2008, 19:11:49 UTC

Once we see how the new application is performing, we'll adjust credit so it's in line with other BOINC projects out there. If someone takes our new code and further optimizes it then there's two options:

1. They're nice and let us in on the optimizations and it's possible to have these in the stock application (ie. they aren't platform independant). In this case we'll update our application and adjust credit accordingly (again to keep it in line with other BOINC projects).

2. They're not nice or it's not possible to have the optimizations in our stock application. In this case we'll still have the speed limit -- which will let these apps get more credit within reason.

We're also have a strategy in the works to check results (without redundancy), which will flag suspicious clients for further examination. With this if we see any apps generating bad results we'll stop awarding them credit.


I have a philosophical problem with Item 2. It goes against the basic BOINC definition that the value of the work is constant across platforms for a given task.

Therefore, granting more credit to a host which runs the task with a third party app which is faster than the stock ones is inheritently unfair to all the stockers out there. It already gets an advantage in that it runs more tasks in a given period of time.

In the case of the other projects which allow third party apps (SAH specifically), they have a large enough host population that this has a relatively small effect on the aggregate project CPCS. However with the small population so far here at MW, history has shown this isn't the case.

Therefore, IMO you would be better off to disallow the anonymous platform at this time and stick to your fixed basis system, then figure out another way to recognize the efforts of the folks helping to improve the app efficiency, at least for now. Development of an improved application does not require being run generally on the main project to prove the concept.

BTW, regarding the new app. Please make sure it will still run on NT4, as this was a shortcoming with Milksop's app package. Also, if the new work is being targeted for what was referred to over the summer as the 'long' work, then you need to extend the deadline to something like 3 1/2 to 4 days to help out the slugs a bit making it in time. My K6/300 was missing by about 8 to 9 hours or so, and once Milksops app was released publicly there was virtually no 'fudge' factor left given a lot of host were knocking the tasks off in 300 seconds or so. ;-)

Alinator
ID: 6309 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Brian Silvers

Send message
Joined: 21 Aug 08
Posts: 625
Credit: 558,425
RAC: 0
Message 6321 - Posted: 20 Nov 2008, 3:15:04 UTC - in response to Message 6309.  
Last modified: 20 Nov 2008, 3:19:30 UTC

Once we see how the new application is performing, we'll adjust credit so it's in line with other BOINC projects out there. If someone takes our new code and further optimizes it then there's two options:

1. They're nice and let us in on the optimizations and it's possible to have these in the stock application (ie. they aren't platform independant). In this case we'll update our application and adjust credit accordingly (again to keep it in line with other BOINC projects).

2. They're not nice or it's not possible to have the optimizations in our stock application. In this case we'll still have the speed limit -- which will let these apps get more credit within reason.

We're also have a strategy in the works to check results (without redundancy), which will flag suspicious clients for further examination. With this if we see any apps generating bad results we'll stop awarding them credit.


I have a philosophical problem with Item 2. It goes against the basic BOINC definition that the value of the work is constant across platforms for a given task.

Therefore, granting more credit to a host which runs the task with a third party app which is faster than the stock ones is inheritently unfair to all the stockers out there. It already gets an advantage in that it runs more tasks in a given period of time.


I doubt that a faster application would receive "more credit per task". What was done this time around is reduce the credit to effectively 108 credits per hour per core. While that is still higher than the per hour rate of the stock app, the per task rate is significantly lower. The 108/hr has been equivalent to an extremely steep progressive taxation curve...

Your puny K6 (compared to my K8): Average credit per CPU second 0.025181

My heavily overclocked K8: Average credit per CPU second 0.030018

My K8 should be getting way more than your K6, which it does over at Einstein, but not here...

Also, worthy of note is since the FPU of the K6 is so weak in comparison, this likely means that there is very little FPU pressure with this project. I'd imagine a 486 could probably complete a task within deadline...
ID: 6321 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Travis
Volunteer moderator
Project administrator
Project developer
Project tester
Project scientist

Send message
Joined: 30 Aug 07
Posts: 2046
Credit: 26,480
RAC: 0
Message 6333 - Posted: 20 Nov 2008, 21:11:15 UTC - in response to Message 6321.  

I doubt that a faster application would receive "more credit per task". What was done this time around is reduce the credit to effectively 108 credits per hour per core. While that is still higher than the per hour rate of the stock app, the per task rate is significantly lower. The 108/hr has been equivalent to an extremely steep progressive taxation curve...

Your puny K6 (compared to my K8): Average credit per CPU second 0.025181

My heavily overclocked K8: Average credit per CPU second 0.030018

My K8 should be getting way more than your K6, which it does over at Einstein, but not here...

Also, worthy of note is since the FPU of the K6 is so weak in comparison, this likely means that there is very little FPU pressure with this project. I'd imagine a 486 could probably complete a task within deadline...


Right now with the optimized applications out there and the credit limit being based on the stock application, a lot of processors are hitting our internal speed limit. When we swap over to the new app and get to see the credit rate with that (and do an overall credit adjustment based on that), there should be more of a difference in the rate CPUs generate credit. There'll still be a speed limit but hopefully it will be much harder to hit, because the stock app hopefully wont be orders of magnitude slower than the optimized ones.
ID: 6333 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Previous · 1 · 2 · 3 · Next

Message boards : Number crunching : @MW staff: credit limit and credit level

©2024 Astroinformatics Group