I have been trying to do photometry with Siding Spring (SD) data and have been found the exercise quite frustrating. The problem is the same as with the WO data. The integrations just don't start on time. I don't know for sure why. Lior and TJ (Dave Torrey) speculated that the remote machine(s) sd.concam.net and wo.concam.net in this case, become busy sending files and this mucks (note the "m") the timing. The timing offset makes it impossible to take the ratio of photometric measures on different nights but the same sidereal time, because the images then start at different sidereal times!
I am not criticizing anyone here, as the same software works great on other seemingly identical CONCAMs. Even so, is there anything simple we can do to get these files to start on time, at the proper sidereal time, every day, as scheduled?
To give some background, all CONCAMs are supposed to take their images in lockstep -- at the same start time -- around the globe. One reason for this is so that transients seen on one CONCAM are more likely to be seen on another CONCAM. Each CONCAM takes an image every 3m56s -- when the Moon is down the image is 180 s. When the Moon is up the image duration is 20 s.
BTW I have noted informally that the 20 second images come off on time much more than the 180 second images.
Anyway, is there some way that the image taking routine can be given super-high priority and the image transfering routine can be given rock-bottom priority so that the image taking routine overrides any delay being caused by the image transferring routine? Maybe Lior and/or TJ can respond about this (or anyone familiar with linux processing). If so, this may be a simple and quick fix.
- RJN
Starting SD WO files on time
WO has a much faster machine than SD. Therefore, camsnap.exe starts faster at WO so the exposure starts earlier.
One option is to change the code of camsnap.exe so it will start before the picture should be taken, and starts the exposure exactly at the time that is given as a parameter (a new parameter to camsnap.exe). This should eliminate the delay caused by loading the process.
One option is to change the code of camsnap.exe so it will start before the picture should be taken, and starts the exposure exactly at the time that is given as a parameter (a new parameter to camsnap.exe). This should eliminate the delay caused by loading the process.
Lior,
OK, that might work, but it seems to require some programming effort. Can't we just run the file transfer program with the linux "nice" command, which can lower its priority? Then, when the normal priority camsnap.exe command is issued, won't linux immediately take notice of the new higher priority job and run it without delay?
- RJN
OK, that might work, but it seems to require some programming effort. Can't we just run the file transfer program with the linux "nice" command, which can lower its priority? Then, when the normal priority camsnap.exe command is issued, won't linux immediately take notice of the new higher priority job and run it without delay?
- RJN
I'm not sure. After the call to "camsnap.exe", "fishsnap.exe" goes to "sleep" anyway. The problem is that it takes some time for the system to start a new process. Some systems are faster than others.RJN wrote:Lior,
OK, that might work, but it seems to require some programming effort. Can't we just run the file transfer program with the linux "nice" command, which can lower its priority? Then, when the normal priority camsnap.exe command is issued, won't linux immediately take notice of the new higher priority job and run it without delay?
- RJN
This indeed requires some programming efforts. The first problem here is that I can't even compile camsnap.exe.
Lior,
Probably your right. But it might be worth a try on WO or SD since it is a minimal change.
What troubles me is that the systems are sometimes many seconds late in starting an exposure. Isn't one second of computer time like 10 years in people time and like a lifetime in dog years? OK, perhaps dogs aren't so important here, but my point is what is the computer doing for that 10 seconds? How can it sleep 10 seconds past its scheduled exposure time?
Another idea is that it might all be related to the time that these systems lose when taking exposures. Somehow this time isn't being reset when the exposuse stops and the date and hw clocks are re-slaved to the mother concam.net computer. Or am I barking up the wrong tree?
- RJN
Probably your right. But it might be worth a try on WO or SD since it is a minimal change.
What troubles me is that the systems are sometimes many seconds late in starting an exposure. Isn't one second of computer time like 10 years in people time and like a lifetime in dog years? OK, perhaps dogs aren't so important here, but my point is what is the computer doing for that 10 seconds? How can it sleep 10 seconds past its scheduled exposure time?
Another idea is that it might all be related to the time that these systems lose when taking exposures. Somehow this time isn't being reset when the exposuse stops and the date and hw clocks are re-slaved to the mother concam.net computer. Or am I barking up the wrong tree?
- RJN
-
nbrosch
- Ensign
- Posts: 78
- Joined: Tue Jul 27, 2004 1:45 pm
- Location: Back at Tel Aviv University after a sabbatical
WO CONCAM
Bob, Lior:
We (Ezra and myself with a couple of other guys) plan to go down to the WO site this coming Sunday and will be there at night (though most of our work needs to be done during daytime). If there are things to try, pls give us a buzz.
Noah
We (Ezra and myself with a couple of other guys) plan to go down to the WO site this coming Sunday and will be there at night (though most of our work needs to be done during daytime). If there are things to try, pls give us a buzz.
Noah
I have been thinking about this problem and I now think that it can be solved by changing the file "clockdaily.script" that runs on the remote stations. A copy is visible here.
This linux script file is very short so I will list it here:
The script gets the time from concam.net and then resets both the "date" and "hwclock" clocks and also displays the times for debugging. It used to be that this file was called only once a day (hence its name) but now it is called before and after every exposure. My worry starts with the "date" clock losing up to several seconds during an exposure, a well known phenomenon. Normally this would not matter since the next "rdate" command will reset it but if the Internet connection is really slow then the exposures start will follow the time-losing "date" clock before "rdate" has a chance to resynch it to the proper concam.net time. Hence the odd time offsets.
I think the fix is to resynch the "date" clock to the "hwclock" again before every exposure. Then even if the BOTH the Internet connection is slow AND the "date" clock is losing seconds per exposure, the "hwclock", which is completely seperate from the "date" clock and should lose much less than one second per exposure, can step in and resynch the time as best it can. Which should be pretty good -- much better than the seconds that are being lost now.
Specifically, one new line of code should be added to implement this plan:
should be added as the first line in the file. If everything is running well nothing should be affected since the "rdate" resynch will happen just after this.
If this is correct then we can make this software change from here and nothing needs to be done physically at the remote stations.
- RJN
This linux script file is very short so I will list it here:
Code: Select all
date
/sbin/hwclock
rdate -s concam.net
date
/sbin/hwclock
/sbin/hwclock --systohc
date
/sbin/hwclock
I think the fix is to resynch the "date" clock to the "hwclock" again before every exposure. Then even if the BOTH the Internet connection is slow AND the "date" clock is losing seconds per exposure, the "hwclock", which is completely seperate from the "date" clock and should lose much less than one second per exposure, can step in and resynch the time as best it can. Which should be pretty good -- much better than the seconds that are being lost now.
Specifically, one new line of code should be added to implement this plan:
Code: Select all
/sbin/hwclock --hctosys If this is correct then we can make this software change from here and nothing needs to be done physically at the remote stations.
- RJN