Có tài liệu nghiên cứu về độ chính xác NTP có sẵn?


13

Theo tôi biết, độ chính xác của quá trình đồng bộ hóa NTP phụ thuộc rất nhiều vào mạng. Tôi đã thấy một số con số từ 50 micro giây đến "dưới một giây" qua internet. Chà, đây là một sự khác biệt rất lớn.

Tôi tin rằng, sự phụ thuộc chính xác là một câu hỏi lớn để nghiên cứu, nhưng cho đến nay tôi đã không tìm thấy bất kỳ tài liệu nào, trong đó nêu rõ rằng, một số cấu hình cụ thể cấp độ chính xác cụ thể đó.

Nó được nói trên http://www.ntp.org/ntpfaq/NTP-s-algo.htm :

Yêu cầu chênh lệch thời gian dưới 128ms giữa máy chủ và máy khách để duy trì đồng bộ hóa NTP. Độ chính xác điển hình trên Internet dao động từ khoảng 5ms đến 100ms, có thể thay đổi theo độ trễ của mạng. Một khảo sát gần đây [2] cho thấy 90% máy chủ NTP có độ trễ mạng dưới 100ms và khoảng 99% được đồng bộ hóa trong vòng một giây với đồng bộ hóa.

Với tính năng đồng bộ hóa PPS, độ chính xác là 50 LẦN và độ ổn định dưới 0,1 PPM có thể đạt được trên PC Pentium (ví dụ chạy Linux).

Đó là một cái gì đó, nhưng có lẽ có một số phân tích kỹ lưỡng hơn về chủ đề này?


3
Mặc dù tôi nghĩ rằng câu hỏi này cho thấy không có nỗ lực nghiên cứu nào cả, và đang hạ thấp trên cơ sở đó - thậm chí còn không rõ OP đã đọc bất kỳ tài liệu nào trên ntp.org - tôi nghĩ đó là một câu hỏi hợp pháp và sẽ tranh luận về việc đóng cửa cơ sở đó. Muốn biết lý do tại sao một giao thức sẽ hoạt động như quảng cáo, thay vì mù quáng triển khai và hy vọng điều tốt nhất, không phải là lãng phí thời gian.
MadHatter

Cảm ơn vì đã cập nhật câu hỏi, tôi đã đọc lại downvote của mình. Điều đó nói rằng, bạn có thể cảm thấy thật khó chịu khi bị gửi trở lại khi bạn đến, nhưng nếu bạn không cho chúng tôi biết bạn đã ở đâu khi bạn đặt câu hỏi, làm sao chúng tôi biết? Tôi cũng lưu ý rằng chính văn bản bạn đăng ở trên bao gồm một con trỏ đến một bài báo học thuật nghiên cứu tính chính xác của các máy chủ NTP. Bạn đã đọc nó, và nếu vậy, bạn có thể chỉ ra tại sao điều đó là không đủ?
MadHatter

Đủ công bằng. Bài viết là một cuộc khảo sát tổng thể 14 năm trên mạng NTP. Nó có thêm liên kết, nhưng tất cả chúng, tất nhiên, thậm chí cũ hơn. Tôi đã dùng thử Google Scholar và CiteSeer, nhưng hầu hết các liên kết đều giống nhau của Mill và Millnar từ những năm 1990. Tôi vẫn đang duyệt, nhưng tôi hơi xa chủ đề này và việc này có thể mất nhiều thời gian, vì vậy tôi đã chọn để nhờ cộng đồng giúp đỡ.
akalenuk

1
NTP đã không thay đổi trong ít nhất 14 năm, tại sao độ chính xác của nó lại thay đổi đáng kể ?? Như được đề cập dưới đây, NTP không có nghĩa là siêu chính xác, nó có nghĩa là trong vòng 1 giây (có lẽ là nơi mà trích dẫn không được hiểu rõ đến từ đó). Nếu bạn cần độ chính xác phụ 1ms thì bạn muốn sử dụng PTP. Tôi thực sự không thể thấy bất kỳ giá trị nào trong việc nghiên cứu tính chính xác của một cái gì đó mà trong việc triển khai rất rộng thực hiện chính xác những gì nó dự định làm.
Chris S

2
Trên thực tế, Chris, hai phần công việc được trích dẫn cho thấy rõ rằng độ chính xác của các máy chủ NTP trên internet (không phải bản thân giao thức, vốn luôn tuyệt vời) đã được cải thiện từ năm 1999 đến nay. Tôi nghi ngờ điều này một phần là do tốt hơn của Internet - độ trễ là thấp hơn một chút và nhiều biến ít hơn một lần họ - và một phần là do chất lượng của các máy chủ S1 đã được cải thiện (giấy 1999 nói rằng các nguồn đồng hồ phổ biến nhất cho các máy chủ S1 là Đồng hồ hệ điều hành!). Tôi rất vui vì OP đã hỏi câu hỏi này, tôi nghĩ nó đáng giá.
MadHatter

Câu trả lời:


14

Không ai có thể đảm bảo NTP sẽ hoạt động tốt như thế nào trên mạng của bạn, bởi vì không ai biết mạng của bạn được kết nối tốt như thế nào với internet và với các máy chủ đồng hồ trên đó. Tuy nhiên, theo trang thuật toán kỷ luật đồng hồ trên ntp.org

Nếu còn chạy liên tục, máy khách NTP trên mạng LAN nhanh trong môi trường gia đình hoặc văn phòng có thể duy trì đồng bộ hóa trên danh nghĩa trong vòng một mili giây. Khi các biến đổi nhiệt độ môi trường nhỏ hơn một độ C, tần số dao động đồng hồ bị kỷ luật trong phạm vi một phần triệu (PPM), ngay cả khi độ lệch tần số dao động đồng hồ là 100 PPM trở lên.

Lưu ý rằng độ trễ lớn nhưng ổn định giữa mạng LAN của bạn và máy chủ đồng hồ của internet không có ảnh hưởng xấu đến độ chính xác như độ trễ biến đổi cao.

Bạn không nói bạn đã ước tính ở đâu ('50 micro giây đến ... "dưới một giây" '), vì vậy tôi không thể nhận xét về chúng, nhưng theo kinh nghiệm của tôi, 50us là không thể trừ khi bạn có đính kèm trực tiếp nguồn đồng hồ và 1 giây là không thể trừ khi bạn có một đoạn dây ướt kết nối bạn với internet và bạn đang sử dụng các máy chủ ngược dòng ở Nam Cực.

Chỉnh sửa : văn bản bạn hiện trích dẫn trong câu hỏi của bạn đưa ra một con trỏ đến một tờ giấy, vào năm 1999, thực sự đã xác định rằng 99% máy chủ ntp được đồng bộ hóa trong vòng một giây. May mắn thay, có nhiều công việc gần đây; trong bài báo này, một số tác giả từ Đại học Liên bang Parana, Brazil, đã lặp lại thí nghiệm vào năm 2005 và nhận thấy (nếu tôi hiểu chính xác Hình 1 của họ) rằng phía bắc 99% - giống như 99,5% - các máy chủ hiện có độ lệch thấp hơn 100ms và 90% có độ lệch nhỏ hơn 10ms. Điều này phù hợp khá tốt với kinh nghiệm của tôi (xem ở trên).

Chỉnh sửa 2 : một nếp nhăn cuối cùng: tất cả các nghiên cứu này không điều tra mức độ chính xác của đồng hồ địa phương, mà thay vào đó, nó khác bao xa so với đồng hồ tham chiếu ngược dòng. Đây là những bằng sáng chế không giống nhau. Nhưng điều đầu tiên là không thể biết được; để biết đồng hồ của bạn sai như thế nào, bạn phải biết chính xác là mấy giờ và nếu bạn biết điều đó, tại sao bạn lại đặt đồng hồ sai ở vị trí đầu tiên? Chỉ cần lưu ý rằng những gì các nghiên cứu này đang đo không phải là sự khác biệt giữa đồng hồ địa phương và thời gian tuyệt đối, mà là giữa đồng hồ địa phương và đồng hồ tham chiếu.


+1 Tôi cũng đã chạy một máy chủ pool,> 20ms trôi theo dõi rõ ràng trên toàn quốc là kỳ lạ.
Chris S

9

Vấn đề gì bạn đang cố gắng giải quyết?

Giải pháp tôi gặp phải cho các môi trường đòi hỏi độ chính xác cao hơn NTP là Giao thức thời gian chính xác (PTP) . Tôi đã có nó trong các ứng dụng máy tính khoa học và máy tính tài chính. Có sự đánh đổi , mặc dù.

Xem thêm: đồng bộ hóa thời gian ptp trên centos6 / rhel


4
"Vấn đề gì bạn đang cố gắng giải quyết?" Câu hỏi yêu thích của tôi - tôi hỏi nó mọi lúc.
mfinni

@mfinni, Khi bạn cần xếp hạng khách hàng nào gửi trước (ví dụ: HFT ), điều đó sẽ giúp chính xác với thời gian của bạn.
Pacerier

6

Một vài điều khác đáng nói:

  • Bạn sẽ may mắn nhận được <100ms jitter đồng hồ trên máy ảo, vì vậy tất cả những điều dưới đây là dành cho máy chủ vật lý
  • Jitter Sub 100ms gần như vô lượng cho hầu hết mọi nhiệm vụ và có thể dễ dàng đạt được qua Internet
  • Có thể cần jitter Sub 30ms cho một số môi trường phục vụ chung (tôi cần nó để tương quan nhật ký ở công việc trước đó) và có thể dễ dàng đạt được bằng cách sử dụng máy chủ NTP trên cùng lục địa nơi kết nối không thông qua liên kết "người tiêu dùng" (ví dụ: không phải vệ tinh , ADSL, DOCSIS, GPON, UMTS / LTE / HSPA / vv)
  • Để có độ chính xác tuyệt đối dưới mức này, bạn nên cài đặt máy chủ NTP phần cứng từ nhà cung cấp chất lượng (ví dụ: Symmetricom)
  • Có thể dễ dàng đạt được thỏa thuận cục bộ 10ms (thường là 1ms) chỉ bằng cách có một bộ ba (bạn có thể làm với ít hơn, nhưng có lý do để sử dụng ba hoặc năm) trong cùng một trung tâm dữ liệu đủ cho hầu hết mọi ứng dụng phi Khoa học

5

Về phần lợi ích của tôi: Tôi là đại lý của Meinberg :-)

Có NTP có thể đạt được độ chính xác từ đầu đến cuối. 50 chúng tôi (tức là micro giây), nếu bạn đồng bộ hóa "máy khách" linux trên kim loại trần chạy Chrony hoặc ntpd, với máy chủ NTP dựa trên Linux được xử lý bằng GPS, đồng hồ nguyên tử cục bộ hoặc một số nguồn như vậy.

Trên máy có GPS cục bộ (có kết nối PPS), bạn có thể sẽ thấy bù 0-2 micro giây, giữa phiên bản ntpd đang chạy trong HĐH và đầu vào trình điều khiển PPS của nó.

50 chúng tôi còn lại "kết thúc để kết thúc mạng LAN" là kết quả của một số giai đoạn đệm, độ trễ IRQ thay đổi, lưu lượng truy cập khác can thiệp vào mạng LAN và trên các máy tính có liên quan và không có gì. 50 chúng tôi có nghĩa là một mạng LAN với lưu lượng rất ít. Thậm chí chỉ cần một công tắc có thể thêm một vài micro giây của jitter - và các công tắc cao cấp hơn với các tính năng phức tạp sẽ thêm độ trễ và jitter. Nói cách khác, có thể khá khó để đạt được 50 micro giây đó trong điều kiện thế giới thực của bạn trên một số mạng LAN thực tế.

Tương tự, các cca <2us của phần bù PPS chỉ xuất phát từ độ không đảm bảo độ trễ IRQ và độ trễ jitter bus chung trên phần cứng PC hoạt động tốt.

Lưu ý rằng NTP và các triển khai của nó ntpd và Chrony chắc chắn đo thời gian khứ hồi giao dịch NTP và trừ (thêm, thực tế) một nửa chuyến đi khứ hồi đó, như một biện pháp để lọc đi độ trễ vận chuyển có hệ thống (một chiều). Họ cũng thực hiện từ chối ngoại lệ, đồng thuận đại biểu, bầu cử syspeer và bất kỳ con quỷ NTP nào lọc các phản hồi mà nó nhận được đối với các truy vấn ngược dòng của nó. Vì vậy, như những người khác đã nói, một phần nghìn giây mà bạn thấy trong Ping và Traceroute không trực tiếp bù cho đồng hồ cục bộ của bạn. Vấn đề là sự thay đổi của chuyến đi khứ hồi giao dịch, tức là lưu lượng truy cập khác trên đường dẫn đến máy chủ NTP ngược dòng của bạn. Ntpq -p là bạn của bạn.

Một máy thu GPS cơ bản để sử dụng thời gian, với TCXO, có thể có 100-200 ns jitter dư + đi lang thang trên đầu ra PPS của nó. Rất nhiều đủ tốt cho NTP, miễn là GPS vẫn bị khóa. (Hiệu suất nắm giữ không tốt lắm với TCXO.) GPS định thời chất lượng với OCXO có thể hoạt động tốt trong vòng 100 ns, có thể giống như 10-30 ns lỗi dư (bù từ UTC toàn cầu).

Lưu ý rằng các vệ tinh thực tế bay trên đầu và chiếu vào bạn trong bầu khí quyển có thể là một trò chơi khó hơn một chút đối với người nhận, so với việc đo điểm chuẩn trong phòng thí nghiệm với máy phát GPS.

PTP là một cái búa. Bạn cần hỗ trợ CTNH trong grandmaster, và trong các nô lệ, và trong bất kỳ thiết bị chuyển mạch nào - nhưng nếu bạn nhận được tất cả những điều đó, việc bù đắp còn lại xuống mức thấp hai chữ số nano giây là có thể. Cá nhân tôi đã thấy điều này trong ptp4l chạy với i210 NIC có hỗ trợ CTNH (tính thời gian với độ phân giải nano giây).

Chip i210 là một kỳ quan. Nó có 4 chân đa năng có thể được sử dụng để nhập hoặc xuất tín hiệu PPS. Bảng mạch bổ trợ Intel tham chiếu với i210 (và các phiên bản OEM của một số nhà cung cấp lớn) được trang bị tiêu đề pin cho phép bạn truy cập vào ít nhất 2 trong số các chân GPIO đó (SDP được gọi bởi Intel). Ngoài việc triển khai cổng grandmaster PTP, đầu vào PPS có thể được tận dụng để xác định thời gian chính xác trong chụp gói. Bạn cần một nguồn PPS chính xác và một phần mềm tùy chỉnh để chạy vòng lặp servo, tinh chỉnh PHC của i210 cho ext.PPS. Trên thiết bị thử nghiệm của tôi, điều này dẫn đến ns một chữ số (mỗi lần lặp 1 giây) của phần bù dư. Đây là độ chính xác mà sau đó bạn có được trong dấu thời gian chụp của mình, nếu bạn chạy một tcpdump hoặc wireshark gần đây trên nhân Linux hiện đại (tất cả các phần mềm cần hỗ trợ cho độ phân giải cấp nano giây). Tốt hơn nữa: Tôi đã đi tất cả các cách và xây dựng một synth PLL đơn giản để tạo ra 25 MHz cho các đồng hồ NIC, được khóa với một tham chiếu 10 MHz ngược dòng chính xác. Sau đó, phần bù dư trong vòng lặp servo của thiết bị bắt gói tin của tôi giảm xuống 0 (một bằng chứng cho thấy tham chiếu 10 MHz của tôi là đồng bộ pha với PPS từ cùng hộp GPS đó).

Lưu ý rằng các đại gia PTP có thể được chỉ định để cung cấp dấu thời gian với độ chi tiết thực tế trên 8 ns (trong loại dữ liệu có độ phân giải 1 ns). Điều này có ý nghĩa - gigabit Ethernet có xu hướng sử dụng đồng hồ 125 MHz, được sử dụng làm đồng hồ byte trong phần bên trong của MAC, đồng hồ này có thể cũng được sử dụng trong GMII và đó cũng là đồng hồ biểu tượng bằng kim loại 1000Base-TX (bốn cặp song song, 2 bit cho mỗi ký hiệu trên mỗi cặp). Vì vậy, trừ khi bạn đang sử dụng 1000Base-FX (cáp quang) với SERDES và triển khai cực đoan của đơn vị đo thời gian CTNH trong PHY hoạt động với các bit SERDES riêng lẻ, 8 ns đó là tất cả những gì bạn có thể thực sự hy vọng trên Ethernet gigabit. Một số bảng dữ liệu chip (có hỗ trợ PTP) thậm chí cho rằng đường dẫn dữ liệu MII không có bộ đệm và một số jitter có thể đến từ đó.

Các gói PTP thực sự chứa dấu thời gian được lưu trữ trong một kiểu dữ liệu cho phép phân giải sâu dưới nano giây. Nhưng "trường phân đoạn phụ nano giây" hiện nay thường không được sử dụng. AFAIR chỉ có dự án Thỏ Trắng (liên quan đến Cern, trung tâm nghiên cứu của Thụy Sĩ) đã thực hiện độ chính xác phụ cho đến nay.

PTP cũng có sẵn trong phần mềm thuần túy, không cần tăng tốc CTNH. Trong trường hợp đó, đối với GM dựa trên SW và máy khách dựa trên SW, hy vọng sẽ có được một jitter dư tương tự như với NTP - tức là khoảng 50 chúng tôi trên mạng LAN chuyên dụng nhưng không biết PTP. Tôi nhớ lại việc nhận được độ chính xác dưới micro giây từ một ông chủ CTNH trên một kết nối trực tiếp (không có công tắc ở giữa) và máy khách chỉ có SW (trên PTP PC không biết PTP). So với NTP, servo của PTP hội tụ nhanh hơn nhiều.

Trong khi thực hiện một số "bài tập về nhà", gần đây tôi nhận thấy rằng việc vận chuyển PPS hoặc tín hiệu thời gian "rời rạc" tương tự trên các tuyến cáp quang diện rộng có thể dễ bị "đi lang thang" phụ thuộc vào nhiệt độ. Và mặc dù tôi không có cách nào để thử nghiệm điều này bằng thực nghiệm, một số nguồn trong các trích dẫn của các bản interwebs nằm trong khoảng từ 40 đến 76 picos giây mỗi km và Kelvin. Lưu ý rằng mặc dù loại "giang hồ nhiệt" này không thể giảm thiểu "trong băng" trong truyền PPS đơn giản, PTP sẽ bù lại điều này vốn có, dựa trên các phép đo độ trễ đường chuẩn của nó (phụ thuộc vào truyền song công hoàn toàn).

Quá nhiều cho một cái nhìn tổng quan về "các phần" trông như thế nào, tại các công nghệ / giao diện thời gian khác nhau. Mức độ chính xác nào đủ tốt cho bạn, điều đó phụ thuộc vào ứng dụng của bạn, vào nhu cầu thực tế của bạn.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.