Đồng bộ thời gian trong phòng lab mạng: khi nào NTP chưa đủ cho timestamp

Nếu bài đo chỉ cần biết sự cố xảy ra trong phút nào, NTP ổn định có thể phù hợp. Nếu cần tính one-way delay theo millisecond hoặc xác định thứ tự giữa link-down, BFD timeout và FIB update, yêu cầu chặt hơn. Clock uncertainty phải nhỏ đáng kể so với ngưỡng đo; sai số 20 ms không phù hợp để kết luận outage 5 ms.

Xác định các câu hỏi: cần absolute time hay chỉ relative time; các điểm đo có cùng thiết bị/clock không; timestamp được tạo trong application, kernel, NIC hay thiết bị đo; kết quả dùng để trend hay pass/fail. Một traffic generator dùng chung clock cho TX/RX có thể đo relative outage tốt dù không đồng bộ tuyệt đối với UTC, nhưng ghép với log DUT vẫn cần mapping và uncertainty.

Vẽ cây thời gian gồm reference, time server/grandmaster, boundary/transparent clock nếu có, client và hệ thống giám sát. Tách management network cho time traffic khi cần; tránh để congestion của bài tải làm hỏng chính hệ thống timestamp. Ghi stratum, source ID, path, polling, domain, profile và cơ chế failover.

Thiết kế ít nhất hai nguồn độc lập khi timeline là bằng chứng nghiệm thu. Hai server cùng phụ thuộc một upstream không phải hai failure domain. Với PTP, xác định grandmaster election, boundary clock và đường multicast/unicast. Với NTP, tránh client lấy thời gian từ nguồn không kiểm soát hoặc thay đổi tùy lúc.

RFC 5905 mô tả NTPv4 và thuật toán đồng bộ qua mạng IP. Hiệu quả thực tế phụ thuộc path delay, asymmetry, server quality, polling, hệ điều hành và tải. NTP phù hợp với nhiều bài log/telemetry, nhưng phải đo offset và jitter thay vì dựa vào biểu tượng “sync”.

PTP thường được chọn khi cần độ chính xác cao hơn và hạ tầng hỗ trợ. Hardware timestamp đưa thời điểm lấy dấu gần cổng mạng hơn, giảm biến thiên do scheduler và software stack. Tuy nhiên PTP không tự nhiên chính xác: profile, domain, grandmaster, boundary/transparent clock, asymmetry và NIC/driver vẫn phải được cấu hình, kiểm chứng.

Đây là hướng thiết kế, không phải cam kết độ chính xác. Con số chỉ có ý nghĩa khi đo trong topology thật.

• Nhu cầu: Ghép log theo giây · Hướng ban đầu: NTP · Điều kiện xác nhận: offset/jitter ổn định
• Nhu cầu: Timeline sự cố vài chục ms · Hướng ban đầu: NTP kiểm soát hoặc PTP · Điều kiện xác nhận: uncertainty nhỏ hơn ngưỡng
• Nhu cầu: One-way latency cấp ms · Hướng ban đầu: PTP/hardware timestamp thường phù hợp hơn · Điều kiện xác nhận: calibration và path asymmetry
• Nhu cầu: Packet timestamp độ phân giải cao · Hướng ban đầu: clock chung hoặc PTP + NIC hỗ trợ · Điều kiện xác nhận: kiểm tra timestamp source
• Nhu cầu: Relative loss trên một chassis · Hướng ban đầu: clock nội bộ thiết bị đo · Điều kiện xác nhận: mapping khi ghép log ngoài

Ghi source, protocol/profile, network path, QoS, delay asymmetry, poll interval, servo, leap handling, timezone display và timestamp format. UTC và local time cần được phân biệt; lưu dữ liệu gốc bằng UTC và chỉ chuyển múi giờ ở lớp hiển thị để giảm lỗi daylight saving hoặc parsing.

Virtual machine có thêm hypervisor scheduling và virtual clock. Container thường dùng clock host nhưng application timestamp vẫn chịu scheduler. Thiết bị có nhiều clock domain giữa control plane, line card, NIC và capture engine; cần biết log nào lấy từ đâu.

Tải CPU, congestion, packet loss của time traffic, reboot và failover có thể làm offset thay đổi. Do đó kiểm thử clock phải chạy cả trước, trong và sau workload, không chỉ lúc lab rảnh.

KPI gồm offset so với reference, jitter/variation, frequency drift, time to synchronize, maximum excursion, holdover drift, packet delay variation và availability của source. Với timeline, thêm uncertainty budget cho từng nguồn timestamp.

Ma trận tối thiểu:

Pass/fail ví dụ: offset tuyệt đối dưới ngưỡng dự án trong 99,9% cửa sổ; maximum excursion không vượt ngân sách; failover không tạo time step làm đảo thứ tự event; sau phục hồi clock hội tụ trong thời gian quy định. Ngưỡng phải được thiết kế theo bài đo.

• Cold start và thời gian đạt trạng thái usable.
• Steady state khi lab không tải.
• Tải CPU/network cao đồng thời.
• Mất primary source, chuyển secondary và failback.
• Mất mạng management/time distribution.
• Reboot client, server hoặc grandmaster.
• Holdover 5/30/60 phút tùy yêu cầu.
• Route asymmetry hoặc thay đổi path.
• Leap/event handling nếu phạm vi cần.

Không dùng timestamp đã được format mất phần thập phân cho bài đo millisecond. Không sửa clock thủ công giữa test nếu không đánh dấu sự kiện.

• Lập inventory thiết bị, clock source và timestamp source.
• Chuẩn hóa UTC, format có timezone và precision cố định.
• Kiểm tra source selection, offset, delay và health.
• Dùng reference độc lập hoặc loop measurement để xác minh.
• Chạy baseline đủ dài để thấy drift và polling cycle.
• Tạo workload mạng/CPU đại diện, tiếp tục đo offset.
• Ngắt primary source có kiểm soát; ghi failover và holdover.
• Khôi phục, kiểm tra time step/slew và event ordering.
• Xuất raw data, cấu hình và uncertainty budget.

Dựng các mốc T0 tạo fault, T1 link/keepalive phát hiện, T2 protocol update, T3 FIB thay đổi, T4 packet đầu tiên nhận lại và T5 KPI ổn định. Với mỗi mốc, ghi nguồn timestamp, precision và uncertainty. Nếu khoảng cách T2–T3 nhỏ hơn tổng uncertainty của hai nguồn, chỉ có thể nói các sự kiện gần đồng thời, không khẳng định thứ tự.

Ưu tiên TX/RX sequence và timestamp cùng clock để tính packet outage. Dùng log DUT để giải thích cơ chế. Nếu log control plane chỉ có độ phân giải một giây, không dùng nó để xác nhận outage 10 ms.

Khi offset tăng theo tải, kiểm tra QoS/path cho time traffic, CPU starvation và software timestamp. Khi offset thay đổi theo hướng, kiểm tra asymmetry. Khi clock nhảy sau failover, xem servo/step policy và source quality. Không “chỉnh số” trong báo cáo; giữ raw timestamp và tài liệu hóa correction nếu thực sự cần.

Vận hành nên có dashboard source, offset, last sync, drift và alarm; lưu cấu hình, firmware và calibration. Trước mỗi campaign, chạy pre-flight time check. Sau thay switch, hypervisor, NIC driver hoặc topology, chạy regression.

“NTP synchronized” là trạng thái giao thức/daemon, không phải chứng thư độ chính xác end-to-end. PTP có hardware support cũng không loại bỏ asymmetry và calibration error. Độ phân giải hiển thị không đồng nghĩa accuracy.

Kết quả chỉ áp dụng cho source, path, tải, thiết bị và thời gian quan sát đã thử. Khi công bố outage hoặc one-way latency, kèm uncertainty và phương pháp timestamp.