As you exhaust the remaining S4 work, you will be getting the new S5 data with time estimates based on your DCF and benchmark values which will be wrong for the new work. The danger is that if you had, for example, a 4 day cache, you may fill up with S5 work which will ultimately prove to have been estimated way too low. When the first S5 result to complete "fixes" this by upping the estimates significantly, you may suddenly find yourself with a lot more work than anticipated. The fix, if you think you might be susceptible to this problem, is simply to reduce your connect to network setting to say 0.5 days or less right now, particularly if you seem to be accumulating a lot of S5 results with surprisingly low estimated times. The times are going to be way longer than what you have been used to with the Akos app.
yeah. I've got too much s5 work because a .13 dfc. I'm going to need to sit down iwth a calculator and figure out how much I can actaully do before the deadline and abort a number of WUs. At least I won't need to worry about running out because my server quota's been cut so far. At ~2x as long as s4 stock client results on the big end I'll only need a half dozenish per day.
A person could "max" their cache at 10 days which would give plenty of S4 work and also plenty of warning when S4 WUs are no longer available as you will see it taper-off and the number of cached WUs will decrease.
At the point that S4 work is completed, send completed WUs, delete app_info.xml, d/l new worker application from server, edit the truxoft_prefs.xml and remove Einstein from calibration or off if it is the only project.
If I'm not mistaken, this would allow a transition that would keep max credit on S4, while migrating to S5 using trux Boinc 5.3.12tx36 w/o the issues below.
Any problems w/ this I'm overlooking?
Yes, plenty of problems!!
Anyone reading this thread please don't max your cache to 10 days. The reason why this is a very bad idea is that you may not get S4 work at all. You have no way of knowing if you might be just 1 workunit away from exhausting your current S4 data file and the server may decide to send you a S5 data file and make up the entire balance of your cache with S5 work. If your DCF just happened to be around 0.2, you could end up with 30-40 real days of work instead of just your cache setting. Everything would look OK until the first S5 result was crunched and the "real" time would then be known. There would suddenly be a big increase in DCF and you would have to end up aborting a big fraction of what had previously been downloaded.
There is no safe way to "max your credit on S4" so the best thing is to just monitor what is being sent to you. My guess is that once you start getting S5, the only S4 you will get from that point on will be dregs of unfinished work. As happened last time, you may get sent a large data file, do one result only and then the data file is exhausted. Unfortunately this is what happens when cleaning up the dregs. As you monitor the S5 work arriving, once you have say 5 results in your worklist (say 10 hours estimated time) realise that this may actually represent a much larger real time of 20 - 50 hours work. At that point just set your cache down to 0.1 - 0.5 range which will stop you getting any more work. Once the first S5 result is crunched and the estimate is "fixed" you can then know exactly how much work you really have and adjust your cache accordingly.
As Ingleside pointed out, once S5 starts crunching it will interfere with the time estimates and credit claiming for any subsequent S4 work that you happen to get. I don't know that you can really do much about this. My guess is that the Trux client will raise the DCF and lower the benchmark so that the remaining S4 work (which will still take its "normal" (short) time) will then be issuing much lower credit claims. The others in the quorum will tend to fix this but any jumping between S5 and S4 is bound to mightily confuse the Trux client :). I would think that the safest action for those in this particular situation to take (ie calibrating or optimised clients) would be to monitor for when the first S5 starts crunching. At that point if you can see that the estimates are way too short then you will know that any further S4 work might really play havoc with the calibrating mechanism so remove it, at least for the EAH project.
Now that both Seti and EAH don't have credit claims based on benchmarks x time, is there any reason to have a calibrating or optimised client?? If not, you could just stop BOINC whilst the first S5 is crunching, replace the client with the standard one and then restart BOINC. In fact it would be a very good opportunity to bring yourself up to the latest version of BOINC by uninstalling whatever version you are currently using and reinstalling 5.4.9. You do not have to worry about the science app or work in progress. These will not be affected by uninstalling and reinstalling BOINC.
You may make a wierd claim for that result in progress but that doesn't matter since the server is going to grant you the correct amount irrespective. After you make this change, remaining S4 work will claim very low but the quorum will tend to fix this at least some of the time. The S4 work will finish pretty quickly anyway as the last workunits have been generated and what is left on the server is all there is. If you look at the server status page you will see that 25K S5 units have already been done and there are about 175K unsent results which I imagine are both S4 and S5. So my guess is that in a day or three, the only S4 work to go out will be replacements for work trashed or not returned by the deadline.
EDIT: Please realise that the above commentary only applies to people using an Akos science app and some form of BOINC calibrating or optimised client. If you are using "beta" apps with the "app_info.xml" mechanism, your actions will be different. If you are using standard apps and a recent standard BOINC client you don't need to do anything but sit back and enjoy the ride into S5.
If you are not using a recent BOINC client (for example if you are still on 4.19 or 4.45, etc, you might do well to upgrade to 5.4.9, the latest stable release since there are quite a few bug fixes and general improvements.
A person could "max" their cache at 10 days which would give plenty of S4 work and also plenty of warning when S4 WUs are no longer available as you will see it taper-off and the number of cached WUs will decrease.
At the point that S4 work is completed, send completed WUs, delete app_info.xml, d/l new worker application from server, edit the truxoft_prefs.xml and remove Einstein from calibration or off if it is the only project.
If I'm not mistaken, this would allow a transition that would keep max credit on S4, while migrating to S5 using trux Boinc 5.3.12tx36 w/o the issues below.
Any problems w/ this I'm overlooking?
Yes, plenty of problems!!
Anyone reading this thread please don't max your cache to 10 days. The reason why this is a very bad idea is that you may not get S4 work at all. You have no way of knowing if you might be just 1 workunit away from exhausting your current S4 data file and the server may decide to send you a S5 data file and make up the entire balance of your cache with S5 work. If your DCF just happened to be around 0.2, you could end up with 30-40 real days of work instead of just your cache setting. Everything would look OK until the first S5 result was crunched and the "real" time would then be known. There would suddenly be a big increase in DCF and you would have to end up aborting a big fraction of what had previously been downloaded.
Yikes! My point of reference was based on the assumption that someone would extend their cache today, but as you pointed-out, to someone reading this thread within the next couple days, it could have quite the opposite effect. Great catch!
I guess one may set to 1.0 or even a bit larger (overestime time-to-complete) from time-to-time so that when S5 arrives, it shold have close to real crunch time and not 0.2 (which suggest that it will be done in 20% of time of what server *thinks*).
btw, fixed credit per each type of model and only server-driven was always there on CPDN since 2004 so nothing new under the Sun :-)
For asome deleting the app_info.xml file (not used on einstien i know) and others had to run down their cache and reinstall boinc before it would allow any of the new units.
The app_info.xml is used on Einstein, if you were using the Beta clients that were available so far. But then just a check in your Messages tab will reveal something of the following:
2006-06-16 12:31:12 [Einstein@Home] Message from server: Remove the app_info.xml file, then restart BOINC to get more Einstein@Home work.
2006-06-16 12:31:12 [Einstein@Home] Message from server: No work sent
Fun misnomer: It doesn't say to exit BOINC first. ;-)
Now that both Seti and EAH don't have credit claims based on benchmarks x time, is there any reason to have a calibrating or optimised client??
My two remaining strong reasons to run the tx36 calibrating client are:
1. generate fair claim on Einstein S4 using akosf S41.07 (this will expire soon)
2. maximum efficiency sharing of my hyperthreaded machine between SETI and Einstein. Tx36 lets me do this with one control file line, whereas I don't know another good way to both have reasonable work caches for outage protection and perfect one thread for SETI, one for Einstein. (this won't expire unless I drop out of SETI)
So, yes, I currently intended to leave tx36 at least on my single HT box, until I learn something more serious wrong. I'll turn off calibration for Einstein once my main S4 completes. As others have suggested, I intend to turn my network connection setting way, way down as soon as appreciable S5 downloads hit my machines. My current Duration Correction Factors range from .17 to .28, so otherwise I could get an awful lot of work beyond my capacity on S5.
I know that. Yet to test out the error message, I would need another application with an app_info.xml file. Else I can't see the error and test it. :-)
RE: As you exhaust the
)
yeah. I've got too much s5 work because a .13 dfc. I'm going to need to sit down iwth a calculator and figure out how much I can actaully do before the deadline and abort a number of WUs. At least I won't need to worry about running out because my server quota's been cut so far. At ~2x as long as s4 stock client results on the big end I'll only need a half dozenish per day.
RE: A person could "max"
)
Yes, plenty of problems!!
Anyone reading this thread please don't max your cache to 10 days. The reason why this is a very bad idea is that you may not get S4 work at all. You have no way of knowing if you might be just 1 workunit away from exhausting your current S4 data file and the server may decide to send you a S5 data file and make up the entire balance of your cache with S5 work. If your DCF just happened to be around 0.2, you could end up with 30-40 real days of work instead of just your cache setting. Everything would look OK until the first S5 result was crunched and the "real" time would then be known. There would suddenly be a big increase in DCF and you would have to end up aborting a big fraction of what had previously been downloaded.
There is no safe way to "max your credit on S4" so the best thing is to just monitor what is being sent to you. My guess is that once you start getting S5, the only S4 you will get from that point on will be dregs of unfinished work. As happened last time, you may get sent a large data file, do one result only and then the data file is exhausted. Unfortunately this is what happens when cleaning up the dregs. As you monitor the S5 work arriving, once you have say 5 results in your worklist (say 10 hours estimated time) realise that this may actually represent a much larger real time of 20 - 50 hours work. At that point just set your cache down to 0.1 - 0.5 range which will stop you getting any more work. Once the first S5 result is crunched and the estimate is "fixed" you can then know exactly how much work you really have and adjust your cache accordingly.
As Ingleside pointed out, once S5 starts crunching it will interfere with the time estimates and credit claiming for any subsequent S4 work that you happen to get. I don't know that you can really do much about this. My guess is that the Trux client will raise the DCF and lower the benchmark so that the remaining S4 work (which will still take its "normal" (short) time) will then be issuing much lower credit claims. The others in the quorum will tend to fix this but any jumping between S5 and S4 is bound to mightily confuse the Trux client :). I would think that the safest action for those in this particular situation to take (ie calibrating or optimised clients) would be to monitor for when the first S5 starts crunching. At that point if you can see that the estimates are way too short then you will know that any further S4 work might really play havoc with the calibrating mechanism so remove it, at least for the EAH project.
Now that both Seti and EAH don't have credit claims based on benchmarks x time, is there any reason to have a calibrating or optimised client?? If not, you could just stop BOINC whilst the first S5 is crunching, replace the client with the standard one and then restart BOINC. In fact it would be a very good opportunity to bring yourself up to the latest version of BOINC by uninstalling whatever version you are currently using and reinstalling 5.4.9. You do not have to worry about the science app or work in progress. These will not be affected by uninstalling and reinstalling BOINC.
You may make a wierd claim for that result in progress but that doesn't matter since the server is going to grant you the correct amount irrespective. After you make this change, remaining S4 work will claim very low but the quorum will tend to fix this at least some of the time. The S4 work will finish pretty quickly anyway as the last workunits have been generated and what is left on the server is all there is. If you look at the server status page you will see that 25K S5 units have already been done and there are about 175K unsent results which I imagine are both S4 and S5. So my guess is that in a day or three, the only S4 work to go out will be replacements for work trashed or not returned by the deadline.
EDIT: Please realise that the above commentary only applies to people using an Akos science app and some form of BOINC calibrating or optimised client. If you are using "beta" apps with the "app_info.xml" mechanism, your actions will be different. If you are using standard apps and a recent standard BOINC client you don't need to do anything but sit back and enjoy the ride into S5.
If you are not using a recent BOINC client (for example if you are still on 4.19 or 4.45, etc, you might do well to upgrade to 5.4.9, the latest stable release since there are quite a few bug fixes and general improvements.
Cheers,
Cheers,
Gary.
RE: RE: A person could
)
Yikes! My point of reference was based on the assumption that someone would extend their cache today, but as you pointed-out, to someone reading this thread within the next couple days, it could have quite the opposite effect. Great catch!
I guess one may set to 1.0
)
I guess one may set to 1.0 or even a bit larger (overestime time-to-complete) from time-to-time so that when S5 arrives, it shold have close to real crunch time and not 0.2 (which suggest that it will be done in 20% of time of what server *thinks*).
btw, fixed credit per each type of model and only server-driven was always there on CPDN since 2004 so nothing new under the Sun :-)
RE: RE: For asome
)
I just improved this, here's the new message.
Bruce
Director, Einstein@Home
RE: Now that both Seti and
)
My two remaining strong reasons to run the tx36 calibrating client are:
1. generate fair claim on Einstein S4 using akosf S41.07 (this will expire soon)
2. maximum efficiency sharing of my hyperthreaded machine between SETI and Einstein. Tx36 lets me do this with one control file line, whereas I don't know another good way to both have reasonable work caches for outage protection and perfect one thread for SETI, one for Einstein. (this won't expire unless I drop out of SETI)
So, yes, I currently intended to leave tx36 at least on my single HT box, until I learn something more serious wrong. I'll turn off calibration for Einstein once my main S4 completes. As others have suggested, I intend to turn my network connection setting way, way down as soon as appreciable S5 downloads hit my machines. My current Duration Correction Factors range from .17 to .28, so otherwise I could get an awful lot of work beyond my capacity on S5.
RE: I just improved this,
)
That should do much better, Bruce. :-)
Thank you.
(Now, where's the next beta EAH app so I can test it again? ;-))
Ageless, that a change in the
)
Ageless, that a change in the scheduler. You don't need to update your app. :)
I know that. Yet to test out
)
I know that. Yet to test out the error message, I would need another application with an app_info.xml file. Else I can't see the error and test it. :-)
Ah :)
)
Ah :)