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.