There are always troubles when we come to damn credits on all project...perhaps not on CPDN :-)
Using trux client might be fine for a calibration, not a solution for "Curse of 32". One can't serve all the parties, heh? It might be consdered unfair for those willing to help in larger portin (i.e. run-as-fast-as-my-machine-can).
So, using BS core and it's (ThierryH's) calibration may be a better choise.
Anyway, after we all get dry soon...in 4 weeks let's say:
1a. Is there a plan for newer application? Perhaps with some built-in optimalizations of akosf's ideas and them of use in large scale? I'm sure this will help whole project more than coupled machines running extra-optimalized apps (and faking CPU numbers).
1b. Having says that, this may somehow solve the problem of non-Windows platforms and their users. It may be considered very unfair to crunch 5x and even more time per WU while source code is not available.
2. Is there a plan for implementing FLOPs counting, which will leave the troube of #1, #2 and #3 options irrelevant?
I'm not saying leave it as it is now, but bringing larger picture that seeks for general, not partial/temporary solution.
Yeah, I know..... :-)
For the moment, though I could re-write like this:
[draft excerpt]
There has been rapid progress in significant optimisations of some of the science applications for E@H. These versions can accelerate the processing of work units many fold. This is a good thing, but has entailed an unexpected effect, as not all users have the new versions. It is hoped to incorporate recent advances in all upcoming official versions, which will make much of what follows moot.
[/draft excerpt]
along with
[draft excerpt]
Many Einstein@Home forum participants have thus concluded that, on balance, the use of a calibrated client ( see below ) when the faster science applications are used, is fairest to all.
.
.
.
.
Installation instructions for:
- .
- .
- .
.
.
.
.
[/draft excerpt]
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
So, using BS core and it's (ThierryH's) calibration may be a better choise.
A lot of work units are pending because of people using the BS core. Many of those computers are taking a week or more to return results. I have seen one computer (a Pentium 4) that had approximately 1,000 unfinished work units in its queue. That's just ridiculous.
Obviously the people using BS like that idea as they don't have to wait for credit. Selfish, if you ask me:
1. The other people processing the same WU have to wait a long time for credit
2. The project has to hold these results in the database longer
3. There could be a shortage of work for others because of these WU hogs
BS also appears to massively over-claim credit, unlike Trux's client. 70, 80, (some even claim over 100 credits) for half an hour's crunching is outrageous. The standard app would claim about 40 credits for that same work unit. I would provide links to examples, but don't want anyone to feel I'm singling them out. It's not hard to find them yourself...
The whole reason for the 32WU quota seems to be to reduce load on the server. But by using BS you are in fact adding further load. It may be a handy tool, but I think it's being mis-used.
A lot of work units are pending because of people using the BS core. Many of those computers are taking a week or more to return results. I have seen one computer (a Pentium 4) that had approximately 1,000 unfinished work units in its queue. That's just ridiculous.
Yes, ridiculous.
But this is not to blame BS, but user's IQ or lack of common-sense.
Since Einstein is - unlike SETI for example - a very reliable project in terms of server and work availabily, there is no point having queue size set to x days (until someone is off-line for a week). I'm generally using 0.2 days which results in Average turnaround time of 0.2 days. And - my machine using BS has wait for others, not the other way round.
ad 1. It is easy to argue that using standard BOINC will make this worse because of no -return_result__imediatelly features that is in BS/Trux core. It is as well easy to argue that people using standard BOINC will make this worse, beucase fast crunchers returning results "immediatelly" have to wait for others. In this perspective, BS + optimalized app will generally return results sooner than standard UCB BOINC and official apps WHILE queue size is set the same. Average turnaround time can be lower with BS, not standard BOINC and standard app.
No offense ment, but in my humble opinion, the problem of pending WUs (which I agree that stress the servers), is about queue size.
Yes, some users may mis-use BS by exagerading size of work cache.
Quote:
BS also appears to massively over-claim credit, unlike Trux's client. 70, 80, (some even claim over 100 credits) for half an hour's crunching is outrageous. The standard app would claim about 40 credits for that same work unit. I would provide links to examples, but don't want anyone to feel I'm singling them out. It's not hard to find them yourself...
Hmm, actually haven't looked at that before. I see - without calibration machine usually claiming about half of what oficial app does even with optimalized BOINC. So, this is "unfair" toward those with standard app.
I consider benchmark ill measurent that doesn't bring parity among projects. Even calibration doesn't solve that. Perhaps trux's idea of calibration WUs would have been good (even for testing machine reliability and stability).
I'm for FLOPs where fair credit can't be maintained. This counts all projects except CPDN where credit is per "work done" (or possibly every project coupled of types of WUs with *fixed* crunch time).
Obviously the people using BS like that idea as they don't have to wait for credit. Selfish, if you ask me:
I cannot speak for other BoincStudio users but I take some offense to your post. If you believe that I use BS as a means for instant gratification, or a way to 'hog' WUs from others, you are seriously mistaken.
I signed up for BOINC so I could provide my computers idle time to Einstein@Home. For those of us who wish too keep our faster machines crunching for E@H without running out of work, the only way to do this with the fast turnaround of WUs is to use BS which allows us to claim more CPUs, and thus, acquire enough work.
Quote:
1. The other people processing the same WU have to wait a long time for credit
The project has always allowed for up to a 10 day work quota for crunchers, so please don't single out BS users as 'slow' to reply.
Quote:
2. The project has to hold these results in the database longer
Please see my above response. The project was designed with a 14 day turn around limit, they expected to have many results in their system.
Quote:
3. There could be a shortage of work for others because of these WU hogs
Must we go and call each other names? We are here for the science aren't we? While I do agree that 1000 WUs is far too much for someone’s work cache, please don't assume that all BS users are trying to keep work from you, I'm just trying to keep my computer running.
Quote:
BS also appears to massively over-claim credit, unlike Trux's client. 70, 80, (some even claim over 100 credits) for half an hour's crunching is outrageous. The standard app would claim about 40 credits for that same work unit. I would provide links to examples, but don't want anyone to feel I'm singling them out. It's not hard to find them yourself...
I do agree with you that BS does over claim, but let me assure you that this is not why I use it. If you take a look at my host
which runs BS, it is not claiming 70 - 100 credits/WU, but rather 50 - 55. While yes, this is still above average, in my eyes it is not unfair. I gladly support modification of BS credit calibration in order to correct this. Also if you look at any of my slower hosts, you will see that I do not employ BS in fear of posts like yours.
So please, before you start making broad ranged accusations take a look around, we are all on the same team, with the same ultimate goal ... to progress our knowledge of the universe that surrounds us.
EDIT: BBC correction
There are 10^11 stars in the galaxy. That used to be a huge number. But it's only a hundred billion. It's less than the national deficit! We used to call them astronomical numbers. Now we should call them economical numbers. - Richard Feynman
BS also appears to massively over-claim credit, unlike Trux's client. 70, 80, (some even claim over 100 credits) for half an hour's crunching is outrageous. The standard app would claim about 40 credits for that same work unit. I would provide links to examples, but don't want anyone to feel I'm singling them out. It's not hard to find them yourself...
The whole reason for the 32WU quota seems to be to reduce load on the server. But by using BS you are in fact adding further load. It may be a handy tool, but I think it's being mis-used.
Again, that's very much debateable. To my understanding, you have two weeks, not one, to return a WU. I am one of those candidates, who take less than 30min for a full scale WU and less than 9min for a small one.
I can process pretty much 100 large WUs a day. So, by circumventing the 32 credits thanks to BS I can provide my full machine capacity to the project.
Moreover, BS most recent version claims ~45 unless you fiddle with the source code, which those participants must have been doing to get that number. Besides as long as there are so many utilising optimised alberts but not calibrating boinc, I consider this a fair method to claim back lost credits elsewhere.
:
your thoughts - the ways :: the knowledge - your space
:
Dave:
In support of your comments I offer the following observation. One of my machines has over half again the pending WUs as the next highest and almost twice the other two. This is despite the fact that it has the smallest cache. Why? Because it is doing nearly twice the work of the other three without extra work ala Boinc Studio.
The reason I ditched using it was despite reading any information I could find to correct the problem, it still invalidated the results of the other projects I was crunching.
I'd rather crunch Einstein and get low credit than waste CPU time on loads of other projects only to have them invalid.
I've noticed that a majority of the work units I have crunched using Akosf's clients have also been crunched with optimised clients so people aren't losing out on credits.
Obviously the people using BS like that idea as they don't have to wait for credit. Selfish, if you ask me:
I cannot speak for other BoincStudio users but I take some offense to your post. If you believe that I use BS as a means for instant gratification, or a way to 'hog' WUs from others, you are seriously mistaken.
Dave, I wasn't singling anyone out. Perhaps I should have said "some people", rather than "the people".
Quote:
So, by circumventing the 32 credits thanks to BS I can provide my full machine capacity to the project.
I don't like this limit either, for the same reason you stated. But does circumventing the project's (deliberate) settings help the project? Should we decide what's best for the project, or should we leave it up to the project admins?
As for credit claims - perhaps your're right and it's not the tool, but some users fiddling with it. I dont know, I haven't used it. Still, I find that in many cases the BS clients were the highest claimant - in some cases by a ridiculous amount, e.g (from a real work unit):
Result 1:
Client: 5.2.13 BoincStudio 0.4b
CPU Time: 1807
Credit claimed: 155.10
Result 2:
Client: 5.2.13
CPU Time: 5,398
Credit claimed: 41.12
Result 3:
Client: 5.2.13
CPU Time: 2062
Credit claimed: 14.89
14.89 was obviously not enough (optimised app, standard client), but 155.10 sure smells of something.
Again, I'd provide links to specific work units but don't want to single anyone out. Take a (random) sample of 20 or more work units you have completed and see how often you get less than claimed. If it's the majority, perhaps the client is overclaiming (for whatever reason)
Yoda:
People have been circumventing the WU/day/cpu limit as long as I have been running E@H (mostly by creating duplicate hosts). I do not recall any protest from the mods or devs. If anything those who use Boinc Studio as intended by its devs are shortening the time the rest of the community have to wait for results to be validated (and sometimes increasing their credit). As for any trolls that abuse the functionality, shame on them.
RE: Thanks for the draft,
)
Yeah, I know..... :-)
For the moment, though I could re-write like this:
[draft excerpt]
There has been rapid progress in significant optimisations of some of the science applications for E@H. These versions can accelerate the processing of work units many fold. This is a good thing, but has entailed an unexpected effect, as not all users have the new versions. It is hoped to incorporate recent advances in all upcoming official versions, which will make much of what follows moot.
[/draft excerpt]
along with
[draft excerpt]
Many Einstein@Home forum participants have thus concluded that, on balance, the use of a calibrated client ( see below ) when the faster science applications are used, is fairest to all.
.
.
.
.
Installation instructions for:
- .
- .
- .
.
.
.
.
[/draft excerpt]
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: So, using BS core and
)
A lot of work units are pending because of people using the BS core. Many of those computers are taking a week or more to return results. I have seen one computer (a Pentium 4) that had approximately 1,000 unfinished work units in its queue. That's just ridiculous.
Obviously the people using BS like that idea as they don't have to wait for credit. Selfish, if you ask me:
1. The other people processing the same WU have to wait a long time for credit
2. The project has to hold these results in the database longer
3. There could be a shortage of work for others because of these WU hogs
BS also appears to massively over-claim credit, unlike Trux's client. 70, 80, (some even claim over 100 credits) for half an hour's crunching is outrageous. The standard app would claim about 40 credits for that same work unit. I would provide links to examples, but don't want anyone to feel I'm singling them out. It's not hard to find them yourself...
The whole reason for the 32WU quota seems to be to reduce load on the server. But by using BS you are in fact adding further load. It may be a handy tool, but I think it's being mis-used.
Join the #1 Aussie Alliance on Einstein
RE: A lot of work units are
)
Yes, ridiculous.
But this is not to blame BS, but user's IQ or lack of common-sense.
Since Einstein is - unlike SETI for example - a very reliable project in terms of server and work availabily, there is no point having queue size set to x days (until someone is off-line for a week). I'm generally using 0.2 days which results in Average turnaround time of 0.2 days. And - my machine using BS has wait for others, not the other way round.
ad 1. It is easy to argue that using standard BOINC will make this worse because of no -return_result__imediatelly features that is in BS/Trux core. It is as well easy to argue that people using standard BOINC will make this worse, beucase fast crunchers returning results "immediatelly" have to wait for others. In this perspective, BS + optimalized app will generally return results sooner than standard UCB BOINC and official apps WHILE queue size is set the same. Average turnaround time can be lower with BS, not standard BOINC and standard app.
No offense ment, but in my humble opinion, the problem of pending WUs (which I agree that stress the servers), is about queue size.
Yes, some users may mis-use BS by exagerading size of work cache.
Hmm, actually haven't looked at that before. I see - without calibration machine usually claiming about half of what oficial app does even with optimalized BOINC. So, this is "unfair" toward those with standard app.
I consider benchmark ill measurent that doesn't bring parity among projects. Even calibration doesn't solve that. Perhaps trux's idea of calibration WUs would have been good (even for testing machine reliability and stability).
I'm for FLOPs where fair credit can't be maintained. This counts all projects except CPDN where credit is per "work done" (or possibly every project coupled of types of WUs with *fixed* crunch time).
RE: Obviously the people
)
I cannot speak for other BoincStudio users but I take some offense to your post. If you believe that I use BS as a means for instant gratification, or a way to 'hog' WUs from others, you are seriously mistaken.
I signed up for BOINC so I could provide my computers idle time to Einstein@Home. For those of us who wish too keep our faster machines crunching for E@H without running out of work, the only way to do this with the fast turnaround of WUs is to use BS which allows us to claim more CPUs, and thus, acquire enough work.
The project has always allowed for up to a 10 day work quota for crunchers, so please don't single out BS users as 'slow' to reply.
Please see my above response. The project was designed with a 14 day turn around limit, they expected to have many results in their system.
Must we go and call each other names? We are here for the science aren't we? While I do agree that 1000 WUs is far too much for someone’s work cache, please don't assume that all BS users are trying to keep work from you, I'm just trying to keep my computer running.
I do agree with you that BS does over claim, but let me assure you that this is not why I use it. If you take a look at my host
which runs BS, it is not claiming 70 - 100 credits/WU, but rather 50 - 55. While yes, this is still above average, in my eyes it is not unfair. I gladly support modification of BS credit calibration in order to correct this. Also if you look at any of my slower hosts, you will see that I do not employ BS in fear of posts like yours.
So please, before you start making broad ranged accusations take a look around, we are all on the same team, with the same ultimate goal ... to progress our knowledge of the universe that surrounds us.
EDIT: BBC correction
There are 10^11 stars in the galaxy. That used to be a huge number. But it's only a hundred billion. It's less than the national deficit! We used to call them astronomical numbers. Now we should call them economical numbers. - Richard Feynman
RE: BS also appears to
)
Again, that's very much debateable. To my understanding, you have two weeks, not one, to return a WU. I am one of those candidates, who take less than 30min for a full scale WU and less than 9min for a small one.
I can process pretty much 100 large WUs a day. So, by circumventing the 32 credits thanks to BS I can provide my full machine capacity to the project.
Moreover, BS most recent version claims ~45 unless you fiddle with the source code, which those participants must have been doing to get that number. Besides as long as there are so many utilising optimised alberts but not calibrating boinc, I consider this a fair method to claim back lost credits elsewhere.
:
your thoughts - the ways :: the knowledge - your space
:
Dave: In support of your
)
Dave:
In support of your comments I offer the following observation. One of my machines has over half again the pending WUs as the next highest and almost twice the other two. This is despite the fact that it has the smallest cache. Why? Because it is doing nearly twice the work of the other three without extra work ala Boinc Studio.
I used Trux's CC very
)
I used Trux's CC very briefly........
The reason I ditched using it was despite reading any information I could find to correct the problem, it still invalidated the results of the other projects I was crunching.
I'd rather crunch Einstein and get low credit than waste CPU time on loads of other projects only to have them invalid.
I've noticed that a majority of the work units I have crunched using Akosf's clients have also been crunched with optimised clients so people aren't losing out on credits.
Clark: Sorry to hear about
)
Clark:
Sorry to hear about your problems, your conclusion is logical.
I have not heard of any such problems with Boinc Studio.
RE: RE: Obviously the
)
Dave, I wasn't singling anyone out. Perhaps I should have said "some people", rather than "the people".
I don't like this limit either, for the same reason you stated. But does circumventing the project's (deliberate) settings help the project? Should we decide what's best for the project, or should we leave it up to the project admins?
As for credit claims - perhaps your're right and it's not the tool, but some users fiddling with it. I dont know, I haven't used it. Still, I find that in many cases the BS clients were the highest claimant - in some cases by a ridiculous amount, e.g (from a real work unit):
Result 1:
Client: 5.2.13 BoincStudio 0.4b
CPU Time: 1807
Credit claimed: 155.10
Result 2:
Client: 5.2.13
CPU Time: 5,398
Credit claimed: 41.12
Result 3:
Client: 5.2.13
CPU Time: 2062
Credit claimed: 14.89
14.89 was obviously not enough (optimised app, standard client), but 155.10 sure smells of something.
Again, I'd provide links to specific work units but don't want to single anyone out. Take a (random) sample of 20 or more work units you have completed and see how often you get less than claimed. If it's the majority, perhaps the client is overclaiming (for whatever reason)
Join the #1 Aussie Alliance on Einstein
Yoda: People have been
)
Yoda:
People have been circumventing the WU/day/cpu limit as long as I have been running E@H (mostly by creating duplicate hosts). I do not recall any protest from the mods or devs. If anything those who use Boinc Studio as intended by its devs are shortening the time the rest of the community have to wait for results to be validated (and sometimes increasing their credit). As for any trolls that abuse the functionality, shame on them.