ไม่มีใครเข้าใจจริงๆว่าการตั้งเวลา HFSC ใน Linux / BSD ทำงานอย่างไร?

ฉันอ่านต้นฉบับPostScript ของ SIGCOMM '97เกี่ยวกับ HFSC มันเป็นเรื่องทางเทคนิคมาก แต่ฉันเข้าใจแนวคิดพื้นฐาน แทนที่จะให้เส้นโค้งบริการแบบเส้นตรง (เช่นเดียวกับอัลกอริธึมการตั้งเวลาอื่น ๆ ) คุณสามารถระบุเส้นโค้งการให้บริการแบบนูนหรือเว้าได้ดังนั้นจึงเป็นไปได้ที่จะแยกแบนด์วิดท์และการหน่วงเวลาออก อย่างไรก็ตามแม้ว่าบทความนี้จะกล่าวถึงชนิดของอัลกอริทึมการจัดตารางเวลาที่ใช้ (เรียลไทม์และลิงค์แบ่งปัน) มันมักจะกล่าวถึงหนึ่งโค้งต่อชั้นเรียนการตั้งเวลา (decoupling จะทำโดยระบุโค้งนี้เพียงหนึ่งโค้งที่จำเป็นสำหรับ )

ตอนนี้ HFSC ได้รับการดำเนินการสำหรับ BSD (OpenBSD, FreeBSD, ฯลฯ ) โดยใช้กรอบการจัดตารางเวลา ALTQและมันได้รับการดำเนินการลินุกซ์โดยใช้กรอบการจัดตารางเวลา TC (ส่วนหนึ่งของ iproute2) การใช้งานทั้งสองเพิ่มเส้นโค้งบริการเพิ่มเติมสองเส้นซึ่งไม่ได้อยู่ในเอกสารต้นฉบับ! เส้นโค้งบริการแบบเรียลไทม์และเส้นโค้งบริการขีด จำกัด บน อีกครั้งโปรดทราบว่ากระดาษต้นฉบับกล่าวถึงอัลกอริธึมการตั้งเวลาสองแบบ (เรียลไทม์และลิงค์แชร์) แต่ในบทความนั้นทั้งคู่ทำงานร่วมกับเส้นโค้งบริการเดียว ไม่เคยมีเส้นโค้งบริการที่เป็นอิสระสองเส้นสำหรับเส้นโค้งใดเส้นหนึ่งตามที่คุณพบใน BSD และ Linux

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

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

alt text http://f.imagehost.org/0177/hfsc-test-setup.png

นี่คือคำถามบางข้อที่ฉันไม่สามารถตอบได้เพราะบทเรียนจะขัดแย้งกัน:

1. ฉันต้องทำอะไรกับเส้นโค้งแบบเรียลไทม์? สมมติว่า A1, A2, B1, B2 ทั้งหมดเป็น 128 kbit / s link-share (ไม่มีเส้นโค้งแบบเรียลไทม์สำหรับหนึ่ง) จากนั้นแต่ละอันจะได้รับ 128 kbit / s หากรูทมี 512 kbit / s เพื่อกระจาย (และ A และ B มีทั้ง 256 kbit / s) ใช่ไหม? เพราะเหตุใดฉันจึงให้ A1 และ B1 เป็นเส้นโค้งแบบเรียลไทม์กับ 128 kbit / s สิ่งนี้จะเป็นสิ่งที่ดีสำหรับ เพื่อให้ทั้งสองมีความสำคัญสูงกว่า? จากเอกสารต้นฉบับฉันสามารถให้ความสำคัญกับพวกเขาได้มากขึ้นโดยใช้เส้นโค้งนั่นคือสิ่งที่ HFSC ให้ความสำคัญ โดยให้ทั้งสองคลาสเป็นเส้นโค้งของ [256kbit / s 20ms 128kbit / s] ทั้งสองมีลำดับความสำคัญเป็นสองเท่ากว่า A2 และ B2 โดยอัตโนมัติ (ยังคงรับเพียง 128 kbit / s โดยเฉลี่ย)

2. แบนด์วิดท์ตามเวลาจริงนับรวมกับแบนด์วิดท์ลิงก์แชร์หรือไม่ เช่นถ้า A1 และ B1 มีเพียง 64kbit / s เรียลไทม์และ 64kbit / s แบนด์วิธแชร์ลิงค์หมายความว่าเมื่อพวกเขาให้บริการ 64kbit / s ผ่านเรียลไทม์ความต้องการแชร์ลิงค์ของพวกเขาก็พอใจเช่นกัน รับแบนด์วิดท์ที่มากเกินไป แต่ให้เพิกเฉยสักวินาที) หรือนั่นหมายความว่าพวกเขาได้รับอีก 64 kbit / s ผ่านลิงค์แชร์ ดังนั้นแต่ละคลาสจะมีแบนด์วิดธ์ "ข้อกำหนด" ของเรียลไทม์รวมถึงลิงค์แชร์ หรือคลาสนั้นมีความต้องการสูงกว่าเส้นโค้งแบบเรียลไทม์หากเส้นโค้งลิงค์ร่วมกันสูงกว่าเส้นโค้งเรียลไทม์ (ข้อกำหนดลิงค์ปัจจุบันแบ่งปันแชร์เท่ากับความต้องการลิงค์แชร์ร่วมที่ระบุลบแบนด์วิดท์ตามเวลาจริง class)?

3. เส้นโค้งขีด จำกัด บนนำไปใช้กับเรียลไทม์เช่นเดียวกับการแชร์ลิงก์หรือทั้งสองอย่าง แบบฝึกหัดบางคำบอกทางเดียวบางคนพูดแบบอื่น บางคนเรียกร้องขีด จำกัด บนคือสูงสุดสำหรับแบนด์วิดท์แบบเรียลไทม์ + แบนด์วิดท์ลิงค์แชร์? ความจริงคืออะไร?

4. สมมติว่า A2 และ B2 มีทั้ง 128 kbit / s มันสร้างความแตกต่างหรือไม่ถ้า A1 และ B1 เป็น 128-link link-share เท่านั้นหรือ 64 kbit / s เรียลไทม์และ 128 kbit / s link-share และถ้าเป็นเช่นนั้น แตกต่างกันอย่างไร

5. ถ้าฉันใช้เส้นโค้งแบบเรียลไทม์แยกเพื่อเพิ่มลำดับความสำคัญของชั้นเรียนทำไมฉันต้องใช้ "เส้นโค้ง" เลย? ทำไมค่าแฟลตและลิงค์แชร์ไม่ใช่ค่าเรียลไทม์? ทำไมเส้นโค้งทั้งสอง ความต้องการเส้นโค้งนั้นชัดเจนในกระดาษดั้งเดิมเพราะมีเพียงคุณลักษณะเดียวต่อประเภทนั้น แต่ตอนนี้มีคุณลักษณะสามอย่าง (เรียลไทม์ลิงก์แชร์และขีด จำกัด บน) ฉันจะต้องใช้เส้นโค้งสำหรับแต่ละรายการอย่างไร เหตุใดฉันจึงต้องการให้รูปร่างโค้ง(ไม่ใช่แบนด์วิดท์เฉลี่ย แต่ความลาดชัน) จะแตกต่างกันสำหรับปริมาณการใช้งานแบบเรียลไทม์และลิงก์แบ่งปัน

6. ตามเอกสารเล็ก ๆ น้อย ๆ ที่มีอยู่ค่าของเส้นโค้งแบบเรียลไทม์จะถูกละเว้นสำหรับคลาสภายใน (คลาส A และ B) พวกมันจะถูกนำไปใช้กับคลาสของใบไม้ (A1, A2, B1, B2) เท่านั้น หากเป็นจริงทำไมการกำหนดค่าตัวอย่าง ALTQ HFSC (ค้นหา3.3 การกำหนดค่าตัวอย่าง ) ตั้งค่าเส้นโค้งแบบเรียลไทม์ในคลาสภายในและอ้างว่าตั้งค่าอัตราการรับประกันของคลาสภายในเหล่านั้นหรือไม่ นั่นไม่มีจุดหมายอย่างสมบูรณ์หรือ (หมายเหตุ: pshare ตั้งค่ากราฟการแชร์ลิงค์ใน ALTQ และเสียดสีโค้งเรียลไทม์คุณสามารถเห็นสิ่งนี้ในย่อหน้าด้านบนการกำหนดค่าตัวอย่าง)

7. บทเรียนบางบทบอกว่าผลรวมของเส้นโค้งแบบเรียลไทม์ทั้งหมดอาจไม่สูงกว่า 80% ของความเร็วของเส้น แต่บางคนบอกว่าจะต้องไม่สูงกว่า 70% ของความเร็วของเส้น เป็นที่หนึ่งที่ถูกต้องหรือพวกเขาอาจผิดทั้งคู่?

8. บทช่วยสอนหนึ่งกล่าวว่าคุณจะลืมทฤษฎีทั้งหมด ไม่ว่าสิ่งต่างๆจะทำงานอย่างไร (ตัวกำหนดตารางเวลาและการกระจายแบนด์วิดท์) ให้จินตนาการถึงสามเส้นโค้งตาม "รูปแบบความคิดที่เรียบง่าย" ดังต่อไปนี้: แบบเรียลไทม์คือแบนด์วิดท์ที่รับประกันว่า link-share คือแบนด์วิดท์ที่คลาสนี้ต้องการที่จะพึงพอใจอย่างเต็มที่ แต่ไม่สามารถรับประกันความพึงพอใจได้ ในกรณีที่มีแบนด์วิดท์มากเกินไปคลาสอาจได้รับแบนด์วิดท์มากกว่าที่จำเป็นเพื่อให้เป็นที่พอใจ แต่ก็ไม่อาจใช้เกินขีด จำกัด บนได้ เพื่อให้ใช้งานได้ทั้งหมดผลรวมของแบนด์วิดท์แบบเรียลไทม์ทั้งหมดอาจไม่เกิน xx% ของความเร็วของสาย (ดูคำถามข้างต้นเปอร์เซ็นต์แตกต่างกันไป) คำถาม: สิ่งนี้มีความแม่นยำมากขึ้นหรือน้อยลงหรือความเข้าใจผิดทั้งหมดของ HSFC?

9. และถ้าข้อสันนิษฐานข้างต้นมีความแม่นยำจริง ๆ การจัดลำดับความสำคัญของโมเดลนั้นอยู่ที่ไหน เช่นทุกคลาสอาจมีแบนด์วิดท์แบบเรียลไทม์ (รับประกัน) แบนด์วิดท์ลิงก์แชร์ (ไม่รับประกัน) และอาจมีขีด จำกัด บน แต่บางคลาสมีความต้องการลำดับความสำคัญสูงกว่าคลาสอื่น ในกรณีนี้ฉันยังต้องจัดลำดับความสำคัญอย่างใดแม้ในเวลาจริงการจราจรของชั้นเรียนเหล่านั้น ฉันจะจัดลำดับความสำคัญโดยความชันของเส้นโค้งหรือไม่ และถ้าเป็นเช่นนั้นเส้นโค้งใด เส้นโค้งแบบเรียลไทม์? เส้นโค้งลิงค์แบ่งปัน? เส้นโค้งขีด จำกัด บน? พวกเขาทุกคน? ฉันจะให้ความชันเดียวกันหรือแต่ละอันต่างกันและหาวิธีความชันที่ถูกต้องได้ไหม?

ฉันยังไม่ได้สูญเสียความหวังว่ามีอย่างน้อยมือที่เต็มไปด้วยผู้คนในโลกนี้ที่เข้าใจ HFSC อย่างแท้จริงและสามารถตอบคำถามเหล่านี้ได้อย่างถูกต้อง และการทำเช่นนั้นโดยไม่แย้งกันในคำตอบน่าจะดีจริงๆ ;-)

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

ฉันได้เขียนสอนสำหรับ HFSC อ่านถ้าคำอธิบายของฉันด้านล่างยังไม่ชัดเจน

ฉันต้องทำอะไรกับเส้นโค้งแบบเรียลไทม์? สมมติว่า A1, A2, B1, B2 ทั้งหมดเป็น 128 kbit / s link-share (ไม่มีเส้นโค้งแบบเรียลไทม์สำหรับหนึ่ง) จากนั้นแต่ละอันจะได้รับ 128 kbit / s หากรูทมี 512 kbit / s เพื่อกระจาย (และ A และ B มีทั้ง 256 kbit / s) ใช่ไหม? เพราะเหตุใดฉันจึงให้ A1 และ B1 เป็นเส้นโค้งแบบเรียลไทม์กับ 128 kbit / s สิ่งนี้จะเป็นสิ่งที่ดีสำหรับ เพื่อให้ทั้งสองมีความสำคัญสูงกว่า? จากเอกสารต้นฉบับฉันสามารถให้ความสำคัญกับพวกเขาได้มากขึ้นโดยใช้เส้นโค้งนั่นคือสิ่งที่ HFSC ให้ความสำคัญ โดยให้ทั้งสองคลาสเป็นเส้นโค้งของ [256kbit / s 20ms 128kbit / s] ทั้งสองมีลำดับความสำคัญเป็นสองเท่ากว่า A2 และ B2 โดยอัตโนมัติ (ยังคงรับเพียง 128 kbit / s โดยเฉลี่ย)

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

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

การแยกการแชร์ลิงก์จากการรับประกันความหน่วงเป็นสิ่งใหม่ที่ HFSC นำมาสู่ตารางและบทความระบุว่าเป็นประโยคเปิดมาก: ในบทความนี้เราศึกษารูปแบบการจัดการทรัพยากรแบบลำดับชั้นและอัลกอริธึมที่สนับสนุนทั้งการแบ่งปันลิงค์และรับประกัน บริการเรียลไทม์ที่มีความล่าช้า decoupled (ลำดับความสำคัญ) และการจัดสรรแบนด์วิดธ์ คำสำคัญในประโยคนั้นแยกออกจากกัน แปลว่าคุณคาดว่าจะบอกได้ว่าจะใช้แบนด์วิดท์ที่ไม่ได้ใช้ร่วมกับ ls อย่างไรและระบุการรับประกันแบบเรียลไทม์ (อาคาแฝงที่รับรองความถูกต้อง) ที่ต้องการด้วย rt ทั้งสองเป็นมุมฉาก

แบนด์วิดท์ตามเวลาจริงนับรวมกับแบนด์วิดท์ลิงก์แชร์หรือไม่

ใช่. ในกระดาษ HFSC พวกเขากำหนดแบนด์วิดธ์ในแง่ของสิ่งที่ชั้นเรียนได้ส่งตั้งแต่ชั้นได้กลายเป็น backlogged (เช่นมีแพ็คเก็ตรอที่จะส่ง) ความแตกต่างเพียงอย่างเดียวระหว่าง rt และ ls คือ rt มองไปข้างหน้าจากทุกครั้งที่คลาสถูกแบ็คล็อกและคำนวณแบนด์วิดท์ที่รับประกันได้ต่ำที่สุดจากชุดนั้นในขณะที่การแชร์ลิงค์จะดูจากครั้งล่าสุด ดังนั้น rt ใช้เวลาพิจารณาไบต์มากกว่า ls แต่ทุกไบต์ ls ที่พิจารณาก็ถือว่า rt ด้วยเช่นกัน

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

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

สมมติว่า A2 และ B2 มีทั้ง 128 kbit / s มันสร้างความแตกต่างหรือไม่ถ้า A1 และ B1 เป็น 128-link link-share เท่านั้นหรือ 64 kbit / s เรียลไทม์และ 128 kbit / s link-share และถ้าเป็นเช่นนั้น แตกต่างกันอย่างไร

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

ถ้าฉันใช้เส้นโค้งแบบเรียลไทม์แยกเพื่อเพิ่มลำดับความสำคัญของชั้นเรียนทำไมฉันต้องใช้ "เส้นโค้ง" เลย? ทำไมค่าแฟลตและลิงค์แชร์ไม่ใช่ค่าเรียลไทม์? ทำไมเส้นโค้งทั้งสอง ความต้องการเส้นโค้งนั้นชัดเจนในกระดาษดั้งเดิมเพราะมีเพียงคุณลักษณะเดียวต่อประเภทนั้น แต่ตอนนี้มีคุณลักษณะสามอย่าง (เรียลไทม์ลิงก์แชร์และขีด จำกัด บน) ฉันจะต้องใช้เส้นโค้งสำหรับแต่ละรายการอย่างไร เหตุใดฉันจึงต้องการให้รูปร่างโค้ง (ไม่ใช่แบนด์วิดท์เฉลี่ย แต่ความลาดชัน) จะแตกต่างกันสำหรับปริมาณการใช้งานแบบเรียลไทม์และลิงก์แบ่งปัน

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

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

ตามเอกสารเล็ก ๆ น้อย ๆ ที่มีอยู่ค่าของเส้นโค้งแบบเรียลไทม์จะถูกละเว้นสำหรับคลาสภายใน (คลาส A และ B) พวกมันจะถูกนำไปใช้กับคลาสของใบไม้ (A1, A2, B1, B2) เท่านั้น หากเป็นจริงทำไมการกำหนดค่าตัวอย่าง ALTQ HFSC (ค้นหา 3.3 การกำหนดค่าตัวอย่าง) ตั้งค่าเส้นโค้งแบบเรียลไทม์ในคลาสภายในและอ้างว่าตั้งค่าอัตราการรับประกันของคลาสภายในเหล่านั้นหรือไม่ นั่นไม่มีจุดหมายอย่างสมบูรณ์หรือ (หมายเหตุ: pshare ตั้งค่ากราฟการแชร์ลิงค์ใน ALTQ และเสียดสีโค้งเรียลไทม์คุณสามารถเห็นสิ่งนี้ในย่อหน้าด้านบนการกำหนดค่าตัวอย่าง)

เอกสารถูกต้อง ลำดับชั้น (และโหนดภายใน) ไม่มีผลต่อการคำนวณแบบเรียลไทม์ แต่อย่างใด ฉันไม่สามารถบอกคุณได้ว่าทำไม ALTQ คิดอย่างชัดเจนว่าเป็นเช่นนั้น

บทเรียนบางบทบอกว่าผลรวมของเส้นโค้งแบบเรียลไทม์ทั้งหมดอาจไม่สูงกว่า 80% ของความเร็วของเส้น แต่บางคนบอกว่าจะต้องไม่สูงกว่า 70% ของความเร็วของเส้น เป็นที่หนึ่งที่ถูกต้องหรือพวกเขาอาจผิดทั้งคู่?

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

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

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

บทช่วยสอนหนึ่งกล่าวว่าคุณจะลืมทฤษฎีทั้งหมด ไม่ว่าสิ่งต่างๆจะทำงานอย่างไร (ตัวกำหนดตารางเวลาและการกระจายแบนด์วิดท์) ให้จินตนาการถึงสามเส้นโค้งตาม "รูปแบบความคิดที่เรียบง่าย" ดังต่อไปนี้: แบบเรียลไทม์คือแบนด์วิดท์ที่รับประกันว่า link-share คือแบนด์วิดท์ที่คลาสนี้ต้องการที่จะพึงพอใจอย่างเต็มที่ แต่ไม่สามารถรับประกันความพึงพอใจได้ ในกรณีที่มีแบนด์วิดท์มากเกินไปคลาสอาจได้รับแบนด์วิดท์มากกว่าที่จำเป็นเพื่อให้เป็นที่พอใจ แต่ก็ไม่อาจใช้เกินขีด จำกัด บนได้ เพื่อให้ใช้งานได้ทั้งหมดผลรวมของแบนด์วิดท์แบบเรียลไทม์ทั้งหมดอาจไม่เกิน xx% ของความเร็วของสาย (ดูคำถามข้างต้นเปอร์เซ็นต์แตกต่างกันไป) คำถาม: สิ่งนี้มีความแม่นยำมากขึ้นหรือน้อยลงหรือความเข้าใจผิดทั้งหมดของ HSFC?

มันเป็นคำอธิบายที่ดีขีด จำกัด บน แม้ว่าคำอธิบายลิงก์จะมีความแม่นยำสูง แต่ก็ทำให้เข้าใจผิด แม้ว่าการแชร์ลิงก์จริงจะไม่ให้การรับประกันเวลาแฝงที่ยากลำบากเหมือนในเวลาจริง แต่มันก็เป็นงานที่ดีกว่าในการจัดสรรแบนด์วิดท์ให้กับชั้นเรียนมากกว่าคู่แข่งเช่น CBQ และ HTB ดังนั้นในการบอกว่าลิงก์แชร์ "ไม่ได้ให้การรับรอง" มันจะถือเป็นมาตรฐานที่สูงกว่าตัวกำหนดตารางเวลาอื่น ๆ ที่สามารถให้ได้

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

ที่กล่าวว่าเวลาจริงไม่ได้ให้การรับประกันเวลาแฝงที่สมบูรณ์แบบเช่นกัน ทำได้หากลิงก์นั้นไม่ได้จัดการโดยแชร์ลิงก์ แต่ผู้ใช้ส่วนใหญ่ต้องการความยืดหยุ่นเพิ่มเติมในการมีทั้งคู่และมันไม่ได้มาฟรี เวลาจริงสามารถพลาดได้คือกำหนดเวลาแฝงตามเวลาที่ใช้ในการส่งแพ็กเก็ต MTU หนึ่งแพ็ค (ถ้ามันเกิดขึ้นมันจะเป็นเพราะมันเป็นลิงค์ MTU แพ็คเก็ตที่แนบมาในขณะที่ในเวลาจริงการรักษาลิงค์ที่ไม่ได้ใช้งานในกรณีที่มันได้รับแพ็คเก็ตที่มีกำหนดเวลาสั้น ๆ ที่จะต้องส่งทันที และเรียลไทม์เพื่อให้การรับประกันแบบเรียลไทม์อาจจงใจรักษาบรรทัดว่างแม้ว่าจะมีแพ็กเก็ตที่จะส่งดังนั้นจึงให้การใช้ลิงก์น้อยกว่า 100% การแชร์ลิงก์ใช้ 100% ของลิงก์ที่มีอยู่เสมอ ,

เหตุผลแบบเรียลไทม์อาจกล่าวได้ว่าให้การรับประกันความล่าช้าอย่างหนักคือความล่าช้าถูก จำกัด ขอบเขต ดังนั้นหากคุณพยายามเสนอการรับประกันเวลาแฝง 20ms บนลิงค์ 1Mbit / วินาทีและการแชร์ลิงก์กำลังส่งแพ็กเก็ต MTU ขนาด (1500 ไบต์) คุณรู้ว่าหนึ่งในแพ็กเก็ตเหล่านั้นจะใช้เวลา 12 มิลลิวินาทีในการส่ง ดังนั้นหากคุณบอกเวลาจริง ๆ ว่าคุณต้องการเวลาแฝง 8 มิลลิวินาทีคุณยังคงสามารถทำได้ตามกำหนดเวลา 20ms - พร้อมรับประกันแน่นอน

และถ้าข้อสันนิษฐานข้างต้นมีความแม่นยำจริง ๆ การจัดลำดับความสำคัญของโมเดลนั้นอยู่ที่ไหน เช่นทุกคลาสอาจมีแบนด์วิดท์แบบเรียลไทม์ (รับประกัน) แบนด์วิดท์ลิงก์แชร์ (ไม่รับประกัน) และอาจมีขีด จำกัด บน แต่บางคลาสมีความต้องการลำดับความสำคัญสูงกว่าคลาสอื่น ในกรณีนี้ฉันยังต้องจัดลำดับความสำคัญอย่างใดแม้ในเวลาจริงการจราจรของชั้นเรียนเหล่านั้น ฉันจะจัดลำดับความสำคัญโดยความชันของเส้นโค้งหรือไม่ และถ้าเป็นเช่นนั้นเส้นโค้งใด เส้นโค้งแบบเรียลไทม์? เส้นโค้งลิงค์แบ่งปัน? เส้นโค้งขีด จำกัด บน? พวกเขาทุกคน? ฉันจะให้ความชันเดียวกันหรือแต่ละอันต่างกันและหาวิธีความชันที่ถูกต้องได้ไหม?

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

ในความเป็นจริงไม่มีใครต้องการลำดับความสำคัญแบบนั้น สิ่งที่พวกเขาต้องการคือสิ่งที่ HFSC ให้ หากคุณมีการรับส่งข้อมูลตามเวลาจริง HFSC จะให้ข้อมูลนั้น แต่มันจะเป็นทุกอย่าง สำหรับส่วนที่เหลือ HFSC ช่วยให้คุณสามารถพูดว่า "บนลิงค์ที่มีความแออัดจัดสรร 90% ไปยังเว็บและปล่อยให้อีเมลไหลเวียนไปที่ 10% และโอ้ส่งแพ็คเก็ต DNS แปลก ๆ อย่างรวดเร็ว

คุณสามารถกำหนดเส้นโค้งด้วยชื่ออื่น:

• rt, เรียลไทม์โค้งรับประกันแบนด์วิดท์ / ล่าช้า
• ls, แชร์ลิงค์, แบนด์วิดท์ / การแบ่งปันล่าช้า (ขึ้นอยู่กับการกำหนดค่าของใบไม้เพื่อนบ้าน)
• ul, เส้นโค้งขีด จำกัด บน, แบนด์วิดท์สูงสุด / ล่าช้ามันอาจบรรลุ

ฉันต้องทำอะไรกับเส้นโค้งแบบเรียลไทม์? สมมติว่า A1, A2, B1, B2 ทั้งหมดเป็น 128 kbit / s link-share (ไม่มีเส้นโค้งแบบเรียลไทม์สำหรับหนึ่ง) จากนั้นแต่ละอันจะได้รับ 128 kbit / s หากรูทมี 512 kbit / s เพื่อกระจาย (และ A และ B มีทั้ง 256 kbit / s) ใช่ไหม? เพราะเหตุใดฉันจึงให้ A1 และ B1 เป็นเส้นโค้งแบบเรียลไทม์กับ 128 kbit / s สิ่งนี้จะเป็นสิ่งที่ดีสำหรับ เพื่อให้ทั้งสองมีความสำคัญสูงกว่า? จากเอกสารต้นฉบับฉันสามารถให้ความสำคัญกับพวกเขาได้มากขึ้นโดยใช้เส้นโค้งนั่นคือสิ่งที่ HFSC ให้ความสำคัญ โดยให้ทั้งสองคลาสเป็นเส้นโค้งของ [256kbit / s 20ms 128kbit / s] ทั้งสองมีลำดับความสำคัญเป็นสองเท่ากว่า A2 และ B2 โดยอัตโนมัติ (ยังคงรับเพียง 128 kbit / s โดยเฉลี่ย)

เมื่อคุณสร้างคำจำกัดความใน HFSC ด้วยอัตราเท่านั้นมันจะตั้ง 'dmax' เป็น 0 โดยอัตโนมัติซึ่งโดยทั่วไปหมายความว่ามันไม่ได้มีความล่าช้า การกำหนดค่า HFSC ที่ดีควรมีทั้งแบนด์วิดท์และขอบเขตการหน่วงเวลาที่คุณต้องการใช้สำหรับคลาสของคุณมิฉะนั้นอัลกอริทึมจะไม่สามารถระบุได้ว่าระดับความสำคัญควรเป็นเท่าไหร่

เมื่อใดก็ตามที่คุณให้ลำดับความสำคัญของแพ็คเก็ตแพ็กเก็ตอื่น ๆ จะต้องลดลงในลำดับความสำคัญ ขึ้นอยู่กับค่า 'dmax' และ 'rate' คลาสทั้งหมดจะถูกใช้มัลติเพล็กซ์โดยใช้ตัวจับเวลาเสมือน อ้างถึง tc-hfsc (7) สำหรับข้อมูลเพิ่มเติม

แบนด์วิดท์ตามเวลาจริงนับรวมกับแบนด์วิดท์ลิงก์แชร์หรือไม่ เช่นถ้า A1 และ B1 มีเพียง 64kbit / s เรียลไทม์และ 64kbit / s แบนด์วิธแชร์ลิงค์หมายความว่าเมื่อพวกเขาให้บริการ 64kbit / s ผ่านเรียลไทม์ความต้องการแชร์ลิงค์ของพวกเขาก็พอใจเช่นกัน รับแบนด์วิดท์ที่มากเกินไป แต่ให้เพิกเฉยสักวินาที) หรือนั่นหมายความว่าพวกเขาได้รับอีก 64 kbit / s ผ่านลิงค์แชร์ ดังนั้นแต่ละคลาสจะมีแบนด์วิดธ์ "ข้อกำหนด" ของเรียลไทม์รวมถึงลิงค์แชร์ หรือคลาสนั้นมีความต้องการสูงกว่าเส้นโค้งแบบเรียลไทม์หากเส้นโค้งลิงค์ร่วมกันสูงกว่าเส้นโค้งเรียลไทม์ (ข้อกำหนดลิงค์ปัจจุบันแบ่งปันแชร์เท่ากับความต้องการลิงค์แชร์ร่วมที่ระบุลบแบนด์วิดท์ตามเวลาจริง class)?

หากโฟลว์ไม่ผ่านขอบเขตของคำจำกัดความลิงก์ - แชร์ของคลาสจะไม่เคยใช้เส้นโค้งแบบเรียลไทม์ การกำหนดเส้นโค้งแบบเรียลไทม์ในกรณีนี้ช่วยให้คุณเช่น: เพื่อรับประกัน 'dmax' ที่แน่นอน

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

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

เส้นโค้งขีด จำกัด บนของคลาสของคุณถูกนำไปใช้กับ link-share เท่านั้นเมื่อคุณกำหนดเส้นโค้งบนขีด จำกัด บนคุณจะต้องกำหนดเส้นโค้ง link-share อย่างไรก็ตามเส้นโค้งขีด จำกัด บนของคลาสแม่ยังคงใช้

สมมติว่า A2 และ B2 มีทั้ง 128 kbit / s มันสร้างความแตกต่างหรือไม่ถ้า A1 และ B1 เป็น 128-link link-share เท่านั้นหรือ 64 kbit / s เรียลไทม์และ 128 kbit / s link-share และถ้าเป็นเช่นนั้น แตกต่างกันอย่างไร

มีความแตกต่างเล็กน้อยถ้าเช่น A2 = 0 kbits / s และ B2 = 256 kbits / s จากนั้นเวลาเสมือนสำหรับ A2 จะเท่ากับค่าสูงสุด เมื่อใดก็ตามที่แพ็กเก็ตถูกจัดประเภทใน A2 มันจะถูกประมวลผลทันที อย่างไรก็ตามกราฟเรียลไทม์ของ B2 จะยังคงมั่นใจว่าสามารถส่งได้อย่างน้อย 64 kbit / s

ถ้าฉันใช้เส้นโค้งแบบเรียลไทม์แยกต่างหากเพื่อเพิ่มลำดับความสำคัญของชั้นเรียนทำไมฉันต้องใช้ "เส้นโค้ง" เลย? ทำไมค่าแฟลตและลิงค์แชร์ไม่ใช่ค่าเรียลไทม์? ทำไมเส้นโค้งทั้งสอง ความต้องการเส้นโค้งนั้นชัดเจนในกระดาษดั้งเดิมเพราะมีเพียงคุณลักษณะเดียวต่อประเภทนั้น แต่ตอนนี้มีคุณลักษณะสามอย่าง (เรียลไทม์ลิงก์แชร์และขีด จำกัด บน) ฉันจะต้องใช้เส้นโค้งสำหรับแต่ละรายการอย่างไร เหตุใดฉันจึงต้องการให้รูปร่างโค้ง (ไม่ใช่แบนด์วิดท์เฉลี่ย แต่ความลาดชัน) จะแตกต่างกันสำหรับปริมาณการใช้งานแบบเรียลไทม์และลิงก์แบ่งปัน

เส้นโค้งแบบเรียลไทม์ไม่แชร์การรับส่งข้อมูลระหว่างใบไม้เพื่อนบ้าน

ตามเอกสารเล็ก ๆ น้อย ๆ ที่มีอยู่ค่าของเส้นโค้งแบบเรียลไทม์จะถูกละเว้นสำหรับคลาสภายใน (คลาส A และ B) พวกมันจะถูกนำไปใช้กับคลาสของใบไม้ (A1, A2, B1, B2) เท่านั้น หากเป็นจริงทำไมการกำหนดค่าตัวอย่าง ALTQ HFSC (ค้นหา 3.3 การกำหนดค่าตัวอย่าง) ตั้งค่าเส้นโค้งแบบเรียลไทม์ในคลาสภายในและอ้างว่าตั้งค่าอัตราการรับประกันของคลาสภายในเหล่านั้นหรือไม่ นั่นไม่มีจุดหมายอย่างสมบูรณ์หรือ (หมายเหตุ: pshare ตั้งค่ากราฟการแชร์ลิงค์ใน ALTQ และเสียดสีโค้งเรียลไทม์คุณสามารถเห็นสิ่งนี้ในย่อหน้าด้านบนการกำหนดค่าตัวอย่าง)

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

บทเรียนบางบทบอกว่าผลรวมของเส้นโค้งแบบเรียลไทม์ทั้งหมดอาจไม่สูงกว่า 80% ของความเร็วของเส้น แต่บางคนบอกว่าจะต้องไม่สูงกว่า 70% ของความเร็วของเส้น เป็นที่หนึ่งที่ถูกต้องหรือพวกเขาอาจผิดทั้งคู่?

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

บทช่วยสอนหนึ่งกล่าวว่าคุณจะลืมทฤษฎีทั้งหมด ไม่ว่าสิ่งต่างๆจะทำงานอย่างไร (ตัวกำหนดตารางเวลาและการกระจายแบนด์วิดท์) ให้จินตนาการถึงสามเส้นโค้งตาม "รูปแบบความคิดที่เรียบง่าย" ดังต่อไปนี้: แบบเรียลไทม์คือแบนด์วิดท์ที่รับประกันว่า link-share คือแบนด์วิดท์ที่คลาสนี้ต้องการที่จะพึงพอใจอย่างเต็มที่ แต่ไม่สามารถรับประกันความพึงพอใจได้ ในกรณีที่มีแบนด์วิดท์มากเกินไปคลาสอาจได้รับแบนด์วิดท์มากกว่าที่จำเป็นเพื่อให้เป็นที่พอใจ แต่ก็ไม่อาจใช้เกินขีด จำกัด บนได้ เพื่อให้ใช้งานได้ทั้งหมดผลรวมของแบนด์วิดท์แบบเรียลไทม์ทั้งหมดอาจไม่เกิน xx% ของความเร็วของสาย (ดูคำถามข้างต้นเปอร์เซ็นต์แตกต่างกันไป) คำถาม: สิ่งนี้มีความแม่นยำมากขึ้นหรือน้อยลงหรือความเข้าใจผิดทั้งหมดของ HSFC?

สิ่งนี้ถูกต้อง

และถ้าข้อสันนิษฐานข้างต้นมีความแม่นยำจริง ๆ การจัดลำดับความสำคัญของโมเดลนั้นอยู่ที่ไหน เช่นทุกคลาสอาจมีแบนด์วิดท์แบบเรียลไทม์ (รับประกัน) แบนด์วิดท์ลิงก์แชร์ (ไม่รับประกัน) และอาจมีขีด จำกัด บน แต่บางคลาสมีความต้องการลำดับความสำคัญสูงกว่าคลาสอื่น ในกรณีนี้ฉันยังต้องจัดลำดับความสำคัญอย่างใดแม้ในเวลาจริงการจราจรของชั้นเรียนเหล่านั้น ฉันจะจัดลำดับความสำคัญโดยความชันของเส้นโค้งหรือไม่ และถ้าเป็นเช่นนั้นเส้นโค้งใด เส้นโค้งแบบเรียลไทม์? เส้นโค้งลิงค์แบ่งปัน? เส้นโค้งขีด จำกัด บน? พวกเขาทุกคน? ฉันจะให้ความชันเดียวกันหรือแต่ละอันต่างกันและหาวิธีความชันที่ถูกต้องได้ไหม?

ความแตกต่างระหว่างเช่น HFSC และ HTB คือ HFSC จะช่วยให้คุณกำหนดจำนวนการจัดลำดับความสำคัญที่คุณต้องการ คุณทำได้โดยกำหนดขอบเขตขั้นต่ำและสูงสุดด้วยค่า 'dmax'

ในที่สุดคู่มือที่ดูเหมือนจะอธิบายถึงความไม่สอดคล้องกันส่วนใหญ่และวิธีการนำไปปฏิบัติในปัจจุบันแตกต่างจากเอกสารต้นฉบับ:

http://manpages.ubuntu.com/manpages/precise/man7/tc-hfsc.7.html

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

ฉันคิดว่าในที่สุดฉันก็จะยอมแพ้กับ HFSC หากคุณสามารถตั้งค่า HFSC ของคุณได้อาจเป็น QoS ที่ดีที่สุดที่คุณจะได้รับ แต่โอกาสที่คุณสับสนอย่างสมบูรณ์จะสูงกว่าโอกาสที่คุณจะประสบความสำเร็จ

หากคุณไม่สามารถรับผู้เขียนต้นฉบับได้ฉันจะลองทำสิ่งต่อไปนี้:

1. เข้าสู่ซอร์สโค้ดเคอร์เนลของ linux และค้นหาไฟล์ C ที่ใช้ "กรอบการกำหนดเวลา TC"
2. ดูที่ส่วนหัวและค้นหารหัส
3. โปรแกรมเมอร์อีเมลของ "กรอบการกำหนดเวลา TC" ขอให้พวกเขาเขียนบทความเกี่ยวกับการใช้งาน

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