Possibly, but I'd argue the case that if you've gone to the trouble of going optimized here on EAH, then you're not the type of user who routinely falls asleep at the trigger about such matters.
Yes, you would hope so. If people are following things enough to know when and how to get in, in the first place, they should also know to be paying attention for when to change or get out. They should already know that their machine has the capacity to run dry if they allow it to.
Quote:
Personally, I deliberately left mine the last time setup for cleaning out S5R2, under the philosophy that the sooner it was history, the better. :-)
Actually there is also another good reason for doing nothing for a while (probably 2 weeks at least after the new app is out). If there are any issues with the new app, why would you want to be the first to suffer them? If everything falls apart at the start, your previous app_info.xml is your friend :-). If previous experience is any guide, you will suffer no shortages for at least two weeks after the new app first arrives, probably a lot longer. After that time you can choose your moment to convert, exactly when it suits you.
Another "incentive" to stay for the cleanup will be the fact that old work will very likely pay a lot more than the new :-). The new will have the "downgraded" pay scales that Bernd was talking about some time ago :-). That sounds like a good plan to me - do the "cr*p" work and be paid accordingly :-).
So, don't tell anyone else and you and I can share the spoils for the next three months :-).
I'm not sure I got this right, but modifying the app_info.xml so that the app accepts S5R4 workunits would be a very bad idea. S5R4 will AFAIK use a new format for the results sent back to the server which requires a change in the app, so S5R4 WUs will be incompatible with S5R3 apps. In order to continue work for S5R4, you will have to download the new apps, which is easiest to do by removing the app_info.xml.
I'm sure by now that you will have worked out that there is no problem with modifying the app_info.xml to allow concurrent crunching of both S5R3 and S5R4. While re-reading your message, a further thought occurred to me on why it's actually a good idea for the bandwidth impaired to create an app_info.xml for themselves for the new stock S5R4 app, if they really do need to limit bandwidth consumption.
If a person is currently on the stock S5R3 app (no app_info.xml) at a random time of the scheduler's choosing, they will be sent a bunch of files (data and executables) for the new run.
As they finish up the old and start the new, they will get server requests to delete the old files.
After that and for a period of perhaps months, there will be a small but significant risk that any request for new work could result in the server sending them an old run resend, with the huge data and executables download penalty that involves. The simple way to avoid this totally would be to look at what executables you have been sent with the new tasks (name and version, etc) and construct yourself an app_info.xml file that allows only the new work. After that, no more old work resends.
At the time of a previous transition (I think the one before last but my memory is hazy) there was a month where my data usage was so abnormally high that I got a bill for excess data of nearly $150 on top of my normal bill. I'm sufficiently concerned enough about this for the future that I've decided to start the hassle of changing ISP's. I'm not unhappy with my current service but I am unhappy with the fact that they want to lock me into a further 12 month contract if I shift to a higher usage plan. Also I can do much better elsewhere as well so it appears. I've been where I am for the last five years so am a bit miffed that "loyalty" seems to count for nothing. I've now got 30 days to get things in order for my current account to be closed. Hopefully I'll be on the new plan with the new ISP around the end of the month anyway, well before the old plan is closed. Effectively I'll have more than three times my current limit for less money and no risk of excess charges. If my usage goes crazy I'll just be shaped.
EDIT: I've moved the above last paragraph and the discussion that followed into a new thread so as not to further hijack the important discussion that was the going on in this thread regarding how those using the app_info.xml mechanism should prepare for transitioning to the new S5R4 apps when they are released.
I apologize for being the unthinking perpetrator of the hijack, hopefully now fixed :-).
When the SSE2 app got accidentally released a while back, I think we pretty much determined that SSE2 does provide a significant speed-up over normal SSE. Has anyone given any thought to providing non-SSE, SSE, and SSE2 apps in one package, with the CPU auto-detection mechanism that we now have for non-SSE and SSE?
To get back fully on topic, here is another bit of preparation/information that people currently using the app_info.xml mechanism should think about.
If last time is anything to go by, there were some fairly rapid fixes/changes that needed to be made to the newly released S5R3 apps not long after they were first released. I can clearly remember still getting S5R2 resends at the time that new betas for S5R3 were appearing. It required me to do quite a bit of editing and deploying in order to support both the handling of resends and the participation in the beta tests on a bunch of machines. This raises the probability of trashing the task cache through human error if you don't fully understand what you are doing when adapting your app_info.xml file, or when trying to do all the changes too quickly and across multiple platforms.
The more I think about the possibilities for grief, the more I realize that having Bernd prepare a suitable set of "transition packages" for the different platforms is probably the best option. We just need to persuade him to take on the pain of actually doing it :-).
... providing non-SSE, SSE, and SSE2 apps in one package ...
There's been nothing mentioned that I've seen and I guess Bernd will ultimately decide how much he can cope with. I'm guessing it might be a lot harder to make sure the SSE/SSE2 capability of a CPU can always reliably be determined.
As for SSE2, I know that Bernd is indeed considering to have a SSE2 app as part of a switching app., at least for Linux. We'll see.
As for the transition to S5R4, I guess this will be more demanding (download wise) than the switch from S5R2 to S5R3. Not sure this wasn't mentioned already, but the data files used below 800Hz for S5R2 and S5R3 were actually the same, so many clients back then could in fact continue crunching for S5R3 on data they had downloaded in S5R2. This should not be possible for S5R4 because as I understand it, S5R4 will use different raw data ==> new l1_* and h1_* files.
As for SSE2, I know that Bernd is indeed considering to have a SSE2 app as part of a switching app., at least for Linux. We'll see.
Well, I'll be mightly grumpy if AMD64/Linux hosts get the advantage that they had back during the early S5R2 run...which is probably what giving the SSE2 version to Linux-only would do... I understand that it is a benefit to the project because of the Merlin/Morgane stuff, but it still makes that chart at BOINC Combined Statistics that David Anderson loves to get riled up about paint an inaccurate picture, at least as far as my specific hardware is concerned (AMD64/Windows), as the faster Linux hosts will make it "seem like" the credit payout is "too high"...
There'd at least need to be a "Power Users" version for Windows, IMNSHO...
If I remember correctly the SSE2 variant was far more useful for the Intel CPU's that to the AMD ones, right?
Let's wait and see what happens. The idea for SSE2 support at the end of S5R3 was not to provide a new hand-optimized assembler version but to have a version compiled with the corresponding compiler switches. As for the GNU gcc compiler under Linux, this did help indeed quite a lot, at least for Intel CPUs. I'm not at all sure the Microsoft compiler under Windows will generate the same kind of benefit for SSE2.
From what I analyzed for the Linux app, the difference in speed between the SSE and SSE2 versions were mostly generated by the that a single line of code was translated by the gcc compiler with and without the SSE2 support enabled.
If I remember correctly the SSE2 variant was far more useful for the Intel CPU's that to the AMD ones, right?
Let's wait and see what happens. The idea for SSE2 support at the end of S5R3 was not to provide a new hand-optimized assembler version but to have a version compiled with the corresponding compiler switches. As for the GNU gcc compiler under Linux, this did help indeed quite a lot, at least for Intel CPUs. I'm not at all sure the Microsoft compiler under Windows will generate the same kind of benefit for SSE2.
From what I analyzed for the Linux app, the difference in speed between the SSE and SSE2 versions were mostly generated by the that a single line of code was translated by the gcc compiler with and without the SSE2 support enabled.
CU
BRM
I'm running all AMD CPUs with a mix of Windows and Linux.
My Linux XP 2500+ is pulling ~19.8 CS/hr while my Windows XP Pro XP 2600+ is only pulling ~19.1 CS/hr. The Linux box is crunch-only however, and the Windows box does video capture occasionally.
My Linux(64-bit) X2 4000 is pulling ~37.3 CS/hr/cpu while my WinXP-64 X2 4600 is only pulling ~30.5 CS/hr/cpu. Again, the Linux box is crunch-only while the Windows box is used occasionally for other things (it's my primary system).
Note that different data paks, even if they give similar credits per WU, can take different amounts of time to crunch even considering peak/trough crunch times.
All windows systems run 4.36; the Linux boxes run 4.38 (XP 2500+) and 4.49 (X2 4000+). The X2 boxes are both overclocked 10%.
[edit]My daughter's X2 4000+ WinXP-32 (not OC; used occasionally for gaming; running 4.36) is pulling ~28.1 CS/hr/cpu. [/edit]
This might be subject to change, but some preliminary info to end speculations here:
Most likely S5R4 will start with Applications very similar to the last Beta Apps, i.e. SSE2 App for MacOS Intel, switching x87/SSE App for Windows, switching G3/AltiVec App for MacOS PPC (which will remain the slowest one in comparison), and an App that switches SSE2/SSE/x87 Apps for Linux.
The next improvements targeted for the Apps are getting the Windows App compiled with MinGW, so gcc-specific improvements could be ported to Windows (SSE2 optimizations), and, more general, get the "weighted" Hough code up to the speed of the currently used "unweighted". As the main improvement there is the prefetching, I'd suspect systems with a faster memory interface (AMD) to be a little faster in that part at the beginning.
However before that we have to get S5R4 running at all, and an almost equally high priority is a major server code upgrade. I doubt that any major work on the App code will be done before that.
RE: Possibly, but I'd argue
)
Yes, you would hope so. If people are following things enough to know when and how to get in, in the first place, they should also know to be paying attention for when to change or get out. They should already know that their machine has the capacity to run dry if they allow it to.
Actually there is also another good reason for doing nothing for a while (probably 2 weeks at least after the new app is out). If there are any issues with the new app, why would you want to be the first to suffer them? If everything falls apart at the start, your previous app_info.xml is your friend :-). If previous experience is any guide, you will suffer no shortages for at least two weeks after the new app first arrives, probably a lot longer. After that time you can choose your moment to convert, exactly when it suits you.
Another "incentive" to stay for the cleanup will be the fact that old work will very likely pay a lot more than the new :-). The new will have the "downgraded" pay scales that Bernd was talking about some time ago :-). That sounds like a good plan to me - do the "cr*p" work and be paid accordingly :-).
So, don't tell anyone else and you and I can share the spoils for the next three months :-).
Cheers,
Gary.
RE: I'm not sure I got this
)
I'm sure by now that you will have worked out that there is no problem with modifying the app_info.xml to allow concurrent crunching of both S5R3 and S5R4. While re-reading your message, a further thought occurred to me on why it's actually a good idea for the bandwidth impaired to create an app_info.xml for themselves for the new stock S5R4 app, if they really do need to limit bandwidth consumption.
If a person is currently on the stock S5R3 app (no app_info.xml) at a random time of the scheduler's choosing, they will be sent a bunch of files (data and executables) for the new run.
As they finish up the old and start the new, they will get server requests to delete the old files.
After that and for a period of perhaps months, there will be a small but significant risk that any request for new work could result in the server sending them an old run resend, with the huge data and executables download penalty that involves. The simple way to avoid this totally would be to look at what executables you have been sent with the new tasks (name and version, etc) and construct yourself an app_info.xml file that allows only the new work. After that, no more old work resends.
At the time of a previous transition (I think the one before last but my memory is hazy) there was a month where my data usage was so abnormally high that I got a bill for excess data of nearly $150 on top of my normal bill. I'm sufficiently concerned enough about this for the future that I've decided to start the hassle of changing ISP's. I'm not unhappy with my current service but I am unhappy with the fact that they want to lock me into a further 12 month contract if I shift to a higher usage plan. Also I can do much better elsewhere as well so it appears. I've been where I am for the last five years so am a bit miffed that "loyalty" seems to count for nothing. I've now got 30 days to get things in order for my current account to be closed. Hopefully I'll be on the new plan with the new ISP around the end of the month anyway, well before the old plan is closed. Effectively I'll have more than three times my current limit for less money and no risk of excess charges. If my usage goes crazy I'll just be shaped.
EDIT: I've moved the above last paragraph and the discussion that followed into a new thread so as not to further hijack the important discussion that was the going on in this thread regarding how those using the app_info.xml mechanism should prepare for transitioning to the new S5R4 apps when they are released.
I apologize for being the unthinking perpetrator of the hijack, hopefully now fixed :-).
Cheers,
Gary.
Here's something I just
)
Here's something I just thought of. . .
When the SSE2 app got accidentally released a while back, I think we pretty much determined that SSE2 does provide a significant speed-up over normal SSE. Has anyone given any thought to providing non-SSE, SSE, and SSE2 apps in one package, with the CPU auto-detection mechanism that we now have for non-SSE and SSE?
To get back fully on topic,
)
To get back fully on topic, here is another bit of preparation/information that people currently using the app_info.xml mechanism should think about.
If last time is anything to go by, there were some fairly rapid fixes/changes that needed to be made to the newly released S5R3 apps not long after they were first released. I can clearly remember still getting S5R2 resends at the time that new betas for S5R3 were appearing. It required me to do quite a bit of editing and deploying in order to support both the handling of resends and the participation in the beta tests on a bunch of machines. This raises the probability of trashing the task cache through human error if you don't fully understand what you are doing when adapting your app_info.xml file, or when trying to do all the changes too quickly and across multiple platforms.
The more I think about the possibilities for grief, the more I realize that having Bernd prepare a suitable set of "transition packages" for the different platforms is probably the best option. We just need to persuade him to take on the pain of actually doing it :-).
Cheers,
Gary.
RE: ... providing non-SSE,
)
There's been nothing mentioned that I've seen and I guess Bernd will ultimately decide how much he can cope with. I'm guessing it might be a lot harder to make sure the SSE/SSE2 capability of a CPU can always reliably be determined.
Cheers,
Gary.
As for SSE2, I know that
)
As for SSE2, I know that Bernd is indeed considering to have a SSE2 app as part of a switching app., at least for Linux. We'll see.
As for the transition to S5R4, I guess this will be more demanding (download wise) than the switch from S5R2 to S5R3. Not sure this wasn't mentioned already, but the data files used below 800Hz for S5R2 and S5R3 were actually the same, so many clients back then could in fact continue crunching for S5R3 on data they had downloaded in S5R2. This should not be possible for S5R4 because as I understand it, S5R4 will use different raw data ==> new l1_* and h1_* files.
CU
Bikeman
RE: As for SSE2, I know
)
Well, I'll be mightly grumpy if AMD64/Linux hosts get the advantage that they had back during the early S5R2 run...which is probably what giving the SSE2 version to Linux-only would do... I understand that it is a benefit to the project because of the Merlin/Morgane stuff, but it still makes that chart at BOINC Combined Statistics that David Anderson loves to get riled up about paint an inaccurate picture, at least as far as my specific hardware is concerned (AMD64/Windows), as the faster Linux hosts will make it "seem like" the credit payout is "too high"...
There'd at least need to be a "Power Users" version for Windows, IMNSHO...
If I remember correctly the
)
If I remember correctly the SSE2 variant was far more useful for the Intel CPU's that to the AMD ones, right?
Let's wait and see what happens. The idea for SSE2 support at the end of S5R3 was not to provide a new hand-optimized assembler version but to have a version compiled with the corresponding compiler switches. As for the GNU gcc compiler under Linux, this did help indeed quite a lot, at least for Intel CPUs. I'm not at all sure the Microsoft compiler under Windows will generate the same kind of benefit for SSE2.
From what I analyzed for the Linux app, the difference in speed between the SSE and SSE2 versions were mostly generated by the that a single line of code was translated by the gcc compiler with and without the SSE2 support enabled.
CU
BRM
RE: If I remember correctly
)
I'm running all AMD CPUs with a mix of Windows and Linux.
My Linux XP 2500+ is pulling ~19.8 CS/hr while my Windows XP Pro XP 2600+ is only pulling ~19.1 CS/hr. The Linux box is crunch-only however, and the Windows box does video capture occasionally.
My Linux(64-bit) X2 4000 is pulling ~37.3 CS/hr/cpu while my WinXP-64 X2 4600 is only pulling ~30.5 CS/hr/cpu. Again, the Linux box is crunch-only while the Windows box is used occasionally for other things (it's my primary system).
Note that different data paks, even if they give similar credits per WU, can take different amounts of time to crunch even considering peak/trough crunch times.
All windows systems run 4.36; the Linux boxes run 4.38 (XP 2500+) and 4.49 (X2 4000+). The X2 boxes are both overclocked 10%.
[edit]My daughter's X2 4000+ WinXP-32 (not OC; used occasionally for gaming; running 4.36) is pulling ~28.1 CS/hr/cpu. [/edit]
Seti Classic Final Total: 11446 WU.
This might be subject to
)
This might be subject to change, but some preliminary info to end speculations here:
Most likely S5R4 will start with Applications very similar to the last Beta Apps, i.e. SSE2 App for MacOS Intel, switching x87/SSE App for Windows, switching G3/AltiVec App for MacOS PPC (which will remain the slowest one in comparison), and an App that switches SSE2/SSE/x87 Apps for Linux.
The next improvements targeted for the Apps are getting the Windows App compiled with MinGW, so gcc-specific improvements could be ported to Windows (SSE2 optimizations), and, more general, get the "weighted" Hough code up to the speed of the currently used "unweighted". As the main improvement there is the prefetching, I'd suspect systems with a faster memory interface (AMD) to be a little faster in that part at the beginning.
However before that we have to get S5R4 running at all, and an almost equally high priority is a major server code upgrade. I doubt that any major work on the App code will be done before that.
BM
BM