I think a potential misconception is that the planned credit reduction by a factor of 1.28 (to get E@H in line with Seti) will mean that everybody should see his/her RAC reduced by about this factor, 1.28.
But this is impossible.
Those who were running the Windows stock app 4.26 at the end of S5R3 (most Windows users, more than half of the total PC "workforce") were now upgraded to the better optimized SSE app, so if their PC supports SSE, they now have a faster app, offsetting the bigger WUs and reduced credit per WU. I guess in the end they will hardly see any drop in RAC at all.
If you were running the Linux stock app or even the power app, your relative drop in RAC will be higher of course, because you gain less in speed as you already had a faster app at the end of S5R3 run.
So as a direct consequence of the (desirable) step towards pewrformance equality between the apps, Windows stock app RAC must suffer less (if at all) than Linux stock app RAC.
I think a potential misconception is that the planned credit reduction by a factor of 1.28 (to get E@H in line with Seti) will mean that everybody should see his/her RAC reduced by about this factor, 1.28.
....
So as a direct consequence of the (desirable) step towards pewrformance equality between the apps, Windows stock app RAC must suffer less (if at all) than Linux stock app RAC.
Hey, Bikeman - that's brilliant, well done! I wouldn't call it a potential misconception though - it's very real and the people who have chased performance will see an "unfair" drop compared to the average user and these "power users" will very likely voice their complaints about the "unfairness" without thinking it through as clearly as you have done.
It's already happening to me. As a result of converting a bunch of hosts to Linux and using the fast Linux app, my RAC reached a peak of 58K at one point not long ago. This was an amazing increase over what it was (around 24K I think) earlier on in S5R3. The numbers don't really tell the full story since I closed a bunch of older machines and started up some more modern and more efficient machines over the same timeframe. It's hard to know if the fewer number of more powerful hosts is producing more or less than the much larger number of older hosts I used to have running.
I'm now at 45K and dropping like a stone. Maybe it's time for me to pick up my bat and ball and head off looking for greener pastures, since I'm obviously being unfairly treated here :-).
I think a potential misconception is that the planned credit reduction by a factor of 1.28 (to get E@H in line with Seti) will mean that everybody should see his/her RAC reduced by about this factor, 1.28.
But this is impossible.
Those who were running the Windows stock app 4.26 at the end of S5R3 (most Windows users, more than half of the total PC "workforce") were now upgraded to the better optimized SSE app, so if their PC supports SSE, they now have a faster app, offsetting the bigger WUs and reduced credit per WU. I guess in the end they will hardly see any drop in RAC at all.
If you were running the Linux stock app or even the power app, your relative drop in RAC will be higher of course, because you gain less in speed as you already had a faster app at the end of S5R3 run.
So as a direct consequence of the (desirable) step towards pewrformance equality between the apps, Windows stock app RAC must suffer less (if at all) than Linux stock app RAC.
CU
Bikeman
You are correct again. I've been watching this host.
From the tasks completed, and still on view, the times for S5R3 varied from 32k5 to 39k1 sec at the rate of 237.53cr.
Now on S5R4 the times are from 37k2 to 43k sec and credits were 194.48 but after "adjustment" now 223.12.
To me that looks like the reduction is only about 7%. This figure may not be the final figure for that host or representative of the majority of the population that did not use the power apps but I believe it is not that far out.
The contents were OK when they left me, hosting is completely untested....
Only click if you trust me, and you also trust them.
I made a complete pig's ear of the transition from S5R3 to S5R4 on my timing run machine. Thank goodness for 'resend lost results', which spared my blushes. Apologies for all the wasted download bandwidth.
But even I got confused by the message:
Quote:
2008-08-08 10:50:24 [Einstein@Home] Message from server: No work can be sent for the applications you have selected
2008-08-08 10:50:24 [Einstein@Home] Message from server: You have selected to receive work from other applications if no work is available for the applications you selected
2008-08-08 10:50:24 [Einstein@Home] Message from server: Sending work from other applications
which I got even when running (briefly) at completely stock settings following a project reset. I'm still getting it before every S5R4 work allocation, even though I've re-optimised to the combo package so I can polish off S5R3 work with the power app. It looks as if we've all been given a (hidden, uncontrollable) preference for S5R3 work.
Since I've bumped my Windows composite package, let's give equal billing to Linux:
You'll find in there the latest S5R3 4.49 and S5R4 6.02 apps for Linux and the app_info.xml. The first package contains the normal SSE application for S5R3, the second the SSE2 app. The S5R4 applications are the same, as 6.02 recognizes SSE2 capable hosts itself.
Thanks to koschi: I guess the same disclaimers apply.
To me that looks like the reduction is only about 7%. This figure may not be the final figure for that host or representative of the majority of the population that did not use the power apps but I believe it is not that far out.
My concern right now is if the calculation of the drop was performed with or without the assistance of the method that Eric proposed. It appears, to me anyway, like it was done by using Eric's method.
If so, you should attempt to find hosts in the "prime" of the Pentium 4 (Netburst, no HT) and Athlon64 era that were also using 4.26.
Also, Randy and I have brought up a question about whether or not our AMD systems are being penalized again, since I can see "AuthenticAMD" in the executable again.
Well it looks like you discovered the gist of the PM I sent you.
I was getting ready to open a Trac ticket about the anon platform problem, when you posted and told us you already had.
For the benefit of the other's here:
Some time back a feature was added to allow participants to emulate some of things you can do when you run the anonymous platform from the project preferences web UI. Riesel Sieve is the only one I know which did have it, but I'm pretty sure there were other projects which had asked for that kind of enhanced functionality. Unfortunately, I never had a chance to play with it to see how it actually works.
Specifically, you can tell the project what applications to run and choose some other parameters for the tasks you want sent to your hosts, if the project chooses to enable that functionality.
Given the wording of the message log snippet Richard provided leads me to conclude that at least part of the issues we have seen here and at SAH lately attributable to this.
The way I'm reading the message is that one of the options you get if the participant decides to use the feature is what happens if there is no work for the current application(s) selected. You can choose to either go idle (or fallback on another project) until new work for your selection is available, or override the selection and DL from any other application the project maybe running.
So the functional problem was that by definition in the BOINC design specification, the anonymous platform is suppose to 'trump' anything which is set from the project side when it comes to what is sent in the way of applications and tasks, and the backend was not honoring that by trying to send work for applications which the host was not supporting. This is a really bad thing for the project to do for a couple of reasons. The worst is that as long as the unsupported task is in limbo, the host won't download any work it can actually run for the effected project.
Well, I've reviewed the Trac ticket, and apparently they fixed the problem of not honoring the requirements of the anonymous platform from a functional viewpoint, but from what Richard is observing there still seems to be some problems with the server side notification system.
As far as botching the transition goes, you think you got it wrong. In my case, all of my remote hosts were set up to run the power apps. However, due to one of those curious ironies of fate, I don't have full physical access to them right at the moment.
Since I know from past experience that a project detach will dump the project completely, including the app_info file, I decide to run the R3 work out, detach, and then reattach to get back in the game running full stock.
However, this time around when I sent the detach command from BoincView, it apparently either knocked out network communication (the two I tried it on lost remote GUI access and haven't contacted any of the other projects they run), or worse, crashed the CC for some reason. The kicker is I may not be able to get to the console to clean up the detritus until next week sometime, so it looks like I torpedoed myself pretty good and sent 27 % of my fleet to the bottom! Worse, the casualties just happened to be my capital ships. ;-)
Now that's what I call an 'ARRRRRGGGGGGH' moment, and there's pretty much no joy in Mudville right now! :-D
To me that looks like the reduction is only about 7%. This figure may not be the final figure for that host or representative of the majority of the population that did not use the power apps but I believe it is not that far out.
My concern right now is if the calculation of the drop was performed with or without the assistance of the method that Eric proposed. It appears, to me anyway, like it was done by using Eric's method.
If so, you should attempt to find hosts in the "prime" of the Pentium 4 (Netburst, no HT) and Athlon64 era that were also using 4.26.
Also, Randy and I have brought up a question about whether or not our AMD systems are being penalized again, since I can see "AuthenticAMD" in the executable again.
As you are so concerned why don't you find a host to that spec, at the momnet none of my wingmen are using those families of cpu.
And I don't think Eric's method has been implemented here yet, because if you calculate the reduction on the original S5R4 granted you will see 194.48 / 237.53 * 100 = 81.88% right on the button for a 28% reduction.
As you are so concerned why don't you find a host to that spec, at the momnet none of my wingmen are using those families of cpu.
:sigh:
Quote:
And I don't think Eric's method has been implemented here yet, because if you calculate the reduction on the original S5R4 granted you will see 194.48 / 237.53 * 100 = 81.88% right on the button for a 28% reduction.
A 28% reduction from 100% is 72% of the baseline/prior value, not 81.88, or approx 82%. 82% would be an 18% reduction from a baseline of 100% (or 1, depending on how you referenced your baseline).
I think a potential
)
I think a potential misconception is that the planned credit reduction by a factor of 1.28 (to get E@H in line with Seti) will mean that everybody should see his/her RAC reduced by about this factor, 1.28.
But this is impossible.
Those who were running the Windows stock app 4.26 at the end of S5R3 (most Windows users, more than half of the total PC "workforce") were now upgraded to the better optimized SSE app, so if their PC supports SSE, they now have a faster app, offsetting the bigger WUs and reduced credit per WU. I guess in the end they will hardly see any drop in RAC at all.
See this host for example (a wingman of mine).
If you were running the Linux stock app or even the power app, your relative drop in RAC will be higher of course, because you gain less in speed as you already had a faster app at the end of S5R3 run.
So as a direct consequence of the (desirable) step towards pewrformance equality between the apps, Windows stock app RAC must suffer less (if at all) than Linux stock app RAC.
CU
Bikeman
RE: I think a potential
)
Hey, Bikeman - that's brilliant, well done! I wouldn't call it a potential misconception though - it's very real and the people who have chased performance will see an "unfair" drop compared to the average user and these "power users" will very likely voice their complaints about the "unfairness" without thinking it through as clearly as you have done.
It's already happening to me. As a result of converting a bunch of hosts to Linux and using the fast Linux app, my RAC reached a peak of 58K at one point not long ago. This was an amazing increase over what it was (around 24K I think) earlier on in S5R3. The numbers don't really tell the full story since I closed a bunch of older machines and started up some more modern and more efficient machines over the same timeframe. It's hard to know if the fewer number of more powerful hosts is producing more or less than the much larger number of older hosts I used to have running.
I'm now at 45K and dropping like a stone. Maybe it's time for me to pick up my bat and ball and head off looking for greener pastures, since I'm obviously being unfairly treated here :-).
Cheers,
Gary.
RE: Seems like there might
)
Hi Rod,
Welcome to the message boards. I see you have been a member for quite a while but this is your first post here.
I also notice that you are in both the "yoyo@home" projects - and an impressive list of other projects as well :-).
I hope you enjoy your stay here and many thanks for your kind words. It's always nice to receive positive feedback like yours.
Cheers,
Gary.
RE: I think a potential
)
You are correct again. I've been watching this host.
From the tasks completed, and still on view, the times for S5R3 varied from 32k5 to 39k1 sec at the rate of 237.53cr.
Now on S5R4 the times are from 37k2 to 43k sec and credits were 194.48 but after "adjustment" now 223.12.
To me that looks like the reduction is only about 7%. This figure may not be the final figure for that host or representative of the majority of the population that did not use the power apps but I believe it is not that far out.
In spite of having prepared
)
In spite of having prepared and used a complete installation file set:
I made a complete pig's ear of the transition from S5R3 to S5R4 on my timing run machine. Thank goodness for 'resend lost results', which spared my blushes. Apologies for all the wasted download bandwidth.
But even I got confused by the message:
which I got even when running (briefly) at completely stock settings following a project reset. I'm still getting it before every S5R4 work allocation, even though I've re-optimised to the combo package so I can polish off S5R3 work with the power app. It looks as if we've all been given a (hidden, uncontrollable) preference for S5R3 work.
Since I've bumped my Windows composite package, let's give equal billing to Linux:
Thanks to koschi: I guess the same disclaimers apply.
RE: I made a complete pig's
)
Well at least it was a complete one! Keep at it! I look forward to viewing a beautiful pig's ear in due course ...... :-)
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: To me that looks like
)
My concern right now is if the calculation of the drop was performed with or without the assistance of the method that Eric proposed. It appears, to me anyway, like it was done by using Eric's method.
If so, you should attempt to find hosts in the "prime" of the Pentium 4 (Netburst, no HT) and Athlon64 era that were also using 4.26.
Also, Randy and I have brought up a question about whether or not our AMD systems are being penalized again, since I can see "AuthenticAMD" in the executable again.
RE: In spite of having
)
RE: RE: To me that looks
)
As you are so concerned why don't you find a host to that spec, at the momnet none of my wingmen are using those families of cpu.
And I don't think Eric's method has been implemented here yet, because if you calculate the reduction on the original S5R4 granted you will see 194.48 / 237.53 * 100 = 81.88% right on the button for a 28% reduction.
RE: As you are so
)
:sigh:
A 28% reduction from 100% is 72% of the baseline/prior value, not 81.88, or approx 82%. 82% would be an 18% reduction from a baseline of 100% (or 1, depending on how you referenced your baseline).