Độ trễ cao lẻ tẻ trên mạng gia đình của tôi


1

tl; dr Mạng gia đình của tôi gần đây đã trải qua các bước nhảy từ độ trễ 27ms đến 600ms. Nó không xảy ra luôn, và dường như xảy ra thường xuyên vào ban đêm. Tôi nên mua thiết bị gì và nên chạy thử để suy ra nguyên nhân?

Thiết lập

Nhà tôi có DSL 12Mb / 800kb. Tôi sống ở vùng núi, cách xa các nguồn Wi-Fi khác. Trong lịch sử (trong nhiều năm) tôi có thể ping google.com và nhận được ~ 27ms lần. Nếu có thứ gì đó làm ngập mạng hoặc kết nối (iPhone đồng bộ hóa tất cả ảnh với iCloud), các lệnh ping sẽ nhảy vào phạm vi 2000-6000ms. Nhưng bình thường mọi thứ đều tốt.

Tuy nhiên, gần đây, mạng vẫn bị chặn khoảng 600ms trong hàng chục phút mỗi lần. Tôi không thể tìm thấy bất kỳ thiết bị nào đang tràn ngập mạng. (Nó có thể tồn tại, nhưng tôi không tìm thấy nó.) Kết nối nói chung hoàn toàn tốt vào buổi sáng và nói chung là rất tệ vào ban đêm (ngay khi chúng tôi muốn phát trực tuyến trên giường!)

Trong thời gian trễ cao, ping đến các thiết bị khác trên mạng (một số mà tôi đã thử) không thay đổi (luôn luôn & lt; 2ms).

Thất bại và khó hiểu Khắc phục sự cố

Tôi đã mua tất cả phần cứng mới (modem DSL, bộ định tuyến Wi-Fi, bộ chuyển mạch mạng) để loại trừ. Vấn đề vẫn tồn tại. Đây là thiết lập:

Phrogz's home network

Tôi đã thử sử dụng Modem DSL làm bộ định tuyến (PPPoE + DHCP + NAT) với các trạm gốc Wi-Fi ở chế độ cầu. Tôi đã thử đặt Modem DSL ở chế độ Cầu nối trong suốt và có Airport Extreme đầu tiên xử lý PPPoE, DHCP và NAT. Vấn đề vẫn tồn tại.

Tôi đã ngắt kết nối tất cả các kết nối có dây (chỉ để lại modem DSL và trạm gốc Wi-Fi). Vấn đề vẫn tồn tại.

Tôi chỉ sử dụng Modem DSL (với PPPoE) và sử dụng Wi-Fi của riêng mình. Vấn đề vẫn tồn tại. Tôi đã cố gắng săn lùng mọi máy tính bảng, điện thoại, máy tính xách tay cũ trên Wi-Fi và tắt chúng đi. Vấn đề vẫn tồn tại. Tôi đã đổi tên SSID Wi-Fi và đặt mật khẩu cho nó, kết nối một máy tính xách tay MacBook Pro qua Wi-Fi. Vấn đề vẫn tồn tại. Tôi đã sử dụng một máy tính xách tay khác qua Wi-Fi. Vấn đề vẫn tồn tại.

Tôi đã kết nối máy tính xách tay trực tiếp với modem qua Ethernet, với Wi-Fi bị tắt trên modem và không có gì khác được kết nối. Vấn đề biến mất! .

Tại một thời điểm, chỉ với một máy tính xách tay được kết nối qua Ethernet, tôi đã bật Wi-Fi cho modem và vấn đề thể hiện chính nó . Độ trễ Ping ngay lập tức tăng vọt ngay khi tôi bật Wi-Fi, mặc dù tôi không tin rằng mọi thiết bị đều được kết nối qua Wi-Fi.

tôi đã sử dụng iStumbler và dường như không có bất kỳ mối tương quan nào giữa độ trễ xấu và tăng tiếng ồn. Thật vậy, SNR có vẻ ổn định qua Wi-Fi.

Hãy nhớ rằng khi mọi thứ tồi tệ, họ không LUÔN xấu. Ngay cả khi mọi thiết bị trong nhà được bật và kết nối, có những lúc độ trễ sẽ giảm xuống 30ms hoặc lâu hơn trong vài giây (hoặc vài phút hoặc vài giờ) trước khi trở lại tồi tệ.

Bước tiếp theo?

tôi suy nghĩ iStumbler đã cho tôi thấy rằng vấn đề không liên quan đến các vấn đề RF. (Có lẽ tôi sai?) Vì vậy, tôi nghĩ đó phải là lưu lượng truy cập thực trên mạng.

Trạm cơ sở Extreme Extreme không hỗ trợ bất kỳ loại ghi nhật ký SNMP nào. Actiontec C1000A cũng không. Tôi không có công tắc với cổng màn hình hoặc trung tâm. Tôi chưa bao giờ sử dụng Wireshark trước đây.

NHƯNG TÔI SILL TIỀN VÀO TIỀN VÀ THỜI GIAN TẠI VẤN ĐỀ NÀY ĐỂ GIẢI QUYẾT

Tôi nên mua cái gì? Tôi nên tiêm nó vào đâu? Tôi nên tìm cái gì? Làm cách nào tôi có thể xem mọi gói trên mạng và xây dựng biểu đồ và đồ thị để xác định xem một thiết bị xấu có làm hỏng tình hình cho mọi người không?


Chỉnh sửa 1 : Thống kê DSL khi mọi thứ đều ổn

+-----------------+-------------+
|   Connection    |   Status    |
+-----------------+-------------+
| DSL Downstream: | 15.869 Mbps |
| DSL Upstream:   | 0.896 Mbps  |
+-----------------+-------------+

Thống kê liên kết DSL

+------------------------------+---------------------+
|        Link Statistic        |       Status        |
+------------------------------+---------------------+
| Broadband Mode Setting:      | Auto Select         |
| Broadband Mode Detected:     | VDSL2 - 8A          |
| DSL Link Uptime:             | 0 Days, 10H:39M:57S |
| Retrains:                    | 1                   |
| Retrains in Last 24 Hours:   | 1                   |
| Loss of Power Link Failures: | 0                   |
| Loss of Signal Link Failure: | 0                   |
| Loss of Margin Link Failure: | 0                   |
| Link Train Errors:           | 0                   |
| Unavailable Seconds:         | 23                  |
| Estimated Loop Length:       | 2250                |
| Uncanceled Echo:             | N/A                 |
| Transport Mode:              | PTM                 |
| Path Parameter:              | 201                 |
| Priority:                    | 0                   |
| Service Type:                | PTM-Tagged          |
+------------------------------+---------------------+

Nguồn DSL

+--------------+-------------------------+------------------------+
|    Levels    |       Downstream        |        Upstream        |
+--------------+-------------------------+------------------------+
| SNR:         | 16 dB                   | 10 dB                  |
| Attenuation: | (DS1)21.7, (DS2)58.8 dB | (US1)4.3, (US2)47.8 dB |
| Power:       | 16.4 dBm                | 7.8 dBm                |
+--------------+-------------------------+------------------------+

Vận tải DSL

+----------------------+------------------+---------------+
|      Transport       |    Downstream    |   Upstream    |
+----------------------+------------------+---------------+
| Packets:             | 1482864          | 1088249       |
| Error Packets:       | 0                | 0             |
| 24 Hour Usage:       | 1225940.68 Mbits | 2420.93 Mbits |
| Total Usage:         | 1225940.68 Mbits | 2420.93 Mbits |
| 30 Minute Discarded: | 0                | 3930          |
+----------------------+------------------+---------------+

Kênh DSL

+----------------+-------------+-------------+
|    Channel     |  Near End   |   Far End   |
+----------------+-------------+-------------+
| Channel Type:  | Interleaved | Interleaved |
| CRC Errors:    | 0           | 0           |
| 30 Minute CRC: | 0           | 0           |
| RS FEC:        | 5873        | 29          |
| 30 Minute FEC: | 372         | 0           |
+----------------+-------------+-------------+

Chỉnh sửa 2 : Báo cáo về bộ đệm của DSLR

Chạy speedtest trong thời gian trễ bình thường khác cho thấy sự cố xảy ra trong quá trình tải lên

Graph showing bad bufferbloat during uploading


Ping lần vào ban đêm và qua đêm

Sự tăng đột biến vào khoảng 10:35 tối là một máy tính bắt đầu tải lên Dropbox.

enter image description here

enter image description here


Chỉnh sửa 3 : Hỗ trợ kỹ thuật của ISP cho biết:

Modem đang nhận được nhiều tín hiệu hơn. Nếu cáp không đủ để mang tải chúng tôi đang gửi, chúng tôi có thể hạ nó xuống 100%. Để kiểm tra điều này là để tôi hạ tín hiệu xuống trong 7 ngày và bạn có thể quan sát xem trình duyệt \ internet có tốt hơn không. Sau 7 ngày, máy chủ của chúng tôi sẽ chạy thử nghiệm và sẽ tăng tín hiệu của bạn lên một lần nữa. Và đến lúc đó chúng ta sẽ có đủ số liệu phải làm gì tiếp theo.

Máy chủ của chúng tôi đang cung cấp cho bạn nhiều hơn so với mua hàng của bạn. Về mặt kỹ thuật, điều này sẽ làm cho internet nhanh hơn nhưng nếu ping và sự chậm trễ gây ra bởi lưu lượng truy cập được quan sát bởi khách hàng. Chúng tôi có thể đưa tín hiệu đến tốc độ đã mua \ và quan sát xem đường DSL trên tiền đề của khách hàng có phải là cáp để mang tải không.

Tốc độ thực tế / được cung cấp / mua
Xuống: 15868/15872 / 12128Mbps
Lên: 896/896/896kbps


Bạn đã thử sử dụng máy chủ DNS nhanh hơn chưa? Ngay cả với iPhone của bạn đồng bộ hóa không dây, những lần ping đó không thực sự được giải thích.
Ramhound

Modem đã được thay thế? Đó là modem gì? Số liệu thống kê ADSL của bạn là gì?
Linef4ult

@ Linef4ult Có, tôi đã thay thế modem. Đó là Actiontec Q1000 và tôi đã thay thế nó bằng Actiontec C1000A. Hiện tại tôi không ở nhà, nhưng khi tôi đến đó: bạn có thể vui lòng làm rõ loại thống kê ADSL nào bạn đang tìm kiếm không?
Phrogz

Số liệu thống kê của nó. Một liên kết xuống cấp đến DSLAM (modem ở phía ISP của bạn) có thể gây ra một loạt lỗi và do đó các vấn đề không liên tục như thế này. Pastebin nội dung của trang trông như thế này: Screenscreen.portforward.com/routers/Actiontec/
Linef4ult

@ Linef4ult Cảm ơn bạn! Sẽ làm trong ~ 7 giờ. Tôi hy vọng đây là trường hợp (đó là lỗi của nhà cung cấp / đường dây). Thực tế là tôi nghĩ Tôi đã thấy một tình huống trong đó Ethernet chỉ khắc phục sự cố và thêm Wi-Fi khiến nó trở nên tồi tệ với FUD rằng vấn đề thuộc về tôi. Chúng ta sẽ thấy!
Phrogz

Câu trả lời:


2

Điều gì đó không đúng. Thống kê 24 giờ cho biết:

Giảm 312.600 MB Tăng lên 250.500 Mbyte

Bạn đã không bao gồm tỷ lệ liên kết nhưng 8.000 ở 2KM có thể cung cấp cho bạn một liên kết 15/5. Ở mức 5Mb US, bạn chỉ có thể tải lên khoảng 55GB / 24 giờ. Ngay cả ở mức 10Mb, bạn sẽ không đạt 250GB, vì vậy đừng tin vào những thống kê đó.

Tuy nhiên, điều này nghe có vẻ như ngang hàng / đồng bộ hóa / phần mềm độc hại trên mạng của bạn là tự DOS.

CẬP NHẬT:

Kết nối của bạn được cân bằng như kết nối ADSL kiểu cũ (8D 0,5U, 12D 0,7U, 15D 1U) so với những gì bạn thường làm với VDSL (2) (15D, 3U). Điều này khiến bạn rơi vào tình huống rất dễ dàng làm tắc nghẽn liên kết của chính bạn.

Bất cứ điều gì chạy trên mạng của bạn có thể gây ra một hàng đợi ngược dòng trong đó modem chứa một loạt các khung đang cố gửi nhưng đang đến nhanh hơn nó có thể chuyển tiếp chúng. Vì vậy, ví dụ thay vì 1ms từ máy tính xách tay của bạn đến modem, 20ms từ modem để trao đổi, 5 ms từ trao đổi đến trang web bạn có: 1ms từ bạn đến modem, 100ms chờ trong bộ đệm khung, 20ms để trao đổi và 5ms đến trang web. Càng gửi nhiều, thời gian chờ càng lớn.

Những điều cần tìm: Peer to Peer (bit torrent, launcher trò chơi) Đồng bộ hóa ứng dụng: Windows 7/8/10 One Drive, Dropbox (đặc biệt là Camera Sync), iCloud Sao lưu ngoại vi như Crashplan / Backblaze vv Ứng dụng cuộc gọi video / VOIP: Skype, TS / Mumble

Bất cứ điều gì gửi dữ liệu ra web.


+1 Đây là một điểm rất tốt. Cách sử dụng ngược dòng của anh ấy khá giống với hạ lưu của anh ấy và tôi tin rằng điều đó khá hiếm đối với hầu hết người dùng trừ khi bạn đang làm một việc gì đó nặng nề như gieo nhiều dòng chảy hoặc thực hiện sao lưu trực tuyến hoặc đồng bộ hóa lớn hoặc một cái gì đó.
Spiff

@ Spp ? (Tôi sẽ đi tìm máy như một vấn đề riêng biệt.)
Phrogz

"Đôi khi sai" của bạn có vẻ đúng. Tôi tự hỏi liệu có phải vì modem DSL đang ở chế độ Cầu nối trong suốt tại thời điểm mà nó dừng ghi lại mọi thứ một cách chính xác. Tối nay tôi sẽ thiết lập lại nó, di chuyển PPPoE / DHCP / NAT trở thành trách nhiệm của nó (thay vì Airport Extreme) và xem liệu điều đó có làm cho các số liệu thống kê không điên rồ không. (Điều đó cũng sẽ giúp tôi dễ dàng lấy các số liệu thống kê tại thời điểm mạng ở trạng thái xấu thay vì tốt.)
Phrogz

@Phrogz ISP của bạn đã nói gì? Các thử nghiệm của họ từ MTAU sẽ nhận phần lớn các lỗi đồng để chúng tôi có thể loại trừ điều đó trong hoặc ngoài.
Linef4ult

@ Linef4ult Tôi đã thêm số liệu thống kê đường DSL cập nhật vào câu hỏi của mình và cũng đã thêm, ở phía dưới, ISP nói gì. Họ thấy không có vấn đề gì với đường dây ngoại trừ việc cung cấp quá mức, hiện tại họ đã bỏ qua để xem nó có giúp ích gì không.
Phrogz

1

Các triệu chứng bạn đã báo cáo nghe giống như sự cố bộ đệm, trong đó bộ định tuyến, modem DSL hoặc bộ đệm DSLAM của ISP của bạn có quá nhiều gói khi liên kết bị nghẽn, dẫn đến độ trễ cao. Thông thường, TCP tìm kiếm các khung hình bị rơi làm bằng chứng tắc nghẽn và tắt. Nhưng nếu bộ định tuyến hoặc modem hoặc bộ đệm DSLAM của bạn mãi mãi và không bao giờ làm giảm khung hình, bạn sẽ bị tăng độ trễ rất lớn mà không có TCP có cơ hội lùi lại để giải tỏa tắc nghẽn. Bạn không bao giờ nên tăng độ trễ lớn chỉ vì băng thông ngược dòng hoặc hạ lưu của bạn đã bão hòa. Nếu bạn làm như vậy, bạn gần như chắc chắn có bộ đệm.

Chạy công cụ kiểm tra tốc độ dslreports.com . Không giống như các công cụ kiểm tra tốc độ khác, công cụ này cũng đo lường và báo cáo các sự cố bộ đệm, có thể gây ra độ trễ cao bất cứ khi nào có thứ gì đó sử dụng tất cả băng thông xuôi dòng hoặc ngược dòng của bạn (như khi bạn quyết định truyền phát video vào ban đêm).

Thực tế là bạn đã chứng minh rằng độ trễ của bạn nhảy khi có thứ gì đó đang sử dụng tất cả băng thông tải lên của bạn (ví dụ đồng bộ hóa iCloud Photo) là một dấu hiệu tốt cho thấy bạn đang gặp vấn đề về bộ đệm.

Modem DSL của bạn có thể là nguồn gốc của bất kỳ vấn đề bộ đệm ngược dòng nào. Một giải pháp có thể là mua modem DSL được biết là không có vấn đề về bộ đệm. Tôi chưa nghiên cứu thị trường này, vì vậy tôi không thể giúp bạn với bất kỳ đề xuất nào. Google-fu của bạn có lẽ tốt như của tôi.

Ngoài ra, hãy xem xét việc mua một cổng nhà có thể chạy CeroWrt, OpenWrt hoặc DD-WRT, tất cả hiện có các công nghệ chống đệm như FQ_CoDel được tiên phong / phát triển đầu tiên trong CeroWrt. Bằng cách sử dụng một hộp như thế để hạn chế một cách giả tạo băng thông ngược dòng và hạ lưu của bạn xuống một cái gì đó khinh bỉ chậm hơn so với những gì liên kết DSL của bạn thực sự có khả năng và có hộp đó thực sự thả khung gửi thông báo giải thích tắc nghẽn (110

Bạn không nhất thiết phải bỏ modem DSL hoặc AirPort Extreme của mình để cài đặt hộp * Wrt này; bạn có thể cài đặt nó dưới dạng hộp có dây giữa modem DSL và AirPort Extreme đầu tiên của bạn. Chỉ cần đảm bảo rằng tất cả lưu lượng truy cập đến / từ mạng gia đình của bạn đi qua hộp này. Đó là, đảm bảo bạn không có bất kỳ thiết bị nào được gắn trực tiếp vào modem DSL ngoài hộp * Wrt này.

Nếu bạn biết bạn có bộ đệm, có lẽ bạn nên loại bỏ nó trước khi tìm kiếm các nguồn tiềm ẩn khác của độ trễ, nếu không nó sẽ cản trở nỗ lực của bạn để tìm các nguồn trễ khác.


Điều này có vẻ như nó có thể được tại chỗ. Xem biểu đồ được thêm vào cuối câu hỏi của tôi: khi mạng hoạt động bình thường, tôi chạy các báo cáo DSL và nó hiển thị bộ đệm xấu khi tải lên. Vấn đề này có thể đứng về phía ISP? Vấn đề bắt đầu sau khi mất điện và dịch vụ; họ có thể khắc phục vấn đề kém?
Phrogz

@Phrogz Bufferbloat tồn tại trên thiết bị nơi hàng đợi bộ đệm được xây dựng, thường nằm trên hộp cuối cùng trước liên kết chậm nhất. Liên kết chậm nhất thường là liên kết băng thông rộng của bạn đến ISP của bạn. Vì vậy, bộ đệm tải lên của bạn có thể nằm trong modem DSL của bạn. Cách duy nhất mất điện có thể đã kích hoạt điều này là nếu tình trạng đường dây điện thoại của bạn trở nên tồi tệ hơn sau khi dịch vụ được khôi phục, khiến việc tải lên chậm hơn và do đó dễ bị quá tải.
Spiff

Cảm ơn, Spiff. Chẩn đoán của bạn đang tìm kiếm nhiều khả năng. Tôi đã cấu hình lại mạng để modem DSL đang thực hiện PPPoE / NAT / DHCP (nhưng không có Wi-Fi) và đặt tất cả các AP Wi-Fi khác vào chế độ bắc cầu. Tôi đã kết nối một máy tính trực tiếp với modem qua Ethernet. Khi sự cố xảy ra với chính nó (500ms ping nhìn thấy trên máy tính được kết nối trực tiếp đó), tôi đã kéo cáp Ethernet đến phần còn lại của mạng. Ngay lập tức vấn đề trở nên tốt hơn. Vì vậy, bây giờ tôi vẫn cần tìm ra cách xác định thủ phạm trong nhà, và sau đó tiêm một hộp OpenWRT vào mạng của tôi.
Phrogz

1
@Phrogz Nếu tôi là bạn, tôi sẽ sử dụng một công tắc gigabit nhỏ có thể quản lý được, hỗ trợ phản chiếu cổng (như Netgear GS105Ev2 với giá 40 đô la) và cắm nó vào giữa modem / cổng DSL Actiontec C1000A và AirPort Extreme đầu tiên, và sử dụng phản chiếu cổng và máy chạy Wireshark để nắm bắt tất cả lưu lượng truy cập đến / từ Internet. Để có kết quả tốt nhất, hãy giữ C1000A ở chế độ NAT và AirPort Extreme ở chế độ cầu trong quá trình thử nghiệm này, theo cách đó, địa chỉ IP của hộp thủ phạm sẽ không bị ẩn sau NAT của AirPort Extreme.
Spiff

Roger đó, Spaceman Spiff. Cảm ơn đã bao gồm một mô hình cụ thể hỗ trợ phản chiếu. Khó chịu khi nó yêu cầu Windows bật nó, nhưng đó là một cái giá nhỏ để trả cho kiến ​​thức.
Phrogz
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.