本篇文章给大家谈谈网络标准时钟，以及手机桌面时钟对应的知识点，文章可能有点长，但是希望大家可以阅读完，增长自己的知识，最重要的是希望对各位有所帮助，可以解决了您的问题，不要忘了收藏本站喔。
本文目录
一、目前网络时间服务有哪几种协议
杭州元帅http://**vbgood**/viewthread.php?tid=18070&highlight=
在一个局域网中，许多**都要求每台计算机能够保持时间的一致性，WIN2000**提供了与主域服务器时间同步功能，即工作站只要登录到主域服务器，工作站**的时间自动与主域服务器时间一致，但接下来的问题是我们如何使主域服务器的时间同步世界标准时间。如要获得世界标准时间，比较精确的做法是使用GPS卫星时钟获得毫秒级精度的标准时间，但这是要money的哦。如果我们在时间精度上只需要秒级的，又能够连接到Internet，则我们可以利用Internet上的标准时间服务器获得标准时间。
事实上在Internet上有三个不同的时间服务，每一个都由Request for Comment（RFC）定义为Internet日期时间标准。这三个标准分别为：RFC-867、RFC-868和RFC-1305。下面就先介绍RFC-867：
RFC867 Daytime协议(RFC867 Daytime Protocol)
本RFC规范了一个ARPA Internet community上的标准。在ARPA Internet上的所有主机应当采用和实现这个标准。
一个有用的测量和调试工具就是daytime服务。它的作用就是返回当前时间和日期，格式是字符串格式。
daytime服务是基于TCP的应用，服务器在TCP端口13侦听，一旦有连接建立就返回ASCII形式的日期和时间(接收到的任何数据被忽略)，在传送完后关闭连接。
daytime服务也可以使用UDP协议，它的端口也是13，不过UDP是用数据报传送当前时间的。接收到的数据被忽略。
对于daytime没有特定的格式，建议使用ASCII可打印字符，空格和回车换行符。daytime应该在一行上。
一种流行的格式是：Weekday, Month Day, Year Time-Zone
例子：Tuesday, February 22, 1982 17:37:43-PST
另一种流行的格式用于SMTP中：dd mmm yy hh:mm:ss zzz
注意：对于机器来说，有用的时间采用了时间协议（Time Protocol RFC-868)
接下来我们用VB程序实现通过RFC867协议设置我们自己的计算机**时间，为使程序简化，程序未进行日期校正，只进行时间校正。在FORM1中添加1个Winsock控件，将下面代码剪贴到FORM1的代码窗体中即可：
'采用RFC867 Daytime协议获取标准时间例程
'**time.ac**为中科院国家授时中心，采用北京时间
'时间格式：Mon Jul 26 09:58:57 2004
'time.nist.gov为美国标准技术院，采用格灵威时间
'时间格式：53212 04-07-26 02:00:12 50 0 0 488.3 UTC(N**T)*
Private Declare Sub Sleep Lib"kernel32"(ByVal dwMilliseconds As Long)
Winsock1.Protocol= sckTCPProtocol'采用TCP协议
NetTime"**time.ac**"'首先取中科院国家授时中心时间
If NoSrv Or TimeFromNet="" Then
'若未取到中科院国家授时中心时间，则取美国标准技术院时间
If NoSrv Or TimeFromNet="" Then
'若不能取美国标准技术院时间，则报错
MsgBox"检测不到网络标准时间服务器time.nist.gov！"
'为使网络传输误差减小，第2次再取美国标准技术院时间
MsgBox"网络标准时间服务器time.nist.gov超时！"
TimeFromNet= Mid(TimeFromNet, 17, 8)
TimeFromNet= TimeSerial((Hour(TimeFromNet)+ 8) Mod 24, Minute(TimeFromNet), Second(TimeFromNet))
Time= TimeFromNet'设置**时间
'为使网络传输误差减小，第2次再取中科院国家授时中心时间
MsgBox"网络标准时间服务器**time.ac**超时！"
Time= Mid(TimeFromNet, 12, 8)'设置**时间
If Winsock1.State<> sckClosed Then
Private Sub Winsock1_DataArrival(ByVal bytesTotal As Long)
TimeFromNet= String(bytesTotal,"")
Winsock1.GetData TimeFromNet, vbString, bytesTotal
Private Sub Winsock1_Error(ByVal Number As Integer, Description As String, ByVal Scode As Long, ByVal Source As String, ByVal HelpFile As String, ByVal HelpContext As Long, CancelDisplay As Boolean)
'从互联网上标准时间提供网站获取标准时间
Private Sub NetTime(TimeSrv As String)
If Winsock1.State<> sckClosed Then Winsock1.Close
Winsock1.RemoteHost= TimeSrv'"**time.ac**"或"time.nist.gov"
Do While TimeFromNet=""'循环等待标准时间网站返回时间数据
If NoSrv Then Exit Do'若Winsock出错，则跳出循环等待
If Winsock1.State<> sckClosed Then Winsock1.Close
搜索更多相关主题的帖子: internet标准
上面介绍了RFC-867标准和VB例程，显然RFC-867标准采用返回当前时间和日期的格式是字符串格式以及对于daytime没有特定的格式（例如：中科院国家授时中心为"Mon Jul 26 09:58:57 2004"，而美国标准技术院为"53212 04-07-26 02:00:12 50 0 0 488.3 UTC(N**T)"），这2点似乎都不是太舒服，因此我们希望Internet上的标准时间服务器最好能够返回具有标准格式的数字类型数据，其实RFC在制定RFC-867标准时已经考虑了我们的意见，因为他同时还推出了RFC-868标准，下面就介绍RFC-868：
本RFC规范了一个ARPA Internet community上的标准。在ARPA Internet上的所有主机应当采用和实现这个标准。
此协议提供了一个**于站点的，机器可读的日期和时间信息。时间服务返回的是以秒数，是从1900年1月1日午夜到现在的秒数，天哪，也不小呢。
设计这个协议的一个重要目的在于，网络上的许多主机并没有时间的观念，在分布式的**上，我们可以想一想，北京的时间和东京的时间如何分呢？主机的时间往往可以人为改变，而且因为机器时钟内的误差而变得不一致，因此需要使用时间服务器通过选举方式得到网络时间，让服务器有一个准确的时间观念。不要小看时间，这对于一些以时间为标准的分布运行的程序简单是太重要了。
这个协议可以工作在TCP和UDP协议下。下面是通过TCP协议工作的时间协议的工作过程：这里S代表服务器，U代表客户。
服务器在端口37上**连接。当连接建立后，服务器返回一个32位的时间值，然后关闭连接。这个过程也不难，如果服务器不能决定现在是什么时间，服务器会拒绝连接或不发送任何数据而直接关闭连接。
下面我们看看使用UDP协议的情况：这里S代表服务器，U代表客户。
S:发送包含32位二进制数（用于表示时间）的数据报
服务器在端口37上**数据包。当一个数据包来后，服务器返回一个包含32位的时间的数据包。这个过程也不难，如果服务器不能决定现在是什么时间，服务器会抛弃接收到的数据报而不作出任何应答。
时间是由32位表示的，是自1900年1月1日0时到当前的秒数，我们可以计算一下，这个协议只能表示到2036年就不能用了。（但是我们也知道计算机发展速度这么快，可能到时候就会有更好的协议代替这个协议，或者有已经想出有效的解决办法了。）
the time 2,208,988,800 corresponds to 00:00 1 Jan 1970 GMT,
2,398,291,200 corresponds to 00:00 1 Jan 1976 GMT,
2,524,521,600 corresponds to 00:00 1 Jan 1980 GMT,
2,629,584,000 corresponds to 00:00 1 May 1983 GMT,
以及-1,297,728,000 corresponds to 00:00 17 Nov 1858 GMT.
接下来我们用VB程序实现通过RFC868协议设置我们自己的计算机**时间，为使程序简化，程序未进行日期校正，只进行时间校正。不过这个例程比上面的程序要完善得多，首先他可以读取全球20个标准时间服务器的时间数据，第二他采用了网络延时的补偿，第三对网络延时超过3秒的标准时间服务器进行了过滤。在FORM1中添加1个Winsock控件，将下面代码剪贴到FORM1的代码窗体中即可：
'时间协定（RFC-868）提供了一个32位元的数字，用来表示从1900年1月1日至今的秒数。
'该时间是UTC（不考虑字母顺序，它表示世界时间座标（CoordinatedUniversalTime）），
'它类似於所谓的格林威治标准时间（GreenwichMeanTime）或者GMT－英国格林威治时间。
'用TCP获得准确时间的程式应该有如下步骤:
'1连结到提供此服务的端口37；
Private Declare Sub Sleep Lib"kernel32"(ByVal dwMilliseconds As Long)
Dim TimeFromNet'存放从时间网站读取的秒数
Dim TimeURL(19) As String'20个时间提供网站的URL
Dim HH As Integer, MM As Integer, SS As Integer'时、分、秒
CDec(TimeFromNet)'转换为 Decimal子类型，28位整数
TimeURL(0)="**time.ac**"'首先取中科院国家授时中心时间
TimeURL(1)="time.nist.gov"'美国标准技术院
TimeURL(2)="time-a.timefreq.bldrdoc.gov"
TimeURL(4)="nist1-dc.glassey**"
TimeURL(5)="nist1-ny.glassey**"
TimeURL(6)="nist1-sj.glassey**"
TimeURL(7)="utcnist.colorado.edu"
TimeURL(8)="time-b.timefreq.bldrdoc.gov"
TimeURL(9)="time-c.timefreq.bldrdoc.gov"
TimeURL(12)="nist1.aol-va.truetime**"
TimeURL(13)="nist1.aol-ca.truetime**"
TimeURL(14)="time-nw.nist.gov"
TimeURL(15)="Time-b.timefreq.bldrdoc.gov"
TimeURL(16)="Time-c.timefreq.bldrdoc.gov"
TimeURL(18)="clock.cmc.ec.gc.ca"
Me.Caption="正在联接—"& TimeURL(i)
NetTime TimeURL(i)'首次读取授时中心时间
If(Not NoSrv) And TimeFromNet> 0 Then'如果时间读取成功
'为使网络传输误差减小，二次再取授时中心时间
T0= Timer'为减小网络延时引起的误差，先读取当前时间
NetTime TimeURL(i)'二次读取授时中心时间
If(Not NoSrv) And TimeFromNet> 0 Then'如果第二次时间读取成功
TimeFromNet= TimeFromNet+ Int((Timer- T0)/ 2+ 0.5)'加上网络延时补偿(延时/2为延时补偿)
TimeFromNet= TimeFromNet- 86400* Int(TimeFromNet/ 86400)'以天取模(86400秒)
SS= TimeFromNet Mod 60'取秒
MM= TimeFromNet Mod 60'取分
HH=((TimeFromNet 60)+ 8) Mod 24'取小时(北京时间+8)
' MsgBox"网络延时："&(Timer- T0)
Time= TimeSerial(HH, MM, SS)'设置**时间
Exit For'取时完毕，退出循环
If Winsock1.State<> sckClosed Then
Private Sub Winsock1_DataArrival(ByVal bytesTotal As Long)
TimeFromNet= TmpData(3)+ TmpData(2)* 256+ TmpData(1)* 256* 256+ TmpData(0)* 256* 256* 256
Private Sub Winsock1_Error(ByVal Number As Integer, Description As String, ByVal Scode As Long, ByVal Source As String, ByVal HelpFile As String, ByVal HelpContext As Long, CancelDisplay As Boolean)
'从互联网上标准时间提供网站获取标准时间
Private Sub NetTime(TimeSrv As String)
Dim i As Integer'超时计数器
If Winsock1.State<> sckClosed Then Winsock1.Close
Winsock1.RemoteHost= TimeSrv'时间提供网站的URL
Winsock1.RemotePort= 37'时间协定（RFC-868）指定端口
If NoSrv Or i> 50 Then Exit Do'若Winsock出错或超时约3秒，则时间获取失败
If Winsock1.State<> sckClosed Then Winsock1.Close
最精确的网络时间协议应该是RFC 1305—NTP（Network Time Protocol）了，它能够1-50 ms的时间精确度，但该协议非常复杂，另外很抱歉我手头没有RFC 1305中文翻译资料，不过后来RFC又出了一个RFC1769—SNTP（Simple Network Time Protocol），简化了一些RFC 1305要求的**作和使用范围，下面就介绍RFC1769—SNTP：
Network Working Group D. Mills
Request for Comments: 1769 University of Delaware
（RFC1769——Simple Network Time Protocol）
本备忘录为Internet community提供了信息，但不规定任何一种类型的 Internet标准。本备忘录的分发没有**。
本备忘录描述简单网络时间协议(SNTP)，这是网络时间协议(NTP)的一个改写本，NTP协议适用于同步因特网上的计算机时钟。当不须要实现RFC 1305所描述的NTP完全功能的情况下，可以使用SNTP。它能用单播方式(点对点)和广播方式(点对多点)**作。它也能在IP多播方式下**作（可提供这种服务的地方）。SNTP与当前及以前的NTP版本并没有大的不同。但它是更简单，是一个无状态的远程过程调用(RPC)，其准确和可靠性相似于UDP/TIME协议在RFC868描述中所预期的。
本备忘录淘汰相同的标题的RFC 1361。它的目的是解释用广播方式**作的协议模式，提供某些地方的进一步说明并且改正一些印刷上的错误。在NTP版本3 RFC 1305中说明的工作机理对SNTP的实现不是完全需要的。本备忘录的分发没有**。
RFC 1305 [MIL92]指定网络时间协议(NTP)来同步因特网上的计算机时钟。它提供了全面访问国家时间和频率传播服务的机制，组织时间同步子网并且为参加子网每一个地方时钟调整时间。在今天的因特网的大多数地方， NTP提供了1-50 ms的精确度，精确度的大小取决于同步源和网络路径等特性。
RFC 1305指定了NTP协议机制中的事件，状态，传输功能和**作，另外，还有可选择的算法，它改进测时质量并且减少了一些同步源中可能存在的错误。为了获得因特网上主要路径的延时精确到毫秒级，使用一些复杂的算法或者他们的等价算法是必要的。但是，在许多场合这样的精确度是不要求，或许精确到秒已足够了。在这样的情况下，更简单的协议例如“时间协议”[POS83 ]已被使用。这些协议通过基于RPC交换：客户端请求此刻时间，然后服务器回传从某个已知时间点到现在的秒钟数。
NTP被设计成了性能差异很大的客户端及服务器均能适用，且适用于客户端及服务器所在网路有大范围的网络延迟和抖动的情况。今天的因特网上的NTP同步子网的大多数用户使用一个软件包包括了一整套的NTP的选择和算法，是一个比较复杂，实时的应用**。软件要适用于多种硬件平台：从巨型计算机到个人计算机。要在这样的范围都适用，它的庞大尺寸和复杂性就不适合于很多应用了。按照要求，探求一些可供选择的访问策略(使用适合于精确度要求不是
本备忘录描述简单网络时间协议(SNTP)，它是一个简化了的NTP服务器和NTP客户端策略。SNTP在协议实现上没有什么更改，在最近也不会有什么变动。访问范例与UDP/TIME协议是一致的，实际上，SNTP应该更容易适用于使用个人计算机的 UDP/TIME客户。而且，SNTP也被设计在一个专门的服务器(包括一台集成的无线电时钟)里**作。由于在**里的那些各种各样反应机制的设计和控制，交付调节时间精确到微秒是可能的。这样的专门设计是切实可行的。
强烈建议SNTP仅仅在同步子网的末端被使用。 SNTP客户端应该仅在子网的叶子(最高的阶层)**作并在配置过程中没有依靠其它NTP或者SNTP客户端来同步。SNTP服务器应该仅在子网的根(阶层1)**作并在配置过程中，除一台可靠的无线电时钟外中没有其它同步源。只有使用了有冗余的同步源及不同的子网路径及整套NTP实现中的crafted算法，主服务器通常期望的可靠性才有可能达到。这种做法使主同步源在无线电时钟通信失败或者交付了错误时间时，还能用到其它几个无线电时钟和通向其它主要服务器的备份路径。因此，应该仔细考虑客户端中SNTP的使用，而不是在主服务器里的NTP的使用。
象NTP一样，SNTP能在单播(点向点)或者广播(点对多点)模式中**作。单播客户端发送请求到服务器并且期望从那里得到答复，并且（可选的），得到有关服务器的往返传播延迟和本地时钟补偿。广播服务器周期性地送消息给一指定的IP广播**或者IP多播**，并且通常不期望从客户端得到请求，广播客户端****但通常并不给服务器发请求。一些广播服务器可能选择对客户端作出反应请求以及发出未经请求广播消息；同时一些广播客户端可能会送请求仅为了确定在服务器和客户端之间的网络传播延迟。
在单播方式下，客户端和服务器的IP**按常规被分配。在广播方式下，服务器使用一指定的IP播送**或者IP多播**，以及指明的媒介访问播送**，客户端要在这些**上帧听。为此，IP广播**将**在一个单独的IP子网范围，因为路由器不传播IP广播数据报。就以太网而论，例如，以太网媒介访问广播**(主机部分全部为1)被用于表示IP广播**。
另一方面，IP多播**将广播的潜在有效范围扩展到整个因特网。其真实范围，组会员和路由由因特网组管理协议(IGMP)确定 [DEE89 ]，对于各种路由协议，超出了这份资料的讨论范围。就以太网而论，例如，以太网媒介访问播送**(全部为1)要和分配的224.0.1.1的IP多播**合用。除了IP**规范和IGMP，在服务器**作IP广播**或者IP多播**没有什么不同。
广播客户端帧听广播**，例如在以太网情况下主机**全部为1的。就广播**的IP而论，没有更进一步规定的必要了。在IP多组广播情况下，主机可能需要实现IGMP，为的是让本地路由器把消息**后送到224.0.1.1多播组。这些考虑不属于这份资料的讨论范围。
就当前指定的SNTP而论，其真正的弱点是多目广播客户端可能被一些行为不当或者敌对的在因特网别处的SNTP/NTP多播服务器攻击而瘫痪，因为目前全部这样服务器使用相同的IP多播**：224.0.1.1组**。所以有必要，存取控制要基于那些以客户端信任的服务器源**，即客户端选择仅仅为自己所知的服务器。或者，按照惯列和非正式协议，全部NTP多播服务器现在在每条消息内应包括已用MD5加密的加密位，以便客户端确定消息没有在传输中被修改。SNTP客户端能实现那些必要加密和密钥分发计划在原则上是可能的，但是这在SNTP被设计成的那些简单的**里不可能被考虑。
考虑到没有一个完整的SNTP规范，故IP广播**将使用在IP子网和局域网部分(指有完整功能的NTP服务器和SNTP客户端在同一子网上的局域网)，而对于IP多播**来说，将只能用在为达到以上相同目而设计的特例中。尤其，只有服务器实现了RFC 1305描述的NTP认证时（包括支持MD5消息位的算法），在SNTP服务器里的IP多播**才被使用。
sntp使用在RFC 1305及其以前的版本所描述标准NTP时间戳的格式。与因特网标准标准一致， NTP数据被指定为整数或定点小数，位以big-endian风格从左边0位或者高位计数。除非不这样指定，全部数量都将设成unsigned的类型，并且可能用一个在bit0前的隐含0填充全部字段宽度。
因为SNTP时间戳是重要的数据和用来描述协议主要产品的，一个专门的时间戳格式已经建立。 NTP用时间戳表示为一64 bits unsigned定点数，以秒的形式从1900年1月1日的0：0：0算起。整数部分在前32位里，后32bits（seconds Fraction）用以表示秒以下的部分。在Seconds Fraction部分，无意义的低位应该设置为0。这种格式把方便的多精度算法和变换用于UDP/TIME的表示（单位：秒），但使得转化为ICMP的时间戳消息表示法(单位：毫秒)的过程变得复杂了。它代表的精度是大约是200 picoseconds，这应该足以满足最高的要求了。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
注意，从1968年起，最高有效位(整数部分的0 bit位)已经被确定，64位比特字段在2036年将溢出。如果NTP或者SNTP在2036年还在使用的话，一些外部方法将有必要用来调整与1900年及2036年有关的时间(136年的其它倍数也一样)。用这样的**使时间戳数据变得很讲究(要求合适的方法可容易地被找到)。从今以后每136年，就会有200picosecond的间隔，会被忽略掉，64个比特字段将全部置为0，按照惯列它将被解释为一个无效的或者不可获得的时间戳。
NTP和SNTP是用户数据报协议( UDP)的客户端 [POS80 ]，而UDP自己是网际协议( IP) [DAR81 ]的客户端. IP和UDP报头的结构在被引用的指定资料里描述，这里就不更进一步描述了。UDP的端口是123，UDP头中的源断口和目的断口都是一样的，保留的UDP头如规范中所述。
以下是SNTP报文格式的描述，它紧跟在IP和UDP报头之后。SNTP的消息格式与RFC-1305中所描述的NTP格式是一致的，不同的地方是：一些SNTP的数据域已被风装，也就是说已初始化为一些预定的值。NTP消息的格式被显示如下。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|LI| VN|Mode| Stratum| Poll| Precision|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
二、以太网物理层怎么时钟同步
1、一级(全国)基准时钟(PRC)位置
一个典型的同步以太网结构中，在图4所示的三个位置之一具有PRC。
情况A，核心位置：这种结构意味只有少量PRC节点即以PRC为m,b用某种形式分配定时到IWF。
情况B，接入位置：PRC将位于网络中的某些点，典型的在多业务接入点。这种结构意味有比情况A更多的PRC节点即以PRC为中心用某种形式分配定时到1wF。
情况C，IWF位置：PRC将位于IWF并直接同步连接到IWF，这种结构意味有很多PRC节点即每个IWF有～个PRC。
参照图3，提供的同步流是由核心网至IWF。不试图从用户设备往核心网方向分配定时。
OAM功能通过使用OAM协议数据单元(OAMPDU)来实现，由以太帧中的特定头字段识别。
QAMPDU是标准的以太MAC帧，但通过长度／类型为慢协议帧(值8809)和子类型(值0x03)两者来识别OAMPDU。编码字段规定OAMPDU帧的类型。编码字段有八种可能的值，特定值(FE)留作组织化特定的扩展。该组织化扩展是位于数据字段的最初三个字节并组成值××，YY，ZZ(这些值由IEEE定义)，剩下39字节用于OAM用户数据，如图5所示。
同步状态信息(SSM)对下游以太交换提供确定可**同步分配方案的机制并返回PRC或者利用更高质量的时钟。
在上游网络故障状态下，同步功能根据SSM和预置的优先权采取适当的**作，选择另一个同步供给。这可能是另一个网络供给或者是外部供给。
SSM由G707定义。在同步以太网络中，SSM的使用准则将有待进一步研究。用户数据字段SSM部分的安排见图6。
用户数据字段剩下的空位装填充数据。
在广域网环境中，**同步以太网产生的抖动和漂移的方案需要满足抖动和漂移的网络容限。
同步以太交换中的同步功能取决于内嵌时钟的性能特性。
当该时钟同步到另一个类似的同步以太网时钟或更高质量的时钟时，该时钟应确保出现适当的网络**作。为了与现存同步网的一致，内嵌时钟必须基于G．813SEC(SDH设备时钟)。当这样的同步以太网与G812SSU(同步供给单元)或SASE(**型同步设备)连接再连接到G．811PRC时，用这样的网络时钟将能保证同步互联，同时也允许现存TDM网与新的分组网之间同步互联。需要指出的是，这些方案不影响现存IEEE802．3的任何特性如频率容差等。
在传统SDH同步网中，规定了不同等级的同步时钟，G．811可以认为是一级PRC，G，812可以认为是二级或**的时钟BITS，G813就是SEC，也是网络中最低的时钟等级。在同步以太网中，也开始考虑组织一个像SDH一样的同步链路。于是就出现了一个新概念：以太网设备时钟(EEC)，G．8262就是定义EEC的一个规范。在同步时钟层次中，SEC和EEC是同等级别，也可以互联互通。
三、网络时间服务器的详细参数
GPS时钟参考模式，一级网络时间服务器，同步精度1µs用户终端同步授时精度：0.5-2ms（局域网典型值）用户容量：可支持数万台客户端NTP请求量：8000次/秒
可作为从服务器同步于其他NTP网络时间服务器
支持4000条日志记录功能
16通道授时型GPS**
UTC同步精度30ns（RMS），支持单星授时窗口模式
接收L1,C/A码信号-1575.42MHz
**及锁定灵敏度可达-160dBm
显示GPS收星状态、时间、GPS卫星个数、经纬度、高度、各网卡IP、**工作状态
指示NTP服务是否启动、网络连接是否正常、
NTP请求是否超过8000次/秒和GPS是否锁定等
GPS天线入：BNC，1路，L1，1575.42MHz，输出5V DC
网口： RJ-45，4路，10/100自适应以太网接口
Console： RJ-45，1路，RS232电平，控制接口
TOD： DB-9 female,2路，RS232电平，时间、位置信息
ALARM干接点报警：3对，电源、GPS、端口容量报警
1PPS：BNC，1路，精度30ns（RMS）
USB：1路，备份、恢复、升级功能
HJ210 NTP网络时间服务器（GPS）
HJ210-OCXO NTP网络时间服务器（GPS恒温晶振）
HJ210-RB NTP网络时间服务器（GPS铷钟）
HJ210-BD NTP网络时间服务器（GPS北斗）
HJ210-BDOCXO NTP网络时间服务器（GPS北斗恒温晶振）
HJ210-BDRB NTP网络时间服务器（GPS北斗铷钟）
HJ210-CDMA NTP网络时间服务器（CDMA）
尺寸：1U机箱447×44.5×300mm
电源：220V±20% 47Hz～63Hz
工作温度：-10℃～ 55℃（主机）
存贮温度：-45℃～ 85℃
30米电缆高灵敏度授时天线 1个
光盘 1张（说明书、NTPC客户端同步软件、NTPM服务器监控软件、windows/Unix/Linux/AIX/Solaris等**同步参考概要）
Opt-BD：北斗参考源输入
Opt-CDMA：CDMA网络参考源
Opt-BTFIN：IRIG-B码、PPSTOD输入**选件
Opt-OCXO：内置恒温晶振
Opt-RB：内置铷原子钟，
Opt-D220：冗余220VAC电源
Opt-A：多路10MHz、1PPS等信号
天馈线避雷器、50、80、100米电缆
数码子钟：网口数码子钟
好了，文章到此结束，希望可以帮助到大家。