1) 如果在局域网中配置一台网络时间服务器,该局域网中的计算机(OS = Windows XP)时间同步精度能达到多少?
2) 如何测试?
关于测试:
-----------------
a) Windows自带一个w32tm.exe,指定/stripchart选项可以用来显示此计算机和另一计算机之间的偏移量的条带图。
w32tm /stripchart /computer:<target> [/period:<refresh>] [/dataonly] [/samples:<count>]
computer:<target> - 要测量偏移量的计算机。
period:<refresh> - 在示例之间的时间间隔,以秒为单位。默认为 2 秒
dataonly - 只显示数据,没有图表。
samples:<count> - 收集 <count> 示例,然后停止。如果没有指定,将一直收集示例,直到按下 Ctrl-C。
缺点:原理不清楚,精度无从判断
b) 使用一个脉冲源,将其输出分别连接到所有待测试计算机的串口的一个输入脚上(例如CTS/DSR/RING)。
编写一个测试程序SyncTest,在每个脉冲的上升沿读取本机时间并记录到文件中,运行一段时间后,比较采样下来的时刻,统计计算
缺点:Windows响应外部事件的实时性有限,会引入误差。
c) 在客户端计算机运行一个程序,不断读取系统时间,每到整秒就反转串口的一个输出脚的电平,由此产生的pps与服务器端输出的pps同时接入示波器观察比较
问题:从程序指令到电平反转存在延迟?而且,怎样才能正好在整秒时刻上发出反转指令?
/------------------------------------
19:26:16, 2009年5月4日
在debian lenny上安装了ntpd version 4,由于GPS时钟部分还没有准备好,所以临时采用本地时钟作为时钟参考。在ntp的配置文件/etc/ntp.conf指定server:
server 127.127.1.0
fudge 127.127.1.0 stratum 12
然后在同一子网的windows xp通过自带的时间服务同步到ntpd,第一次点击“更新”比较顺利,不过过一段时间再尝试就出错了。原因比较多样,记不清了,不过好像报超时的居多。运行w32tm /stripchart,从最初的输出看,offset有逐步收敛的趋势,曾经有一小段时间(<20s)保持在1ms一下。但是后面的输出会发生跳跃,比如从<100ms突然加大到>1s。尝试时间同步,操作超时。
/--------------------------------------
22:37:54, 2009年5月5日
在使用本地时钟(LCL)作为参考时钟,为了支持广播(broadcast),需要在server那一行指定prefer关键字:
server 127.127.1.0 prefer
fudge127.127.1.0 stratum 12
大概看一下ntpq的用法,它是标准ntp套件的性能(时间同步精度)测试工具。常用子命令(subcommand)有pe/as/rv等。offset变量标记了本地时钟和参考时钟之间的差值(是一个统计值,单位为ms)。按照文档的说法,使用ntp在局域网可以指望达到1ms以下的同步精度。
ntp还考虑了安全和认证等内容,不过现在我不关心。
发现ntp套件已经有了win平台下的移植,虽然尚未实现全部功能,但对我来说已经够用了:-)
/--------------------------------------
22:40:29, 2009年5月7日
为了使本地时钟尽快同步到参考时钟:
a) 启动ntpd时,增加-g选项
b) 在ntp.conf中,为相应的参考时钟(server)增加iburst关键字
另外,除了ntpq工具,ntpd所提供的丰富的监控选项(monitoring options)也可以作为性能测试的一种选择。比如:
# Enable this if you want statistics to be logged.
statsdir c:\ntpstats
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
以上面的loopstats为例,ntpd会在c:\ntpstats目录下生成loopstats.yyyymmdd文件。
每次系统时间更新后,将在该文件写入一条记录,例如:
50935 75440.031 0.000006019 13.778 0.000351733 0.013380 6
Item | Units | Description |
50935 | MJD | date |
75440.031 | s | time past midnight |
0.000006019 | s | clock offset |
13.778 | PPM | frequency offset |
0.000351733 | s | RMS jitter |
0.013380 | PPM | RMS wander |
6 | log2 s | clock discipline loop time constant |
offset是最重要的变量,它表示ntp计算出的当前计算机时间与若干时钟源时间的差的组合值(combined offset)。
precision标记了当前计算机的计时精度,-19表示pow(2,-19) = 1 / (219) s, 近似于1.9μs
reftime为最近一次的同步时间
clock为执行ntpq时的当前计算机时间
/--------------------------------------
22:16:20, 2009年7月20日
关于NTP的有用链接:
http://www.ntp.org/
http://groups.google.com/group/comp.protocols.time.ntp/topics
http://www.wraith.sf.ca.us/ntp/
http://www.satsignal.eu/ntp/index.html
http://davehart.net/ntp/refclock/
http://time.qnan.org/
maillist: http://www.360doc.com/mailto:questions@list.ntp.org
/--------------------------------------
12:09:11, 2009年7月25日
NTP在Win32平台的编译
NTP:ntp-4.2.4p7
OS:Windows XP Pro SP3
IDE:VC++ 6.0 SP6 ,PSDK 2003Feb
在Win32平台使用NTP,除了选择Meinberg制作的安装包,也可以自己编译。从http://www.ntp.org/下载NTP源码包,解压后仔细阅读ntp-4.2.4p7\html\build\hints\winnt.html,我这里说一下实际编译过程中遇到的问题,以供参考。
首先编译安装openssl(编译这玩意儿需要perl环境,所以还得先安装perl),我编译的版本是openssl-0.9.8k。编译完成后安装在
D:\OPENSSL-0.9.8K
├─bin
│ libeay32.dll
│ openssl.exe
│ ssleay32.dll
│
├─include
│ └─openssl
│ aes.h
│ applink.c
│ asn1.h
│ asn1t.h
│ ...
└─lib
│ libeay32.lib
│ ssleay32.lib
│
└─Debug
/--------------------------------------
23:35:48, 2009年9月26日
原来NTP在NT下已经支持NMEA来作为参考时钟了呀,我太土了。手头没有可用的GPS,于是写了一小段模拟GPS输出的代码,测试一下,果然可以的。比方说NMEA由串口3输入,ntp.conf中应指定参考时钟为:
server 127.127.20.3
至于mode选项,要用的时候再查查doc吧。
ok的话,事件查看器会看到这样的记录:
synchronized to GPS_NMEA(3), stratum 0
/--------------------------------------
21:43:07, 2010年3月29日
对于NMEA driver,虽然NTP的文档声称支持4800/9600/19200……等多种波特率(通过mode选项中的bit 4/5/6指定),但至少我没有成功过,除了默认的4800bps。在GPS模块以9600bps的速率送出GGA语句的情况下,即使指定了mode 18,NTP依然无法正常接收数据(i386/FreeBSD 7.2R/NTP 4.2.5)。经过一番Google和好一番的尝试,终于通过stty限定波特率的方法,使NTP正常接收串口数据并同步到NMEA refclock了。串口通信的所有细节,包括波特率/数据位/停止位/校验位/流控制......等都可以通过stty设定初始化值或固定值,应根据GPS模块的设置进行相应设置。
详见man stty。
/--------------------------------------
23:34:40, 2010年4月22日
更正一下,上一篇中说到NTP对非4800bps的NMEA driver支持有问题,是我错了。当时用的版本是4.2.4p5(FreeBSD 7.2R默认安装),这个版本本来就支持4800bps,而我看的NTP文档是针对4.2.6p1的。在FreeBSD 7.2R编译并安装ntp 4.2.6p1后,测试可以支持9600bps。
今天整个下午都在调试pps,晚上又跑去办公室调了一会,依然无果。内核已启用PPS_SYNC选项重新编译过;pps信号-7v ~ +8v,占空比50%,送入串口1的#1(DCD);ntp.conf也启用了pps相关选项。然而ntptime和ntpdc -c kern返回的状态只有PLL和NANO,偶尔会出现PPSTIME和PPSFREQ,PPSSIGNAL却从未出现过。
/--------------------------------------
22:54:06, 2010年4月23日
只是修改了Kernel Configuration File中的ident字段值,重新编译内核,配置NTP,检查输入信号,测试输出……似乎一切正常了……难道,假如把GENERIC复制一份到PPSGENERIC,然后在PPSGENERIC中仅仅添加一行options PPS_SYNC,不修改ident字段,保存,make buildkernel installkernel KERNCONF=PPSGENERIC,重启,使用的依然是默认的、不支持kernel pps discipline的GENERIC内核?不管怎样,总算出来我想看到的结果了。
/--------------------------------------
15:29:27, 2010年5月9日
在FreeBSD 7.2R上手工编译安装了NTPD v4.2.6p1,用以替代系统默认安装的4.2.4p5,重启发现NTPD的初始化时间似乎长了些,日志记录也没有前一版本详细,ntpq -p的输出的状态标记是一个"o",而前一版本是"*"。
联系客服