Re: [ARMini-support] !NetTime no longer resetting clock
- From: Alan P Dawes <alan.dawes@xxxxxxxxxx>
- To: ARMini-support list <armini-support@xxxxxxxxxxxxx>
- Date: Tue, 07 Feb 2012 13:57:54 +0000 (GMT)
Thanks to everyone for their input. I have now done more testing of
!NetTime (Using !NetTime_Status and *NetTime_kick) and read some postings
to csa from a while ago. Here are my findings.
1) There is no problem with the time servers it uses. They are a pool of
servers so that if one is out of action another will be used.
2) Looking at the date stamps on a number of files yesterday and sunday
were not the only time that !NetTime has failed to set the clock - there
is a set of "Jan 1970" folders and files which were written on the 29th
Jan.
3) At the time of those problems !FreeTime was not on the computer so that
was not a factor (I had started with a new USB stick for RComp Beagleboard
scheme).
4) What seems to be happening is that when !NetTime is first started it
does not reset the time, it checks the internal time and looks at a time
server for the net time and then goes to sleep for what seems to be 4
minutes. It then wakes up and again reads a net time server and if it was
consistent with the previous time server time it resets the clock. It then
goes back to sleep for 30 minutes before waking and adjusting if needed
and so on.
So any files saved during the first 4 (?) minutes after the BB-xm (without
battery) is turned on will have a Jan 1970 date stamp but provided
!NetTime is operating correctly then all will be well after that. Chris
Hall's posting gives his modification to get round this.
5) This does not explain why on 3 occasions, even after 4 minutes after
turning on, !NetTime did not correct the clock. When this happened
yesterday I did a *NetTime_Status which showed the status as "Dormant"
rather than the usual "Sleeping". Nothing that alters the clock had been
run and I only noticed the 1970 date stamp as I had the filer display set
to Full info.
What conditions make !NetTime go "Dormant"?
a) As !NetTime is using the internal clock to decide when to wake up from
sleeping any change in the internal clock makes it go dormant. eg if you
change the date/time using !Alarm and then *NetTime_Status shows Status:
Dormant. After which you would need somthing to issue the *NetTime_kick
command to restart it. I assume that this would be useful to a developer
testing if a program worked correctly at various dates and times without
!NetTime kicking in every 30min to reset the clock.
b) I wonder if another condition for going dormant is an inconsistency
between the first reading of a net time server and the subsequent one.
This would explain the 3 occasions when my clock was not reset. As
!NetTime was written for the Iyonix which has a battery backed clock this
does not be an unreasonable setting.
Consequences of using !NetTime as is on a BB-xm without battery:
1) Always in the first few minutes:
Any files that are saved will have the 1970 date stamp which could have
consequences when installing programs etc.
Any emails sent may have the wrong date stamp and could be discarded as
spam.
2) If !NetTime has become dormant because of b) above then 1) will happen
throughout that session.
What to do:
1) Follow Chris Halls advice:
I put a file in !Boot.Choices.Boot.Tasks called SetTime (a short BASIC
programme) containing
10 SYS "OS_Word",15,CHR$(15)+"Mon,17 Feb 1992"
20*NetTime_Kick
to kick !NetTime into setting the time at start up.
2) I've put an obey file file containing the line:
*Time
on my pinboard so I can easily check that the time has been set by just
clicking on it.
3) If you feel the need for "belt and braces" also use !FreeTime but add to
the end of the !Run file *NetTime_kick to ensure that !NetTime is active
after whatever correction is made by !FreeTime
3) If you run a program which alters the time or use !Alarm to reset it
then
do a *NetTime_kick to wake up !NetTime again.
Does the above tally what others have observed?
Alan
--
alan.dawes@xxxxxxxxxxxxx
alan.dawes@xxxxxxxxxx
Using an Acorn RiscPC
---
To alter your preferences or leave the group,
visit //www.freelists.org/list/armini-support
List-related queries to support@xxxxxxxxxxxx
Other related posts:
