Here's the deal. Team Gridcoin is paying people to do a job. The members are not mining directly, so it's not a pool. The members are crunching boinc projects for profit. That puts every single member under contractor status and should by law be required to fill out a 1099 before doing a thing. Advertising on most of the boinc sites makes it sound like free money. It's not free. They are doing a job and getting paid. Most of the members are not paying taxes on it I assure you. Comingt forward to ask boinc to fix the credit system to stop the cheating was the worst move any blunderhead could have made. According to the guidelines in the US, Team Gridcoin is a cheat, a fraud and a thief. I hope the "owner" and the admins have enough for a lawyer for their members. For when the servers start getting comp4nscated to find out who is doing the work and also the ones getting paid to crunch, it's nt going to s6op with the heads of gridcoin since4, nobody has bothered to file a 1099. Team Gridcoin is illegal that it's a non-profit organization hiring people and recruiting from other teams while playing to cruncher's greed. You can try to argue all you want and ju8stify why it's perfectly ok to do what it's been doing for over years. Sadly, tham Gridcoin has violated and skirted the laws for far too long. I'm surprised nobody has had the gumption to call them on this until now. So many of the reams talk about Gridcoin without a clue how to handle them Well I say, lets stop the cheats......it's time to call the team for what it really is a business that doesn't pay a cent in taxes. So, pucker up buttercup. The taxman is a coming.

Quoted from mikey (message 69486):
You're right, the BOINC credit system doesn't have any responsibility to change its system(s) to suit the needs of Gridcoin; it does however have a responsibility to continue improving/developing its system(s) to address the needs of BOINC users/projects as a whole.

Is there any BOINC development funding any more? I thought that ended recently?

1. Team Gridcoin is paying people to do a job.
2. The members are crunching boinc projects for profit.
3. That puts every single member under contractor status
3. and should by law be required to fill out a 1099 before doing a thing.
4. Team Gridcoin is illegal that it's a non-profit organization hiring people and recruiting from other teams

1. no. People are doing something and it happens that a third party is giving them a few digits for it if they want.
2. Maybe, maybe not. You dont know. atm its not possible to do a profit except you dont have to pay for energy.
3. as I said US laws dont interest the majority.
4. Gridcoin is not an org, neither for profit or not and it is not hiring. Gridcoin programmer itself does not know any user that does not pop up in the forums, and even there only a name, not even if the name is part of the network.

I suggest you first find out what Gridcoin is before talking about it. And then came back to topic - how to make a fair credit system.

Quoted from mikey (message 69486):
You're right, the BOINC credit system doesn't have any responsibility to change its system(s) to suit the needs of Gridcoin; it does however have a responsibility to continue improving/developing its system(s) to address the needs of BOINC users/projects as a whole.

Is there any BOINC development funding any more? I thought that ended recently?

My previous post was rather inaccurate/arrogant, there are no enforced responsibilities to continue any BOINC development, since funding has ended it's entirely up to volunteers to continue development.

[...]
People who consistently contribute are able to participate in the project's decision-making processes.
[...]
Project decisions are generally made by community consensus. To manage this process, and to resolve conflicts when they occur, there is a Project Management Committee (PMC) consisting of community members who have consistently contributed to the project.
[...]

So any actual decision to focus on development of a 4th gen credit system is largely in the hands of active BOINC devs and the Project Management Committee.

BOINC's funding from the U.S. National Science Foundation has ended,
at least for the time being.
[...]
However, any new development and major bug fixes to BOINC will need to be done by volunteer programmers.
I'm confident that the BOINC community will meet the challenge.
[...]

Christian Beer's comment (https://github.com/BOINC/boinc/issues/1493#issuecomment-211246173) does raise some important questions - ultimately a tip4commit system would place an individual (the fundraiser) in a centralized position of power (https://peer4commit.com/faq) which is somewhat incompatible with the existing project governance model. If there is a trusted treasury within the PMC, they could accept direct GRC/<any crypto> donations instead of relying on a tip4commit system.

These funds are spread over 10 years and are for all Seti projects, not just for the Seti@Home project. It may even get none, hasn't had any thus far. And even then, it'll probably be spent on the hardware with which the recordings take place, not the hardware that stores the BOINC project.

I believe "The Breakthrough Listen Lab" is a new facility at Berkeley, partially or wholly funded through Yuri Milner's foundation. We may learn more in 10 days' time (but I can't go).

SETI@Home has been processing additional data, recorded at the Green Bank Telescope, since Yuri's Night #55, the 55th anniversary of Yuri Gagarin's historic first space flight on April 12, 1961. I think that some of the Milner Money went on that, too - such as the new data recorder at GBT.

What I don't know - but I think we should be told - is how broadly the terms of the Milner support have been drafted. In UK philanthropic circles, at least, it is now widely accepted that good practice requires that, if your gift enables a significant enhancement of the work or the receiving organisation, then you should devote a significant - and realistic - proportion of the gift to enhancing the core administration and infrastructure of the hosting body. In this case, it seems as if lab provision has been included, which is a good start, but I have seen no sign of additional staffing, and I would argue that the BOINC codebase should be considered as core infrastructure for the Breakthrough team too - no (public) sign of that either, yet.

Here's the deal. Team Gridcoin is paying people to do a job. The members are not mining directly, so it's not a pool. The members are crunching boinc projects for profit. That puts every single member under contractor status and should by law be required to fill out a 1099 before doing a thing. Advertising on most of the boinc sites makes it sound like free money. It's not free. They are doing a job and getting paid. Most of the members are not paying taxes on it I assure you. Comingt forward to ask boinc to fix the credit system to stop the cheating was the worst move any blunderhead could have made. According to the guidelines in the US, Team Gridcoin is a cheat, a fraud and a thief. I hope the "owner" and the admins have enough for a lawyer for their members. For when the servers start getting comp4nscated to find out who is doing the work and also the ones getting paid to crunch, it's nt going to s6op with the heads of gridcoin since4, nobody has bothered to file a 1099. Team Gridcoin is illegal that it's a non-profit organization hiring people and recruiting from other teams while playing to cruncher's greed. You can try to argue all you want and ju8stify why it's perfectly ok to do what it's been doing for over years. Sadly, tham Gridcoin has violated and skirted the laws for far too long. I'm surprised nobody has had the gumption to call them on this until now. So many of the reams talk about Gridcoin without a clue how to handle them Well I say, lets stop the cheats......it's time to call the team for what it really is a business that doesn't pay a cent in taxes. So, pucker up buttercup. The taxman is a coming.

There are 700 cryptocurrencies.https://coinmarketcap.com/all/views/all/
Why Exclusive only German gridcoin can use the BOINC Manager and the overall infrastructure for their financial benefit.
Why gridcoin programmers work for "free" to allow the financial benefit for BOINC volunters. or ..? :-)

Here is why:
If any cryptocurencies wants to become successful must do something to get people's awareness and especially to be used. and it is very appropriate to use the already established global network of BOINC computers based on years of research and support from US state and berkeley university.
Gridcoin with its exclusive right and "boost" to use BOINC infrastructure has reached what others from cryptocurrencies doesn't have a chance...

And people from backgrounds gridcoin would like to be changed BOINC credit system....oops when this discussion takes place in style, shut up and write only about a this topic thread. like here
-I suggest you first find out what Gridcoin is before talking about it. And then came back to topic - how to make a fair credit system.- -- LennStar registred from 8 may 2016 ...)))

so gridcoin received in recent days by someone big money...
and begins manufacturing hardware devices that primarily will be riding on the Berkeley BOINC and volunteer for production crypto curency.. and "science"
gridcoin be completely *ape/destroys everything what we BOINC volunteer for years created.teams for exemple. and boinc future will be the buckle on money and not "rocket science".

And people from backgrounds gridcoin would like to be changed BOINC credit system....oops when this discussion takes place in style, shut up and write only about a this topic thread. like here
-I suggest you first find out what Gridcoin is before talking about it. And then came back to topic - how to make a fair credit system.- -- LennStar registred from 8 may 2016 ...)))

so gridcoin received in recent days by someone big money...
and begins manufacturing hardware devices that primarily will be riding on the Berkeley BOINC and volunteer for production crypto curency.. and "science"
gridcoin be completely *ape/destroys everything what we BOINC volunteer for years created.teams for exemple. and boinc future will be the buckle on money and not "rocket science".

Oh, you got banned so had to create a socketpuppet?
Even if I am repeating myself - learn what gridcoin is (thats why I write this for all).
For example it is not German. I guess the main programmer is from US.
PiGird is I think students from Germany - but they have nothing to do with the Gridcoin network infrastructure at all. They just thought it is cool that BOINC work can paid.
I dont know why you find it bad that other hardware can now perform BOINC work, too.

Gridcoin getting money is something only existing in your brain. If not I want some of that too, please transfer it to me, thanks.

And regarding your ad hominem: Yes, my Forum account is new - I thought I had one from years back, but maybe they get deleted after inactivity. If you want to discredit me as a Noob because the account is new - bad for you. I am both BOINC and Gridcoin user practically since they started (and invested/donated several thousand € in hardware and energy in that time). In both cases because I think its a great idea. Rewarding volunteer work that is already done with an non-wasteful cryptocurrency.
Yes, I think that is something that no other coin has. That is the reason why I joined.
btw. is Gridcoin only the third coin I know of "sitting" on top of BOINC. Difference is - it works for every project.

Sorry for the repeated disgression, I just hope it clears some things about Gridcoin.

I would like to ask everyone to calm down and return back to the topic. This is not about GridCoin but about the BOINC Credit system. The GridCoin System currently uses the BOINC Credit System and wants to improve it. The BOINC Community also has some issues with the Credit System and wants to improve it. I find it a worthwhile discussion to find out what both parties think how to improve it.

At the end it will be up to the individual projects to adopt any sort of CreditSystem. And all participants (Gridcoin users and non-GridCoin users) need to decide by themselves if they want to participate in a project with a certain CreditSystem or not.

Right now we should aim to agree that Credits or Points should show the contribution of a Volunteer to a specific project. It should be fair within this project (the same amount of work should give the same amount of Points on a given host) but it can't be fair across projects.
I think we can also agree that using Runtime as a basis for reward calculation is flawed because it is the most easily changeable value on the host. So if we can't trust anything that comes from the host how are we supposed to calculate a reward?
Another open question is how do projects determine the amount of work per Job? For some projects (that develop their own app) this is easy, for other projects that have data dependent applications from a third party it is not so easy. but knowing how much work is in a Job is necessary to fulfill the inner-project fairness criteria. Again we can't completely trust what the host sends us and the project may not be able to change the application it uses.

It may very well be that each project can do as they please with the credit system, and cross project comparing is a waste of time [at this time it is], but why then is there a BOINC credit system, a CPID and the many project comparing statistics websites for host/OS/team/member and more, to include the not unique: http://boinc.netsoft-online.com/e107_plugins/boinc/get_cpcs.php, which highlights the differentials in a matrix of how one second of computing compares on hosts that share the same projects. E.g. WCG sticks to Credit_New with some outlier anti-cheat rules on top and SETI is the gold standard reference of Credit_new, yet WCG only grants 0.4 or less per second than SETI. The flaw in credit new is basic: Float and Integer are summed, where CPUs and OSses don't equally well execute the two parts. The credit is based on averaging and assumes fairly regular run times from task to task and batch to batch. There's at least at WCG only one science that actually does have regular computing times... the rest are all highly variable [non-deterministic, highly variable molecule complexities], which is where CN falls thoroughly over... a complete credit mess even between the various sub-projects such as expressed on this chart: https://bit.ly/WCGCPH1, and this is a running 7 day average. From day to day, we've seen most recently one swinging from 26 to near 40 per hour to 26, and this is mild, compared to what happens if you drill down to the host level.

Solution: Each science / task includes a post-job benchmark test [not part of the BOINC client code itself] for which the project assigns a credit value.

As for ease of time manipulation... first I heard of this, but then outlier rules can capture if time was manipulated... the amount of data from which to draw comparative stats to ascertain real/unreal is bountiful [a 4 core device cant deliver 5 days of computing day after day and the relative task benchmarks not adding up].

For sure, something gottah change as moan is endless, where BOINC provided the framework. Certainly I don't see why each project admin has to waste time on normalizing against a flawed system. Fix the system, so we can return to what volunteering for distributed computing was created for with the comparative fun points/credit/runtime result counts team challenges can be enjoyed again.Coelum Non Animum Mutant, Qui Trans Mare Currunt

Hi, just stumbled over this discussion... I'm just an average BOINC volunteer, and do not have a deep understanding of the inner workings of BOINC. That said, let me share my two cents...

The original idea of distributed computing was that volunteers donate (unused) computing resources to an endeavor (project) they find worthwhile. Therefore, the most meaningful measure of progress, contribution and success comes from this endeavor - number of climate model iterations computed, prime numbers found, proteins folded, encryption keys tried, core hours - you name it.

This is fairly easy to determine by the project, it's meaningful for participants, and it can be put in stats tables. Competitions are also still possible (and the organizers can make their own rules how to compare projects). Cheating is rather pointless, as project validation will accept only valid/confirmed work units.

Yes, that means saying good-bye to the idea of combined stats which, as has been pointed out in this discussion, is unrealistic anyway, as it's next to impossible to make projects comparable. So what? When riding a dead horse, it's best to dismount. For statistical purposes, data about OS/CPU/FLOPS etc. can still be collected.

As for *coin: basing this scheme on the BOINC credit system creates a dependency that may or may not hold - sorry, your risk.

First, what are Credits (or Points, or Unicorns) for? For volunteers they are motivational, but for BOINC itself they are a statement of computer science attainment. They're right there on the front page: "24-hour average: 11.562 PetaFLOPS". That figure is reverse-engineered from the total number of BOINC credits awarded, no matter where or how: clicking Top 100 multi-project BOINC participants gives you some idea of where they come from.

Speaking personally, I'd like to retain both elements of that: call it 'motivation by scientific attainment', if you like - credits that are in some respect pegged to (hypothetically) measurable quantities. Since there are only a limited number of measurable quantities to pick from, that should also bring with it at least some comparability across projects: I'd like to see that, and I recoil against that "can't be fair" assertion. Maybe if projects were explicit about whether their credits were for single-precision flops, double-precision flops, or integer maths, some of the fog might lift?

That's the theory, at least. Now, let's turn to the problem of implementation. A little history.

I think we can safely assert that BOINC arose out of the original self-contained SETI@Home Classic project. The same developers worked on both SETI and BOINC, and the expected primary function (signal processing by single-precision floating point maths on general purpose home computer CPUs) probably infuenced the evolving reward mechanism heavily. BOINC credits are also known as cobblestones, and the linkage is explicit.

The early days of both SETI and BOINC were perceived to suffer (scientifically speaking) from cheating. Reading CreditNew, specifically the description of the transitions between the first and the second, and the second and the third, credit systems, it's clear that the developers felt the need to remove as much scope for cheating from the volunteers, and as much need for bespoke programming from project developers, as possible.

So what happened? SETI was using the second credit system (flopcounting), when GPU computing joined the BOINC framework in the winter of 2008/09. Despite the impression given in CreditNew, flopcounting and GPUs coexisted successfully (-ish - I won't pretend there weren't some difficulties) for over a year.

Then, two things happened in quick succession. Initially, BOINC's third generation credit system was trialed on SETI's Beta server on 31 March 2010: the message board thread New credit calculation code still makes informative (and entertaining) reading. Because flopcounters were still present in the SETI applications, the old (second generation) credit claims could be compared with the new (third generation) credit awards. Although the image host I was using at the time is no longer performing, I still have the original graphs from that thread and I can re-post them if they would contribute to the discussion.

And the second thing which happened was the public release to sale of the next generation of GPUs: NVidia's Fermi range (that helps to contextualise the dates). It turned out that the new hardware was incompatible with existing software, and much chaos ensued: in the midst of the chaos, a new Fermi application was obtained from NVidia, and when it was deployed to SETI on 7 June 2010, CreditNew was deployed as well.

So, CreditNew was tested at SETI Beta for barely more than two months before being declared the new gold standard, and I can find - then or now - no evidence that it was evaluated for 'fitness for purpose'. Certainly, examining the History for boinc/sched/credit.cpp, there are some bug fixes and adaptations to meet new needs, but no revisions that even attempt to address the shortcomings we started to see in those first two months at Beta.

And I think that's the biggest problem with the third generation credit system. Nobody owns it - certainly nobody loves it. Volunteers take their grumbles to project administrators: project administrators say 'this isn't what I signed up to deal with - I'm a scientist' (and run to hide behind the nearest bush): and BOINC seems to say 'here you are, we've made this - take it or leave it'. Most people choose to leave it.

Of course, other things have happened during the six years that CreditNew has languished in the orphanage. Most significantly, the NSF has withdrawn - strictly, declined to renew - development funding for BOINC. I think that's a positive event - the NSF are saying that BOINC is no longer a computer science experiment: it's grown up, succeeded, left the nursery laboratory. It now has to make its own future as infrastructure in and for the scientific research community.

That's both a challenge and an opportunity. Fundamentally, I think it's time that the projects (re-) took control of the strategic direction of BOINC: they should decide collectively what is needed, and what are merely decorative bells and whistles.

After the NSF funding ceased, BOINC set up an ideal structure for this: the Project Management Committee. But it was given absurd terms of reference - looking downwards and inwards towards micro-code, instead of outwards and upwards to the needs of the scientific community. I think it should seize the strategic role instead, and as a first step remove David Anderson from the role of chairperson. David may have been a brilliant experimentalist, but mature, robust, infrastructure needs different skills, and the committee chair needs to be someone who can manage them.

Then, I'd ask that the new PMC consider this question of credit, and decide whether it is something they wish to address (I hope they do). Then, if the strategic heads of the organisation are listening, there is more hope that the labourers at the coalface - like the authors of Evaluation Of CreditNew - will feel that their efforts are worthwhile.

It may very well be that each project can do as they please with the credit system, and cross project comparing is a waste of time [at this time it is], but why then is there a BOINC credit system, a CPID and the many project comparing statistics websites for host/OS/team/member and more, to include the not unique: http://boinc.netsoft-online.com/e107_plugins/boinc/get_cpcs.php, which highlights the differentials in a matrix of how one second of computing compares on hosts that share the same projects.

You have to keep in mind that the basic idea of one credit system for many projects is a relic of a time when there was not a big diversity of projects doing very different types of calculations and the differences between CPUs were comparable across the projects. If project A granted twice as much credit as project B on one host, the ratio was about the same on every other host. Nobody thought of developments like x64 and AVX, let alone GPUs, which may be a hundred times faster than a CPU on project A, but slower than the CPU or even unusable on project B. And that's not because of bad optimization, but just because the projects are calculating different things.

Those cross-project comparison sheets were useful in ancient times, but now we have seen all those developments and should learn our lesson, even if that requires dropping some old thinking, cross-project comparison sheets and 'combined' stats.

The original idea of distributed computing was that volunteers donate (unused) computing resources to an endeavor (project) they find worthwhile. Therefore, the most meaningful measure of progress, contribution and success comes from this endeavor - number of climate model iterations computed, prime numbers found, proteins folded, encryption keys tried, core hours - you name it.

This is fairly easy to determine by the project, it's meaningful for participants, and it can be put in stats tables. Competitions are also still possible (and the organizers can make their own rules how to compare projects). Cheating is rather pointless, as project validation will accept only valid/confirmed work units.

I completely agree and a number of projects is already doing that. Unfortunately, it's not always as simple as one might think (e.g., counting primes would not be a very good measure for work done at PrimeGrid and they in fact needed many years to find a good credit system). And it cannot be done by the BOINC developers.

The BOINC server code should only include a very easy standard credit system (i.e. fixed number of points per task, which is sufficient for test projects and projects with fixed-length tasks... and, to be honest, is already more fair than a lottery for variable-length tasks as long as their runtime is really not predictable) and make it as easy as possible to replace with a more accurate system as soon as the project administrators have an idea.

The more I think about this and the more I read the more I think only an ex post average-comparative credit system will work (for projects that don't have a definite length).
(only coincidantally that is nearly what Gridcoin does)

That means we start with a BOINC-wide "standard number" of (just for show) 1 point per hour on an i5-6500 @3,5Ghz and projects (in alpha) test their available computers to that result.
This allows to make a table with a few processors and their efficiency for this project.

Then in closed beta you send out the same WUs to computers having those CPUs (GPUs) and to new processors (set to standard) to get their relative efficiency until you have a table with (nearly) all processors.

Now you have a quite accurate comparision table and can reward based on that numbers.
From time to time (or rolling average) you control those numbers.

That means we start with a BOINC-wide "standard number" of (just for show) 1 point per hour on an i5-6500 @3,5Ghz and projects (in alpha) test their available computers to that result.
This allows to make a table with a few processors and their efficiency for this project.

Then in closed beta you send out the same WUs to computers having those CPUs (GPUs) and to new processors (set to standard) to get their relative efficiency until you have a table with (nearly) all processors.

Now you have a quite accurate comparision table and can reward based on that numbers.
From time to time (or rolling average) you control those numbers.

That's basically the old first generation credit system with centralized benchmarking instead of local benchmarks on every single host. So benchmark manipulation is not possible, but the system still relies on easy-to-fake reported runtimes. You would not only run into trouble with rare CPUs not in your table, but also you would rely on the reported CPU type (can be faked very easily right now). You would also have to accurately measure CPU clock, otherwise overclocked CPUs are doing more work but get same credit per time. And that's just one of a gazillion parameters possibly affecting the actual computation speed.

Moreover, the 'benchmark phase' would have to be repeated everytime a new application version is released, creating even more work for project administrators than my project-specific credit approach.

Any average-comparative credit system will also break long-term credit stability on project level, while you still would not really have cross-project parity as different hosts just behave too differently on different applications. So in the end, you would have a complicated system and people not only complain about cheating and project A granting more credit per time than project B on their hosts, but also about broken credit stability on project level. A discussion about the 5th generation BOINC credit system would likely come up in no time.

There's also a problem with extending even project-generated and server-held averages from CPUs to GPUs.

It is reasonable to assume that all CPU cores in a given host run at the same speed. It's less reasonable to assume that all CPUs of the same model number run at the same speed - some might have hyperthreading enabled, others not, even before we mention overclocking.

But BOINC made what is now acknowledged as a big design mistake by letting the servers assume that all GPUs (from each manufacturer) in a given host are also comparable. Until and unless the proposed server change allowing tracking of individual GPUs is implemented (and I see no sign of it yet), I fear a lot of extra programming work - much reinventing of many wheels - at the project level. I suspect that most project administrators would much prefer that the credit solution was taken out of their scope and handled centrally.

P.S.: I don't know anything about the specific reasons why people hide their hosts but they should have the possibility.

Regards
Christian

My suggestion would be to allow Team Founders to see this data anyway, keep the average person from seeing it, but if you join a Team then the Team Founder CAN see it, after all it's THEIR Team that's being affected by the cheating. People used to hop from team to team when team total credit went with them, when that stopped some of the team hopping stopped, but some people still hop from team to team for various reasons. If someone is cheating and viewing their pc's can help stop that and allowing Team Founders to see all Team Members pc's can stop it, then I'm all for it. But as I said if you have 50 pc's because you are running a computer lab or whatever and wish to keep them hidden from the general user, I'm okay with that too.

That is a start and a good point for we are trying to make the job of a cheater more difficult so why do we want to help him by allow him to hide his computers. The guy in the computer lab with his 50 machines could possibly want to hide such numbers so that he bis credit be recognized under his name and not that of the computer lab. That alone is unfair as well as other IT professionals major corporation like IBM registering their machines as individual rather than as a team. But that is another matter.

What I see is that people stare themselves blind on the recent average credit (RAC) and when it goes down, they panic, even while their credit is still going up.

So I am wondering if we shouldn't just do something about the RAC. With the present CreditNew RAC is being calculated all wrong anyway, so isn't it easiest then to get rid of RAC?

It is at the moment no longer a value that shows how well your computer has been doing over a set length of time. So either fix it so it again is showing the progress your computer makes over a set length of time, or don't use RAC.JordOnly partially available.
Please do not private message me for tech support. Use the forums for that. Tech PMs will be ignored.

I had a chance to read the MalikStone paper about this new benchmark and want to share my thoughts in case someone else stumbles upon this.

At first let me say that I find the term P2P computing for Volunteer Computing very misleading. BOINC is not a Peer2Peer system and does not do P2P computing. Apart from that it seems the author has created another synthetic benchmark that has categories (floating-point, integer, logic, program constructs, string manipulation) instead of only one number (as in whetstone, drystone). The assumption is that a project can determine (from code) the percentage of each category it can better estimate the performance of an application on a specific host. Besides the point that those values are easily adjustable on the client (Cheaters need to alter 5 instead of 2 values), the system fails when the performance of the application is data dependent or the project can not determine the percentages of each category. Another point is optimization of the application. Does the Benchmark take AVX or SSE into account?

I don't see this MalikCredit/Stone as an alternative to dhrystone/whetstone at this point. What would help is indeed a system that uses real scientific data to benchmark a host. The problem here is that this is not easily doable for each project. I think that there is a way to introduce benchmark jobs that use real data and real applications but first I need to find a way to untangle all of the CreditNew code so it can be replaced at all.