Có ai thực sự hiểu cách lập lịch trình HFSC trong Linux / BSD không?

Tôi đã đọc bài viết PostScript SIGCOMM '97 gốc về HFSC, nó rất kỹ thuật, nhưng tôi hiểu khái niệm cơ bản. Thay vì đưa ra một đường cong dịch vụ tuyến tính (như với hầu hết các thuật toán lập lịch khác), bạn có thể chỉ định một đường cong dịch vụ lồi hoặc lõm và do đó có thể tách rời băng thông và độ trễ. Tuy nhiên, mặc dù bài báo này đề cập đến loại thuật toán lập lịch được sử dụng (thời gian thực và chia sẻ liên kết), nó luôn chỉ đề cập MỘT đường cong trên mỗi lớp lập lịch (việc tách rời được thực hiện bằng cách chỉ định đường cong này, chỉ cần một đường cong cho điều đó ).

Bây giờ HFSC đã được triển khai cho BSD (OpenBSD, FreeBSD, v.v.) bằng cách sử dụng khung lập lịch ALTQ và nó đã được Linux triển khai bằng cách sử dụng khung lập lịch TC (một phần của iproute2). Cả hai triển khai đều bổ sung hai đường cong dịch vụ bổ sung, KHÔNG có trong bài báo gốc! Đường cong dịch vụ thời gian thực và đường cong dịch vụ giới hạn trên. Một lần nữa, xin lưu ý rằng bài báo gốc đề cập đến hai thuật toán lập lịch (thời gian thực và chia sẻ liên kết), nhưng trong bài báo đó cả hai đều hoạt động với một đường cong dịch vụ duy nhất. Chưa bao giờ có hai đường cong dịch vụ độc lập cho một trong hai như bạn hiện thấy trong BSD và Linux.

Thậm chí tệ hơn, một số phiên bản ALTQ dường như thêm ưu tiên hàng đợi bổ sung vào HSFC (cũng không có thứ gọi là ưu tiên trong bài báo gốc). Tôi đã tìm thấy một số BSD HowTo đề cập đến cài đặt ưu tiên này (mặc dù trang man của bản phát hành ALTQ mới nhất không biết thông số nào như vậy cho HSFC, vì vậy chính thức nó thậm chí không tồn tại).

Tất cả điều này làm cho việc lập lịch trình HFSC thậm chí còn phức tạp hơn thuật toán được mô tả trong bài báo gốc và có rất nhiều hướng dẫn trên Internet thường mâu thuẫn với nhau, một tuyên bố ngược lại với thuật toán khác. Đây có lẽ là lý do chính tại sao dường như không ai thực sự hiểu cách lập lịch trình HFSC thực sự hoạt động. Trước khi tôi có thể đặt câu hỏi của mình, chúng tôi cần một thiết lập mẫu nào đó. Tôi sẽ sử dụng một cái rất đơn giản như trong hình dưới đây:

văn bản thay thế http://f.imagehost.org/0177/hfsc-test-setup.png

Dưới đây là một số câu hỏi tôi không thể trả lời vì các hướng dẫn mâu thuẫn với nhau:

1. Tôi cần một đường cong thời gian thực để làm gì? Giả sử A1, A2, B1, B2 là tất cả chia sẻ liên kết 128 kbit / s (không có đường cong thời gian thực cho một trong hai), thì mỗi cái sẽ nhận được 128 kbit / s nếu gốc có 512 kbit / s để phân phối (và Tất nhiên A và B đều là 256 kbit / s), phải không? Tại sao tôi cũng cung cấp cho A1 và B1 một đường cong thời gian thực với 128 kbit / s? Điều này sẽ tốt cho cái gì? Để ưu tiên cao hơn cho hai người? Theo bài báo gốc, tôi có thể ưu tiên cao hơn cho họ bằng cách sử dụng đường cong , đó là tất cả những gì HFSC muốn nói. Bằng cách cung cấp cho cả hai lớp một đường cong [256kbit / s 20ms 128kbit / s], cả hai đều có mức độ ưu tiên cao gấp đôi so với A2 và B2 (vẫn chỉ nhận được trung bình 128 kbit / s)

2. Băng thông thời gian thực có được tính vào băng thông chia sẻ liên kết không? Ví dụ: nếu cả A1 và B1 chỉ có băng thông chia sẻ liên kết thời gian thực 64kbit / giây và 64kbit / giây, điều đó có nghĩa là một khi chúng được phục vụ 64kbit / giây qua thời gian thực, thì yêu cầu chia sẻ liên kết của chúng cũng được thỏa mãn nhận được băng thông dư thừa, nhưng hãy bỏ qua điều đó trong một giây) hoặc điều đó có nghĩa là họ nhận thêm 64 kbit / s thông qua liên kết chia sẻ? Vì vậy, mỗi lớp có một "yêu cầu" băng thông của thời gian thực cộng với chia sẻ liên kết? Hoặc một lớp chỉ có yêu cầu cao hơn đường cong thời gian thực nếu đường cong chia sẻ liên kết cao hơn đường cong thời gian thực (yêu cầu chia sẻ liên kết hiện tại bằng với yêu cầu chia sẻ liên kết đã chỉ định trừ đi băng thông thời gian thực đã cung cấp cho điều này lớp học)?

3. Là đường giới hạn trên cũng được áp dụng cho thời gian thực, chỉ để chia sẻ liên kết, hoặc có thể cho cả hai? Một số hướng dẫn nói một cách, một số nói theo cách khác. Một số thậm chí cho rằng giới hạn trên là tối đa cho băng thông thời gian thực + băng thông chia sẻ liên kết? Sự thật là gì?

4. Giả sử A2 và B2 đều là 128 kbit / s, liệu có khác biệt gì không nếu A1 và B1 chỉ là chia sẻ liên kết 128 kbit / s, hoặc 64 kbit / s thời gian thực và chia sẻ liên kết 128 kbit / s, và nếu vậy , khác nhau cái gì?

5. Nếu tôi sử dụng đường cong thời gian thực riêng biệt để tăng mức độ ưu tiên của các lớp, tại sao tôi lại cần "đường cong"? Tại sao thời gian thực không phải là giá trị cố định và chia sẻ liên kết cũng là giá trị cố định? Tại sao cả hai đường cong? Sự cần thiết cho các đường cong là rõ ràng trong bài báo gốc, bởi vì chỉ có một thuộc tính của loại đó cho mỗi lớp. Nhưng bây giờ, có ba thuộc tính (thời gian thực, chia sẻ liên kết và giới hạn trên), tôi vẫn cần những đường cong nào cho mỗi thuộc tính? Tại sao tôi muốn hình dạng đường cong (không phải băng thông trung bình, nhưng độ dốc của chúng) khác nhau đối với lưu lượng truy cập chia sẻ liên kết và thời gian thực?

6. Theo tài liệu nhỏ có sẵn, các giá trị đường cong thời gian thực hoàn toàn bị bỏ qua cho các lớp bên trong (lớp A và B), chúng chỉ được áp dụng cho các lớp lá (A1, A2, B1, B2). Nếu đó là sự thật, tại sao cấu hình mẫu ALTQ HFSC (tìm kiếm cấu hình mẫu 3.3 ) đặt các đường cong thời gian thực trên các lớp bên trong và tuyên bố rằng những cái đó đặt tỷ lệ được bảo đảm của các lớp bên trong đó? Điều đó không hoàn toàn vô nghĩa sao? (lưu ý: pshare đặt đường cong chia sẻ liên kết trong ALTQ và ghi lại đường cong thời gian thực; bạn có thể thấy điều này trong đoạn trên cấu hình mẫu).

7. Một số hướng dẫn nói rằng tổng của tất cả các đường cong thời gian thực có thể không cao hơn 80% tốc độ đường truyền, một số khác nói rằng nó không được cao hơn 70% tốc độ đường truyền. Cái nào đúng hay cả hai đều sai?

8. Một hướng dẫn cho biết bạn sẽ quên tất cả các lý thuyết. Bất kể mọi thứ thực sự hoạt động như thế nào (bộ lập lịch và phân phối băng thông), hãy tưởng tượng ba đường cong theo "mô hình tâm trí đơn giản hóa" sau: thời gian thực là băng thông được đảm bảo mà lớp này sẽ luôn có được. link-share là băng thông mà lớp này muốn trở nên hoàn toàn hài lòng, nhưng sự hài lòng không thể được đảm bảo. Trong trường hợp có băng thông dư thừa, lớp thậm chí có thể được cung cấp nhiều băng thông hơn mức cần thiết để trở nên hài lòng, nhưng nó có thể không bao giờ sử dụng nhiều hơn giới hạn trên. Để tất cả điều này hoạt động, tổng của tất cả các băng thông thời gian thực có thể không vượt quá xx% tốc độ đường truyền (xem câu hỏi ở trên, tỷ lệ phần trăm khác nhau). Câu hỏi: Điều này nhiều hay ít chính xác hay là sự hiểu lầm hoàn toàn về HSFC?

9. Và nếu giả định ở trên là thực sự chính xác, ưu tiên ở đâu trong mô hình đó? Ví dụ, mọi lớp có thể có băng thông thời gian thực (được bảo đảm), băng thông chia sẻ liên kết (không được bảo đảm) và có thể có giới hạn trên, nhưng vẫn có một số lớp có nhu cầu ưu tiên cao hơn các lớp khác. Trong trường hợp đó, tôi vẫn phải ưu tiên bằng cách nào đó, ngay cả trong lưu lượng truy cập thời gian thực của các lớp đó. Tôi sẽ ưu tiên theo độ dốc của các đường cong? Và nếu vậy, đường cong nào? Đường cong thời gian thực? Đường cong chia sẻ liên kết? Đường cong giới hạn trên? Tất cả bọn họ? Tôi sẽ cung cấp cho tất cả chúng cùng một độ dốc hoặc mỗi một độ dốc khác nhau và làm thế nào để tìm ra độ dốc phù hợp?

Tôi vẫn không mất hy vọng rằng có ít nhất một tay đầy người trên thế giới này thực sự hiểu HFSC và có thể trả lời chính xác tất cả những câu hỏi này. Và làm như vậy mà không mâu thuẫn với nhau trong các câu trả lời sẽ thực sự tốt đẹp ;-)

Đọc các bài báo về HFSC và anh em họ của nó không phải là một cách tốt để hiểu nó. Mục tiêu chính của bài viết HFSC là cung cấp một bằng chứng toán học nghiêm ngặt về các tuyên bố của nó, không giải thích cách thức hoạt động của nó. Thật vậy, bạn không thể hiểu cách thức hoạt động của nó từ giấy HFSC, bạn cũng phải đọc các tài liệu mà nó tham khảo. Nếu bạn có một số vấn đề với khiếu nại hoặc bằng chứng của họ thì liên hệ với các tác giả của các bài báo có thể là một ý tưởng tốt, nếu không tôi nghi ngờ họ sẽ quan tâm đến việc nghe từ bạn.

Tôi đã viết một hướng dẫn cho HFSC . Đọc nó nếu giải thích của tôi dưới đây không rõ ràng.

Tôi cần một đường cong thời gian thực để làm gì? Giả sử A1, A2, B1, B2 là tất cả chia sẻ liên kết 128 kbit / s (không có đường cong thời gian thực cho một trong hai), thì mỗi cái sẽ nhận được 128 kbit / s nếu gốc có 512 kbit / s để phân phối (và Tất nhiên A và B đều là 256 kbit / s), phải không? Tại sao tôi cũng cung cấp cho A1 và B1 một đường cong thời gian thực với 128 kbit / s? Điều này sẽ tốt cho cái gì? Để ưu tiên cao hơn cho hai người? Theo bài báo gốc, tôi có thể ưu tiên cao hơn cho họ bằng cách sử dụng đường cong, đó là tất cả những gì HFSC muốn nói. Bằng cách cung cấp cho cả hai lớp một đường cong [256kbit / s 20ms 128kbit / s], cả hai đều có mức độ ưu tiên gấp đôi so với A2 và B2 (vẫn chỉ nhận trung bình 128 kbit / s)

Đường cong thời gian thực và đường cong chia sẻ liên kết được đánh giá theo những cách khác nhau. Đường cong thời gian thực tính đến những gì một lớp đã làm trong toàn bộ lịch sử của nó. Nó phải làm điều đó để cung cấp băng thông chính xác và phân bổ độ trễ. Nhược điểm không phải là điều mà hầu hết mọi người trực giác nghĩ là công bằng . Theo thời gian thực, nếu một lớp mượn băng thông khi không ai muốn nó, nó sẽ bị phạt khi người khác muốn nó quay lại sau. Điều này có nghĩa là theo thời gian thực đảm bảo một lớp không thể có băng thông trong một thời gian dài bởi vì nó đã sử dụng nó sớm hơn, khi không ai muốn nó.

Việc chia sẻ liên kết là công bằng, ở chỗ nó không phạt một lớp vì sử dụng băng thông dự phòng. Tuy nhiên, điều này có nghĩa là nó không thể cung cấp đảm bảo độ trễ mạnh mẽ.

Sự tách biệt của chia sẻ liên kết với việc cung cấp bảo đảm độ trễ là điều mới mà HFSC mang đến cho bảng và bài báo nói rất nhiều trong câu mở đầu của nó: Trong bài viết này, chúng tôi nghiên cứu các mô hình và thuật toán quản lý tài nguyên phân cấp hỗ trợ cả chia sẻ liên kết và đảm bảo dịch vụ thời gian thực với độ trễ tách rời (ưu tiên) và phân bổ băng thông. Từ khóa trong câu đó được tách rời. Được dịch, điều đó có nghĩa là bạn sẽ nói rằng băng thông không được sử dụng sẽ được chia sẻ với ls như thế nào và chỉ định những gì đảm bảo thời gian thực (còn gọi là đảm bảo độ trễ) là cần thiết với rt. Hai là trực giao.

Băng thông thời gian thực có được tính vào băng thông chia sẻ liên kết không?

Vâng. Trong bài viết HFSC, họ định nghĩa băng thông theo những gì lớp đã gửi vì lớp đã bị tồn đọng (tức là có các gói đang chờ để gửi). Sự khác biệt duy nhất giữa rt và ls là rt mong đợi từ mỗi khi lớp trở nên bị tồn đọng và tính toán băng thông được bảo đảm thấp nhất từ ​​tập hợp đó, trong khi chia sẻ liên kết chỉ nhìn từ lần cuối cùng lớp bị đăng nhập. Vì vậy, rt mất nhiều byte xem xét hơn ls, nhưng mỗi byte ls xem xét cũng được xem xét bởi rt.

Là đường giới hạn trên cũng được áp dụng cho thời gian thực, chỉ để chia sẻ liên kết, hoặc có thể cho cả hai?

Giới hạn trên không ngăn các gói được gửi để đáp ứng điều kiện thời gian thực. Các gói được gửi trong điều kiện thời gian thực vẫn được tính vào giới hạn trên và do đó có thể trì hoãn một gói được gửi trong điều kiện chia sẻ liên kết trong tương lai. Đây là một sự khác biệt khác giữa thời gian thực và chia sẻ liên kết.

Giả sử A2 và B2 đều là 128 kbit / s, liệu có khác biệt gì không nếu A1 và B1 chỉ là chia sẻ liên kết 128 kbit / s, hoặc 64 kbit / s thời gian thực và chia sẻ liên kết 128 kbit / s, và nếu vậy , khác nhau cái gì?

Vâng, nó làm cho một sự khác biệt. Như đã giải thích ở trên nếu bạn sử dụng thời gian thực, độ trễ được đảm bảo nhưng liên kết không được chia sẻ công bằng (và đặc biệt là lớp có thể bị chết đói băng thông) và các giới hạn trên không được thực thi. Nếu bạn sử dụng chia sẻ liên kết thì độ trễ không được đảm bảo, nhưng chia sẻ liên kết là công bằng, không có nguy cơ chết đói và giới hạn trên được thực thi. Thời gian thực luôn được kiểm tra trước khi chia sẻ liên kết, tuy nhiên điều này không cần thiết có nghĩa là chia sẻ liên kết sẽ bị bỏ qua. Đó là bởi vì các gói được tính khác nhau. Vì lịch sử được xem xét theo thời gian thực, một gói có thể không cần để đáp ứng bảo đảm thời gian thực (vì một tính được bao gồm trong lịch sử) nhưng cần để đáp ứng chia sẻ liên kết vì nó bỏ qua gói lịch sử.

Nếu tôi sử dụng đường cong thời gian thực riêng biệt để tăng mức độ ưu tiên của các lớp, tại sao tôi lại cần "đường cong"? Tại sao thời gian thực không phải là giá trị cố định và chia sẻ liên kết cũng là giá trị cố định? Tại sao cả hai đường cong? Sự cần thiết cho các đường cong là rõ ràng trong bài báo gốc, bởi vì chỉ có một thuộc tính của loại đó cho mỗi lớp. Nhưng bây giờ, có ba thuộc tính (thời gian thực, chia sẻ liên kết và giới hạn trên), tôi vẫn cần những đường cong nào cho mỗi thuộc tính? Tại sao tôi muốn hình dạng đường cong (không phải băng thông trung bình, nhưng độ dốc của chúng) khác nhau đối với lưu lượng truy cập chia sẻ liên kết và thời gian thực?

Đường cong cho các điều khiển thời gian thực cho phép bạn giao dịch độ trễ chặt chẽ cho một lớp lưu lượng truy cập cụ thể (ví dụ VOIP) cho độ trễ kém cho các lớp lưu lượng truy cập khác (ví dụ: email). Khi quyết định gói nào sẽ gửi theo ràng buộc thời gian thực, HFSC chọn gói sẽ hoàn thành gửi trước. Tuy nhiên, nó không sử dụng băng thông của liên kết để tính toán điều này, nó sử dụng băng thông được phân bổ theo đường cong thời gian thực. Do đó, nếu chúng ta có các gói VOIP và email có cùng độ dài và gói VOIP có đường cong lồi cho phép tăng gấp 10 lần so với đường cong lõm cho email, thì 10 gói VOIP sẽ được gửi trước gói email fist. Nhưng điều này chỉ xảy ra trong thời gian bùng nổ, mà tối đa là thời gian cần thiết để gửi một vài gói - tức là mili giây. Sau đó, đường cong VOIP sẽ bị san phẳng, và VOIP sẽ không nhận được sự thúc đẩy nào trong tương lai trừ khi nó lùi lại trong một thời gian (điều này, với VOIP là một ứng dụng băng thông thấp, thì nên). Kết quả cuối cùng của tất cả những điều này là để đảm bảo một vài gói VOIP đầu tiên được gửi nhanh hơn bất kỳ thứ gì khác, do đó mang lại cho VOIP độ trễ thấp với chi phí email có độ trễ cao.

Như tôi đã nói trước đó, vì chia sẻ liên kết không nhìn vào lịch sử, nó không thể đảm bảo độ trễ. Một đảm bảo vững chắc về đá là những gì cần thiết cho lưu lượng thời gian thực như VOIP. Tuy nhiên, trung bình một đường cong lồi chia sẻ liên kết vẫn sẽ cung cấp độ trễ cho lưu lượng truy cập của nó. Nó chỉ không được đảm bảo. Điều đó tốt cho hầu hết mọi thứ, như lưu lượng truy cập web qua email.

Theo tài liệu nhỏ có sẵn, các giá trị đường cong thời gian thực hoàn toàn bị bỏ qua cho các lớp bên trong (lớp A và B), chúng chỉ được áp dụng cho các lớp lá (A1, A2, B1, B2). Nếu đó là sự thật, tại sao cấu hình mẫu ALTQ HFSC (tìm kiếm cấu hình mẫu 3.3) đặt các đường cong thời gian thực trên các lớp bên trong và tuyên bố rằng những cái đó đặt tỷ lệ được bảo đảm của các lớp bên trong đó? Điều đó không hoàn toàn vô nghĩa sao? (lưu ý: pshare đặt đường cong chia sẻ liên kết trong ALTQ và ghi lại đường cong thời gian thực; bạn có thể thấy điều này trong đoạn trên cấu hình mẫu).

Các tài liệu là chính xác. Hệ thống phân cấp (và do đó là các nút bên trong) không ảnh hưởng đến việc tính toán thời gian thực. Tôi không thể cho bạn biết lý do ALTQ rõ ràng nghĩ như vậy.

Một số hướng dẫn nói rằng tổng của tất cả các đường cong thời gian thực có thể không cao hơn 80% tốc độ đường truyền, một số khác nói rằng nó không được cao hơn 70% tốc độ đường truyền. Cái nào đúng hay cả hai đều sai?

Cả hai đều sai. Nếu 70% hoặc 80% lưu lượng truy cập của bạn có yêu cầu độ trễ cứng phải được chỉ định theo thời gian thực, thì thực tế là bạn gần như chắc chắn bạn không thể đáp ứng chúng với liên kết bạn đang sử dụng. Bạn cần một liên kết nhanh hơn.

Cách duy nhất mà ai đó có thể nghĩ rằng việc chỉ định 80% lưu lượng truy cập phải là thời gian thực là nếu họ sử dụng thời gian thực như một ưu tiên tăng. Có, để cung cấp độ trễ đảm bảo bạn có hiệu lực tăng mức độ ưu tiên của một số gói. Nhưng nó chỉ nên trong một phần nghìn giây. Đó là tất cả một liên kết có thể đối phó và vẫn cung cấp đảm bảo độ trễ.

Có rất ít lưu lượng truy cập cần đảm bảo độ trễ. VOIP là một, NTP khác. Phần còn lại nên được thực hiện với chia sẻ liên kết. Bạn muốn web nhanh, bạn làm cho nó nhanh bằng cách phân bổ hầu hết dung lượng liên kết. Chia sẻ đó được đảm bảo trong thời gian dài. Nếu bạn muốn nó có độ trễ thấp (trung bình), hãy tạo cho nó một đường cong lồi dưới chia sẻ liên kết.

Một hướng dẫn cho biết bạn sẽ quên tất cả các lý thuyết. Bất kể mọi thứ thực sự hoạt động như thế nào (bộ lập lịch và phân phối băng thông), hãy tưởng tượng ba đường cong theo "mô hình tâm trí đơn giản hóa" sau: thời gian thực là băng thông được đảm bảo mà lớp này sẽ luôn có được. link-share là băng thông mà lớp này muốn trở nên hoàn toàn hài lòng, nhưng sự hài lòng không thể được đảm bảo. Trong trường hợp có băng thông dư thừa, lớp thậm chí có thể được cung cấp nhiều băng thông hơn mức cần thiết để trở nên hài lòng, nhưng nó có thể không bao giờ sử dụng nhiều hơn giới hạn trên. Để tất cả điều này hoạt động, tổng của tất cả các băng thông thời gian thực có thể không vượt quá xx% tốc độ đường truyền (xem câu hỏi ở trên, tỷ lệ phần trăm khác nhau). Câu hỏi: Điều này nhiều hay ít chính xác hay là sự hiểu lầm hoàn toàn về HSFC?

Đó là một mô tả tốt giới hạn trên. Trong khi mô tả chia sẻ liên kết là hoàn toàn chính xác, nó là sai lệch. Mặc dù chia sẻ liên kết thực sự của nó không mang lại sự đảm bảo độ trễ cứng như thời gian thực, nhưng nó mang lại cho lớp học sự phân bổ băng thông tốt hơn so với các đối thủ cạnh tranh, như CBQ và HTB. Vì vậy, khi nói chia sẻ liên kết "không cung cấp đảm bảo", nó đang giữ nó ở một tiêu chuẩn cao hơn mà bất kỳ lịch trình nào khác có thể cung cấp.

Mô tả thời gian thực quản lý được cả hai chính xác, nhưng rất sai lầm tôi gọi nó là sai. Như tên ngụ ý mục đích thời gian thực không phải là để cung cấp băng thông được bảo đảm. Đó là cung cấp độ trễ được đảm bảo - tức là gói được gửi NGAY BÂY GIỜ, không phải là một khoảng thời gian ngẫu nhiên sau đó tùy thuộc vào cách sử dụng liên kết. Hầu hết lưu lượng truy cập không cần độ trễ được đảm bảo.

Điều đó nói rằng, thời gian thực cũng không cung cấp đảm bảo độ trễ hoàn hảo. Nó có thể, nếu liên kết không được quản lý bởi chia sẻ liên kết, nhưng hầu hết người dùng muốn có thêm tính linh hoạt của việc có cả hai và nó không miễn phí. Thời gian thực có thể bỏ lỡ thời hạn trễ của thời gian gửi một gói MTU. (Nếu điều đó xảy ra, đó sẽ là do đó là chia sẻ liên kết gói MTU trong khi thời gian thực giữ liên kết không hoạt động trong trường hợp gói được cung cấp với thời hạn ngắn phải được gửi ngay lập tức. Đây là một sự khác biệt khác giữa chia sẻ liên kết và thời gian thực. Để đảm bảo bảo đảm thời gian thực có thể cố tình giữ dòng không hoạt động mặc dù có các gói để gửi, do đó cung cấp ít hơn 100% sử dụng liên kết. Chia sẻ liên kết luôn sử dụng 100% dung lượng liên kết có sẵn. ,

Lý do thời gian thực có thể nói là cung cấp các đảm bảo độ trễ cứng là độ trễ bị ràng buộc. Vì vậy, nếu bạn đang cố gắng cung cấp bảo đảm độ trễ 20ms cho liên kết 1Mbit / giây và chia sẻ liên kết đang gửi các gói có kích thước MTU (1500 byte), bạn biết một trong những gói đó sẽ mất 12ms để gửi. Do đó, nếu bạn cho biết thời gian thực bạn muốn có độ trễ 8ms, bạn vẫn có thể đáp ứng thời hạn 20ms - với sự đảm bảo tuyệt đối.

Và nếu giả định ở trên là thực sự chính xác, ưu tiên ở đâu trong mô hình đó? Ví dụ, mọi lớp có thể có băng thông thời gian thực (được bảo đảm), băng thông chia sẻ liên kết (không được bảo đảm) và có thể có giới hạn trên, nhưng vẫn có một số lớp có nhu cầu ưu tiên cao hơn các lớp khác. Trong trường hợp đó, tôi vẫn phải ưu tiên bằng cách nào đó, ngay cả trong lưu lượng truy cập thời gian thực của các lớp đó. Tôi sẽ ưu tiên theo độ dốc của các đường cong? Và nếu vậy, đường cong nào? Đường cong thời gian thực? Đường cong chia sẻ liên kết? Đường cong giới hạn trên? Tất cả bọn họ? Tôi sẽ cung cấp cho tất cả chúng cùng một độ dốc hoặc mỗi một độ dốc khác nhau và làm thế nào để tìm ra độ dốc phù hợp?

Không có một mô hình ưu tiên. Nghiêm túc. Nếu bạn muốn ưu tiên lưu lượng tuyệt đối, hãy sử dụng pfifo. Đó là những gì nó cho. Nhưng cũng hãy cẩn thận rằng nếu bạn ưu tiên tuyệt đối lưu lượng web trên giao thông email, mà phương tiện để cho lưu lượng web bão hòa liên kết và do đó không có gói dữ liệu email nhận được thông qua, ở tất cả . Tất cả các kết nối email của bạn sau đó chết.

Trong thực tế không ai muốn loại ưu tiên đó. Những gì họ muốn là những gì HFSC cung cấp. Nếu bạn thực sự có lưu lượng thời gian thực, HFSC cung cấp điều đó. Nhưng nó sẽ là thứ tất cả. Đối với phần còn lại, HFSC cho phép bạn nói "trên một liên kết bị tắc nghẽn, phân bổ 90% cho web và để email nhỏ giọt ở mức 10% và nhanh chóng gửi gói DNS kỳ lạ nhưng đừng để ai đó cho tôi sử dụng nó."

Bạn có thể xác định các đường cong với các tên khác nhau:

• rt, đường cong thời gian thực, đảm bảo băng thông / độ trễ.
• ls, đường cong chia sẻ liên kết, chia sẻ băng thông / độ trễ (dựa trên cấu hình của các lá lân cận)
• ul, đường cong giới hạn trên, băng thông tối đa / độ trễ nó có thể đạt được.

Tôi cần một đường cong thời gian thực để làm gì? Giả sử A1, A2, B1, B2 là tất cả chia sẻ liên kết 128 kbit / s (không có đường cong thời gian thực cho một trong hai), thì mỗi cái sẽ nhận được 128 kbit / s nếu gốc có 512 kbit / s để phân phối (và Tất nhiên A và B đều là 256 kbit / s), phải không? Tại sao tôi cũng cung cấp cho A1 và B1 một đường cong thời gian thực với 128 kbit / s? Điều này sẽ tốt cho cái gì? Để ưu tiên cao hơn cho hai người? Theo bài báo gốc, tôi có thể ưu tiên cao hơn cho họ bằng cách sử dụng đường cong, đó là tất cả những gì HFSC muốn nói. Bằng cách cung cấp cho cả hai lớp một đường cong [256kbit / s 20ms 128kbit / s], cả hai đều có mức độ ưu tiên gấp đôi so với A2 và B2 (vẫn chỉ nhận trung bình 128 kbit / s)

Khi bạn thực hiện một định nghĩa trong HFSC chỉ với tỷ lệ, nó sẽ tự động đặt 'dmax' thành 0. Điều đó về cơ bản có nghĩa là nó không tính đến độ trễ. Một cấu hình HFSC tốt phải bao gồm cả ranh giới băng thông VÀ độ trễ bạn muốn sử dụng cho lớp của mình, nếu không thuật toán không thể tìm ra chính xác mức độ ưu tiên của một lớp.

Bất cứ khi nào bạn ưu tiên các gói, các gói khác sẽ được giảm mức độ ưu tiên. Dựa trên các giá trị 'dmax' và 'Rate', tất cả các lớp sẽ được ghép kênh bằng bộ định thời ảo. Tham khảo tc-hfsc (7) để biết thêm thông tin.

Băng thông thời gian thực có được tính vào băng thông chia sẻ liên kết không? Ví dụ: nếu cả A1 và B1 chỉ có băng thông chia sẻ liên kết thời gian thực 64kbit / giây và 64kbit / giây, điều đó có nghĩa là một khi chúng được phục vụ 64kbit / giây qua thời gian thực, thì yêu cầu chia sẻ liên kết của chúng cũng được thỏa mãn nhận được băng thông dư thừa, nhưng hãy bỏ qua điều đó trong một giây) hoặc điều đó có nghĩa là họ nhận thêm 64 kbit / s thông qua liên kết chia sẻ? Vì vậy, mỗi lớp có một "yêu cầu" băng thông của thời gian thực cộng với chia sẻ liên kết? Hoặc một lớp chỉ có yêu cầu cao hơn đường cong thời gian thực nếu đường cong chia sẻ liên kết cao hơn đường cong thời gian thực (yêu cầu chia sẻ liên kết hiện tại bằng với yêu cầu chia sẻ liên kết đã chỉ định trừ đi băng thông thời gian thực đã cung cấp cho điều này lớp học)?

Nếu luồng không đi qua ranh giới của định nghĩa chia sẻ liên kết của lớp, thì đường cong thời gian thực không bao giờ được sử dụng. Xác định đường cong thời gian thực trong trường hợp này cho phép bạn, ví dụ: để đảm bảo một 'dmax' nhất định.

Nếu định nghĩa chia sẻ liên kết của bạn là hoàn hảo, thì bạn sẽ không cần các đường cong thời gian thực. Bạn chỉ có thể xác định đường cong dịch vụ (sc), nhưng điều đó sẽ làm cho cấu hình của bạn hoạt động mạnh hơn.

Là đường giới hạn trên cũng được áp dụng cho thời gian thực, chỉ để chia sẻ liên kết, hoặc có thể cho cả hai? Một số hướng dẫn nói một cách, một số nói theo cách khác. Một số thậm chí cho rằng giới hạn trên là tối đa cho băng thông thời gian thực + băng thông chia sẻ liên kết? Sự thật là gì?

Đường cong giới hạn trên của lớp của bạn chỉ được áp dụng cho chia sẻ liên kết, khi bạn xác định đường cong giới hạn trên, bạn PHẢI xác định đường cong chia sẻ liên kết. Tuy nhiên, đường cong giới hạn trên của các lớp cha vẫn được áp dụng.

Giả sử A2 và B2 đều là 128 kbit / s, liệu có khác biệt gì không nếu A1 và B1 chỉ là chia sẻ liên kết 128 kbit / s, hoặc 64 kbit / s thời gian thực và chia sẻ liên kết 128 kbit / s, và nếu vậy , khác nhau cái gì?

Có một sự khác biệt nhỏ, ví dụ: A2 = 0 kbits / s và B2 = 256 kbits / s. Sau đó, thời gian ảo cho A2 sẽ ở mức tối đa của anh ấy. Bất cứ khi nào các gói được phân loại trong A2, chúng sẽ được xử lý ngay lập tức. Tuy nhiên, đường cong thời gian thực của B2 vẫn sẽ đảm bảo có thể truyền ít nhất 64 kbit / s

Nếu tôi sử dụng đường cong thời gian thực riêng biệt để tăng mức độ ưu tiên của các lớp, tại sao tôi lại cần "đường cong"? Tại sao thời gian thực không phải là giá trị cố định và chia sẻ liên kết cũng là giá trị cố định? Tại sao cả hai đường cong? Sự cần thiết cho các đường cong là rõ ràng trong bài báo gốc, bởi vì chỉ có một thuộc tính của loại đó cho mỗi lớp. Nhưng bây giờ, có ba thuộc tính (thời gian thực, chia sẻ liên kết và giới hạn trên), tôi vẫn cần những đường cong nào cho mỗi thuộc tính? Tại sao tôi muốn hình dạng đường cong (không phải băng thông trung bình, nhưng độ dốc của chúng) khác nhau đối với lưu lượng truy cập chia sẻ liên kết và thời gian thực?

Đường cong thời gian thực không chia sẻ lưu lượng giữa các lá lân cận, đường cong chia sẻ liên kết làm.

Theo tài liệu nhỏ có sẵn, các giá trị đường cong thời gian thực hoàn toàn bị bỏ qua cho các lớp bên trong (lớp A và B), chúng chỉ được áp dụng cho các lớp lá (A1, A2, B1, B2). Nếu đó là sự thật, tại sao cấu hình mẫu ALTQ HFSC (tìm kiếm cấu hình mẫu 3.3) đặt các đường cong thời gian thực trên các lớp bên trong và tuyên bố rằng những cái đó đặt tỷ lệ được bảo đảm của các lớp bên trong đó? Điều đó không hoàn toàn vô nghĩa sao? (lưu ý: pshare đặt đường cong chia sẻ liên kết trong ALTQ và ghi lại đường cong thời gian thực; bạn có thể thấy điều này trong đoạn trên cấu hình mẫu).

Đúng là các đường cong thời gian thực bị bỏ qua cho các lớp bên trong, chúng chỉ được áp dụng cho các lớp lá. Tuy nhiên, các đường cong thời gian thực được xác định trên các lớp bên trong được tính đến để tính toán trên các lớp lá.

Một số hướng dẫn nói rằng tổng của tất cả các đường cong thời gian thực có thể không cao hơn 80% tốc độ đường truyền, một số khác nói rằng nó không được cao hơn 70% tốc độ đường truyền. Cái nào đúng hay cả hai đều sai?

Ý nghĩa của chúng là: bạn không thể ưu tiên tất cả lưu lượng truy cập ... Bất cứ khi nào bạn ưu tiên các gói, các gói khác sẽ phải giảm mức độ ưu tiên. Nếu bạn bảo đảm quá mức, thuật toán trở nên vô nghĩa. Xác định lớp có mức độ ưu tiên và xác định các lớp có thể bị.

Một hướng dẫn cho biết bạn sẽ quên tất cả các lý thuyết. Bất kể mọi thứ thực sự hoạt động như thế nào (bộ lập lịch và phân phối băng thông), hãy tưởng tượng ba đường cong theo "mô hình tâm trí đơn giản hóa" sau: thời gian thực là băng thông được đảm bảo mà lớp này sẽ luôn có được. link-share là băng thông mà lớp này muốn trở nên hoàn toàn hài lòng, nhưng sự hài lòng không thể được đảm bảo. Trong trường hợp có băng thông dư thừa, lớp thậm chí có thể được cung cấp nhiều băng thông hơn mức cần thiết để trở nên hài lòng, nhưng nó có thể không bao giờ sử dụng nhiều hơn giới hạn trên. Để tất cả điều này hoạt động, tổng của tất cả các băng thông thời gian thực có thể không vượt quá xx% tốc độ đường truyền (xem câu hỏi ở trên, tỷ lệ phần trăm khác nhau). Câu hỏi: Điều này nhiều hay ít chính xác hay là sự hiểu lầm hoàn toàn về HSFC?

Chính xác.

Và nếu giả định ở trên là thực sự chính xác, ưu tiên ở đâu trong mô hình đó? Ví dụ, mọi lớp có thể có băng thông thời gian thực (được bảo đảm), băng thông chia sẻ liên kết (không được bảo đảm) và có thể có giới hạn trên, nhưng vẫn có một số lớp có nhu cầu ưu tiên cao hơn các lớp khác. Trong trường hợp đó, tôi vẫn phải ưu tiên bằng cách nào đó, ngay cả trong lưu lượng truy cập thời gian thực của các lớp đó. Tôi sẽ ưu tiên theo độ dốc của các đường cong? Và nếu vậy, đường cong nào? Đường cong thời gian thực? Đường cong chia sẻ liên kết? Đường cong giới hạn trên? Tất cả bọn họ? Tôi sẽ cung cấp cho tất cả chúng cùng một độ dốc hoặc mỗi một độ dốc khác nhau và làm thế nào để tìm ra độ dốc phù hợp?

Sự khác biệt giữa ví dụ HFSC và HTB là HFSC sẽ cho phép bạn xác định chính xác mức độ ưu tiên mà bạn muốn nó có. Bạn làm điều này bằng cách xác định các giới hạn tối thiểu và tối đa với giá trị 'dmax'.

Cuối cùng, một hướng dẫn dường như giải thích hầu hết các mâu thuẫn và cách thực hiện hiện tại khác với bài báo gốc:

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

Theo hướng dẫn này, nhiều hướng dẫn và bài đăng trên diễn đàn khác về HFSC hoàn toàn vô nghĩa; nó chỉ cho thấy HFSC phức tạp như thế nào, vì nhiều người có vẻ là chuyên gia và giả vờ hiểu đầy đủ về HFSC, thực tế chỉ có một phần kiến ​​thức và đưa ra tuyên bố sai dựa trên sự hiểu lầm về khái niệm và cách tất cả các cài đặt đó chơi với nhau.

Tôi nghĩ rằng cuối cùng tôi sẽ từ bỏ HFSC. Nếu bạn có thể thiết lập HFSC đúng cách, đó có thể là QoS tốt nhất bạn có thể nhận được, nhưng khả năng bạn hoàn toàn làm hỏng là cao hơn nhiều so với cơ hội mà bạn thành công.

Nếu bạn không thể có được một tác giả gốc thì tôi sẽ thử điều này tiếp theo:

1. đi vào cây nguồn linux và tìm các tệp C thực hiện "khung lập lịch TC"
2. Nhìn vào tiêu đề và tìm tác giả của mã.
3. Các lập trình viên E-Mail của "khung lập lịch TC" yêu cầu họ cung cấp tài liệu về việc thực hiện.

Ngoài ra, hãy thử kiểm tra các giấy tờ mới hơn trích dẫn này. Có thể có những bài báo mới hơn về việc tiếp tục nghiên cứu trong lĩnh vực này và có thể bao gồm nhiều thông tin hơn về các câu hỏi bạn đang hỏi.