Thank you Gary, indeed I would be interested in the results/performance ...:-)
Just to be clear about this, if you wish to help Mike gather the results/performance data for as large a number of tasks as possible, you should extend your "extra days" local preference to get a number of extra tasks on board and then you should suspend communications with the project so that all the details for each task crunched stay in your state file and don't get prematurely truncated by uploading and reporting. This will constitute some extra work for you to keep track of what is going on and will disrupt the normal flow of credits to your account. Depending on how much you decide to extend your cache, it might be quite a few days before all the tasks are crunched and you are able to see credit flowing again. During that time your RAC will decline quite alarmingly but think of the "big bang" at the end :-).
A second point is that your wingmen may also notice an increase in their pendings while they are waiting for you.
Thirdly, if you support multiple projects, this is going to distort your downloads from and reports to the other projects as well.
Please don't enter into this unless you are comfortable with all of the above.
Quote:
... plus the other xml files for that matter ...
What other xml files?? There are quite a few but I'm not immediately aware of any that would contain any relevant task information related to skygrid files.
What other xml files?? There are quite a few but I'm not immediately aware of any that would contain any relevant task information related to skygrid files.
Thinking particularly of
sched_reply_einstein.phys.uwm.edu.xml - which has and nodes.
Of course I've yet to see how useful any of this will be.
As an example I feel/hunch there may be some command line influence on point selection/sequencing with, for instance :
--gridType=3
looks suspiciously like the maximum number of pole to pole traversals. From memory the WU sequence number ( 'partitionIndex' ) never seems to exceed ~ 2 + 7/8th's periods/cycles ( numSkyPartitions ) - as displayed on RR7, multi-cycle say. Alternatively it may be some modular/clock arithmetic which determines selection of every third point in a partition, say - so 1 ... 4 .... 7 .... 10 .... followed by 2 ... 5 .... 8 ..... 11 ..... and lastly 3 .... 6 .... 9 .... 12 .... [ these two ideas may be linked ]
--nStacksMax=121
suspiciously resembles the number of points per partition/WU that Bikeman mentioned.
--pixelFactor=0.500
triggers a vague memory of mine - either the frequency 'wings' on a given band, or perhaps some solid-angle/areal overlap on the celestial sphere. Hmmmmm .....
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
I might be wrong but my understanding is that when the local BOINC client decides that it needs to talk to the server, it constructs the request by extracting a standardised set of current information (including the details of all current tasks on board) from the state file. There is nothing in the request that isn't already in the state file. The reply from the server may very well contain details of new task(s) but the client will immediately double check the contents of the reply against the contents of the state file and insert/update the details as appropriate.
So as soon as the exchange is completed, the state file will be up-to-date and the request and reply can be discarded. I believe you can't get anything extra from the most recent request/reply exchange that will just happen to be lying around.
At one point I think you mentioned client_state_prev.xml. It is a slightly older but otherwise duplicate copy of the state file. Again I might be wrong but I believe that it is there just in case the state file is found to be corrupt during a BOINC startup. For example, if the power went down or the computer crashed while the state file happened to be open for writing, it might be that the state file is left in an inconsistent state. If BOINC finds this on restarting, it has a fallback option since the previous version of the file shouldn't be corrupted. So I don't think you need the previous state file either.
The previous state file is as Gary stated. It is just an older copy that is maintained in case the altrerations to the current state file corrupt the system totally. A safety feature implemented so that issues arising from problems when making a rotation in these files occurs ...
I would have to look at the code to get the sequence of operation but, the old file should be the same as the current less one change set ...
RE: Thank you Gary, indeed
)
Just to be clear about this, if you wish to help Mike gather the results/performance data for as large a number of tasks as possible, you should extend your "extra days" local preference to get a number of extra tasks on board and then you should suspend communications with the project so that all the details for each task crunched stay in your state file and don't get prematurely truncated by uploading and reporting. This will constitute some extra work for you to keep track of what is going on and will disrupt the normal flow of credits to your account. Depending on how much you decide to extend your cache, it might be quite a few days before all the tasks are crunched and you are able to see credit flowing again. During that time your RAC will decline quite alarmingly but think of the "big bang" at the end :-).
A second point is that your wingmen may also notice an increase in their pendings while they are waiting for you.
Thirdly, if you support multiple projects, this is going to distort your downloads from and reports to the other projects as well.
Please don't enter into this unless you are comfortable with all of the above.
What other xml files?? There are quite a few but I'm not immediately aware of any that would contain any relevant task information related to skygrid files.
Cheers,
Gary.
RE: What other xml files??
)
Thinking particularly of
sched_reply_einstein.phys.uwm.edu.xml - which has and nodes.
sched_request_einstein.phys.uwm.edu.xml - mentions skygrid names
Of course I've yet to see how useful any of this will be.
As an example I feel/hunch there may be some command line influence on point selection/sequencing with, for instance :
--gridType=3
looks suspiciously like the maximum number of pole to pole traversals. From memory the WU sequence number ( 'partitionIndex' ) never seems to exceed ~ 2 + 7/8th's periods/cycles ( numSkyPartitions ) - as displayed on RR7, multi-cycle say. Alternatively it may be some modular/clock arithmetic which determines selection of every third point in a partition, say - so 1 ... 4 .... 7 .... 10 .... followed by 2 ... 5 .... 8 ..... 11 ..... and lastly 3 .... 6 .... 9 .... 12 .... [ these two ideas may be linked ]
--nStacksMax=121
suspiciously resembles the number of points per partition/WU that Bikeman mentioned.
--pixelFactor=0.500
triggers a vague memory of mine - either the frequency 'wings' on a given band, or perhaps some solid-angle/areal overlap on the celestial sphere. Hmmmmm .....
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: Thinking particularly
)
I might be wrong but my understanding is that when the local BOINC client decides that it needs to talk to the server, it constructs the request by extracting a standardised set of current information (including the details of all current tasks on board) from the state file. There is nothing in the request that isn't already in the state file. The reply from the server may very well contain details of new task(s) but the client will immediately double check the contents of the reply against the contents of the state file and insert/update the details as appropriate.
So as soon as the exchange is completed, the state file will be up-to-date and the request and reply can be discarded. I believe you can't get anything extra from the most recent request/reply exchange that will just happen to be lying around.
At one point I think you mentioned client_state_prev.xml. It is a slightly older but otherwise duplicate copy of the state file. Again I might be wrong but I believe that it is there just in case the state file is found to be corrupt during a BOINC startup. For example, if the power went down or the computer crashed while the state file happened to be open for writing, it might be that the state file is left in an inconsistent state. If BOINC finds this on restarting, it has a fallback option since the previous version of the file shouldn't be corrupted. So I don't think you need the previous state file either.
Cheers,
Gary.
The previous state file is as
)
The previous state file is as Gary stated. It is just an older copy that is maintained in case the altrerations to the current state file corrupt the system totally. A safety feature implemented so that issues arising from problems when making a rotation in these files occurs ...
I would have to look at the code to get the sequence of operation but, the old file should be the same as the current less one change set ...