Note: A pdf version of the News History can be downloaded here.
2019-05-06: Version 3.10 release [Build 0310]
Version 3.10 introduces NTP Auto Cluster. This new feature enables the G Suite to automatically configure (a), refine (b), and maintain (c) a cluster of NTP servers.
When the Auto Cluster feature is enabled (ON), a cluster of NTP servers is automatically configured according to the following set of criteria:
The primary server is mandatory and it is always member of the cluster.
All servers with Stratum <= Max. Stratum suit the Max. Stratum criterion.
The location criterion may also consist of a set of country codes (e.g. "US,DE,BR,FR...")
All of these criteria may be set from within the Auto Cluster Configuration Menu of G_GUI.exe and by means of G_Setup.exe with their associated keywords. The GUI only provides a limited choice for each of them. However, it shows all values set be G_Setup.exe.
The Primary NTP server, as mandatory member of the cluster, may have any location, any stratum, and any address family. It provides data to the NTP cluster algorithms, but it is excluded from the Auto Cluster functionality.
Servers may be pre-configured by means of the G_Setup server_add=... keyword. They may also be added directly by means of the G_Setup cluster_add=... keyword directly. In both cases they will be added to the internal list of configured servers. When this list does not provide enough servers matching the current criteria, the list is automatically extended by a server search (pool.ntp.org) following the current location criterium.
The auto cluster algorithm will attempt to fill the NTP server cluster until the desired cluster size is reached.
NTP cluster members may be removed due to KoD (Kiss-of-death) messages, timeouts, or manually. In any event, the cluster is subsequently filled to the desired size.
The automatically configured cluster of NTP servers may be refined automatically when Auto Refine is enabled (ON) with the enabled Auto Cluster. Three criteria are guiding the auto refinement:
An active auto refinement splits the NTP cluster into two categories. Any new added NTP server will enter an evaluation phase initially. NTP servers in evaluation phase do not contribute to the cluster average and are only evaluated according to the rules stated above. The Max. Timeout criteria and the Max. Offset criteria apply from the beginning. The RTD stdev criteria only applies after 10 NTP Offset captures. The evaluation phase ends successfully for each NTP server after 20 NTP Offset captures with a total of less than 5 faults. Faults are: Max. RTD stdev exceeded and/or Max. Offset deviation exceeded.
The evaluation state is shown in the NTP Server Cluster tab (see next figure below). Faults are reported in the comment column of the respective cluster member; values causing the fault are highlighted with light red background.
Collecting 20 Offset values from an NTP server may take a long time when the NTP update period is chosen to be long. For this reason, the auto refine scheme enters an auto update period of 15 seconds when the period chosen by user exceeds 15 seconds. Setting longer update periods is prohibited (disabled) during this auto period phase.
The Auto Cluster scheme configures an NTP server cluster according to the given criteria, not matter whether NTP is enabled or not. Nevertheless, the auto-refine only acts based on measurements taking place. Hence, it only acts when NTP is active.
A change (by user) to the auto cluster criteria will force a reconfiguration of the cluster to maintain a cluster matching the chosen criteria. This scheme allows to change settings at almost any time. The change of criteria is only disabled (postponed) when NTP server gathering (via. pool.ntp.org) is active.
When an NTP server has succeeded its evaluation phase, it becomes full member of the cluster and contributes to the cluster NTP Offset average. The current max. abs. NTP Offset and the current max. RTD stdev are highlighted with gray background.
The next figure shows the new GUI extensions in the NTP Server Cluster tab dealing with the auto cluster feature:
Details:
All of the new Auto Cluster settings may be configured through keywords supplied to G_Kernel.exe at startup or by means of keywords supplied to G_Setup.exe. See the new keyword sections for G_Kernel.exe and G_Setup.exe further down.
Related GUI menu items:
The Auto Cluster Configuration branches into a set of Auto Cluster settings:
Auto Cluster Settings:
Auto Refine Settings:
Chart context menus have been extended by an optional Remove ... from cluster item. Whenever the x-hair cursor gets near a chart point, the related NTP server is shown:
When the indicated NTP server is currently member of the cluster, the chart context menus will offer the Remove ... from cluster option:
This allows to remove an NTP server from the cluster directly from within one of the chart tabs (NTP Offset or Scatter Plot).
New keywords:
G_Kernel.exe
The ntp keyword now supports the optional /location=CC flag when a hostname or an IP address is specified. CC specifies the two-character country code.
[/on] - enables G_Kernels auto cluster mode.
[/size=n] - cluster size n = 1...64, default = 10.
[/max_stratum=m] max_stratum m = 1...3, default = 3.
[/location=CC-list, local, global] - CC-list: e.g. US,DE,GB (list of country codes), local: uses the local country code (local NTP servers), global uses all country codes (world-wide NTP servers), default: local
[/family=af] - address family af = IPv4, IPv6, or all, default = all (both).
[/auto_refine=state] - state = ON or OFF, optionally enables auto-refinement. Default: OFF
[/max_timeouts=n] - lets the auto refine algorithm dismiss a server which has accumulated n consecutive timeouts, default: 0, n=0: no rejection due to timeout.
Note: The auto cluster max. timeouts setting overrides the max_ntp_restarts setting in auto cluster mode.
[/max_rtd_stdev=f] - lets the auto refine algorithm dismiss a server which does not match this criterion. f in milliseconds, default: 1.0 ms
Note: The local drift is continuously updated by the internal drift estimation when NTP services are enabled. However, the local drift may be set "fixed" using the "/fixed" option.
This setting will set the following features:
Note: The full_auto keyword has to be accompanied by one of the keywords gui, silent, or console. All other settings are default in full_auto mode.
Suggested start to get an idea: "G_Kernel.exe gui full_auto"
G_Setup.exe
G_CreateServerSetupScript.exe
Miscellaneous updates:
G_Lib.lib / G_dll.dll
The server name argument (FQHN) of the library function NTP_Setup(...) may now contain an optional location flag to configure an NTP server with a specific location associated. Example: "time.windows.com/location=US".
All colors and background colors supported for the library function qfprinf(...).
The estimation and refinement of the local clock drift has undergone substantial improvements. The resulting drift estimation is available quicker and more accurate with version 3.1:
The chart above shows the cluster mean of an NTP cluster consisting out of 60 NTP servers. During the initial phase (up to approx. 12:46:40), the local clock drift is unkown. As a result, the NTP captures are biased by the local drift. With an NTP update period of 15 seconds, this results in a residual offset of approx. - 360 μs because the local drift component is not taken into account by the ongoing system time adjustment, its value is 0.0 μs/s. During this phase, the drift estimation takes place and gets a first rough estimate at approx. 12:46:40. Subsequent adjustments of the local clock are accompanied by the yet known drift estimate (approx 23.9 μs/s for the system this measurement was taken on). Each of the following NTP samples are a result of the adjustment corrected by the local drift. Consequently, the mean of the 60 NTP cluster captures raises gradually during the next NTP update period until all of them are corrected by the local drift (at approx. 13:01:40 which is exactly one NTP period later).
Fixes:
G_Kernel.exe
G_Kernels startup value of max_ntp_restarts now also applies for cluster members.
NTP_Service: Out of sync IPv6 packet wasn't discarded, fixed.
The system time adjustment could under specific conditions persist after the G suite terminated, fixed.
G_GUI.exe
Save Session Setup always set the nolog flag, fixed.
Save Session Setup didn't save force_jump and max_ntp_restarts flags, fixed.
Save Session Setup did save the wrong chart scroll width when auto-scroll was active, fixed.
A filter rejected primary server capture was not indicated rejected in the comment column of the NTP Server Cluster tab, fixed.
G_Setup gui/select=xx/server=.../custom_color=none was not resetting the custom color, fixed.
G_Setup.exe
G_Setup gui/select=**/server=any_pool/custom_color=FF0000 now also matches with pool names.
Custom color now prohibited for primary server.
Custom colors may only be set for cluster members.
2018-03-28: Version 3.00 release [Build 0300]
Version 3.00 introduces a number of new features:
The scatter plot shows the NTP offset vs. the round-trip time (RTT). This new view into the NTP data improves the assessment of the NTP server quality.
The above scatter plot shows data for 4 NTP servers. The leftmost server shows signs of asymmetry; a correlation between NTP offset and RTT is obvious. The G suites disciplining algorithm applies a linear regression to the data on the fly and takes the estimated asymmetry into account. Outliers rejected by the filter system may optionally show as filled circles in the chart when the outlier view mode is set to show.
Each row in the NTP Server Cluster tab list view shows a check box in the "Plot" column. The state of this check box determines whether the selected server is shown in the NTP Offset and the Scatter Plot chart.
Note: This plot selection is shared within a GUI group. See grouping of GUI instances in the next chapter.
Instances of the GUI may be started with an ID. The ID consists of a group part and a member part (ID=gm: g=0...9 specifies the GUI group and m=0...9 specifies the GUI group member). Members of the same group do share the settings for the plot/noplot selection and for the custom color. This way one GUI can be used to change the plot/noplot and custom color settings for another GUI. A total of 10 groups with 10 members each can be run this way. GUI IDs don’t have to be unique. Multiple use of the same ID is allowed and may even be advantageous. GUIs started without ID will revert to ID=00. GUI IDs different from 00 are shown in the window title bar. The GUI started by G_Kernel.exe has the ID=00 unless otherwise specified.
The GUI ID also allows configuring individual instances of the GUI by means of G_Setup.exe. See G_HowTo_0300.pdf or the description of new G_Setup.exe keywords further down to learn more about GUI IDs and their use.
The ID used within G_Setup.exe may contain the wildcard character "x". ID=xm will select member m in all groups, id=gx will select all members in group g. ID=xx will select all GUIs.
The new disciplining algorithm provides a much higher accuracy. Based on improved local clock drift refinement, the obtained remaining offset is now much smaller.
The chart above shows the clock disciplining based on the mean of 51 cluster members (50 cluster members + 1 primary server). Disciplining (autoadjust) was turned off for a few seconds at about 17:35 to let the system drift to an offset of about -100 μs. The residual mean offset maintained while autoadjust was enabled is kept within a band of approx. +/- 10 μs. Note: The shown mean offset is derived from all contributing servers (cluster members and primary server). However, the mean offset does not represent the plain average. Some corrections are applied to compensate for unwanted errors.
Drift estimation is performed in autoadjust mode and monitor mode. However, it only takes place at time slices >= 3000ms. Time slices are determined by the NTP update period divided by the number of servers. Hence, the required NTP period to obtain drift estimation for 51 servers is at least 153 seconds (51 x 3000 ms).
Drift refinement typically requires a couple of NTP periods; it may take a while before an initial drift estimate gets available. The following NTP offset chart shows the refinement of the local clock drift:
The internal drift was set fixed to 0.0 μs/s during the first 5 minutes. The used systems local clock drift is approx. 23 μs/s and the used slice is 3 seconds. Therefore, the offset is about –70 μs during this initial phase.
As a result, the drift is refined to small fractions of a μs. This allows accurate proactive system time adjustments, even with very long NTP update periods.
It is recommended to run the drift estimation or the suite in general with at least the Reject Outliers filter enabled. Version 3.0 has this filter enabled as default filter setting. Filters become active for a server after at least 10 NTP captures have been collected from that server. Therefore, the drift estimation is only enabled when at least 10 captures have been collected from all contributing servers. In other words, it takes at least 10 NTP update periods before drift estimation starts to refine. With the example above, consisting of 51 servers and an NTP update period of 153 seconds, filters get active after 1530 seconds and drift estimation/refinement starts.
The Save Session Setup option manages the refined drift, if any. Restarting the session using the session setup script (.BAT file) will start the session with the refined drift from the beginning.
The File Menu has been extended by the Save Session Setup and the Save Session Setup As ... menu items.
Saving a session includes all current settings. The created .BAT file can be used to restart the session as it is at the time of saving.
Once a filename is provided with the Save Session Setup As ... option, the Save Session Setup menu item is enabled and uses that file as default. A save options dialog will pop up to query additional information:
This dialog allows the configuration of additional save options:
G_Setup.exe may accept multiple servers to be configured with a single setup command line. Uncheck this check box when each server shall be configured with its individual setup line.
Unused servers are currently configured servers which neither currently belong to the cluster nor being configured as primary server. They are not required to restore the session as it is. Therefore, they may be discarded. Check this box when unused servers shall be discarded.
The save session options dialog will appear with the Save Session Setup and the Save Session Setup As ... menu option. Checking this box will pop up the dialog with the Save Session Setup As ... menu option only.
Note: Save session filename and options are shared with all GUI instances. Once a filename is chosen all save session parameters are shared with all GUIs.
A new executable is added to the suite: G_SaveCaptures.exe. This executable cannot be started from the command line. This process can only be started by G_Setup.exe. G_SaveCaptures.exe is a background process which saves all NTP captures on the fly to a file.
For detailed information, see the save_captures[/file=filename] keyword of G_Setup.exe in G_HowTo_0300.pdf.
Cluster mode is now default mode. None cluster mode is still available with the nocluster keyword. The G suite reverts to old style non-cluster mode with the nocluster keyword.
New Keywords
G_Kernel.exe
G_GUI.exe
G_Setup.exe
Note: The FQHN is either the fully qualified domain name (FQDN) or the IP.
New File: GID_Test.bat
This script file illustrates the usage of GUI IDs.2017-02-15: Version 2.60 release [Build 0260]
Version 2.60 introduces NTP server cluster monitoring. This new feature may optionally be enabled by the G_Kernel.exe startup keyword "cluster" (e.g. "G_Kernel.exe gui cluster". As a result, a set of NTP servers can be monitored simultaneously:
Members of the NTP cluster are now plotted along with the primary NTP server in the NTP Offset tab. The NTP server cluster can handle up to 60 NTP servers simultaneously.
Rejection of unreliable NTP captures has been significantly improved with this version. The filter algorithm has received an adaptive component, which has greatly contributed to much better rejection efficiency. A set of selectable filters can be enabled or disabled from within the GUI (NTP Cluster Configuration menu item) or asynchronously by means of the G_Setup.exe tool (See new G_Setup.exe parameters below). The procedure shown with the graph above is a short drift period followed by a period of local clock disciplining with the primary NTP server as reference. The primary server was time.fu-berlin.de.
Amongst the known view modes (all, scrolled, zoomed), version 2.6 offers showing rejected captures. The Outlier View menu item within the chart context menu allows showing or hiding rejected outliers. The graph shown above shows the rejected outliers marked with a dot. Note: The number of shown dot indicators is limited to 1500. Rejected outliers are not discarded but only marked as rejected. As a result, also Save Chart Data will now save the rejected captures to file. However, rejected captures will be marked "rejected" in the file. The default setting of the Outlier View is Hide.
Keeping the "rejected" data has been a result of filter development. The knowledge of previously rejected captures guides the prediction of rejections for incoming captures.
The Outlier View menu item in the graph context menu:
Cluster members can be configured within the new NTP Server Cluster tab, the NTP Cluster Configuration menu, or the G_Setup.exe tool. This new tab shows "live" information about the configured cluster servers, e.g. name, ip, stratum, round trip delay (RTD), mean RTD (+/- Standard Deviation), and color settings. The color settings are determining the chart color for a specific server. The color is system wide and predefined by G_Kernel.exe. This way all instances of G_GUI.exe show the same color for a particular server (default color). However, a custom color can be selected individually within a G_GUI instance. The NTP Server Cluster tab:
The selected custom color will only apply from after being set. Servers can be also added and be removed from the cluster by the NTP Server Cluster context menu:
The Add server to cluster… menu item allows adding a cluster member from the list of preconfigured NTP servers. The available servers are selectable from a popup list:
NTP cluster members can be removed by choosing the Remove… menu item. The selected server will be removed from the cluster but it will not be removed from the list of preconfigured servers.
The Choose custom color menu item pops up a color chooser dialog box. The chosen custom color will apply for the selected server after being set. A chosen custom color can only be used once. This is audited internally; selecting a color already in use will result in an error message. A few colors are internally disallowed (white, black, and a few other colors). The custom color can be changed at any time. It can also be overridden by a new custom color.
A menu item Quit custom color… appears when a custom color is selected for a server. Quitting a custom color will return the chart of the selected server to its predefined default color.
Cluster configuration is done by means of the NTP Server Cluster tab context menu as described above or by means of the Cluster Configuration submenu in the NTP menu:
Add Cluster Server and Remove Cluster Server are implemented as in the NTP Server Cluster tab context menu.
Show Custer Server writes a list of current cluster members to the All Output tab and thus also into the log file when logging is enabled.
The remaining menu items allow setting the rejection filters and the cluster scheduling. Version 2.6 supports a selection of two filters: The Reject Outliers filter and the Reject RMS Peaks filter:
The Reject Outliers filter is based on the evaluation of RTD (Round Trip Delay) and its distribution/variation. This is a very powerful filter which is capable to reject most unwanted NTP captures. As mentioned earlier, it has an adaptive component which allows this filter to learn. It typically takes about 20 captures for the algorithm to converge.
However, heavy network traffic may result in captures beyond the scope of the Reject Outliers filter. Such harsh conditions are the field of the Reject RMS Peaks filter.
Possible filter settings: Both, each one, or none. The default filter setting is none. Note: The primary server has its own filter. This filter cannot be controlled from outside; it is enabled at all time. Hence, the chart may show rejected captures for the primary server with Outlier View = Show and Filter Selection = None.
The scheduling of the NTP captures offers two modes: Distributed and Bunched.
The primary NTP server determines the NTP capture scheduling for all cluster members. It will trigger first and subsequently the cluster members. The scheduling scheme Distributed will schedule the cluster member captures evenly distributed over the selected NTP update period. The Bunched mode will schedule the captures in a bunch. The bunch covers an interval matching the shortest selectable NTP update period (250 ms). Within this short interval, the captures are scheduled (again) evenly distributed.
G_GUI.exe:
G_Kernel.exe:
G_Setup.exe:
Note: Searching a random server is done be means of using the local country code. Multiple attempts to add a new server this way, may result in "Unable to find a new server at this time. Try later…".
Supported filter names: "reject_outliers", "reject_rms_peaks".
G_CreateServerSetupScript.exe:
2016-10-28: Version 2.50 release [Build 0250]
G_IO_Service.exe: Revised queuing, improved performance, and less overhead. Now also handles "future" messages.
Fixes:
2016-10-14: Version 2.45 release [Build 0245]
G_CreateServerSetupScript.exe: Improved efficiency with new internal structures. However, the user interface remains unchanged.
Fixes:
2016-10-04: Version 2.44 release [Build 0244]
G_Kernel.exe supports a new keyword: nocalibration. Starting the G suite with this keyword will force G_Kernel to skip the file time transition calibration during startup and during operation in slow mode.
Fixes:
2016-09-01: Version 2.43 release [Build 0243]
G_GUI.exe: Switching the NTP Offset and Calibrated Performance Counter Frequency Offset charts to scroll-mode has discarded scrolled-out data with previous versions.
Hence, the Save Chart Data option has only written the remaining data to a csv file. Even selecting a larger scroll width or disabling the scroll has not recovered the data.
Version 2.43 introduces caching of scrolled-out data in a temporary file. As a consequence, all of the collected data will be kept. Selecting the Save Chart Data option will restore the scrolled-out data
from them temporary file and write them in proper sequence with the hold data into the csv file. This also applies for the auto-scroll mode.
The limit of 10.000.000 points for the chart display (see fixes below) represents approx. 58 days for the Calibrated Performance Counter Frequency Offset chart with typically two points/s
and approx. 290 days for the NTP Offset chart at an NTP update period of 2,5 seconds. Exceeding this range will force the GUI to enter auto-scroll mode. The time span (scroll width) of the auto-scroll
is shown in the chart. The temporary file is created at the location of G_GUI.exe. Its name is composed of the GUIs PID, a name, and the time of creation, followed by a .tmp,
e.g. "GUI_12672_NTPO_CHART_DATA_2016-08-29_13_48_48.tmp" stores the scrolled-out data of the NTP Offset chart. These temporary files may appear if required and disappear if no longer used.
This scheme allows recording a virtually endless number of chart points. Accordingly, writing the data to a csv file may result in very big files.
Changing the scroll width will now always show all available data for the selected scroll width. Nevertheless, the available data may not be enough to entirely fill the selected scroll width.
In this case, the chart will keep collecting data until the scroll width is reached and start scrolling thereafter.
Fixes:
2016-08-03: Version 2.42 release [Build 0242]
Fixes:
2016-07-20: Version 2.41 release [Build 0241]
Microsoft Visual Studio Community 2015 is a free, fully-featured, and extensible IDE for creating modern applications for Windows. It can be downloaded here. The sample solution G.sln is now set up to operate with Visual Studio 2015 (Version 14). Note: Visual Studio may ask to install some additional features (SDK, XP support, etc.) to be compatible with the G suite requirements. However, this is done automatically and possible user intervention is well guided by the Visual Studio update tool.
Fixes:
Supplement: The temporary license, optionally requested during download, lasts until December 31, 2017.
2016-06-30: Version 2.40 release [Build 0240]
G_Kernel.exe: Windows Server 2016 Technical Preview 5 compatible (Builds 14300, 14316, and 14352).
G_GUI.exe: Asynchronous system time adjustments are now indicated by means of purple color.
Items concerned:Fixes:
Notes:
2016-04-06: Version 2.32 release [Build 0232]
Fixes for system timer resolution issues.
2016-03-30: Version 2.31 release [Build 0231]
Windows 10 TH2 (Build 10586) compatible.
Supplements and fixes:
2016-01-29: Version 2.30 release [Build 0230]
A new keyword for G_Setup.exe: purge operates like the Purge NTP Server List item in the NTP menu described above.
A new ? menu item for G_GUI.exe: Show Status Summary. This function gathers a status summary and writes it to the All Output tab. The summary contains:
A new keyword for G_Setup.exe: status operates like the Show Status Summary item in the NTP menu described above. However, it also writes the status information to the console.
A new value for the state field of the timestamp structure: TIME_STAMP_LICENSE_EXPIRED (4). The TimeStamp state is set to TIME_STAMP_LICENSE_EXPIRED when the license expires during runtime. The sample code of G_User.c now exhibits it in this way:
TimeStamp_TYPE TimeStamp;
GetTimeStamp(&TimeStamp);
if (TimeStamp.State == TIME_STAMP_LICENSE_EXPIRED) {
fprintf(stdout, "License expired, continuing at default accuracy...\n");
} else {
fprintf(stdout,"G_Kernel.exe has established calibration, continuing...\n");
}
Note: After the improvement of IPC with version 2.02, the granularity of the functions Time() and GetTimeStamp() is given by the granularity of the performance counter which shows a few 100 ns on a typical "invariant TSC" system. Calls to Time() or GetTimeStamp() only require a few 10 ns, therefore consecutive calls to Time() or GetTimeStamp() may show identical values.
2015-10-01: Version 2.20 release [Build 0220]
Improved drift estimation.
Updated documentation.
2015-08-26: Version 2.11 release [Build 0211]
A new NTP menu item for G_GUI.exe: Add New NTP Server. A new NTP server is added to the internal list of servers and made the currently selected server. This functionality does not require NTP to be active. The search of a new server prefers "local" servers by means of applying the current country code whenever available. However, the search is extended to servers outside the country code match, when no new server can be found quickly. Too frequent use of this option may cause the error "Unable to find a new server at this time. Try later..." to appear, because the search is limited to the region. This also depends on the number of NTP servers already stored in the internal list. A retry at a later point in time is likely to be successful.
A new keyword for G_Setup.exe: add_server operates like the Add New NTP Server item in the NTP menu. It adds a new NTP server to the internal list and selects it.
2015-08-07: Version 2.10 release [Build 0210]
Windows 10 release version (Build 10240) compatible.
The suite is now targeted to Windows Vista, 7, 8, 8.1, and 10. Moreover, it remains compatible with Windows XP.
Notes:
Some security software e.g. virus scanners may delay the start of the suite when it is called for the first time. This may cause parts of the windowstimestamp suite to complain and to terminate with an error window. However, subsequent starts will be successful.
Despite the knowledge that GetSystemTimePreciseAsFileTime() misbehaves when a system time adjustment is active (described in the news section of version 1.60), Microsoft has not fixed the inaccuracy during such adjustments with Windows 10. Version 2.10 of the windowstimestamp suite does not use the function GetSystemTimePreciseAsFileTime().
2015-07-27: Version 2.02 release [Build 0202]
Updated documentation.
2015-07-23: Version 2.02 release [Build 0202]
Supplements and fixes:
G_GUI.exe (x64) has suffered a flaw with some data alignment. As a result, maneuvering the hour/minute/second/millisecond spin box across an overflow forced an unintentional termination. Fixed.
The inter process communication security scheme has been restructured. This new lightweight IPC design has led to a considerable performance advantage. Nonetheless, the x64/x86 interoperability remains fully functional.
2015-07-10: Version 2.01 release [Build 0201]
G_Setup.exe timer_resolution keyword now accepts approximated values for the resolution. This allows easier use of this feature, because the system timer resolutions are calibrated during boot on platforms running Windows above version 7.
Here is a short excerpt of "G_Setup.exe query" to show typical values for available timer resolutions on a typical Windows 8.1 platform:
- This platform currently supports 17 different timer resolutions [100 ns units]:
- 5003 [ 0.5003 ms], thread quantum: 31.5 ms.
- 10007 [ 1.0007 ms], thread quantum: 32.0 ms.
- 20001 [ 2.0001 ms], thread quantum: 32.0 ms.
- 30008 [ 3.0008 ms], thread quantum: 33.0 ms.
- 40002 [ 4.0002 ms], thread quantum: 32.0 ms.
- 50009 [ 5.0009 ms], thread quantum: 35.0 ms (currently active)
- 60003 [ 6.0003 ms], thread quantum: 36.0 ms.
- 70010 [ 7.0010 ms], thread quantum: 35.0 ms.
- 80005 [ 8.0005 ms], thread quantum: 32.0 ms.
- 90012 [ 9.0012 ms], thread quantum: 36.0 ms.
- 100006 [10.0006 ms], thread quantum: 40.0 ms.
- 110000 [11.0000 ms], thread quantum: 33.0 ms.
- 120007 [12.0007 ms], thread quantum: 36.0 ms.
- 130002 [13.0002 ms], thread quantum: 39.0 ms.
- 140009 [14.0009 ms], thread quantum: 42.0 ms.
- 150003 [15.0003 ms], thread quantum: 45.0 ms.
- 156251 [15.6251 ms], thread quantum: 46.9 ms.
The implementation of the shared memory resource use by Time() and GetTimeStamp() has been revised and optimized to achieve less overhead. This new scheme has made the mutex protection dispensable, both functions are performed in just a couple of 10 ns.
2015-05-20: Version 2.0 release [Build 0200]
Windows 10 ("insider preview") compatible.
2015-01-07: Version 1.82 release [Build 0182]
Updated documentation: "Microsecond Resolution Time Services for Windows: Section 2.1.4.3. Timer Periods with Invariant TSC"
Fixes for specific Intel 4G mobile processors.
2014-10-13: Version 1.81 release [Build 0181]
Full 64-bit support. Libraries and executables are now available in x86 (32-bit) and x64 (64-bit) versions. 32-bit and 64-bit static or dynamic libraries provide full interoperability. Any client (x86 or x64) can operate with any G_Kernel.exe (x86 or x64). Example: G_Kernel.exe (x64 or x86) may operate with an x86 G_GUI.exe and simultaneously with an x64 G_GUI.exe.
Build version MSC 1800 (Microsoft Visual Studio 12.0). Runtime libraries linked statically, no installation of Visual C++ redistributables required.
Directory structure of the package adapted to x86/x64 branches. Batch scripts NTP_Server_Setup_200.bat and G_Test.bat need a parameter x86 or x64 to branch into the desired suite.
Fixes:
2014-10-01: Version 1.80 release [Build 0180]
The NTP engine has been extended by a quick test function and a scoring algorithm. NTP servers are quickly diagnosed during setup. As a result, server details like stratum, reference ID/KoD, and score are available to the user. The output of the NTP_Query() function, its data structure, and the output of G_Setup.exe query has changed accordingly.
Scoring NTP servers is based on various parameters, some of them are:
Version 1.80 assigns score values between 0 and 5. A score of 0 is the worst score and indicates a non-responding NTP server. However, specific error conditions may result in negative scores.
G_Kernel.exe automatically configures a local NTP server to operate with when no server is specifically requested. In case of errors or discontinuities with a chosen server, the code reverts to substitutional NTP servers. A number of NTP servers may get configured during the course of this substitutional recovery procedure. However, when servers are already configured, the code prefers to revert to the most recently used server showing a score greater than 0.
G_CreateServerSetupScript.exe has been revised and improved. About 200 global NTP servers can be gathered within the first minute of operation. G_CreateServerSetupScript now also performs an initial server test. This way it obtains, similar to G_Kernel.exe, server details like stratum and reference ID/KoD.
Two new keywords have been added to G_CreateServerSetupScript.exe:
local forces local NTP servers to get chosen. This is obtained by means of using the GetUserGeoID function. If the user GeoID is not configured, an extended diagnosis of NTP servers will find the appropriate country code information to suit the requested local mode. This country code building may take a few minutes.
max_stratum=n Testing NTP servers results in knowledge of the server's stratum value. This may be used to filter the search result during the search. Allowed stratum values are 1 to 16. Accordingly, max_stratum=1 will only search for stratum 1 NTP servers, while max_stratum=16 will include any responding servers.
Typing G_CreateServerSetupScript.exe in a console will provide detailed usage information:
G_CreateServerSetupScript V1.80 usage:
G_CreateServerSetupScript.exe iterations delay [number [n x countrycode]] [max_stratum=n]
- iterations: number of pool scans, e.g. 10.
- delay: delay between poolscans in seconds, e.g. 20.
- number optionally specifies a limit for the number of servers to create.
- country code , e.g. "US". Multiple codes supported, e.g. "US DE SE FI".
The country code may optionally be "local" to use the local country code only.
"local" option is not allowed in combination with other country codes.
Current local country code: "DE" (Germany).
- max_stratum=1..16 limits the search to servers providing at least the specified max_stratum.
Examples:
"G_CreateServerSetupScript 10 60
"CreateServerSetupScript 10 60 max_stratum=2"
"G_CreateServerSetupScript 10 60 GB PL ES"
"G_CreateServerSetupScript 20 30 12 DE US SE FI"
"G_CreateServerSetupScript 20 30 local"
"G_CreateServerSetupScript 20 30 12 max_stratum=2"
"G_CreateServerSetupScript 20 30 12 PT BR NO max_stratum=2"
Note: "Ctrl C" terminates properly with the number of servers collected at the time of termination.
A comprehensive log file is built upon termination. This is an excerpt of such a log file:
14:52:24: Total server(s): 28, server hit stats: (hit rank, hits, country code, address family, stratum, host name, ip)
.
.
27. 1 IE IPv4, stratum=2 "eu-m03.nthweb.co.uk" (46.51.182.47)
28. 1 IN IPv4, stratum=3 "dnspun.net4india.com" (202.71.140.36)
14:52:24: Total local (DE) "Germany" server(s): 4
1. 1 DE IPv4, stratum=2 "ntp2.m-online.net" (212.18.3.19)
.
.
4. 1 DE IPv4, stratum=2 "www.danzuck.ch" (46.165.212.204)
14:52:24: Sanity check OK.
14:52:24: End.
The NTP_Setup() function remains backwards compatible but has received a few modifications:
Version 1.80 of G_GUI.exe shows stratum and score in the NTP server selection menu.
The NTP_Query_TYPE data structure for G_Setup.exe query and the NTP_Query() function has been extended by score, reference ID, stratum, and address family:
typedef struct NTP_Query_TYPE {
unsigned long msg_status; // optional error status
unsigned long status; // states NTP_STATUS_INACTIVE (1), NTP_STATUS_GATHERING (2), or NTP_STATUS_ACTIVE (3)
unsigned long mode; // modes NTP_MODE_OFF (1), NTP_MODE_MONITOR (2), or NTP_MODE_AUTOADJUST (3)
unsigned long update_period; // current NTP update period in ms
char host[MAX_PATH]; // NTP host URL, e.g. "time-a.nist.gov"
char ip[MAX_PATH]; // NTP host IP as dotted notation string, e.g. "178.23.124.2"
int locked; // locked TRUE when the past three consecutive NTP synchronizations were successful
int wsa_up; // windows sockets have been started, the WinSock DLL was initiated (WSAStartup)
double offset; // current NTP offset
double mean_offset; // mean NTP offset
double stddev; // standard deviation of mean offset
long long offset_timestamp; // timestamp of the last NTP synchronization
int address_family; // address family
int score; // derived score, as of V1.80 0...5
unsigned long refid; // reference identifier
int stratum; // stratum
} NTP_Query_TYPE;
The result of G_Setup.exe query:
G_Setup: NTP query:
- Local time: 2014-08-29 14:06:05.364760.5
- Mode: NTP AUTOADJUST
- Selected host: "xxx.xxxxx.xx"
- Selected IP: "83.169.43.165" (IPv4)
- Selected update period: 250 ms (00:00:00.250)
- Score: 2
- Stratum: 1 (PPS)
- MeanOffset: +0.000010 +/-0.000117 s
Timer resolution query:
- This platform currently supports 7 different timer resolutions [100 ns units]:
- 5000 [ 0.5000 ms]
- 10000 [ 1.0000 ms], thread quantum: 32.0 ms (currently active).
- 12500 [ 1.2500 ms]
- 25000 [ 2.5000 ms]
- 50000 [ 5.0000 ms]
- 100000 [10.0000 ms]
- 156000 [15.6000 ms]
Supplements and fixes:
IPv6 compatibility was partially lost with version 1.70. Version 1.80 has returned to full compatibility with IPv6.
The entire NTP timeout and recovery scheme has been restructured.
GetTimeStamp(): Recursion stack overflow fixed.
"Kiss-o'-Death" message handling completed.
G_GUI.exe: Context menu outside graph area did not perform the selection, fixed.
G_GUI.exe: Setting the scroll range will apply immediately and update the graph.
2014-08-06: Version 1.70 [Build 0170]
Usage: G_CreateServerSetupScript.exe iterations delay [number [n x country code]]
- iterations: number of pool scans, e.g. 10.
- delay: delay between pool scans in seconds, e.g. 20.
- number: optionally specifies a limit for the number of servers to create.
- country code: e.g. "uk". Multiple codes supported, e.g. "uk de se fi".
G_CreateServerSetupScript runs in 2 phases:
- Phase 1 generates a native list of NTP server pools when no country code is supplied.
- Phase 2 scans those pools for new servers in a loop specified by "iterations" and "delay"
Example: "G_CreateServerSetupScript 20 30 12 de uk se fi"
Note: "Ctrl C" terminates properly with the number of servers collected at the time of termination.
:: G_Setup script to configure NTP servers:
:: Note: None of the subsequent G_Setup command lines exceeds 4095 characters.
::
G_setup ntp=196.25.1.9 ntp=41.248.247.207 ntp=193.108.227.130 ntp=72.51.27.50 ntp=.....
::
:: Total servers included: 200
typedef struct TimeStamp_TYPE {
long long Time; // 100ns units
long long ScheduledTime; // 100ns units
double RefinedPerformanceCounterFrequency; // 1/sec
int Accuracy; // 1ns units
int State;
} TimeStamp_TYPE;
2014-05-22: Version 1.60 [Build 0160]
NTP query:
- Local time: 2014-05-14 17:10:03.618096.9
- Mode: NTP MONITOR
- Update period: 620 ms (00:00:00.620)
- Host: "time.fu-berlin.de"
- IP: "130.133.1.10"
- StdDev: +/-0.003753 s
- MeanOffset: +0.386032 s
- Locked: 1
- WSA_up: 1
- Offset: 0.377741
- OffsetTimestamp: 2014-05-14 17:10:03.012835.7
Timer resolution query:
- This platform currently supports 6 different timer resolutions [100 ns units]:
- 5000 [ 0.5000 ms]
- 10000 [ 1.0000 ms], thread quantum: 32.0 ms (currently active and acquired by G_Kernel.exe).
- 12500 [ 1.2500 ms]
- 25000 [ 2.5000 ms]
- 50000 [ 5.0000 ms], thread quantum: 35.0 ms.
- 100000 [10.0000 ms], thread quantum: 40.0 ms.
- Lower resolutions are currently unavailable for detection.
2014-04-03: Version 1.51 [Build 0151]
2014-03-22: Updated documentation
2014-03-01: Version 1.50 [Build 0150]
2014-01-15: Version 1.40 [Build 0140]
2013-12-18: Version 1.32 [Build 0132]
2013-11-30: Version 1.31 [Build 0131]
Examples:
void DumpMessages(LPSTR lpMsg, int DumpFlag);
with DumpFlag taking on of the two values:
#define DUMP_FLAG_CONSOLE1 << 0
#define DUMP_FLAG_WINDOW1 << 1
int GetMMTimerResolution( MMtimerResolution_TYPE * MMtimerResolution);
This function updates the content of the MMtimerResolution structure:
typedef struct MMtimerResolution_TYPE {
DWORD MMminRes;// minimum timer resolution
DWORD MMmaxRes;// maximum timer resolution
DWORD MMcurRes;// current timer resolution
} MMtimerResolution_TYPE;
2013-10-30: Version 1.30 [Build 0130]
2013-10-01: Version 1.22 [Build 0122]
DWORD G_Sleep(LONGLONG Delay);
is now also available with the dynamic link library (DLL). See news 2013-06-07 for details.int NTP_Query(NTP_Query_TYPE * ntp_query);
This function updates the content of the ntp_query structure:
typedef struct NTP_Query_TYPE {
DWORD msg_status; // optional error status
DWORD status; // NTP_STATUS_INACTIVE, NTP_STATUS_GATHERING, or NTP_STATUS_ACTIVE
DWORD mode; // NTP_MODE_OFF, NTP_MODE_MONITOR, or NTP_MODE_AUTOADJUST
DWORD update_period; // current update period in ms
char host[MAX_PATH]; // host URL, e.g. "time.windows.com"
char ip[MAX_PATH]; // host IP as dotted notation string, e.g. "178.23.124.2"
BOOL locked; // the past three consecutive NTP synchronizations were successful
BOOL wsa_up; // WinSock DLL was initiated
double offset; // current NTP offset
double mean_offset; // mean NTP offset
double stddev; // standard deviation of mean offset
long long offset_timestamp; // timestamp of last NTP synchronization
} NTP_Query_TYPE;
Example:
G_Kernel.exe silent nolog ntp=pool.ntp.org period=2500 autoadjust
This example starts the package without any output or log file, synchronizing the system time to an NTP server with an update period of 2.5 seconds.2013-08-06: Version 1.21 [Build 0121]
2013-07-05: Microsoft Visual C++ Redistribution Package
2013-06-28: Updated pdf files
2013-06-07: Part II: Adjustment of System Time
2013-06-07: Version 1.2 [Build 0120]
SetTimedEvent(...)
has received a limitation for its argument TimerPeriod for single core platforms: TimerPeriod now needs be at least 2 times the ActualResolution returned by the function NtQueryTimerResolution. Smaller values of TimerPeriod are rejected as invalid argument on single core platforms.DWORD WaitForSingleTimedEvent( HANDLE hEvent, DWORD dwMilliseconds, long long * pTimeNow = NULL);
WaitForSingleTimedEvent executes the WaitForSingleObject function in a capsule with raised priority. It is up to the user to alternatively also use WaitForSingleObject but it is not guaranteed that WaitForSingleObject returns in timely manner when other threads of equal or higher priority are running. However, pTimeNow is set within the capsule and therefore represents the actual time at which the event occurred. Additionally, the processor affinity is adjusted inside the capsule to obtain best results. The static library also contains a function MsgWaitForMultipleObjectsOrTimedEvents which refers to the function MsgWaitForMultipleObjects in a similar way. (See G_User.c in the samples directory for more details on how to use the WaitForSingleTimedEvent function.)int NTP_Setup(LPCTSTR lpNtpHostName,
DWORD dwNTPPeriod,
DWORD dwNTPMode);
NTP_Setup currently supports three modes of operation:
Example:
if (!NTP_Setup( "time.windows.com", 350, NTP_MODE_AUTOADJUST)) HandleTheNTP_SetupError();
Such a call to NTP_Setup will establish a 350 milliseconds update period of the NTP server time of one of the servers in the "time.windows.com" NTP server pool and will start the continuous adjustment of the local clock.DWORD G_Sleep(LONGLONG Delay);
This function accepts Delay in 100 ns units. At this stage Delay is expected to have a positive value. Delay may also be 0. Unlike the common Windows Sleep() function, G_Sleep(0) will NOT relinquish the reminder of the threads time slice to other threads. A successful call to G_Sleep will return TRUE.Remarks: The G_Sleep service is initialized once per process with the first call. Therefore, it is advised to make a call (e.g. G_Sleep(0)) ahead of any time critical task. G_Sleep can only conquer the sub-milliseconds range by means of busy waits. However, the system wide structure allows to only having one busy section for all executing G_Sleep instances and this section is only busy for at most the millisecond ahead of the expiration of the desired delay. Multicore platforms don't show any significant performance drawbacks. A careful use of G_Sleep is advised on single core platforms. Consecutive calls to G_Sleep with delays less than 2 times the ActualResolution returned by the function NtQueryTimerResolution (approx. 2-3 ms) may put the hardware in a close to 100% busy state at high priority. As a consequence, the user interface may get less responsive.
Example:
G_Kernel.exe gui ntp=pool.ntp.org period=250 autoadjust
This example starts with a single GUI instance, updating the network time from one of the servers in the pool of pool.ntp.org at a rate of 4 updates per second with autoadjustment enabled.2012-12-22: Version 1.1 [Build 0110]
Note: Windows is a registered trademark of Microsoft Corporation in the United States and other countries. The Windows Timestamp Project is an independent publication and is not affiliated with, nor has it been authorized, sponsored, or otherwise approved by Microsoft Corporation.
…