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.

Td4 time drifts  

 Data from 01feb12 thru 20feb12 (10:00 hours) was analyzed to see if the little star tmscounter time was drifting.

• Compute tmsCounterSec - utcSec  for every sample in  a data
• utcSec is the utc second for the tick when the little start status block is read.

• 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 were switches..
• This was to see if maybe one of the little start computers had problems.
• The problem stayed with td 4.
• 17feb 12: the little star program  on td4 was edited to declare tmscounter and tmscounteratlast100ms to be SHARED variables.
• The accesses to these 4 byte variables are now atomic. Interrupts are disabled, enabled around access to these variables
• 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 interrupt mode.
• 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 corrupting something,
• the access was switched from td12,td4,td8 to td12,td8,td4.
• The problem remained.

Summary:

• 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 is 3??
  
• 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.
  

<- page up

home_~phil