RahuNAS กับ Bandwidth Shaping ที่เจอกับตัวถึงเข้าใจปัญหา

Traffic ของ RahuNAS รุ่นปรับปรุงเฉพาะกิจ (Site หอพัก Inter มหาวิทยาลัยขอนแก่น)
รับ Load ประมาณ 1000 users + bandwidth shaping per user

Internet link => 3BB FTTx 100/50 Mbps - Business Use x 2 เส้น ทำ load balance โดย script ที่ร่วมกันเขียนกับ พี่ Theppitak Karoonboonyanan + ปรับปรุงเรื่อง connection mark เพื่อบังคับให้ connection เดียวกันออกเส้นเดิม

Server เป็น HP pavilion HPE (Core i7) อันนี้ไม่มีสิทธิ์เลือก เพราะมีคนเข้าไปทำระบบก่อน ซื้อไว้ก่อนแล้ว (เจอ NIC Gigabit TP-Link ก็อึ้งไปพักนึง) ณ ตอนนี้ คือ ภาวนาไม่ให้มันกลั้นใจตายเป็นพอ ตอนนี้ ก็หวังพึ่ง Xyzel ES1100 => HP JE005A => Cisco 2960S => TP-Link (Server) -_-'' แต่วิ่งมาหลายวันก็พอไหวอยู่

ส่วน RahuNAS สำหรับงานนี้ เจอประสบการณ์ใหม่เรื่อง bandwidth shaping
จริง ๆ ปัญหาเกิดให้เห็นก่อน ตอนใช้ wondershaper เพราะพอเปิดทำงาน ก็ถึงกับงงว่าทำไม download speed ได้ไม่เกิน 12-15 Mbps ในใจก็นึกโทษ 3BB ด้วยความไม่ไว้ใจเป็นทุนเดิม เหอ ๆ .... แต่เช็คไปเช็คมา ผู้ร้ายตัวจริง คือ wondershaper ที่ใช้ tc-htb (HTB: Hierarchy Token Bucket) ในการทำเรื่อง bandwidth shaping ซึ่งตอนแรกก็งงมาก ว่ามันเกิดจากสาเหตุอะไร จนมาถึงบางอ้อ ก็ตอนอ่าน http://linux.die.net/man/8/tc-htb

=== >8 ===
Notes

Due to Unix timing constraints, the maximum ceil rate is not infinite and may in fact be quite low. On Intel,
there are 100 timer events per second, the maximum rate is that rate at which 'burst' bytes are sent each
timer tick. From this, the minimum burst size for a specified rate can be calculated. For i386, a 10mbit rate
requires a 12 kilobyte burst as 100*12kb*8 equals 10mbit. 
=== 8< ===

และอ่านต่อที่ http://linux.die.net/man/7/time
ก็พบว่า default ของ kernel ตั้งแต่รุ่น 2.6.13 คือ 250 Hz ซึ่งยันกับ default config ของ Debian stock kernel รุ่น 2.6.32-5-amd64

...
...
CONFIG_HZ_250=y
CONFIG_HZ=250
...
...

เรื่องนี้ผ่าน ๆ ตา ตอนดู code ipset เนื่องจากมีคำหนึ่งที่ให้ไล่หาความหมายคือ jiffies (1/Hz) - http://en.wikipedia.org/wiki/Jiffy_%28time%29

ซึ่ง wondershaper ตั้ง burst ไว้ 6k

6 * 250 * 8 = 12000 ~ 12 Mbps

ซึ่งไม่พอสำหรับ bandwidth 100 Mbps อยู่ดี

และที่ซ้ำร้ายคือ RahuNAS หนักกว่า เพราะไม่ได้กำหนด burst ไว้ เลยเป็น default ที่ 1.5k

1.5 * 250 * 8 = 3000 ~ 3 Mbps

** แสดงว่า RahuNAS ตั้ง shape ยังไง ก็วิ่งไม่เกิน ~3 Mbps T_T **
ว่าไปแล้วก็นั่งขำตัวเอง ก็ตัวโปรแกรม ดันเกิดในยุคที่ Internet bandwidth มีอยู่ 1 - 2 Mbps อย่างหรู หุหุ

สำหรับ link 100 Mbps (ceil) ต้องคำนวณ burst ใหม่

102400 / 8 / 250 = 51.2 ~ 52k

สำหรับ RahuNAS ใน site นี้ แก้สดใน rahunas-bandwidth script อยู่ ใช้สูตรคำนวณแบบเดียวกัน
งานนี้ เจอกับตัวเอง ถึงกับมืดอยู่วันสองวันเลยทีเดียว (ก่อนหน้านี้เคยมีคน report แต่ไม่ได้เจอกับตัว ก็เลยไม่ได้สนใจ คิดว่าตัว RahuNAS ไม่ใช่ปัญหา)

รุ่น legacy ก็แก้แบบนี้ไปก่อน
ส่วนรุ่น -next ว่าจะลองหาเวลาทดสอบ codel (http://www.bufferbloat.net/projects/codel/wiki) แทน
sfq (SFQ - Stochastic Fairness Queueing - http://linux.die.net/man/8/tc-sfq) ดู เพราะว่าจะเขียนเสร็จ kernel ที่มากับ Debian รุ่นนั้น น่าจะมี codel support มาให้แล้ว

Happy Hacking