đo độ trễ một chiều / jitter / mất gói


10

Tôi đang tăng độ trễ và StDev do tắc nghẽn tuyến đường và mất gói , nhưng đường dẫn chuyển tiếp và ngược lại đi qua các mạng khác nhau (ví dụ: một là init7.net, một mạng khác là he.net), vì vậy, rất khó hiểu mạng hoặc máy chủ nào chịu trách nhiệm cho sự tắc nghẽn, mất gói, jitter và độ trễ tăng.

Có cách nào để thu hẹp sự đổ lỗi sau khi chuyển tiếp và đảo ngược mtrkhông xác định chính xác thủ phạm và các liên hệ NOC @ không trả lời hoặc tuyên bố không bị tổn thất trên đường đi trong câu hỏi? (Tôi đang sử dụng OpenBSD.)

Tôi thậm chí đã thử mtrtrực tiếp làm việc với một số khách hàng của cả hai mạng có thể gặp phải sự cố tắc nghẽn, nhưng thực sự không thể tìm thấy bất kỳ vấn đề nào theo cách đó, đặc biệt là, ví dụ, he.net có nhiều POP và đôi khi các tuyến khác nhau được thực hiện giữa một mục nhập và thoát POP nhất định, vì vậy khi tôi cố gắng truy cập mtrmáy chủ của họ (như tserv) tại POP thoát mà tôi có thể bị mất các gói trong mạng của họ, một đường dẫn he.net khác được đưa đến POP rất giống nhau và không xảy ra mất gói, điều này chứng tỏ không có gì đáng quan tâm (ngoài một gợi ý có thể là chúng thực sự có thể làm quá tải một số tuyến, trong khi đảm bảo các tuyến khác không bị kiểm soát, tất cả đều bỏ qua các yêu cầu NOC @ từ những người không phải là khách hàng).


Có câu trả lời nào giúp bạn không? nếu vậy, bạn nên chấp nhận câu trả lời để câu hỏi không xuất hiện mãi mãi, tìm kiếm câu trả lời. Ngoài ra, bạn có thể cung cấp và chấp nhận câu trả lời của riêng bạn.
Ron Maupin

Câu trả lời:


9

Một cách để làm điều này là Dấu thời gian ICMP, tức là mili giây từ nửa đêm UTC. Nó có thêm lợi ích mà bạn không nhất thiết phải kiểm soát cả hai đầu, miễn là đầu xa không được tường lửa, rất có thể nó sẽ hoạt động.

Tuy nhiên, để có các phép đo một chiều đáng tin cậy, bạn cần có thời gian đáng tin cậy ở cả hai đầu. Vì dấu thời gian ICMP chỉ có độ chính xác 1ms (gần như không đủ cho nhiều ứng dụng, nhưng đủ cho điều này), thật dễ dàng tìm thấy ngay cả các máy chủ không hợp tác trong đó dấu thời gian ICMP sẽ cung cấp dữ liệu hữu ích.

Nếu bạn kiểm soát cả hai đầu, hãy chắc chắn rằng bạn đang đồng bộ hóa NTP với chỉ 1 máy chủ và cùng một máy chủ. Đồng hồ tuyệt đối không quan trọng lắm, điều quan trọng là bạn trải nghiệm càng gần thời gian càng tốt.

Nếu dấu thời gian ICMP không đủ, bạn có thể dễ dàng viết 10 dòng ruby ​​/ perl / python hoặc thậm chí C để thực hiện các phép đo khi bạn điều khiển cả hai đầu.

Tôi thực sự không thể đề xuất phần mềm để thực hiện các phép đo dấu thời gian ICMP một cách đơn phương, hping2 hỗ trợ gửi dấu thời gian ICMP nhưng vì một số lý do không tạo ra các giá trị đơn hướng. Tôi đã viết bản vá cho hping2 để hiển thị độ trễ một chiều.


Wow, hping --icmp-tssố học thêm của bạn rất tuyệt vời! Quá lười biếng để lấy các nguồn và biên dịch lại nhị phân, tôi đã có cho mình một phiên bản shell của bản vá hping của bạn ( stackoverflow.com/q/20172028/1122270 ) và nó cho thấy thời gian khá dài liên tục trên đường init7 đến hetzner và một phương sai tất cả trên bản đồ với đường dẫn he.net từ hetzner! Cuối cùng tôi đã có bằng chứng chắc chắn rằng init7 đang nói sự thật! Mặc dù tôi tranh luận về việc sử dụng cùng một máy chủ ntp chỉ vì điều này: chỉ cần đảm bảo rằng một ntpd còn sống (tôi hoàn toàn không phải thay đổi bất kỳ cài đặt nào, nhưng các giá trị trông có vẻ hợp lý).
cnst

1
Nếu bạn quan tâm đến thời gian treo tường chính xác, bạn sẽ muốn có ít nhất 3 máy chủ NTP (Để có thể phát hiện mã đánh dấu sai, 2 máy chủ NTP là tùy chọn tồi tệ nhất bạn có thể làm). Nhưng ở đây chúng tôi không quan tâm đến thời gian treo tường, chúng tôi quan tâm đến việc đánh dấu chính xác vào cùng một đồng hồ, bất kể tường. Vì vậy, đối với kết quả đo tối ưu 1 chiều đến từ đồng hồ chính xác, thời gian treo tường không liên quan. Rất vui khi biết bạn có kết quả!
ytti
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.