Td 4 time drifting
New little stars were installed on tiedowns 4 and 8 on
24jan12. . The programs for all 3 tiedowns were then
recompiled with the latest zworld compiler (ver 6.). The time on
td4 little star has been drifting, td12 and td8 have no problem.
For an explanation of the tiedown time system
see how the timing works:
Td4 time drifts
Data from 01feb12 thru 20feb12 (10:00 hours) was analyzed
to see if the little star tmscounter time was drifting.
The processing was:
- Compute tmsCounterSec - utcSec for every sample in
- utcSec is the utc second for the tick when the little start
status block is read.
The plots show the tmscounter time
drifting for td4 (.ps) (.pdf):
- Tiedown 12 and tiedown 8 showed no drifts.
- Dates missing showed no drift (01,07,08 feb)
- The vertical scales are different for each day.
- The jumps back to zero are when the settime command was sent
to the tiedowns to resync them to UTC.
- It appears that the drift slows down around 10am each day. The
dashed green line is 32768000 milliseconds.
- Days with large drifts:
- 12feb12: 100 seconds
- 18feb12: 80 seconds.
- 20feb12: 13 seconds.
- Tests to see what was causing the drifts:
- 08feb12: the little star computers at td 4 and td 8
- This was to see if maybe one of the little start computers
- The problem stayed with td 4.
- 17feb 12: the little star program on td4 was edited to
declare tmscounter and tmscounteratlast100ms to be SHARED
- The accesses to these 4 byte variables are now atomic.
Interrupts are disabled, enabled around access to these
- The routines that modify, access these variables are:
- The ConrolLaw is started every 5 milliseconds by the
real time scheduler. It probably is not running in
- The 1 sec tickroutine is running in interrupt mode.It
disables and renables its own interrupt on entry/exit.
- After this change, the tmscounter time of td4
continued to drift.
- 19feb12: switched the order that the vxWorks program queried
td4 and td8.
- I had thought that there might be a problem between
the i/o routine interrupts and the 5 millisecond real
time interrupt. Since the problem stayed at td 4, it might
be that the timing of the status query for td4 was
- the access was switched from td12,td4,td8 to td12,td8,td4.
- td4 is showing tmscounter drifts. td12 and td8 do not
show any drifts
- The drifts seem to slow down and stop around 10am.
- switching little stars at td4,td8 did not change anything. The
problem remained at td4.
- --> the problem is not a bad little star
- The tmscounter variable and tmsCounterAt100ms were set to be
shared (i think tmscounterat100ms was also shared). this made
the accesses atomic.
- This did not affect the problem.
- The order of querying td4,td8 were reversed.
- The drift remained at td4.
- this implies that it is probably not a problem with the i/o
interrupt interfering with the 5sec interrupt.
- What is left of it to be:
- The constant 5 in the program might be wiped out... maybe it
- The 5 millisecond routine must be running more often then
once every 5 milliseconds.
- Something else my be generating an interrupt that is the
same one used by the 5 millisecond scheduler.
- We need to put a scope on the control law active bit when
the clock is drifting to see if it is really be run more often
than once every 5 milliseconds.