|
|
Posted on 2009-04-18 22:27 buf 阅读(8600) 评论(-1) 编辑 收藏 引用
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 |
/--------------------------------------
20:14:08, 2009年05月16日
要开始搭建测试平台了，没想到一开始就遇到了问题。
准备在一台dell品牌机机装debian+ntpd做时间服务。装系统时居然不认网卡！linux对硬件支持不好，那应该是很久远的说法了，至少在此之前我没有经历过。那是一台没有Internet连接的机器，我没有其它选择，只能不装网卡驱动，打算先装完系统再说。还好同一批次的机器配置一样，在另一台机器上copy了网卡型号：intel 82567lm-3 gigabyte network controller。
回家上网，在intel的官方网站找到了这款网卡芯片的linux驱动和安装说明，还好。不过，按照说明尝试make install安装的时候却出错了：
"no rule to make target"
再上网找资料，发现有人说2.6.28|29内核可以支持这个网卡芯片，而我的debian lenny的内核版本是2.6.26。心说为了一个网卡，难道还要升级内核？真是麻烦...后来仔细看了一下报错的消息，终于发现了问题：原来驱动源码的路径名中有空格，makefile里执行pwd获得的路径名就被截断了，第一段被作为路径名，第二段被作为make的target，怪不得找不到target呢／／／stupid.
然后网卡驱动的编译安装就没问题了。
/--------------------------------------
23:21:28, 2009年5月18日
使用ntpq -c rv检查ntpd，示例输出如下（win32，meinberg distribution）：
D:\Program Files\NTP\bin>ntpq -c rv
assID=0 status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg,
version="ntpd 4.2.4p6@vegas-v2-o Jan 12 15:27:46 (UTC+01:00) 2009 (4)",
processor="unknown", system="WINDOWS/NT", leap=00, stratum=2,
precision=-19, rootdelay=65.003, rootdispersion=81.220, peer=20248,
refid=210.72.145.44,
reftime=cdbbfa40.14d3ca54 Mon, May 18 2009 23:16:16.081, poll=6,
clock=cdbbfaed.b0061992 Mon, May 18 2009 23:19:09.687, state=4,
offset=-67.855, frequency=49.741, jitter=8.469, noise=16.150,
stability=7.225, tai=0
offset是最重要的变量，它表示ntp计算出的当前计算机时间与若干时钟源时间的差的组合值（combined offset）。
precision标记了当前计算机的计时精度，-19表示pow(2,-19) = 1 / (219) s, 近似于1.9μs
reftime为最近一次的同步时间
clock为执行ntpq时的当前计算机时间
/--------------------------------------
22:19:52, 2009年5月19日
进行了ntp性能的简单测试，主要关注offset分布情况，效果很不理想。
两次测试，每次2小时左右，每30秒运行一次ntpq -c rv，提取offset并记录到log文件。第一次测试时offset最初超过60ms，运行一段时间后最小达到-2ms左右，然后呈递增趋势，结束时超过10ms。第二次的情况稍好一些，从6ms收敛到1~2ms，然后又缓慢增加，结束时超过10ms。
不知道是否和以下事实有关：
1、ntp server运行在一台长时间没有使用过的老机器上，主板电池没电了。每次启动后系统时间都从2002年某时刻开始...
2、使用LCL（本地时钟）作为时钟源
我觉得1应该不会对试验结果产生影响。我的理解，系统运行期间并不依赖主板上的计时模块进行计时，只是在启动初始化时读取一个初始值。
/--------------------------------------
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
http://time.qnan.org/
maillist: 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制作的安装包，也可以自己编译。从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
有了openssl后，打开ntp-4.2.4p7\ports\winnt\ntp.dsw进行批构建，注意以下几点：
1、某些工程需要连接libeay32.lib，工程选项中设定的路径为$(OPENSSL)\out32dll\libeay32.lib。根据你的情况修改这个路径（或者保证文件在此路径上）；
2、需要添加$(OPENSSL)\include到VC的include目录列表中（或者在工程选项中设置）；
3、NTP支持IPv6，编译时会通过_MSC_VER这个宏来检测编译器版本。如果发现使用VC6，会帮你添加一些IPv6的相关定义——因为VC6本身是不包含这些定义的。但是，因为我这里装了PSDK，相关的定义已经被添加进来了，所以会产生重定义错误，解决方法有二：
a）不使用PSDK中的文件，也就是在vc->tools->options->directories选项卡中移除PSDK的相关目录
b）在源文件中增加对PSDK的检测，修改以下两个文件：
>>> ntp-4.2.4p7\ports\winnt\include\config.h
#define HAVE_PLATFORMSDK // 我不知道有什么官方的办法检测PSDK，于是自己定义了一个...
#if ((defined _MSC_VER && _MSC_VER > 1200) || (defined HAVE_PLATFORMSDK))
//#if defined _MSC_VER && _MSC_VER > 1200
#define HAVE_STRUCT_SOCKADDR_STORAGE
#define ISC_PLATFORM_HAVEIPV6
#define ISC_PLATFORM_HAVEIN6PKTINFO
#define NO_OPTION_NAME_WARNINGS
#endif
>>> ntp-4.2.4p7\ports\winnt\include\isc\net.h
//#if _MSC_VER < 1300
#if _MSC_VER < 1300 && !defined HAVE_PLATFORMSDK
#define in6addr_any isc_net_in6addrany
#define in6addr_loopback isc_in6addr_loopback
#endif
这样编译就不会有错误了^^。
/--------------------------------------
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内核？不管怎样，总算出来我想看到的结果了。
# ntpdc -c kern
pll offset: -2.7815e-05 s
pll frequency: -1.809 ppm
maximum error: 0.221987 s
estimated error: 1.4e-05 s
status: 2107 pll ppsfreq ppstime ppssignal nano
pll time constant: 6
precision: 1e-09 s
frequency tolerance: 496 ppm
pps frequency: -1.809 ppm
pps stability: 0.076 ppm
pps jitter: 8.42e-07 s
calibration interval: 128 s
calibration cycles: 24
jitter exceeded: 2
stability exceeded: 0
calibration errors: 1
# ntptime
ntp_gettime() returns code 0 (OK)
time cf7c2309.ba3970f4 Fri, Apr 23 2010 21:45:45.727, (.727439275),
maximum error 216487 us, estimated error 14 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
modes 0x0 (),
offset -32.258 us, frequency -1.809 ppm, interval 128 s,
maximum error 216487 us, estimated error 14 us,
status 0x2107 (PLL,PPSFREQ,PPSTIME,PPSSIGNAL,NANO),
time constant 6, precision 0.001 us, tolerance 496 ppm,
pps frequency -1.809 ppm, stability 0.076 ppm, jitter 1.246 us,
intervals 24, jitter exceeded 2, stability exceeded 0, errors 1.
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*GPS_NMEA(2) .gps. 0 l 16 64 377 0.000 -0.007 0.100
/--------------------------------------
15:29:27, 2010年5月9日
在FreeBSD 7.2R上手工编译安装了NTPD v4.2.6p1，用以替代系统默认安装的4.2.4p5，重启发现NTPD的初始化时间似乎长了些，日志记录也没有前一版本详细，ntpq -p的输出的状态标记是一个"o"，而前一版本是"*"。
|