Been following this with interest, and have 2 questions you may care to answer?
We are here to serve :-).
(Although sometimes we might wish that that service didn't involve quite so much repetition of what had already been written :-).
Quote:
First: If my caches, which will continue to crunch, are finishing after the server upgrade next week, will this be an issue?
If it could possibly be an issue then I'm in big trouble :-). No, it won't be a problem!
At the moment some new (and hopefully higher capacity) hardware is being prepped to take over the role of the current hardware. This new hardware will be loaded with all the stuff that is currently running as well as the new stuff required for the new S5R4 run. If you look at the current server status page, you will see that there are still S5R2 programs (assimilator and validator, etc) that are running just in case a stray S5R2 result comes wandering back 9 months or more after S5R2 officially finished. I imagine the S5R3 equivalent programs that are running now will still be running next week, next month and probably even when S5R4 is heading towards completion. Whenever your machine(s) are able to return completed tasks, there will be suitable programs running to deal with those tasks, validate them and assign you the credit.
Quote:
Second: I am using the SSE version to crunch the S5R3 WUs. I am not sure whether this SSE client, with the right app_info fie, can also crunch the S5R4 WUs (when these are released to the wild)?
A different app (with S5R4 as part of its name) will be provided next week. As your machines request new work, the scheduler will make the decision to send you either "resend" work for S5R3 (if available) or the new app and new data for the new S5R4 run. This will be at the discretion of the scheduler for those who are not running any beta or power app - ie most people.
For those (relatively small number) of you operating under the anonymous platform mechanism (app_info.xml), the scheduler will be prevented from sending S5R4 work unless and until you either delete your app_info.xml file or modify it to be "dual app ready". If you want to understand the full implications of the various choices that you have to decide on, you should reread the earlier posts in this thread from various people, which explain those choices. If you don't plan properly, you could easily trash any work that is currently in your cache.
In previous messages, I've said that people using app_info.xml should leave things as they are until either your cache is empty and results are reported or until you have modified your app_info.xml file to handle the transition (dual app ready). I've said that I will publish at least one example of what the app_info.xml file should look like after I've had time to download the new app and test everything to my satisfaction. This of course will depend on when the project comes back up again on the new hardware. If the project comes back up on Monday, I should have something ready by Tuesday but I'm not promising a firm date.
Been following this with interest, and have 2 questions you may care to answer?
First: If my caches, which will continue to crunch, are finishing after the server upgrade next week, will this be an issue?
No, it will accept the work for quite a while after. There are reruns that will go out after and need to be accepted.
Quote:
Second: I am using the SSE version to crunch the S5R3 WUs. I am not sure whether this SSE client, with the right app_info fie, can also crunch the S5R4 WUs (when these are released to the wild)?
You will not get R4 without either deleting the app_info, or modifying it. I deleted it a few days back (my RAC dropped like a rock). I hate messing the the xml files.
Many thanks for the replies from Gary (a very detailed, if for him repetitive one) and to Pooh Bear 27.
I had noticed the servers covering earlier WUs (S5R2, etc), and should have realised the same facility would be available here.
I am pleased to use the SSE client, and the appropriate app_imfo.xml file, to crunch the current remaining S5R3 WUs in my cache. I also look forwards to sight of the new app_imfo.xml that will be released. I will also back read this thread next week.
I must apologies for asking a repeat question, but I only look in occasionally.
Shih-Tzu are clever, cuddly, playful and rule!! Jack Russell are feisty!
Just had a peek at the server status screen, unsent 4.
So I guess that is the end of S5R3 except for the few re-sends.
This morning the unsent count has moved around a little with values such as 8,6,3,4 (yes, sometimes it has increased).
However the "oldest unsent result" value is currently 12 minutes, which is long after the big crunch earlier this week in which all remaining S5R3 work was generated. At face value this might mean some tiny trickle of next release stuff is going out? Or is there some other mechanism for something that was counted as "sent" to be reclassified as unsent, while also resetting the age timer?
Once we have an SSE2 App for Windows then probably built with the same compiler we use for Linux and MacOS Intel, most Apps used out there should behave roughly the same from the timing aspect, so this should be easier to handle.
That's music to my ears Bernd... It kinda chaps me that there's all this NOISE about "equal credit", when there are examples where there is currently a degree of inequality, such as here, comparing a dual-boot Linux and Windows system. The Linux side will be significantly faster because the app performs better...
Also, I have made the decision to bring my Pentium 4 over here as its' primary project due to the technical issues at Cosmology and the political issues at SETI, so this is welcome news from that aspect as well...
Just had a peek at the server status screen, unsent 4.
So I guess that is the end of S5R3 except for the few re-sends.
This morning the unsent count has moved around a little with values such as 8,6,3,4 (yes, sometimes it has increased).
However the "oldest unsent result" value is currently 12 minutes, which is long after the big crunch earlier this week in which all remaining S5R3 work was generated. At face value this might mean some tiny trickle of next release stuff is going out? Or is there some other mechanism for something that was counted as "sent" to be reclassified as unsent, while also resetting the age timer?
More likely these are _2 (or higher) WUs that are replacements for never returned work.
Just had a peek at the server status screen, unsent 4.
So I guess that is the end of S5R3 except for the few re-sends.
This morning the unsent count has moved around a little with values such as 8,6,3,4 (yes, sometimes it has increased).
However the "oldest unsent result" value is currently 12 minutes, which is long after the big crunch earlier this week in which all remaining S5R3 work was generated. At face value this might mean some tiny trickle of next release stuff is going out? Or is there some other mechanism for something that was counted as "sent" to be reclassified as unsent, while also resetting the age timer?
More likely these are _2 (or higher) WUs that are replacements for never returned work.
Yes, from direct observation I've seen a couple of hosts trying to report work actually succeed and then be given a resend task at the same time (_2 or higher). I'm sure there isn't any new work going out yet.
The resend work is probably quite a steady stream coming mainly from stuff issued 18 days earlier that is now expiring. I had thought that the old project would have been shut down at this time and that the resends would simply accumulate over the weekend. It seems the old project is still running and that the resends are being sent out as soon as they appear.
When the new systems are brought on line next Monday, I would imagine that many hosts will shift automatically to the new run (all the set and forget hosts using stock apps and stock caches which are currently hammering the old system). Resends from the previous 18 days will continue to be generated but there will be fewer and fewer hosts actually requesting them specifically. Those using the anonymous platform (AP) mechanism who leave their app_info files in place will increasingly be useful in stopping a buildup of resends.
If there were no AP hosts, there would likely be a future problem with not enough "unconverted hosts" remaining to service the resend flow. The scheduler might have to start "reconverting" some hosts that had been converted to S5R4 in order to keep up with the flow. I believe I saw something like this happening last time which was why I went to the trouble of making some of my hosts "dual app ready" last time.
The downside for people willing to make their hosts dual app ready is that they will be running the new stock app under AP. If the project upgrades the new stock app at some stage in the future (highly likely) the AP hosts would not be able to use the upgrade until the app_info file was modified or deleted, which (just as for current AP users now) would have to be done with some care.
If you aren't able to be paying attention to what is happening with the new run, it would probably be best not to continue using AP.
...and when all the clients will be converted all at once when they ask for new work on Monday, they will all have to download a full set of input files from mirror sites. I guess that could lead to some heavy server load in the first hours of S5R4, let's see what happens.
So I guess seen from a positive angle, the efforts that went into the Ready Reckoner and all the runtime statistics collecting wasn't in vain, and can now be used now to help calibrate the WUG's credit scheme :-).
Ah, so great minds DO think alike ( while fools ... ) :-)
As Baldrick ( Tony Robinson, of BlackAdder ) says - 'I have a cunning plan'. Which file in the BOINC directory discloses the detail of the currently running work unit(s)? client_state.xml ( if sampled regularly ) would divulge all the RR inputs we have been discussing?
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: Been following this
)
We are here to serve :-).
(Although sometimes we might wish that that service didn't involve quite so much repetition of what had already been written :-).
If it could possibly be an issue then I'm in big trouble :-). No, it won't be a problem!
At the moment some new (and hopefully higher capacity) hardware is being prepped to take over the role of the current hardware. This new hardware will be loaded with all the stuff that is currently running as well as the new stuff required for the new S5R4 run. If you look at the current server status page, you will see that there are still S5R2 programs (assimilator and validator, etc) that are running just in case a stray S5R2 result comes wandering back 9 months or more after S5R2 officially finished. I imagine the S5R3 equivalent programs that are running now will still be running next week, next month and probably even when S5R4 is heading towards completion. Whenever your machine(s) are able to return completed tasks, there will be suitable programs running to deal with those tasks, validate them and assign you the credit.
A different app (with S5R4 as part of its name) will be provided next week. As your machines request new work, the scheduler will make the decision to send you either "resend" work for S5R3 (if available) or the new app and new data for the new S5R4 run. This will be at the discretion of the scheduler for those who are not running any beta or power app - ie most people.
For those (relatively small number) of you operating under the anonymous platform mechanism (app_info.xml), the scheduler will be prevented from sending S5R4 work unless and until you either delete your app_info.xml file or modify it to be "dual app ready". If you want to understand the full implications of the various choices that you have to decide on, you should reread the earlier posts in this thread from various people, which explain those choices. If you don't plan properly, you could easily trash any work that is currently in your cache.
In previous messages, I've said that people using app_info.xml should leave things as they are until either your cache is empty and results are reported or until you have modified your app_info.xml file to handle the transition (dual app ready). I've said that I will publish at least one example of what the app_info.xml file should look like after I've had time to download the new app and test everything to my satisfaction. This of course will depend on when the project comes back up again on the new hardware. If the project comes back up on Monday, I should have something ready by Tuesday but I'm not promising a firm date.
Cheers,
Gary.
RE: Been following this
)
No, it will accept the work for quite a while after. There are reruns that will go out after and need to be accepted.
You will not get R4 without either deleting the app_info, or modifying it. I deleted it a few days back (my RAC dropped like a rock). I hate messing the the xml files.
Many thanks for the replies
)
Many thanks for the replies from Gary (a very detailed, if for him repetitive one) and to Pooh Bear 27.
I had noticed the servers covering earlier WUs (S5R2, etc), and should have realised the same facility would be available here.
I am pleased to use the SSE client, and the appropriate app_imfo.xml file, to crunch the current remaining S5R3 WUs in my cache. I also look forwards to sight of the new app_imfo.xml that will be released. I will also back read this thread next week.
I must apologies for asking a repeat question, but I only look in occasionally.
Shih-Tzu are clever, cuddly, playful and rule!! Jack Russell are feisty!
RE: Just had a peek at the
)
This morning the unsent count has moved around a little with values such as 8,6,3,4 (yes, sometimes it has increased).
However the "oldest unsent result" value is currently 12 minutes, which is long after the big crunch earlier this week in which all remaining S5R3 work was generated. At face value this might mean some tiny trickle of next release stuff is going out? Or is there some other mechanism for something that was counted as "sent" to be reclassified as unsent, while also resetting the age timer?
RE: Once we have an SSE2
)
That's music to my ears Bernd... It kinda chaps me that there's all this NOISE about "equal credit", when there are examples where there is currently a degree of inequality, such as here, comparing a dual-boot Linux and Windows system. The Linux side will be significantly faster because the app performs better...
Also, I have made the decision to bring my Pentium 4 over here as its' primary project due to the technical issues at Cosmology and the political issues at SETI, so this is welcome news from that aspect as well...
RE: RE: Just had a peek
)
More likely these are _2 (or higher) WUs that are replacements for never returned work.
RE: RE: RE: Just had a
)
Yes, from direct observation I've seen a couple of hosts trying to report work actually succeed and then be given a resend task at the same time (_2 or higher). I'm sure there isn't any new work going out yet.
The resend work is probably quite a steady stream coming mainly from stuff issued 18 days earlier that is now expiring. I had thought that the old project would have been shut down at this time and that the resends would simply accumulate over the weekend. It seems the old project is still running and that the resends are being sent out as soon as they appear.
When the new systems are brought on line next Monday, I would imagine that many hosts will shift automatically to the new run (all the set and forget hosts using stock apps and stock caches which are currently hammering the old system). Resends from the previous 18 days will continue to be generated but there will be fewer and fewer hosts actually requesting them specifically. Those using the anonymous platform (AP) mechanism who leave their app_info files in place will increasingly be useful in stopping a buildup of resends.
If there were no AP hosts, there would likely be a future problem with not enough "unconverted hosts" remaining to service the resend flow. The scheduler might have to start "reconverting" some hosts that had been converted to S5R4 in order to keep up with the flow. I believe I saw something like this happening last time which was why I went to the trouble of making some of my hosts "dual app ready" last time.
The downside for people willing to make their hosts dual app ready is that they will be running the new stock app under AP. If the project upgrades the new stock app at some stage in the future (highly likely) the AP hosts would not be able to use the upgrade until the app_info file was modified or deleted, which (just as for current AP users now) would have to be done with some care.
If you aren't able to be paying attention to what is happening with the new run, it would probably be best not to continue using AP.
Cheers,
Gary.
...and when all the clients
)
...and when all the clients will be converted all at once when they ask for new work on Monday, they will all have to download a full set of input files from mirror sites. I guess that could lead to some heavy server load in the first hours of S5R4, let's see what happens.
CU
Bikeman
RE: So I guess seen from a
)
Ah, so great minds DO think alike ( while fools ... ) :-)
As Baldrick ( Tony Robinson, of BlackAdder ) says - 'I have a cunning plan'. Which file in the BOINC directory discloses the detail of the currently running work unit(s)? client_state.xml ( if sampled regularly ) would divulge all the RR inputs we have been discussing?
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
New HTML style. Nice buttons
)
New HTML style. Nice buttons & fonts. No avatars, yet.
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