Tôi đã đọc nhiều lần về bộ lọc mã thông báo của Linux (tbf) và tôi vẫn không hiểu đầy đủ về cách tôi nên tính toán burstvà latencytham số, xấu hổ với tôi :(

Tôi cho rằng độ trễ hợp lý là khoảng 50 ms. OK, nhưng giá trị nào nên bùng nổ?

Trang này nói:

Tính toán sau có tính đến kích thước của thùng, tỷ lệ và có thể là đỉnh (nếu được đặt). Hai tham số này là loại trừ lẫn nhau.

Vì vậy, độ trễ liên quan đến xô và bộ lọc như thế nào? Có một công thức để tính toán nó? Hay đơn giản chỉ là vấn đề "OK, X byte nổ và Y giây có độ trễ tốt cho tôi"?

Từ trang chủ, hạn chế duy nhất burstlà nó phải đủ cao để cho phép tốc độ được cấu hình của bạn: nó phải ở mức tối thiểu / HZ. HZ là một tham số cấu hình kernel; bạn có thể tìm ra nó là gì trên hệ thống của bạn bằng cách kiểm tra cấu hình kernel của bạn. Ví dụ: trên Debian, bạn có thể:

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

vì vậy HZ trên hệ thống của tôi là 250. Để đạt tốc độ 10mbps, do đó tôi cần burstít nhất 10.000.000 bit / giây ÷ 250 Hz = 40.000 bit = 5000 byte. (Lưu ý giá trị cao hơn trong trang chủ là từ khi HZ = 100 là mặc định).

Nhưng ngoài điều này, burstcũng là một công cụ chính sách. Nó cấu hình mức độ mà bạn có thể sử dụng ít băng thông hơn bây giờ để "lưu" nó để sử dụng trong tương lai. Một điều phổ biến ở đây là bạn có thể muốn cho phép tải xuống nhỏ (giả sử, một trang web) đi rất nhanh, trong khi điều chỉnh các lượt tải lớn. Bạn làm điều này bằng cách tăng burstlên kích thước bạn xem xét tải xuống nhỏ. (Mặc dù, bạn thường chuyển sang một qdisc đẳng cấp như htb, vì vậy bạn có thể phân đoạn các loại lưu lượng khác nhau.)

Vì vậy: bạn định cấu hình cụm để ít nhất đủ lớn để đạt được mong muốn rate. Ngoài ra, bạn có thể tăng thêm, tùy thuộc vào những gì bạn đang cố gắng đạt được.

Mô hình khái niệm của bộ lọc mã thông báo

Một "cái xô" là một đối tượng ẩn dụ. Thuộc tính quan trọng của nó là nó có thể chứa mã thông báo và số lượng mã thông báo có thể giữ bị hạn chế nếu bạn cố thêm, nó "tràn" và mất thêm mã thông báo (giống như cố gắng cho quá nhiều nước vào xô thực tế). Kích thước của xô được gọi burst.

Để thực sự truyền một gói lên mạng, gói đó phải có được các mã thông báo bằng kích thước của nó tính bằng byte hoặc mpu(tùy theo giá trị nào lớn hơn).

Có (hoặc có thể) một dòng (hàng đợi) các gói đang chờ mã thông báo. Điều này xảy ra khi thùng rỗng hoặc thay thế có ít mã thông báo hơn kích thước của gói. Chỉ có rất nhiều phòng trên vỉa hè phía trước xô và số lượng phòng (tính bằng byte) được đặt trực tiếp bởi limit. Ngoài ra, nó có thể được đặt gián tiếp với latency(trong một thế giới lý tưởng, phép tính sẽ là rate× latency).

Khi kernel muốn gửi một gói ra khỏi giao diện được lọc, nó sẽ cố gắng đặt gói ở cuối dòng. Nếu không có bất kỳ phòng nào trên vỉa hè, điều đó thật không may cho gói tin, bởi vì ở cuối vỉa hè là một cái hố không đáy và hạt nhân làm rơi gói tin.

Phần cuối cùng là một máy tạo mã thông báo có thêm rate/ HZmã thông báo vào nhóm mỗi lần đánh dấu. (Đây là lý do tại sao xô của bạn ít nhất phải lớn như vậy, nếu không, một số mã thông báo mới được đúc sẽ bị loại bỏ ngay lập tức).

Một câu trả lời khác để bổ sung cho derobert.

Đầu tiên trên CPU Intel hiện đại, hướng dẫn sử dụng đã hết hạn. CPU hiện đại có bộ định thời độ phân giải cao và Linux hiện đại được đánh dấu ít hơn - nghĩa đen là không có dấu thời gian. Do đó, tất cả những bình luận làm cho các thùng đủ lớn để giữ các mã thông báo trong một bộ đếm thời gian là không liên quan. Trong thực tế, sự tương tự xô chỉ có ở đó để giúp người dùng hiểu được sự tương tác giữa độ chi tiết của bộ đếm thời gian và tốc độ gửi. Bây giờ Linux có bộ định thời nano giây trên phần cứng hiện đại, nó mất đi tính hữu dụng.

Đối với TBF, tham số cụm là số byte có thể được gửi ở tốc độ không giới hạn trước khi giới hạn tốc độ (được chỉ định bởi tốc độ ) được kích hoạt. Một khi giới hạn tốc độ được kích hoạt theo cách duy nhất để bật lại là giới hạn việc gửi của bạn xuống dưới tốc độ đó .

Ví dụ: giả sử tham số cụm tbf của bạn là 10K byte và tham số tốc độ tbf của bạn là 2K byte / giây và hiện tại bạn bị giới hạn tốc độ (nghĩa là cụm đã hết, vì vậy bạn bị giới hạn gửi ở tốc độ 2kb / giây). Nếu bạn tự nguyện giảm tốc độ bạn gửi xuống còn 1Kb / giây trong 10 giây, bạn sẽ tích lũy lại khoản trợ cấp 10 byte byte của mình (= (2000 [byte / giây] - 1000 [byte / giây]) * 10 giây). Giữ nó dưới 1kbps trong hơn 10 giây sẽ không có hiệu lực vì tbf không cho phép bạn không được phép tích lũy nhiều hơn tham số cụm .

Nếu bạn đã ngừng chi tiêu hoàn toàn thì bạn sẽ nhận lại khoản trợ cấp bùng nổ của mình sau 5 giây (= 100000 [byte] / 2000 [byte / giây]).

Bạn không cần phải lấy lại toàn bộ số tiền trợ cấp của mình để sử dụng nó, bạn có thể sử dụng bao nhiêu tiền bạn đã tích lũy.

Một cách khác để xem xét điều này là: bạn được phép gửi các byte nổ với tốc độ không giới hạn, sau đó tốc độ trung bình dài hạn của bạn không bao giờ có thể vượt quá tốc độ . Tuy nhiên, vì là mức trung bình dài hạn, nếu bạn giảm xuống dưới tốc độ, bạn được phép bắt kịp bằng cách gửi ở tốc độ tối đa - nhưng ngay cả khi đó bạn chỉ được phép gửi đầy đủ cho hầu hết các byte bùng nổ (và nếu điều đó không cho phép bạn bắt kịp bạn không thể).

Một nếp nhăn khác là TBF có hai trong số các bộ hạn chế tốc độ này và lưu lượng truy cập của bạn phải đi qua cả hai. Trong cái thứ hai, tham số cụm được gọi là mtu và, tốc độ được gọi là đỉnh . Bạn phải sử dụng cái thứ hai này để hạn chế tốc độ mà cái đầu tiên có thể gửi. Sử dụng cái thứ hai này là tùy chọn và nếu bạn không sử dụng nó, các vụ nổ được gửi ở tốc độ thiết bị.

Cuối cùng, tbf có một tham số giới hạn . Nếu chương trình liên tục gửi nhanh hơn tốc độ , thì các gói sẽ tích lũy trong hàng đợi. Không có bộ nhớ kernel vô hạn, vì vậy giới hạn cho biết có bao nhiêu byte có thể tích tụ trước khi kernel bắt đầu loại bỏ các gói.