Tóm tắt nhanh
- Tốc độ tải cao chỉ cho thấy đường truyền tới máy chủ đo truyền dữ liệu nhanh tại thời điểm kiểm tra, không bảo đảm mọi ứng dụng đều phản hồi tốt.
- Cần so sánh độ trễ lúc mạng rảnh với lúc tải xuống hoặc tải lên, rồi tách lỗi Wi-Fi khỏi lỗi đường truyền bằng kết nối dây.
- SQM xử lý hàng đợi khi tải nặng; Airtime Fairness và lựa chọn băng tần xử lý vấn đề chia sẻ sóng, còn DNS liên quan đến phân giải tên miền.
- Với mạng gia đình, bằng chứng về vị trí và thời điểm phát sinh lỗi hữu ích hơn một ảnh chụp Speedtest để quyết định nâng gói cước.
Wi-Fi đạt hàng trăm Mbps vẫn có thể khiến cuộc họp trực tuyến ngắt tiếng hoặc nhân vật trong game phản hồi chậm khi một thiết bị khác bắt đầu truyền dữ liệu. Mâu thuẫn nằm ở cách đọc kết quả: tốc độ tải cho biết lượng dữ liệu đi qua trong một khoảng thời gian, còn độ trễ cho biết gói tin phải chờ bao lâu.
Vì vậy, nên dùng Speedtest làm một phần của quá trình chẩn đoán thay vì coi con số lớn nhất là kết luận về cả mạng gia đình. Điều cần tìm là lỗi xảy ra trên đoạn kết nối nào, trong điều kiện nào và có lặp lại được hay không.
Phép đo Internet không phải phép đo riêng Wi-Fi
Speedtest trên điện thoại đo cả đường đi tới máy chủ thử nghiệm, trong đó Wi-Fi chỉ là chặng kết nối từ điện thoại đến điểm truy cập. Sau đó dữ liệu còn đi qua router, đường truyền nhà mạng và mạng dẫn tới máy chủ. Bởi vậy, kết quả thấp chưa đủ để kết luận Wi-Fi yếu, cũng như kết quả cao không chứng minh mọi đường đi khác đều thông suốt.
Các luồng tải liên tục có lợi cho việc đo thông lượng, tức lượng dữ liệu thực sự truyền được, nhưng khác với những gói tin nhỏ cần đến đúng lúc trong game hoặc cuộc gọi. Một máy chủ đo ở gần cũng không đại diện cho máy chủ game ở xa hay mọi dịch vụ mà trình duyệt phải kết nối khi mở trang web.
Cũng không nên hiểu rằng ứng dụng đo tốc độ hoàn toàn bỏ qua độ trễ. Một số công cụ hiển thị ping, jitter hoặc độ trễ khi tải; vấn đề là người dùng thường chỉ nhìn Mbps. Ping phản ánh thời gian khứ hồi, còn jitter phản ánh mức biến động của độ trễ: đường truyền có lúc phản hồi nhanh, lúc phải chờ lâu vẫn có thể gây khó chịu dù tốc độ tải trung bình cao.
Giữ lại tên máy chủ đo và điều kiện đo sẽ giúp lần so sánh sau có ý nghĩa hơn. Nếu đổi cả thiết bị, vị trí và máy chủ cùng lúc, rất khó biết thay đổi nào thực sự khiến kết quả tốt lên.
Độ trễ khi tải mới bộc lộ hàng đợi quá dài
Bufferbloat đáng nghi nhất khi mạng phản hồi bình thường lúc rảnh nhưng chậm rõ rệt ngay khi đường truyền bị sử dụng hết. Thiết bị mạng giữ quá nhiều gói tin trong hàng đợi, khiến dữ liệu cần phản hồi nhanh phải chờ sau dữ liệu đang truyền, dù tổng lượng dữ liệu mỗi giây vẫn lớn.
Đường tải lên cũng cần được kiểm tra riêng. Một tác vụ sao lưu có thể làm đầy chiều tải lên trong khi người dùng chỉ đang quan sát tốc độ tải xuống; khi ấy nâng mức tải xuống không phải câu trả lời trực tiếp cho hàng đợi đang gây chậm ở chiều còn lại.
Hướng dẫn của FastSpeedTest dùng mức tăng độ trễ trên 100 ms so với lúc rảnh làm dấu hiệu bufferbloat nặng. Đây là ngưỡng tham khảo của hướng dẫn, không phải phép xác định chính xác thiết bị nào có lỗi: hàng đợi có thể nằm ở router, modem hoặc thiết bị trên mạng nhà cung cấp.
Cách kiểm tra thực dụng là ghi lại độ trễ khi không có tác vụ truyền lớn, sau đó đo lại trong lúc tải xuống, rồi trong lúc tải lên. Ưu tiên công cụ đo độ trễ liên tục ngay trong giai đoạn truyền dữ liệu. Nếu chỉ đo ping trước khi bắt đầu tải, kết quả đó không trả lời được mạng có phản hồi tốt khi bận hay không.
Nên lặp lại bằng kết nối Ethernet nếu có máy tính và cổng mạng phù hợp. Cả kết nối dây lẫn Wi-Fi đều tăng độ trễ khi tải là lý do để xem tiếp hàng đợi và đường truyền chung; chỉ Wi-Fi xấu đi thì cần tập trung thêm vào môi trường vô tuyến. Phép so sánh này thu hẹp phạm vi, chưa phải kết luận tuyệt đối.
SQM hữu ích khi giữ được hàng đợi trong tầm kiểm soát
Chấp nhận giảm một phần tốc độ cực đại có thể là đánh đổi hợp lý nếu đổi lại cuộc họp và game không bị gián đoạn khi cả nhà dùng mạng. Smart Queue Management, viết tắt SQM, kiểm soát hàng đợi và phân chia các luồng dữ liệu thay vì để gói tin tích tụ quá lâu; CAKE và fq_codel là những thuật toán thường được nhắc đến trong nhóm giải pháp này.
FastSpeedTest đề xuất bắt đầu với giới hạn tải xuống và tải lên khoảng 90% tốc độ thực đo để chừa khoảng trống cho việc quản lý hàng đợi. Đây là điểm khởi đầu để hiệu chỉnh, không phải cấu hình bảo đảm phù hợp cho mọi đường truyền. Đặt giới hạn vượt tốc độ thực tế sẽ khiến thiết bị khó kiểm soát điểm đang gây tắc.
Cần kiểm tra đúng tính năng mà firmware của router cung cấp. Một mục mang tên QoS hay ưu tiên thiết bị không tự động đồng nghĩa với SQM dùng CAKE hoặc fq_codel, và cũng không có cơ sở hứa rằng bật lên sẽ đưa ping của mọi máy chủ về cùng một mức thấp.
Sau khi thay đổi, đo lại bằng cùng công cụ, cùng máy chủ và cùng kiểu tải. Kết quả đáng giữ là độ trễ khi bận ổn định hơn mà tốc độ còn đủ cho nhu cầu sử dụng; nếu chỉ Mbps giảm nhưng cuộc gọi vẫn ngắt, chưa thể coi cấu hình đó thành công. Không nên mua thêm router chỉ vì nhìn thấy tên tính năng mà chưa xác định lỗi có liên quan đến hàng đợi hay không.
Thiết bị ít dữ liệu vẫn có thể chiếm nhiều thời gian phát sóng
Wi-Fi còn có giới hạn mà nâng gói cước Internet không giải quyết trực tiếp được: các thiết bị phải chia sẻ thời gian sử dụng môi trường vô tuyến. Một thiết bị truyền chậm có thể cần nhiều thời gian hơn để gửi cùng lượng dữ liệu, nên mức tiêu thụ Mbps thấp không có nghĩa ảnh hưởng của nó tới mạng luôn nhỏ.
Airtime Fairness hướng tới phân bổ thời gian phát sóng công bằng hơn giữa các máy khách. Tuy nhiên, không nên hiểu tên tính năng thành lời hứa rằng mọi thiết bị sẽ luôn được chia thời gian bằng nhau hoặc kết nối sẽ tốt hơn trong mọi hoàn cảnh. Cần so sánh trước và sau khi bật, đồng thời kiểm tra các thiết bị cũ có còn hoạt động ổn định không.
Với nhà có nhiều thiết bị thông minh, có thể bố trí thiết bị phù hợp ở băng tần 2,4 GHz và để điện thoại, máy tính hỗ trợ dùng 5 GHz khi vị trí cho phép. Đây là cách phân bổ kết nối theo khả năng thiết bị và điều kiện sóng, không phải lý do để đẩy mọi máy sang 5 GHz bất kể khoảng cách hoặc vật cản.
Tách tên mạng cũng không tự tạo thêm tài nguyên vô tuyến. Nếu các tên mạng vẫn dùng chung một radio và cùng kênh, chúng vẫn phải chia sẻ thời gian phát sóng. Giá trị của việc tách tên trước hết là giúp người dùng biết thiết bị đang kết nối ở đâu và chủ động chọn kết nối phù hợp.
Ứng dụng phân tích Wi-Fi có thể giúp quan sát các mạng xung quanh và kênh đang dùng, nhưng không thay được phép đo trải nghiệm tại vị trí có lỗi. Hãy so sánh ngay cạnh router với nơi thường họp hoặc chơi game: kết nối tốt ở gần nhưng kém ở phòng khác gợi ý cần xem vị trí điểm truy cập và vùng phủ trước khi tăng tiền gói cước.
Đổi DNS chỉ nên nhắm vào độ chậm khi mở kết nối
DNS đáng kiểm tra khi trình duyệt chờ lâu trước khi trang bắt đầu tải, còn dữ liệu đã truyền thì chạy nhanh. DNS phân giải tên miền thành địa chỉ để thiết bị kết nối; nó không phải cơ chế sửa hàng đợi của router hay giải phóng thời gian phát sóng đang bị chiếm dụng.
XDA nêu thời gian phân giải thường dưới 50 ms và có thể kéo dài tới hàng trăm mili giây nếu máy chủ DNS chậm hoặc quá tải. Những con số đó cho thấy vì sao thời gian chờ ban đầu có thể đáng chú ý, nhưng không phải bằng chứng DNS mặc định của mọi nhà mạng Việt Nam đều chậm.
Với mạng VNPT, Viettel hoặc FPT, hợp lý hơn là so sánh DNS đang dùng với lựa chọn thay thế ngay trên đường truyền của mình, rồi thử lại các trang thường truy cập. Nếu công cụ chỉ cho một kết quả tốt ở một thời điểm, chưa nên suy rộng rằng dịch vụ đó sẽ nhanh nhất ở mọi địa điểm và mọi giờ.
Đổi DNS cũng không bảo đảm giảm ping trong trận đấu đã kết nối tới máy chủ, bởi đường đi của gói tin và hàng đợi vẫn có thể giữ nguyên. Tương tự, không nên mặc định DNS thay thế luôn riêng tư hơn: quyết định đó còn phụ thuộc nhà cung cấp và cách thiết bị thiết lập kết nối DNS.
Ghi lại cấu hình cũ trước khi thử, chỉ đổi một yếu tố rồi kiểm tra lại. Nếu thời gian mở trang không khác mà cuộc gọi vẫn giật khi có tác vụ tải lớn, hãy quay lại kiểm tra tải và độ trễ thay vì tiếp tục đổi DNS theo cảm tính.
Chọn nâng gói cước hay sửa mạng bằng phép đối chiếu có điều kiện
Với gia đình tại Việt Nam, quyết định chi tiền nên dựa vào nơi xuất hiện giới hạn, không dựa vào việc một con số trông có đủ lớn hay chưa. Cùng một biểu hiện “mạng chậm” nhưng cách xử lý sẽ khác nếu lỗi chỉ xảy ra ở phòng ngủ, khi sao lưu dữ liệu hoặc với một dịch vụ nhất định.
| Biểu hiện khi đối chiếu | Hướng kiểm tra tiếp | Chưa thể kết luận |
|---|---|---|
| Kết nối dây ổn, Wi-Fi kém tại vị trí sử dụng | Vùng phủ, vật cản, băng tần và môi trường kênh | Nhà mạng thiếu băng thông |
| Cả dây lẫn Wi-Fi tăng độ trễ khi tải nặng | Hàng đợi, tải lên và khả năng quản lý tải | Phải thay ngay router |
| Chỉ một dịch vụ chậm trong khi phép đo khác tốt | Đường đi và tình trạng dịch vụ đó | Toàn bộ mạng gia đình hỏng |
| Chờ lâu trước khi trang bắt đầu tải | Đối chiếu thời gian phân giải DNS và quá trình mở kết nối | Đổi DNS chắc chắn hết lag |
Bảng này là cách khoanh vùng, không phải bộ quy tắc chẩn đoán tự động. Điều quan trọng là giữ nguyên các điều kiện còn lại khi thay đổi một yếu tố, để biết cải thiện đến từ cấu hình nào thay vì chỉ gặp lúc mạng ít người dùng hơn.
Nếu cần làm việc với bộ phận hỗ trợ nhà mạng, hãy gửi kết quả đo dây và Wi-Fi, vị trí đo, thời điểm xảy ra lỗi và độ trễ lúc có tải. Những thông tin đó cụ thể hơn lời phản ánh “Speedtest vẫn cao mà mạng lag”, đồng thời giúp tránh nâng gói cước cho một vấn đề nằm trong mạng không dây ở nhà.
Chỉ nên cân nhắc tăng băng thông sau khi xác định nhu cầu truyền dữ liệu thường xuyên vượt khả năng đường truyền hiện tại. Còn nếu vấn đề là thời gian chờ của gói tin hoặc vùng phủ, mục tiêu cần đạt là cuộc họp không đứt tiếng tại bàn làm việc khi cả nhà dùng mạng, chứ không phải thêm một kỷ lục Mbps cạnh router.
Nguồn tham khảo: XDA Developers, FastSpeedTest
