Message from server: No work sent
Message from Server: There was work available, but none for you as you are a greedy sod.

---

I started again with some testing, and the first ones (0.7) had still quite excessive, but not as much as before, credit values per hour of crunching. What should be on my computer something around 25 - 30 C/h was 72 C/h, better than the 102 before the optimization, and definitely better than the 216 or 108 for Milksops application.

Now I just finished some more tests and ran again in the 108 barrier twice:
57763717
57763587
It's not any optimized stuff from outside programmers, just the application delivered by the project.

---

Grüße vom Sänger

Now I just finished some more tests and ran again in the 108 barrier twice:
57763717
57763587
It's not any optimized stuff from outside programmers, just the application delivered by the project.

Well, there are some broken WUs out there. Some are too short for the given credit (i.e. you run into the credit limit) and some are too long. For two examples look here and here.
About 40 credits on a Core2 Quad for roughly 9600 seconds (15cr/h) isn't exactly overpaying. I don't know how common these two types of broken WUs are, but for me it appears to average out (especially because of the limit for the shorter ones). Albeit I've not experienced it myself, from what I've heard, there are even some WUs from that series that take close to 8 hours on a C2Q to completion and still get only 40 credits.

Now I just finished some more tests and ran again in the 108 barrier twice:
57763717
57763587
It's not any optimized stuff from outside programmers, just the application delivered by the project.

Well, there are some broken WUs out there. Some are too short for the given credit (i.e. you run into the credit limit) and some are too long. For two examples look here and here.
About 40 credits on a Core2 Quad for roughly 9600 seconds (15cr/h) isn't exactly overpaying. I don't know how common these two types of broken WUs are, but for me it appears to average out (especially because of the limit for the shorter ones).

They are just 2 credits below claim, so the credits for those two are probably the only ones quite correct ;)

---

Grüße vom Sänger

I started again with some testing, and the first ones (0.7) had still quite excessive, but not as much as before, credit values per hour of crunching. What should be on my computer something around 25 - 30 C/h was 72 C/h, better than the 102 before the optimization, and definitely better than the 216 or 108 for Milksops application.

Now I just finished some more tests and ran again in the 108 barrier twice:
57763717
57763587
It's not any optimized stuff from outside programmers, just the application delivered by the project.

Yea. well noticed you did not include these, nice to skew the numbers by only showing the ones you want

http://milkyway.cs.rpi.edu/milkyway/result.php?resultid=57581422
http://milkyway.cs.rpi.edu/milkyway/result.php?resultid=57536867
http://milkyway.cs.rpi.edu/milkyway/result.php?resultid=57581422

or these errors

http://milkyway.cs.rpi.edu/milkyway/result.php?resultid=57571986
http://milkyway.cs.rpi.edu/milkyway/result.php?resultid=57572265
a bunch of the last ones

Not quite a stable project yet, don't you think....

They are just 2 credits below claim, so the credits for those two are probably the only ones quite correct ;)

Forget about those stupid claim! If it is benchmark based it is sure to be broken (look at Spinhenge with a Win 64Bit client or some of the Linux clients producing abysmal scores, these clients claim only 5 to 7 credits there, where an old Win32 Box claims 12-14 credits, which is somewhat correct and also inline with SETI).

And as I said, there are even WUs out there taking a factor of 3 longer for the 40 credits than the ones I linked.

Edit:

or these errors

http://milkyway.cs.rpi.edu/milkyway/result.php?resultid=57571986
http://milkyway.cs.rpi.edu/milkyway/result.php?resultid=57572265
a bunch of the last ones

Not quite a stable project yet, don't you think....

To strengthen that point, look this message!
To cite it:

the worse is that on linux the app doesn't error out ... instead it tries to crunch that wu for hours without progress :(

Let's talk about some WUs with a zero credit/hour rate!

Not quite a stable project yet, don't you think....

Those were my fault, I experimented with a third-party app and botched it.

Forget about those stupid claim! If it is benchmark based it is sure to be broken (look at Spinhenge with a Win 64Bit client or some of the Linux clients producing abysmal scores, these clients claim only 5 to 7 credits there, where an old Win32 Box claims 12-14 credits, which is somewhat correct and also inline with SETI).

Spin doesn't have a good Lin app, I'm eagerly waiting for one.
As long as they don't have I would not crunch there with my Lin-machine, too ineffective.
Benchmarks of the newer clients, not treated by cheaters, give quite a good estimate of what should be granted.

If the grant is below claim for one OS and not for another, like in Spin for Lin compared to Win, it's a good sign for it's wastefulness. Same goes for Pirates btw, even a bit less: I claim my usual 25 and get on average 10. But as they last only a few seconds, and you get only about 10 - 20 WUs a month, I don't care there.

Edit:
Same goes the other way around:
If the grand is above the claim for one OS and not for another, like CPDN-MidHol for Lin64, it's a good sign for the suitability of that application.

Of course it's not possible to get a uniform performing client across all CPU/OS settings, but the main set-up (probably Windows on Intel) should be in line.

---

Grüße vom Sänger

Forget about those stupid claim! If it is benchmark based it is sure to be broken (look at Spinhenge with a Win 64Bit client or some of the Linux clients producing abysmal scores, these clients claim only 5 to 7 credits there, where an old Win32 Box claims 12-14 credits, which is somewhat correct and also inline with SETI).

Spin doesn't have a good Lin app, I'm eagerly waiting for one.
As long as they don't have I would not crunch there with my Lin-machine, too ineffective.
Benchmarks of the newer clients, not treated by cheaters, give quite a good estimate of what should be granted.

If the grant below claim for one OS and not for another, like in Spin for Lin compared to Win, it's a good sign for it's wastefulness.

From my experience the Linux app of Spin is only about 10% slower than the Win-App. My problem is that the client I used at that time was only getting half the benchmark values it deserved, thus claiming only 5 to 6 credits per WU, which is definatly too low. If the Linux-App would have been as efficient as the Win-App, you could reduce this to 4.5 to 5.5. Hardly an improvement.

In that sense your comment goes in a completely wrong direction, as the granted credits for Spin were definately higher than the claimed ones. But it was just the effect of strange benchmark scores. The same problem applies for the 64Bit Win clients. The floating point benchmarks are definetly too low (about 25%), thus claiming often also 25% less when compared to the same computer with 32Bit Win. And I won't start to talk about the problems that arise if the computer was busy or just clocked down when the client decided too start the benchmark.
The benchmark system is simply stupid. Period. Fixed credits are the way to go.

The WUs I crunched for Spin with my current machine (C2Q9450@3.2, Lin64) claimed 14.5 credits and got the usual 10, this was end August, begin September.

BOINC is a 6.2.14, the benches are +/- the same as for win on those machines afaik.

Of course are fixed credits, or at least server side calculated credits, the right thing, it's best to act against those 5.5.0-type cheaters, but they have to be in the same ballpark as all other projects across BOINC, that's one of the founding principles of BOINC. I don't know about Windows here, perhaps Linux is just by far better, but MW still is far above average (3 times), even for the "normal" WUs on my machine.

---

Grüße vom Sänger

it's best to act against those 5.5.0-type cheaters

FYI, I used 5.5.0 in the past because I wanted the quicker reporting of completed tasks, not because of inflated benchmarks. Your choice of branding everyone that used that particular version as having an intent to cheat is quite offensive. If you want to talk about the performance impacts of the faster reporting, then bear in mind that I stopped using 5.5.0 a long time ago and currently use 5.8.16, one that does not support the newer connect interval features that came about in 5.10.xx and up...

Stop throwing the word "cheater" around so much...

Not quite a stable project yet, don't you think....

Those were my fault, I experimented with a third-party app and botched it.

Oh trying to cheat were we........

and also inline with SETI).

There's that 4 letter word again that you all like to bring up when anything goes against your wishes

Spin doesn't hOf course it's not possible to get a uniform performing client across all CPU/OS settings, but the main set-up (probably Windows on Intel) should be in line.

Oh, cross project parity on ONLY Windows on Intel boxes now... there's parity

Oh and I see that all but 520 of your credits were crunched on non - Windows Intel boxes. So everyone else must be in line but not you....... NICE

http://milkyway.cs.rpi.edu/milkyway/hosts_user.php?userid=32

If cross project parity is not feasible across all platforms then do not keep picking on the Windows - Intel platform. It is either feasible or it is not, if not, do not keep bringing it up, it's not possible.

Period.

And since this is a stock Optimized app, (reworked and compiled by the people actually doing the crunching here, this is Open Source is it not) lets start comparing the credits to SETI's opto app shall we. Not the stock SETI app.

And one more point, since you are not active in this project at this time, why must you worry so much? The only answer is it is stepping on your holy grail, the DA and SETI stock client standards. Which must not be allowed to have even 1 more credit per hr that the stock SETI app.

Just forget that more actual science has been done here in the last 3 months that the previous 9 months of the project. (this is still Beta is it not) How about giving the project's personal some time to work the bugs out in all the apps before you point out 2 that gave you 108 cr per hr and run around saying the sky is falling.

This picking and choosing what is and should be has got to stop, because it is not possible. PERIOD.

Deal with it.

and also inline with SETI).

There's that 4 letter word again that you all like to bring up when anything goes against your wishes

It wasn't me, and I would not bring this project into the equation as it's a "bad" project as well. Since a very long time they fail to incorporate the wellknown optimisations, imho because they want to have an indecent advantage over other projects. I would post there, only I can't because I have to crunch WUs thre to do so, and as they imho don't do any science since some years I won't.

Those were my fault, I experimented with a third-party app and botched it.

Oh trying to cheat were we........

Yes, that was part of my testing.
I have the project on NNW and only let some WUs in manually. I wanted to try the efficiency of the new, optimised app in comparsion to outside optimised ones, whether it's still the same as before or the app is really optimised.
I would have posted the outcome here after a few WUs.

---

Grüße vom Sänger

Ok, I am a newbie here and probably have much to learn. But I have to wonder how a user can have been in the MW project for 5 months and have 1.2 million credits or even 5 million. That's 600k and more a month. Another at 450k for three months. I have been in the project for 16 days, running 2 machines, with 9 other projects with 3,500 credits. Can someone pls tell me how to get the hugh credits. Looks like I'm about 300k credits short for the month! Help!!

---

Ok, I am a newbie here and probably have much to learn. But I have to wonder how a user can have been in the MW project for 5 months and have 1.2 million credits or even 5 million. That's 600k and more a month. Another at 450k for three months. I have been in the project for 16 days, running 2 machines, with 9 other projects with 3,500 credits. Can someone pls tell me how to get the hugh credits. Looks like I'm about 300k credits short for the month! Help!!

Well start with a boat load of Intel Quads, a dedicated electric company (or someone to foot the bill), your own personal optimized client and go back about 2 months ago and you'd stand a chance. MW has made some changes to the client since it was found to be very inefficient and now the credits have been adjusted so no one can abuse the stats again. MAYBE.

---

MAYBE.

It seems that some may be trying. Check out some posts in this thread:

http://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=401

Doesn't seem very likely that that much can be done in a day by one system.

---

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

...I have to wonder how a user can have been in the MW project for 5 months and have 1.2 million credits or even 5 million. That's 600k and more a month.

I worked out that on average, since I started with BOINC, I've crunched 113,500 credits per month. BOINCstats tells me I'm crunching over 316,000 a month currently, so I must have started a lot slower. But then I started out with just a 1GHz AMD athlon, and now have a small crunching farm ;)

---

I got 18 Credits for the stripe86_er1 WUs, it tooks ~600 seconds

=> 108 credits per hour per core or 10368 credits per day per system.

Result

Intel(R) Core(TM)2 Quad CPU Q9300 @ 3.20GHz - WinXp64

Looks like I missed out on all the fun. Story of my life! I was wondering if there were 'SUPER DUPER' WU's or there was some tweaks I needed to do to my puny systems. Or some 'hanky panky'?! Thanks for the replies. Quads huh?

---

The current stock client, which is partially optimised, is about 2.5 times slower than Milksop's efficient client, but it does more calculation and, therefore, science.

At the time Milksop used his client there was little in the way of restrictions on the credit paid, other than that paid out for the then stock and very slow client.

Today there are restrictions on the number of WUs downloaded to a working cache, as well as the credit paid and the maximum credit a fast CPU can earn per core.

The reason for all this is to try and keep MW roughly in line with the credit given by other projects. This comparibility is roughly now in place, depending on the power of the PC being used.

The current stock client, which is partially optimised, is about 2.5 times slower than Milksop's efficient client, but it does more calculation and, therefore, science.

At the time Milksop used his client there was little in the way of restrictions on the credit paid, other than that paid out for the then stock and very slow client.

Today there are restrictions on the number of WUs downloaded to a working cache, as well as the credit paid and the maximum credit a fast CPU can earn per core.

The reason for all this is to try and keep MW roughly in line with the credit given by other projects. This comparibility is roughly now in place, depending on the power of the PC being used.

Actually i think the current version is a bit closer to milksop's app, if they were both working on the same input.

---