Wi-Fi ช้าตอนกลางคืน? ตรวจพอร์ตอิ่มตัวและความแออัด

Wi-Fi ช้าตอนกลางคืน อาจเกี่ยวข้องกับพอร์ตอิ่มตัว กล่าวคือปริมาณข้อมูลเข้าใกล้ความจุของพอร์ต Ethernet การเชื่อมต่อ WAN หรืออัปลิงก์ที่ใช้ร่วมกัน ทำให้แพ็กเก็ตรออยู่ในคิว ในที่นี้ “พอร์ต” หมายถึงอินเทอร์เฟซเครือข่าย ไม่ใช่พอร์ตบริการ TCP หรือ UDP การใช้งานในบ้านช่วงเย็น การแย่งเวลาใช้คลื่นกับเพื่อนบ้าน ลิงก์กายภาพที่ช้า ความแออัดของผู้ให้บริการ และความครอบคลุมที่อ่อนในห้อง ต้องใช้วิธีแก้ต่างกัน จึงควรเทียบอุปกรณ์เครื่องเดิมทั้งช่วงเงียบและช่วงใช้งานมากก่อนเลือกวิธีแก้

แยกพอร์ตอิ่มตัวออกจากลิงก์ที่เจรจาความเร็วได้ต่ำ#

พอร์ตที่เจรจาความเร็วได้ 100 Mbps แทน 1,000 Mbps ตามที่คาดไว้ ทำให้เกิดเพดานคงที่ ซึ่งอาจจำกัดผลทดสอบแบบมีสายทั้งตอนเช้าและตอนกลางคืน ปริมาณข้อมูลช่วงเย็นอาจทำให้เห็นข้อจำกัดชัดขึ้น แต่ความเร็วลิงก์เป็นคนละเรื่องกับความต้องการใช้งานที่ทำให้ลิงก์เต็ม ตรวจสถานะ Ethernet ของอุปกรณ์ที่ต่ออยู่ และสถานะ LAN, WAN หรืออัปลิงก์ที่เกี่ยวข้องบนเราเตอร์ แทนการคิดว่าช่องเสียบทุกช่องเป็นกิกะบิต

ตรวจเส้นทางตั้งแต่แล็ปท็อป สายเคเบิล สวิตช์ เราเตอร์ ไปจนถึงโมเด็มหรือ ONT พอร์ตที่เร็วขึ้นบนแล็ปท็อปชดเชยลิงก์ที่ช้ากว่าในจุดอื่นไม่ได้ ถ้าพบลิงก์ 100 Mbps โดยไม่คาดคิด ให้ตรวจข้อกำหนดและลองสายที่มั่นใจว่าใช้งานได้ดี หรือพอร์ตที่รองรับ อย่าบังคับการตั้งค่าการเจรจาความเร็วหากไม่มีคำแนะนำจากผู้ผลิต

ค่าที่วัดทั้งสี่ชนิดบอกข้อมูลต่างกัน:

ตัวอย่างเช่น บริการอัปโหลด 20 Mbps อาจเต็มได้ แม้ลิงก์ Ethernet ฝั่ง WAN ของเราเตอร์ยังเป็น 1,000 Mbps ขีดจำกัดบริการเป็นคอขวดอีกจุดหนึ่ง ป้ายกิกะบิตไม่ได้ให้โควตาความเร็วขาขึ้นระดับกิกะบิต เช่นเดียวกัน สัญญาณ Wi-Fi แรงไม่ได้ทำให้คิว WAN ที่รับภาระอยู่หายไป ถ้าทุกช่วงเวลาพบเพดานแบบมีสายเท่าเดิม ให้เริ่มจาก ลำดับการตรวจความเร็วกิกะบิต ก่อนกล่าวโทษช่วงเวลาเย็น

เปรียบเทียบเครื่องเดิมขณะว่าง รับภาระ และพักงาน#

ในช่วงเงียบและช่วงที่มักมีปัญหา ใช้แล็ปท็อป เซิร์ฟเวอร์ทดสอบ และตำแหน่งเดิม บันทึกชนิดการเชื่อมต่อ ย่าน Wi-Fi ความเร็ว Ethernet ดาวน์โหลด อัปโหลด และ ping การเปลี่ยนเซิร์ฟเวอร์เปลี่ยนเส้นทางที่กำลังทดสอบด้วย

1. ค่าตั้งต้นแบบมีสาย: ต่อกับเราเตอร์ ปิด Wi-Fi บนแล็ปท็อป แล้วบันทึก ping ขณะว่างโดยไม่จงใจสร้างภาระทดสอบ จดว่ายังมีการสตรีม สำรองข้อมูล หรืออัปเดตในบ้านใดทำงานอยู่
2. แบบมีสายขณะรับภาระ: ทดสอบดาวน์โหลด ดู ping แล้วทดสอบอัปโหลดแยกกัน บันทึกว่าข้อมูลทิศทางใดทำให้ความล่าช้าเพิ่ม การทดสอบความเร็วสร้างทราฟฟิก จึงไม่ใช่ค่าขณะว่าง
3. พักทราฟฟิกในบ้าน: ช่วงที่มีปัญหา ให้พักงานสำรองข้อมูล ดาวน์โหลดเกม ซิงค์รูป และสตรีมที่ไม่จำเป็นชั่วครู่ แล้ววัดแบบมีสายอีกครั้ง ให้งานจำเป็นและอุปกรณ์ความปลอดภัยทำงานต่อ และจดทราฟฟิกที่พักไม่ได้
4. Wi-Fi ใกล้เราเตอร์: ถอด Ethernet แล้วทดสอบข้างเราเตอร์ โดยใช้ย่านเดิมถ้าเป็นไปได้ วิธีนี้ตรวจเส้นทางวิทยุโดยไม่รวมกำแพงของห้องไกล
5. Wi-Fi ในห้องไกล: ทดสอบซ้ำที่เก้าอี้ใช้งานจริง แล้วเทียบกับค่าที่อยู่ใกล้ ทดสอบสายสนทนา เกม หรือการส่งไฟล์ที่ใช้งานจริง ไม่ใช่เฉพาะดาวน์โหลด

รูปแบบผลลัพธ์ช่วยจำกัดขอบเขตการตรวจ แต่ไม่ได้ระบุชิ้นส่วนที่เสียโดยอัตโนมัติ

ประเมินการใช้ลิงก์จากตัวนับไบต์เพียงทิศทางเดียว#

ถ้าเราเตอร์แสดงตัวนับไบต์ ให้ระบุอินเทอร์เฟซและทิศทาง การรับ/ส่งฝั่ง WAN กับการรับ/ส่งของแล็ปท็อปอ้างถึงขอบเขตต่างกัน อย่านำป้ายของทั้งสองมาปนกัน บันทึกสองค่าและเวลาที่ผ่านไป กราฟที่ไม่มีตัวนับยังไม่เพียงพอสำหรับการคำนวณนี้

นี่คือ การคำนวณตัวอย่าง ไม่ใช่ค่าที่วัดจากบ้านจริง สมมติว่าตัวนับขารับของอินเทอร์เฟซหนึ่งเพิ่ม 112,500,000 ไบต์ใน 10 วินาที:

• 112,500,000 ไบต์ / 10 วินาที × 8 = 90,000,000 บิตต่อวินาที
• ในหน่วยเครือข่ายฐานสิบ นั่นคือ 90 Mbps
• เทียบกับลิงก์ 100 Mbps: 90 / 100 × 100 = 90% คือสัดส่วนการรับเฉลี่ย
• เทียบกับลิงก์ 1,000 Mbps: 90 / 1,000 × 100 = 9% คือสัดส่วนการรับเฉลี่ย

คำนวณขาส่งแยกด้วยการเปลี่ยนแปลงตัวนับของขาส่งเอง อย่ารวมเปอร์เซ็นต์รับกับส่งแล้วสรุปว่าทิศทางหนึ่งของลิงก์ฟูลดูเพล็กซ์เกินภาระ ตัวเลขนี้เป็นการประเมินแบบง่าย ไม่รวมส่วนเกินของโปรโตคอลทั้งหมด คำอธิบายการใช้ประโยชน์อินเทอร์เฟซของ Cisco อธิบายผลต่างของตัวนับและการคำนวณขาเข้า/ขาออกแยกกัน

ตัวอย่างนี้ไม่ได้เปลี่ยนบริการอัปโหลด 20 Mbps ให้เป็นการอัปโหลด 90 Mbps ตัวนับ LAN หรือขาลงกับความจุขาขึ้นของบริการอ้างถึงคนละขอบเขต ให้เลือกความจุให้ตรงกับขอบเขตและทิศทางที่กำลังประเมิน

ถ้าตัวนับถูกรีเซ็ต วนกลับ หรือเปลี่ยนความหมายระหว่างช่วงวัด ให้ทิ้งการคำนวณแบบง่ายนี้แล้วเก็บช่วงใหม่ที่ใช้ได้ ค่าเฉลี่ยระยะยาวอาจซ่อนทราฟฟิกที่พุ่งสั้น ๆ ตัวนับหนึ่งตัวอย่างหรือผลทดสอบความเร็วครั้งเดียวไม่พิสูจน์ว่าพอร์ตใดแออัด ก่อนระบุสาเหตุ ให้ตรวจช่วงเวลาที่พบซ้ำ ความล่าช้าในคิว ข้อผิดพลาดแพ็กเก็ต สภาพสาย และภาระเราเตอร์

เลือกวิธีแก้ให้ตรงคอขวด#

ค่าความเร็วข้อมูลกับการสนทนาที่ตอบสนองทันทีเป็นคนละผลลัพธ์ ตัวอย่างเพื่ออธิบาย อาจมี ping ขณะว่าง 15 ms และขณะรับภาระ 200 ms การเปลี่ยนแปลงมากนี้ชวนให้ตรวจความล่าช้าขณะรับภาระ ไม่ใช่เกณฑ์ตัดสินสากลหรือหลักฐานว่าคิวอยู่ตรงไหน บันทึกปลายทางและทิศทางทราฟฟิก คำอธิบายแบนด์วิดท์และความล่าช้าขณะใช้งานของ Cloudflare อธิบายว่าทราฟฟิกที่รอในบัฟเฟอร์ทำให้แอปโต้ตอบล่าช้าได้อย่างไร แม้ค่าความเร็วข้อมูลยังยอมรับได้ ความหน่วงเกมและ bufferbloat มีขั้นตอนตรวจต่อในทางปฏิบัติ

กำหนดเวลาสำรองข้อมูล ซิงค์รูป และอัปเดตในช่วงเงียบ โดยคงการสนทนาและอัปโหลดจำเป็นไว้ สตรีม สายสนทนา และสำรองข้อมูลใช้ความจุต่างกัน ตรวจข้อกำหนดของแต่ละแอป งานสำรองข้อมูลอาจทำให้โควตาอัปโหลดที่เล็กกว่าเต็ม แม้ยังมีความจุดาวน์โหลดเหลือ

ถ้าอุปกรณ์รองรับ ให้พิจารณา QoS หรือ SQM ทำตามเอกสารเราเตอร์เรื่องการตั้งค่าความจุ และตั้งดาวน์โหลดกับอัปโหลดแยกกัน ทราฟฟิกที่พุ่งขึ้น อัตราบริการที่เปลี่ยน และกำลังประมวลผลเราเตอร์อาจต้องใช้ค่าต่างกัน ไม่มีค่าหนึ่งที่ใช้ได้ทุกกรณี ทดสอบความล่าช้าขณะรับภาระและความเร็วที่ใช้งานได้อีกครั้งหลังปรับแต่ละอย่าง การเปิดฟีเจอร์ไม่พิสูจน์ว่าช่วยแล้ว

ต่อสายให้เครื่องใช้งานสูงที่อยู่ประจำเมื่อทำได้ การย้ายทีวีหรือคอมพิวเตอร์ตั้งโต๊ะไป Ethernet ลดเวลาคลื่น Wi-Fi ที่มันใช้ แต่การดาวน์โหลดอินเทอร์เน็ตเดิมยังเพิ่มความต้องการ WAN อย่ารับรองว่าต่อสายหนึ่งเครื่องแล้วจะรักษาการเชื่อมต่ออินเทอร์เน็ตที่เต็มได้

ถ้า Wi-Fi ใกล้แย่ลงในขณะที่แบบมีสายยังคงเดิม ให้ตรวจสภาพวิทยุ บน 2.4 GHz ช่อง 1, 6 หรือ 11 ที่ความกว้าง 20 MHz เป็นตัวเลือกทั่วไปในพื้นที่ที่กฎช่องท้องถิ่นอนุญาต ช่อง 5 GHz ที่เงียบกว่าหรือความกว้างแคบกว่าอาจช่วยในอาคารหนาแน่น ทำตาม คู่มือช่องแออัด และเทียบก่อน/หลังในช่วงมีปัญหา การมองเห็นเครือข่ายเพื่อนบ้านไม่ใช่หลักฐานว่าเครือข่ายนั้นทำให้ช้า

ถ้ามีปัญหาเฉพาะห้องไกล ให้ตรวจผนังและตำแหน่ง ตัวขยายสัญญาณช่วยเส้นทางครอบคลุมที่อ่อนได้ หากยังเชื่อมกับเราเตอร์ได้ดี แต่มันเพิ่มความจุผู้ให้บริการหรือลบการแข่งขันใช้เวลาคลื่นไม่ได้ ใช้ Wi-Fi ช้าในห้องเดียว ยืนยันรูปแบบนี้ก่อนเพิ่มฮาร์ดแวร์

จดบันทึกช่วงเย็นก่อนซื้ออุปกรณ์#

ทำซ้ำในสองหรือสามเย็นของวันธรรมดาตามปกติ จดห้อง เวลา เซิร์ฟเวอร์ ย่าน ความเร็ว Ethernet ping ขณะว่าง/รับภาระ ทราฟฟิกทั้งสองทิศ และงานที่กำลังทำ วิธีนี้แยกวิธีแก้ที่ได้ผลออกจากคืนที่เงียบกว่าโดยบังเอิญ หากรูปแบบเปลี่ยน ให้ตรวจซ้ำสัปดาห์หน้า

เปลี่ยนทีละอย่าง แล้วปล่อยให้คงที่นานพอจะเทียบหลายเย็น บันทึกงานไม่จำเป็นที่พักไว้และคืนตารางปกติภายหลัง การดีขึ้นทันทีหลังรีสตาร์ตหรือปรับค่าเป็นข้อมูลที่ควรจด แต่ยังไม่แยกสาเหตุ เฝ้าดูข้อผิดพลาดแพ็กเก็ตหรือภาระเราเตอร์ควบคู่กับความล่าช้าที่พุ่ง ทางเลือกเหล่านี้สำคัญแม้ค่าไบต์เฉลี่ยดูไม่สูง

ถ้าแบบมีสายยังแย่แม้พักความต้องการในบ้านและตรวจเส้นทางภายในแล้ว ให้ติดต่อผู้ให้บริการพร้อมวันเวลาและผลทดสอบ ถามเรื่องเหตุขัดข้อง การใช้งาน และขีดจำกัดบริการ แทนการกล่าวหาว่าจำกัดความเร็วโดยเจตนา ข้อจำกัดเราเตอร์/โมเด็มยังเป็นไปได้ การทดสอบก่อนติดต่อผู้ให้บริการ ช่วยจัดหลักฐาน

วางแผนปรับความครอบคลุมใน Range Up#

สำหรับปัญหาครอบคลุม ให้ ดาวน์โหลด Range Up บน iPhone หรือ Android เครื่องมือฟรีให้วาดแปลนและผนัง วางเราเตอร์ ทำเครื่องหมายจุดเป้าหมาย และดูความครอบคลุมจำลอง Premium เพิ่มการวางตัวขยาย จุดที่แนะนำ และผล ก่อน / หลัง แบบประมาณ แอปไม่ได้วัด RSSI สด อ่านตัวนับพอร์ต ทดสอบความเร็ว หรือตั้งค่าเราเตอร์ ใช้ คู่มือวางตัวขยาย Wi-Fi แล้วตรวจแผนด้วยการทดสอบจริงช่วงเย็น