ขนาดถังเป็น tbf


11

ฉันได้อ่านหลาย ๆ ครั้งเกี่ยวกับตัวกรองโทเค็นโทเค็นของ Linux (tbf)แล้วและฉันก็ยังไม่เข้าใจว่าฉันควรคำนวณburstและlatencyพารามิเตอร์อย่างไรอย่างน่าละอายกับฉัน :(

ฉันคิดว่าเวลาแฝงที่เหมาะสมประมาณ 50 ms ตกลง แต่สิ่งที่ควรจะมีมูลค่าออกมา?

manpage พูดว่า:

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

ดังนั้นเวลาแฝงเกี่ยวข้องกับ bucket และตัวกรองอย่างไร มีสูตรคำนวณหรือไม่? หรือมันเป็นเพียงเรื่องของ "ตกลง, X ไบต์ของการระเบิดและ Y วินาทีของความล่าช้าเป็นสิ่งที่ดีสำหรับฉัน"?


1
สำหรับทุกคนที่พบสิ่งที่ไม่ชัดเจน: tbfเป็นส่วนหนึ่งของกรอบการควบคุมปริมาณการใช้งาน Linux man tbfหรือman tc-tbfควรนำเอกสารขึ้นมา
Derobert

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

ในที่สุดก็เพิ่มในคำอธิบายแนวคิด
Derobert

คำตอบ:


16

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

$ egrep '^CONFIG_HZ_[0-9]+' /boot/config-`uname -r`
CONFIG_HZ_250=y

ดังนั้น HZ ในระบบของฉันคือ 250 หากต้องการอัตรา 10mbps ฉันต้องมีburstอย่างน้อย 10,000,000 บิต / วินาที sec 250 Hz = 40,000 บิต = 5,000 ไบต์ (โปรดสังเกตว่าค่าที่สูงกว่าใน manpage มาจากเมื่อ HZ = 100 เป็นค่าเริ่มต้น)

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

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

แบบจำลองแนวคิดของตัวกรองถังโทเค็น

ถังกรองโทเค็น

"bucket" เป็นวัตถุเชิงเปรียบเทียบ คุณสมบัติที่สำคัญของมันคือมันสามารถเก็บโทเค็นได้และจำนวนโทเค็นที่สามารถเก็บได้นั้นมี จำกัด - ถ้าคุณพยายามเพิ่มอีกมัน "ล้น" และโทเค็นพิเศษจะหายไป (เช่นพยายามใส่น้ำมากเกินไปใน ถังจริง) burstขนาดของถังที่เรียกว่า

เพื่อส่งแพ็กเก็ตไปยังเครือข่ายจริงแพ็คเก็ตนั้นจะต้องได้รับโทเค็นเท่ากับขนาดเป็นไบต์หรือmpu(แล้วแต่จำนวนใดจะใหญ่กว่า)

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

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

ชิ้นสุดท้ายคือเครื่องทำโทเค็นที่เพิ่มrate/ HZโทเค็นลงในถังทุกเห็บ (นี่คือสาเหตุที่ที่ฝากข้อมูลของคุณต้องมีขนาดใหญ่อย่างน้อยนี้มิฉะนั้นโทเค็นที่เพิ่งสร้างใหม่บางส่วนจะถูกยกเลิกทันที)


ฉันคิดว่ามันแตกต่างกันตรงที่คุณยอมให้เกินอัตราสักครู่หนึ่งซึ่งถูกชดเชยด้วยอัตราที่ต่ำกว่าในภายหลังเพื่อให้ถึงอัตราเฉลี่ย ...
sebelk

@sebelk ผมไม่แน่ใจว่าโดยไม่ต้อง RTFS แต่มันจะทำงานออกมาให้ผลแบบเดียวกันยกเว้นสำหรับกรณีที่เมื่อ TBF rateถูกเพิ่มลงในอินเตอร์เฟซที่กำลังทำงานอยู่ข้างต้น หรือไม่เช่นเดียวกับคุณอาจจะบอกว่าถังเริ่มเต็ม ...
derobert

@sebelk: นั่นก็เป็นจริงเช่นกัน ให้บอกว่าเรามีที่เก็บข้อมูล 1000 ไบต์ (ขนาดแตกออก) และอัตราโทเค็นคือ 10 ไบต์ราคา ที่สอง ดังนั้นหากไม่มีแพ็กเก็ตมาถึง 100 วินาทีที่ฝากข้อมูลจะถูกเติมเต็ม จากนั้นแพ็กเก็ต 1,000 ไบต์ถัดไปที่มาถึงจะถูกส่งทันทีโดยไม่ต้องถูกจัดคิว อัตราการส่งข้อมูลที่สูงกว่าอัตราการสร้างโทเค็น
Bjarke Freund-Hansen

5

คำตอบอื่น ๆ ที่เติมเต็มให้กับ Derobert

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

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

ตัวอย่างเช่นสมมติว่าพารามิเตอร์tbf burstของคุณคือ 10K ไบต์และพารามิเตอร์อัตรา tbf ของคุณคือ 2K ไบต์ / วินาทีและขณะนี้คุณมีอัตรา จำกัด (เช่นการระเบิดหมดลงดังนั้นคุณจึง จำกัด การส่งที่ 2kbps) หากคุณลดความเร็วที่คุณส่งลงไปที่ 1Kbps เป็นเวลา 10 วินาทีโดยสมัครใจคุณจะสะสม 10K ไบต์เป็นค่าเผื่อการสำรองข้อมูลอีกครั้ง (= (2000 [ไบต์ / วินาที] - 1,000 [ไบต์ / วินาที]) * 10 วินาที) การทำให้ต่ำกว่า 1kbps นานกว่า 10 วินาทีจะไม่มีผลเนื่องจาก tbf ไม่อนุญาตให้คุณไม่ได้รับอนุญาตให้สะสมมากกว่าพารามิเตอร์burst

หากคุณหยุดการใช้จ่ายโดยสิ้นเชิงคุณจะได้รับเงินสำรองพิเศษอีกครั้งใน 5 วินาที (= 100000 [ไบต์] / 2000 [ไบต์ / วินาที])

คุณไม่จำเป็นต้องได้รับเงินสำรองทั้งหมดกลับมาใช้คุณสามารถใช้มากเท่าที่คุณสะสมได้

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

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.