TimeSync (Frequently Asked Questions)
- How do I ... install ...deinstall ...upgrade...TimeSync?
...turn off event log messages ? - Where can I find ...the binaries ...error messages?
- Why doesn't ...TimeSync show any messages ... TimeSync terminate in immediate mode ... the clock stay accurate when the PC is switched off?
- Who is ...an NTP server?
- What is ...NTP ... adjustment ... the difference between /install and /immediate?
- When is/does ...TimeSync set the clock?
- How good is TimeSync?
- Why do I need to use TimeSync?
- Does TimeSync have ...an NTP server ...a TCP/IP time server ... any other server component?
- Do you have a sample configuration file?
- What can I do with a web-based parameter file?
- Is TimeSync ... Year 2000 compliant .... cluster-ready?
- Will TimeSync work ... if the time source is in another timezone ... across daylight savings transitions ... if I change the Timezone on my notebook ... I'm still having difficulties, what gives?
- Are there ...bugs in TimeSync?
How do I ...
...install TimeSync?
Detailed installation instructions are in the main document. Here are simplified instructions for the impatient. Before installing it you have to find a machine that will act as the time source. Once that is done copy the file TimeSync.exe to the directory %SystemRoot%\system32\ and type the following in a console window: "timesync /install <time source>". For example, if you had picked an NT server named goofy as the time source, this is what you would have to enter: "timesync /install /nt_machine=\goofy". This will cause TimeSync to synchronize at startup and every 8 hours after that. You can customize TimeSync better with command line arguments.
Usually workstations are made to synchronize with the PDC (Primary Domain Controller). If this is what you would like to do, you are in luck. Just omit the time source in the instructions above. TimeSync will determine the PDC and synchronize with it. Thus the command line that you need to type reduces to "timesync /install". Simple, eh? However, do not do this on the PDC itself as it will smugly synchronize with itself! I recommend that all servers/controllers synchronize with a machine outside the domain.
...deinstall TimeSync?
In a console window type "TimeSync /remove". Delete the TimeSync.exe file. That should remove the last traces of TimeSync.
...upgrade TimeSync?
If you are currently running a previous version of TimeSync (0.6 or earlier) you should first type the following in a console window: "Net stop TimeSync" followed by "TimeSync /remove". You have now deinstalled the previous version of TimeSync. Now follow the instructions for installing TimeSync above.
...turn off event log messages?
There are two ways of going about this. If the success messages in the event log are of no use to you, they can be turned off by installing TimeSync with the parameter "/trace=error". This will only show error messages. You cannot turn off error messages.
If you do not want to clog the event log with TimeSync messages but would nevertheless like to see what it is doing you can redirect the log messages to a file with the parameter "/log=logfilename.log". This will function as a circular buffer with a maximum default size of 10 KB. If you want to specify your own size for the file append a comma and the file size in KB to the name of the file, e.g. "/log=timesync.log,200". This will cause TimeSync to write all log messages to the file named timesync.log. It will not grow larger than 200 KB. After appending messages it will eventually reach that size. At this point it will start overwriting the lines at the beginning. You can find the latest messages by looking for the line "--end--" and walking back from there. With this feature you can be sure that your disk will never get full but will still be able to see the latest activity.
Back to Top
Where can I find ... ?
...the binaries?
TimeSync binaries may be downloaded from my Web server. Check out http://www.intsoft.com/products/timesync/download.php for details.
...error messages?
TimeSync writes error messages to the event log by default. Search for it in the application section. If you have redirected log messages to a file the error messages will appear in the specified file.
Back to Top
Why doesn't ... ?
...TimeSync show any messages?
Error messages are written, by default, to the event log. If you specified an alternate logging file all messages will be in that file. If you specified /trace=error, only error messages will be included in the log device; other messages will be suppressed. Further, TimeSync writes success messages only after completion of the action. Thus, the message that TimeSync has successfully synchronized if adjust is specified will show up after the adjust period which can take up to 30 minutes.
... TimeSync terminate in immediate mode?
You wanted to set the clock from the command line and specified /immediate but TimeSync just hung at this point. Right? With version 1.4 the default has changed to clock adjustment which means that it needs some time to nudge the clock gently till it falls in line. This can take up to 30 minutes. If you do not want adjustment just use /adjust=no. Prior to version 1.4 the default was no adjustment. Therefore, TimeSync has not crashed but merely trying to discipline you clock. Despite the warning in the documentation many users thought that TimeSync was hanging when it did not return. I have therefore made TimeSync display a message that clock adjustment is going on so that users do not panic.
... the clock stay accurate when the PC is switched off?
A couple of reasons for this. When the PC is switched off the RTC (Real Time Clock) on your motherboard takes over the duty of timekeeping. At this time the operating system is naturally not in control. On booting up the machine again the operating system reads the current time from the RTC and keeps the time till the machine is switched off again. The RTC has a resolution of 1 second which means that there could be an inaccuracy or +- 0.5 seconds. On top of this the RTC might drift due to the characteristics of the crystal clock.Crystals are very sensitive to temperature and when the PC is off the temperature tends to be lower. The drift of the crystal could be considerable if the PC is not off over longer periods.
Back to Top
Who is ... ?
...an NTP server?
If you have a connection to the Internet there are public NTP servers. Even your access point to the Internet may have NTP installed.
Back to Top
What is ... ?
...NTP?
Network Time Protocol is an Internet standard for very accurate time keeping. The accuracy could be even as high as +- 1 millisecond; the standard itself can handle accuracy in the microsecond range. In practice, however, one should expect a deviation of +- 5 milliseconds. Please ask your friendly ISP and complain if he does not have an NTP server. In this day and age keeping the current time is not a luxury.
Adjustment is the process by which the operating system clock is speeded up or slowed down over a time period in order to compensate for inaccuracy. For example, let's assume that your PC clock is 2 seconds behind. Further let us assume that TimeSync has 100 seconds during which has to correct the clock. This means that during the next 100 seconds TimeSync will have to speed up the clock so that at the end of that period the time would have advanced by 102 seconds. During each timer tick that occurs every 10 milliseconds, the clock will be advanced by an almost imperceptible 10.2 milliseconds instead of 10 milliseconds. A user on the machine will not notice it and all the scheduled jobs will run as before. After the 100 seconds are up adjustment will be switched off and the clock will run as before. At this point the clock would have advanced by 102 seconds, effectively making up for the 2 seconds that it was behind.
... the difference between /install and /immediate?
It is subtle but important - /install installs the TimeSync service with all the parameters specified on the command line whereas /immediate runs TimeSync without installing the service (but with all the parameters on the command line). The typical use of /immediate is to test is TimeSync will function properly when run as a service. One could specify all the time sources and other arguments and check out if TimeSync gets any errors. Once this is done to your satisfaction, execute the command line again with /immediate substituted with /install.
The defaults for some arguments are different in each case. Error & success messages are written by default to the console in the case of /immediate; these messages go to the event log when TimeSync runs as a service through /install. Thus, when testing time sources one can see the errors in the console and make changes accordingly.
Back to Top
When is/does ... ?
...TimeSync set the clock?
This depends on two parameters: at and period. At determines when TimeSync starts synchronizing. Period is the time duration from one synchronization point to the next. If you did not specify /at it will synchronize when TimeSync starts up. If you did not specify /period the default value is 8 hours. If you reboot the machine TimeSync will start automatically.
If you specified /adjust, it will take a short duration during which NT will speed up or slow down the clock. This will be half the period that was specified up to a max of 30 minutes.
Back to Top
How good is TimeSync?
Naturally, TimeSync cannot do better than the time sources that you specify. If the time sources are not accurate your clocks will not be accurate either. Hence you need to find machines that have accurate clocks. This means that if you have access to the Internet that one or more of your machines should act as local time servers by synchronizing with an Internet NTP server. The rest of the machines should synchronize with these local time servers. If you do not have access to the external world you may be able to use a radio clock or dial-up to a time server periodically on one machine.
If you have an accurate time source and use NTP or NT's LanManager protocol, the clocks could be kept within +-50 milliseconds on average. With TCP time protocol you should not expect better that +- 1 second as that is the resolution of the time message.
I have compiled some charts of how good TimeSync is when used on some rogue machines.
Why do I need to use TimeSync?
The clock of a typical PC drifts with time - just like any other clock or watch. The amount by which it drifts depends very much on the quality of the clock chip. Some of them deviate by as much as 25 seconds per day. This accumulates over time and at the end of the month the clock could almost be 15 minutes out of sync with the actual time! If you are on a network, file times will not be accurate which may cause problems with make (if you happen to be developing software) or reloading files in Netscape, etc. Further, error messages in the event log cannot be compared with those of other machines, because you will not be able to see the real sequence of what happened. Therefore, it is imperative that all the clocks of a network are in sync.
Does TimeSync have ...?
...an NTP server?
No. TimeSync only has an NTP client.
...a TCP/IP time server?
Yes. TimeSync TCP/IP time server on the TCP time port.
... any other server component?
No. But NT has a Lan Manager server and therefore you can get the time from any NT machine and the operating system will provide an answer. TimeSync does not need to do anything here.
Do you have a sample configuration file?
Here is one that you could build on. It is annotated with comments. It has several time sources so you might want to remove unnecessary ones and replace the names.
| # # A sample configuration file for TimeSync # /domain # use the PDC of my domain /domain=sales # a well-known domain in my network /domain=personnel # another well-known domain in my network /ntp_machine=ntp.mydomain.com # a primary time server in my network /select=1,40 # choose one of the time servers listed above for 40 sync periods /period=2:0:0 # sync every 2 hours (i.e. the sync period) /adjust # adjust the clock instead of jamming in the new time /log=c: emp\TimeSync.log,50 # write all messages to this file instead of the event log; max length 50 Kbytes |
Here 4 time sources are specified: the PDC of the workstation's domain, the PDC of the domain named sales and personnel and an NTP machine named ntp.mydomain.com. For the time source election all 4 of the specified time sources will be asked for their times. The time source that has the least network delay will be elected as the definitive time source. TimeSync will use it for a maximum of 80 hours (40 periods x 2 hours per period) before conducting another election with all four time sources again.
Here is a variant of the above for those who think that the network load involved in asking 4 time sources for their time is unacceptable. By changing the select statement to /select=1,40,R only the minimum required time sources will be contacted. TimeSync will contact the time sources in the order specified. Out of the 4 machines, the first one that replies will elected as the time source; none of the others will be contacted. Thus, in the example above, the PDC of the workstation's domain will be contacted. If it replies, bingo! That will be used as the definitive time source for the workstation. If it does not reply, the next one will be contacted and so on.
What can I do with a web-based parameter file?
The configuration information for TimeSync is entered on the command line when TimeSync is installed. To ease the job the configuration parameters can be put into a file and then the name of the file can be told to TimeSync with the /file control argument. An further advantage of using a file is that if changes are required to the configuration all that is required is that the file be modified accordingly and TimeSync be stopped and restarted. Both these actions can be done remotely. But I still need to update the file on all machines which can be a royal pain. Couldn't I keep the file on a central server and make all TimeSync instances point to that file? Brilliant! Unfortunately, this does not work because the account that TimeSync runs under (LocalSystem) does not permit access to the network through the Lan Manager interface; file system falls under this too. TCP/IP, however, does not fall into this category and due the current popularity of web and FTP servers it was considered desirable to add this feature. Thus, you can store a central file on a web server and have all instances of TimeSync get their parameters from it. The appropriate buzzword is 'reduced TCO' (Total cost of Ownership). If your boss refuses to buy TimeSync throw in this acronym and watch the situation change!
You could go one further and generate the file on-the-fly in the server by checking the name of the machine the request came from. You could customize it depending on network topology, the time of the day, etc. The possibilities are endless...
Is TimeSync ...
... Year 2000 compliant?
Yes. TimeSync will function correctly across the millenium transition (December 31, 1999 to Jan 01 2000). This has been tested by setting the clock to 11:55 December 31 1999 and watching the activity as the year changed to 2000. Several clients have performed this test independently and come to the conclusion that TimeSync will fly through it with nary a problem. Before I take credit for this let me say that the protocols were designed this way and TimeSync just uses it as should be. Having got the year 2000 out of the way, let me relate that there are limitations. In particular, at some point in the year 2037 there will be a singularity: the seconds counter will overflow the 32-bit that has been allocated for it. Frankly, I do not see TimeSync running 38 years from now but if it is still being used in the year 2025 I promise I will make an update that will tide over that limitation. That's more than 11 years before that great event - early enough in my opinion. Any complaints? I wonder which version of NT will be on our Merced++ machines then :-).
.... cluster-ready?
Yes, it is. If you look at the default groups in MSCS you will notice a time service. If that's there already do I need TimeSync? The answer is again affirmative. The built-in time synchronizer is only for keeping the two machines of the cluster in sync - not for keeping the cluster node that the group is running on, synchronized with a time source. Therefore, you still need TimeSync. As TimeSync has been written as a standard service without any shortcuts you can install it in the cluster as a generic service. Do it on both machines. No special registry entries are required. Add it to a group and then fail-over and watch TimeSync stop on the failed machine and start on the owner of the group. You can toggle this manually, if necessary. When a machine fails the other one will automatically take over the duty of the synchronizer. In the meantime, the built-in time synchronizer will ensure that the backup node keeps time with the primary.
Will TimeSync work ...
... if the time source is in another timezone?
TimeSync uses UTC (Universal Coordinated Time) which is independent of timezones and daylight savings changes; this is a monotonically increasing counter that has the number of time units from an agreed-on point in time. This is the the format that NT keeps the operating system clock in. When time messages are transferred it is done in UTC. Thus, it does not matter which timezone you are in and if it is different from that of your time reference. If I happen to be in Las Vegas, Nevada I could use the time source situated in Outer Mongolia and still have the correct time.
... across daylight savings transitions?
As explained in the previous paragraph, the fact that UTC is used for all time messages implies that daylight savings transitions do not have any effect at all to the time
... if I change the Timezone on my notebook?
Nope, this does not matter either. The internal clock does not change at all as it is unaffected by the timezone.
... I'm still having difficulties, what gives?
Ensure that your timezone setting is correct and the time, as shown by the control panel applet, is within 10 minutes of the correct time of your locale.
Are there ...
...bugs in TimeSync?
Though I hate to admit it, as is with all good software TimeSync has its fair share of bugs. However, most of it is unknown - even to its maker. We'll not try to dig up those now. Then there are some that I am aware of and, naturally, will be trying to eradicate them. Here are some that you might encounter.
| Symptom | Remedy |
|---|---|
| When /immediate, /log and /trace are specified together, C++ error R6025 is displayed about virtual functions. | Just ignore it as it occurs after all the synchronization work is done. |