리눅스 / BSD에서 HFSC 스케줄링이 어떻게 작동하는지 실제로 아는 사람이 있습니까?

HFSC에 대한 원본 SIGCOMM '97 PostScript 논문을 읽었 지만 기술적으로는 기본 개념을 이해합니다. 거의 모든 다른 스케줄링 알고리즘과 마찬가지로 선형 서비스 곡선을 제공하는 대신 볼록 또는 오목 서비스 곡선을 지정할 수 있으므로 대역폭과 지연을 분리 할 수 ​​있습니다. 그러나이 백서에서는 사용중인 일정 알고리즘 (실시간 및 링크 공유)에 대해 언급하지만 일정 클래스 당 하나의 곡선 만 언급합니다 (디커플링은이 곡선을 지정하여 수행됩니다. 단 하나의 곡선 만 필요합니다. ).

이제 HFSC는 ALTQ 스케줄링 프레임 워크를 사용하여 BSD (OpenBSD, FreeBSD 등)에 대해 구현되었으며 TC 스케줄링 프레임 워크 (iproute2의 일부)를 사용하여 Linux를 구현했습니다 . 모두 구현했다 두 개의 추가 서비스 곡선을 추가 하지 원래 논문을! 실시간 서비스 곡선 및 상한 서비스 곡선. 다시 한 번, 원본 논문에는 두 가지 스케줄링 알고리즘 (실시간 및 링크 공유)이 언급되어 있지만,이 논문에서는 단일 서비스 곡선으로 작동합니다. 현재 BSD와 Linux에서 볼 수 있듯이 두 개의 독립적 인 서비스 곡선은 없었습니다.

더 나쁜 것은 일부 ALTQ 버전은 HSFC에 대기열 우선 순위를 추가하는 것 같습니다 (원본에도 우선 순위는 없습니다). 최신 ALTQ 릴리스의 man 페이지가 HSFC에 대한 그러한 매개 변수를 알지 못하더라도 공식적으로는 존재하지 않더라도이 우선 순위 설정에 대해 여러 BSD HowTo가 언급했습니다.

이 모든 것이 HFSC 스케줄링을 원본 논문에 설명 된 알고리즘보다 훨씬 더 복잡하게 만들며 인터넷상에서 서로 상반되는 수많은 튜토리얼이 있습니다. 하나는 서로 반대되는 주장입니다. 이것은 아마도 아무도 HFSC 스케줄링이 실제로 어떻게 작동하는지 이해하지 못하는 주된 이유 일 것입니다. 질문을하기 전에 어떤 종류의 샘플 설정이 필요합니다. 아래 이미지에서 볼 수 있듯이 매우 간단한 것을 사용하겠습니다.

대체 텍스트 http://f.imagehost.org/0177/hfsc-test-setup.png

튜토리얼이 서로 상충되기 때문에 대답 할 수없는 몇 가지 질문이 있습니다.

1. 실시간 곡선이 필요합니까? A1, A2, B1, B2가 모두 128 kbit / s 링크 공유라고 가정하면 (둘 중 하나에 대한 실시간 곡선이 없음) 루트에 512 kbit / s가 분배되면 각각이 128 kbit / s를 얻습니다. A와 B는 모두 256 kbit / s입니다). A1과 B1에 128kbit / s의 실시간 곡선을 추가로 제공하는 이유는 무엇입니까? 이것이 무엇에 좋을까요? 이 두 가지에 우선 순위를 부여하려면? 원본 논문에 따르면 곡선 을 사용하여 더 높은 우선 순위를 부여 할 수 있습니다 .HFSC는 결국 모든 것입니다. 두 클래스에 [256kbit / s 20ms 128kbit / s]의 곡선을 제공하면 둘 다 자동으로 A2 및 B2보다 두 배의 우선 순위를 갖습니다 (여전히 평균 128kbit / s 만 얻음).

2. 실시간 대역폭은 링크 공유 대역폭에 포함됩니까? 예를 들어 A1과 B1에 모두 64kbit / s 실시간 및 64kbit / s 링크 공유 대역폭 만있는 경우, 일단 실시간으로 64kbit / s를 제공하면 링크 공유 요구 사항도 충족됩니다. 초과 대역폭을 얻지 만 잠시 동안 무시하십시오. 또는 링크 공유를 통해 다른 64kbit / s를 얻는다는 의미입니까? 각 클래스에는 실시간 + 링크 공유의 대역폭 "요구 사항"이 있습니까? 또는 링크 공유 곡선이 실시간 곡선보다 높으면 클래스가 실시간 곡선보다 높은 요구 사항을 갖습니까 (현재 링크 공유 요구 사항은 지정된 링크 공유 요구 사항에서 이미 제공된 실시간 대역폭을 뺀 값과 동일 함) 수업)?

3. 상한 곡선이 실시간, 링크 공유에만 적용됩니까, 아니면 둘 다에 적용됩니까? 일부 자습서는 한 가지 방법을 말하고 일부 자습서는 다른 방법을 말합니다. 실시간 대역폭 + 링크 공유 대역폭의 최대 값이 최대 값이라고 주장하는 사람들도 있습니까? 진실은 무엇입니까?

4. A2와 B2가 모두 128kbit / s라고 가정하고 A1과 B1이 128kbit / s 링크 공유 만이거나 64kbit / s 실시간 및 128kbit / s 링크 공유이면 차이가 있습니까? 무슨 차이가 있습니까?

5. 수업의 우선 순위를 높이기 위해 별도의 실시간 곡선을 사용한다면 왜 "곡선"이 필요할까요? 실시간이 고정 가치와 링크 공유도 고정 가치가 아닌 이유는 무엇입니까? 왜 두 커브가 다릅니 까? 클래스 당 하나의 속성 만 있기 때문에 원본 논문에서 커브가 필요합니다. 그러나 이제 세 가지 속성 (실시간, 링크 공유 및 상한)이 있는데 각각에 대한 곡선이 여전히 필요합니까? 실시간 및 링크 공유 트래픽 에서 곡선 모양 (평균 대역폭이 아니라 기울기)이 다른 이유는 무엇 입니까?

6. 이용 가능한 작은 문서에 따르면 실시간 곡선 값은 내부 클래스 (클래스 A 및 B)에 대해 완전히 무시되며 리프 클래스 (A1, A2, B1, B2)에만 적용됩니다. 이것이 사실이라면 왜 ALTQ HFSC 샘플 구성 ( 3.3 샘플 구성 검색 )이 내부 클래스에 실시간 곡선을 설정하고 내부 클래스의 보장 속도를 설정한다고 주장합니까? 완전히 무의미하지 않습니까? (참고 : pshare는 ALTQ에서 링크 공유 곡선을 설정하고 실시간 곡선을 생성합니다. 샘플 구성 위의 단락에서 확인할 수 있습니다).

7. 일부 자습서에서는 모든 실시간 곡선의 합이 회선 속도의 80 %보다 높지 않을 수 있다고 말하고 다른 자습서에서는 회선 속도의 70 %보다 높지 않아야한다고 말합니다. 어느 것이 옳거나 둘 다 틀릴 수 있습니까?

8. 한 튜토리얼은 모든 이론을 잊어 버릴 것이라고 말했다. 실제로 작동하는 방식 (스케줄러 및 대역폭 분포)에 관계없이 다음 "간단한 마인드 모델"에 따라 세 가지 곡선을 상상해보십시오. 실시간은이 클래스가 항상 얻을 수있는 보장 된 대역폭입니다. 링크 공유는이 클래스가 완전히 만족하기를 원하는 대역폭이지만 만족을 보장 할 수는 없습니다. 초과 대역폭이있는 경우 클래스는 만족하는 데 필요한 것보다 더 많은 대역폭을 제공받을 수 있지만 상한값 이상을 사용하지는 않을 것입니다. 이 모든 것이 작동하려면 모든 실시간 대역폭의 합이 회선 속도의 xx %를 초과 할 수 없습니다 (위의 질문 참조, 백분율이 다름). 질문 : 이것이 HSFC에 대해 다소 정확하거나 완전히 오해 되었습니까?

9. 위의 가정이 실제로 정확한 경우 해당 모델의 우선 순위는 어디에 있습니까? 예를 들어 모든 클래스에는 실시간 대역폭 (보장), 링크 공유 대역폭 (보증되지 않음) 및 상한이있을 수 있지만 일부 클래스는 다른 클래스보다 우선 순위가 더 높습니다. 이 경우 클래스의 실시간 트래픽 중에서도 우선 순위를 정해야합니다. 커브의 기울기로 우선 순위를 정합니까? 그렇다면 어떤 곡선입니까? 실시간 곡선? 링크 공유 곡선? 상한 곡선? 그들 모두? 그들 모두에게 같은 경사를 주거나 다른 경사를 주겠습니까?

나는 아직도이 세상에 HFSC를 이해하고이 모든 질문에 정확하게 대답 할 수있는 사람들로 가득 찬 손이 있다는 희망을 잃지 않았습니다. 그리고 대답에서 서로 모순되지 않고 그렇게하는 것은 정말 좋을 것입니다 ;-)

HFSC와 그 사촌에 관한 논문을 읽는 것은 그것을 이해하는 좋은 방법이 아닙니다. HFSC 논문의 주요 목표는 작동 원리를 설명하지 않고 주장에 대한 엄격한 수학적 증거를 제공하는 것입니다. 실제로 HFSC 용지에서만 작동하는 방식을 이해할 수 없으므로 참조하는 용지도 읽어야합니다. 당신이 주장이나 그 증거에 문제가 있다면 논문의 저자에게 연락하는 것이 좋습니다. 그렇지 않으면 그들이 당신의 의견에 관심이있을 것입니다.

HFSC에 대한 자습서를 작성했습니다 . 아래 설명이 명확하지 않은 경우 읽으십시오.

실시간 곡선이 필요합니까? A1, A2, B1, B2가 모두 128 kbit / s 링크 공유라고 가정하면 (둘 중 하나에 대한 실시간 곡선이 없음) 루트에 512 kbit / s가 분배되면 각각이 128 kbit / s를 얻습니다. A와 B는 모두 256 kbit / s입니다). A1과 B1에 128kbit / s의 실시간 곡선을 추가로 제공하는 이유는 무엇입니까? 이것이 무엇에 좋을까요? 이 두 가지에 우선 순위를 부여하려면? 원본 논문에 따르면 곡선을 사용하여 더 높은 우선 순위를 부여 할 수 있습니다 .HFSC가 결국 중요합니다. 두 클래스에 [256kbit / s 20ms 128kbit / s]의 곡선을 제공하면 둘 다 자동으로 A2 및 B2보다 두 배의 우선 순위를 갖습니다 (여전히 평균 128kbit / s 만 얻음).

실시간 곡선과 링크 공유 곡선은 다른 방식으로 평가됩니다. 실시간 곡선은 전체 역사에서 클래스가 수행 한 작업을 고려합니다. 정확한 대역폭 및 대기 시간 할당을 제공하기 위해 그렇게해야합니다. 단점은 대부분의 사람들이 직관적으로 공정하다고 생각하는 것이 아닙니다 . 실시간으로 클래스가 다른 사람이 원치 않을 때 대역폭을 빌리면 나중에 다른 사람이 원할 때 불이익을받습니다. 이는 실시간으로 클래스가 원치 않을 때 이전에 클래스를 사용했기 때문에 오랫동안 대역폭을 확보 할 수 없음을 의미합니다.

링크 공유는 여유 대역폭을 사용하는 클래스에 불이익을주지 않기 때문에 공정합니다. 그러나 이는 강력한 대기 시간 보장을 제공 할 수 없음을 의미합니다.

대기 시간 보장을 제공하는 것과 링크 공유를 분리하는 것이 HFSC가 표에 가져 오는 새로운 것입니다 . 그리고이 논문 은 개막 문장에 대해 다음과 같이 말합니다. 지연된 지연 (우선 순위) 및 대역폭 할당을 통한 실시간 서비스. 그 문장의 핵심어는 분리되어 있습니다. 즉, 사용되지 않은 대역폭을 ls와 공유하는 방법을 말하고 RT에 필요한 실시간 보증 (일명 대기 시간 보장)을 지정해야합니다. 둘은 직교입니다.

실시간 대역폭은 링크 공유 대역폭에 포함됩니까?

예. HFSC 논문에서는 클래스가 백 로그 된 이후 (즉, 패킷 전송 대기 중) 클래스가 전송 한 대역폭을 정의합니다. rt와 ls의 유일한 차이점은 rt는 클래스가 백 로그 될 때마다 rt 기대하고 해당 세트에서 보장 된 최저 대역폭을 계산하는 반면 링크 공유는 클래스가 백 로그 된 마지막 시점에서만 보입니다. 따라서 rt는 ls보다 많은 바이트를 고려하지만 ls가 고려하는 모든 바이트는 rt에서도 고려됩니다.

상한 곡선이 실시간, 링크 공유에만 적용됩니까, 아니면 둘 다에 적용됩니까?

상한은 실시간 조건을 만족시키기 위해 패킷이 전송되는 것을 막지 않습니다. 실시간 조건 하에서 전송 된 패킷은 여전히 ​​상한에 포함되므로, 링크 공유 조건 하에서 전송되는 패킷은 나중에 지연 될 수 있습니다. 이것이 실시간 공유와 링크 공유의 또 다른 차이점입니다.

A2와 B2가 모두 128kbit / s라고 가정하고 A1과 B1이 128kbit / s 링크 공유 만이거나 64kbit / s 실시간 및 128kbit / s 링크 공유이면 차이가 있습니까? 무슨 차이가 있습니까?

그렇습니다. 위에서 설명한대로 실시간을 사용하는 경우 지연 시간이 보장되지만 링크가 공평하게 공유되지 않으며 (특히 클래스에 대역폭이 고갈 될 수 있음) 상한이 적용되지 않습니다. 링크 공유를 사용하면 대기 시간이 보장되지 않지만 링크 공유가 공정한 경우 기아의 위험이 없으며 상한이 적용됩니다. 링크 공유 전에 실시간을 항상 확인하지만 반드시 링크 공유가 무시되는 것은 아닙니다. 패킷이 다르게 계산되기 때문입니다. 히스토리는 실시간으로 고려되므로 패킷이 히스토리에 포함 된 것으로 인해 실시간 보증을 충족 할 필요는 없지만 히스토리 패킷을 무시하므로 링크 공유를 충족시켜야합니다.

수업의 우선 순위를 높이기 위해 별도의 실시간 곡선을 사용한다면 왜 "곡선"이 필요할까요? 실시간이 고정 가치와 링크 공유도 고정 가치가 아닌 이유는 무엇입니까? 왜 두 커브가 다릅니 까? 클래스 당 하나의 속성 만 있기 때문에 원본 논문에서 커브가 필요합니다. 그러나 이제 세 가지 속성 (실시간, 링크 공유 및 상한)이 있는데 각각에 대한 곡선이 여전히 필요합니까? 실시간 및 링크 공유 트래픽에서 곡선 모양 (평균 대역폭이 아니라 기울기)이 다른 이유는 무엇입니까?

실시간 제어 곡선을 사용하면 특정 트래픽 클래스 (예 : VOIP)에 대한 긴 대기 시간을 다른 트래픽 클래스 (예 : 전자 메일)에 대한 지연 시간이 짧게 거래 할 수 있습니다. 실시간 제약 조건에서 전송할 패킷을 결정할 때 HFSC는 먼저 전송을 완료 할 패킷을 선택합니다. 그러나이를 계산하기 위해 링크의 대역폭을 사용하지 않고 실시간 곡선에 의해 할당 된 대역폭을 사용합니다. 따라서 우리가 동일한 길이의 VOIP 및 이메일 패킷을 가지고 있고 VOIP 패킷에 볼록한 곡선이 있으면 이메일의 오목한 곡선보다 10 배 향상되면 첫 번째 이메일 패킷 전에 10 개의 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는 다른 하나입니다. 나머지는 모두 링크 공유로 수행해야합니다. 웹 속도가 빠르기를 원한다면 대부분의 링크 용량을 할당하여 웹 속도를 높이십시오. 그 점유율 은 장기적으로 보장됩니다. 대기 시간이 짧고 (평균) 링크 공유시 볼록한 곡선이됩니다.

한 튜토리얼은 모든 이론을 잊어 버릴 것이라고 말했다. 실제로 작동하는 방식 (스케줄러 및 대역폭 분포)에 관계없이 다음 "간단한 마인드 모델"에 따라 세 가지 곡선을 상상해보십시오. 실시간은이 클래스가 항상 얻을 수있는 보장 된 대역폭입니다. 링크 공유는이 클래스가 완전히 만족하기를 원하는 대역폭이지만 만족을 보장 할 수는 없습니다. 초과 대역폭이있는 경우 클래스는 만족하는 데 필요한 것보다 더 많은 대역폭을 제공받을 수 있지만 상한값 이상을 사용하지는 않을 것입니다. 이 모든 것이 작동하려면 모든 실시간 대역폭의 합이 회선 속도의 xx %를 초과 할 수 없습니다 (위의 질문 참조, 백분율이 다름). 질문 : 이것이 HSFC에 대해 다소 정확하거나 완전히 오해 되었습니까?

좋은 설명 상한입니다. 링크 공유 설명은 엄격하지만 오해의 소지가 있습니다. 진정한 링크 공유는 실시간처럼 하드 레이턴시 보장을 제공하지는 않지만 CBQ 및 HTB와 같은 경쟁 업체보다 클래스에 대역폭을 할당하는 것이 더 좋습니다. 따라서 링크 공유는 "보증을 제공하지 않습니다"라고 말하면 다른 스케줄러가 제공 할 수있는 표준보다 높은 수준으로 유지됩니다.

실시간 설명은 둘 다 정확하지만 오해의 소지가 있습니다. 이름에서 알 수 있듯이 실시간 목적은 보장 된 대역폭을 제공하지 않는 것입니다. 이는 보장 된 대기 시간을 제공하는 것입니다. 즉, 링크 사용 방법에 따라 나중에 임의의 시간이 아닌 패킷이 지금 전송됩니다. 대부분의 트래픽은 보장 된 대기 시간이 필요하지 않습니다.

즉, 실시간은 완벽한 대기 시간 보장을 제공하지 않습니다. 링크를 링크 공유로 관리하지 않으면 대부분의 사용자는 추가 유연성을 원하며 무료로 제공되지 않습니다. 실시간으로 하나의 MTU 패킷을 보내는 데 걸리는 시간이 지연 될 수 있습니다. (만일 발생하는 경우, 즉시 전송해야하는 짧은 기한이있는 패킷이 제공된 경우 링크를 유휴 상태로 유지하면서 실시간으로 링크를 유휴 상태로 유지하는 것이 MTU 패킷 링크 공유이기 때문입니다. 이는 링크 공유의 또 다른 차이점입니다. 보장을 제공하기 위해 보낼 패킷이 있어도 실시간으로 의도적으로 회선을 유휴 상태로 유지하여 100 % 미만의 링크 사용률을 제공 할 수 있습니다 링크 공유는 항상 100 %의 링크 사용 가능한 용량을 사용합니다. ,

지연 시간이 제한되어 있기 때문에 실시간으로 하드 레이턴시 보장을 제공 할 수있는 이유는 다음과 같습니다. 따라서 1Mbit / sec 링크에서 20ms 대기 시간 보장을 제공하려고하고 링크 공유가 MTU 크기 (1500 바이트) 패킷을 전송하는 경우 해당 패킷 중 하나가 전송하는 데 12ms가 걸린다는 것을 알고 있습니다. 따라서 실시간으로 8ms 대기 시간을 원한다고해도 절대 보장으로 20ms 마감 시간을 충족시킬 수 있습니다.

위의 가정이 실제로 정확한 경우 해당 모델의 우선 순위는 어디에 있습니까? 예를 들어 모든 클래스에는 실시간 대역폭 (보장), 링크 공유 대역폭 (보증되지 않음) 및 상한이있을 수 있지만 일부 클래스는 다른 클래스보다 우선 순위가 더 높습니다. 이 경우 클래스의 실시간 트래픽 중에서도 우선 순위를 정해야합니다. 커브의 기울기로 우선 순위를 정합니까? 그렇다면 어떤 곡선입니까? 실시간 곡선? 링크 공유 곡선? 상한 곡선? 그들 모두? 그들 모두에게 같은 경사를 주거나 다른 경사를 주겠습니까?

우선 순위 모델이 없습니다. 진심으로. 트래픽에 절대 우선 순위를 부여하려면 pfifo를 사용하십시오. 그것이 바로 그런 것입니다. 또한 웹 트래픽에 전자 메일 트래픽보다 절대 우선 순위를 부여하면 웹 트래픽이 링크를 포화시켜 전자 메일 패킷이 전혀 통과되지 않도록 해야 합니다. 그런 다음 모든 이메일 연결이 종료됩니다.

실제로 아무도 그런 종류의 우선 순위를 원하지 않습니다. 그들이 원하는 것은 HFSC가 제공하는 것입니다. 실제로 실시간 트래픽이있는 경우 HFSC가이를 제공합니다. 그러나 그것은 모든 것이 될 것입니다. 나머지는 HFSC를 사용하면 "혼잡 한 링크에서 웹에 90 %를 할당하고 10 %로 전자 메일을 전송하고 이상한 DNS 패킷을 빨리 보내지 만 다른 사람이 저를 DOS에 보내지 못하게하십시오"라고 말할 수 있습니다.

다른 이름으로 커브를 정의 할 수 있습니다.

• RT, 실시간 곡선, 대역폭 / 지연 보장.
• LS, 링크 공유 곡선, 대역폭 / 지연 공유 (인접한 잎의 구성에 따라)
• ul, 상한 곡선, 도달 할 수있는 최대 대역폭 / 지연.

실시간 곡선이 필요합니까? A1, A2, B1, B2가 모두 128 kbit / s 링크 공유라고 가정하면 (둘 중 하나에 대한 실시간 곡선이 없음) 루트에 512 kbit / s가 분배되면 각각이 128 kbit / s를 얻습니다. A와 B는 모두 256 kbit / s입니다). A1과 B1에 128kbit / s의 실시간 곡선을 추가로 제공하는 이유는 무엇입니까? 이것이 무엇에 좋을까요? 이 두 가지에 우선 순위를 부여하려면? 원본 논문에 따르면 곡선을 사용하여 더 높은 우선 순위를 부여 할 수 있습니다 .HFSC가 결국 중요합니다. 두 클래스에 [256kbit / s 20ms 128kbit / s]의 곡선을 제공하면 둘 다 자동으로 A2 및 B2보다 두 배의 우선 순위를 갖습니다 (여전히 평균 128kbit / s 만 얻음).

속도 만 사용하여 HFSC에서 정의하면 자동으로 'dmax'를 0으로 설정합니다. 기본적으로 지연을 고려하지 않습니다. 올바른 HFSC 구성에는 클래스에 사용하려는 대역폭과 지연 경계가 모두 포함되어야합니다. 그렇지 않으면 알고리즘이 클래스의 우선 순위를 정확히 파악할 수 없습니다.

패킷에 우선 순위를 지정할 때마다 다른 패킷의 우선 순위를 줄여야합니다. 'dmax'및 'rate'값을 기반으로 모든 클래스는 가상 타이머를 사용하여 다중화됩니다. 자세한 내용은 tc-hfsc (7)를 참조하십시오.

실시간 대역폭은 링크 공유 대역폭에 포함됩니까? 예를 들어 A1과 B1에 모두 64kbit / s 실시간 및 64kbit / s 링크 공유 대역폭 만있는 경우, 일단 실시간으로 64kbit / s를 제공하면 링크 공유 요구 사항도 충족됩니다. 초과 대역폭을 얻지 만 잠시 동안 무시하십시오. 또는 링크 공유를 통해 다른 64kbit / s를 얻는다는 의미입니까? 각 클래스에는 실시간 + 링크 공유의 대역폭 "요구 사항"이 있습니까? 또는 링크 공유 곡선이 실시간 곡선보다 높으면 클래스가 실시간 곡선보다 높은 요구 사항을 갖습니까 (현재 링크 공유 요구 사항은 지정된 링크 공유 요구 사항에서 이미 제공된 실시간 대역폭을 뺀 값과 동일 함) 수업)?

흐름이 클래스의 링크 공유 정의의 경계를 넘지 않으면 실시간 곡선이 사용되지 않습니다. 이 경우 실시간 곡선을 정의하면 예를 들어 특정 'dmax'를 보장 할 수 있습니다.

링크 공유 정의에 결함이없는 경우 실시간 곡선이 필요하지 않습니다. 서비스 곡선 (sc) 만 정의 할 수 있지만 구성 작업이 더 어려워집니다.

상한 곡선이 실시간, 링크 공유에만 적용됩니까, 아니면 둘 다에 적용됩니까? 일부 자습서는 한 가지 방법을 말하고 일부 자습서는 다른 방법을 말합니다. 실시간 대역폭 + 링크 공유 대역폭의 최대 값이 최대 값이라고 주장하는 사람들도 있습니까? 진실은 무엇입니까?

클래스의 상한 곡선은 링크 공유에만 적용됩니다. 상한 곡선을 정의 할 때는 반드시 링크 공유 곡선을 정의해야합니다. 그러나 부모 클래스의 상한 곡선은 여전히 ​​적용됩니다.

A2와 B2가 모두 128kbit / s라고 가정하고 A1과 B1이 128kbit / s 링크 공유 만이거나 64kbit / s 실시간 및 128kbit / s 링크 공유이면 차이가 있습니까? 무슨 차이가 있습니까?

예를 들어 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 %보다 높지 않아야한다고 말합니다. 어느 것이 옳거나 둘 다 틀릴 수 있습니까?

의미하는 바는 모든 트래픽의 우선 순위를 지정할 수 없다는 것입니다. 패킷에 우선 순위를 지정할 때마다 다른 패킷의 우선 순위를 줄여야합니다. 과도하게 보증하면 알고리즘이 의미가 없습니다. 우선 순위를 얻는 클래스를 정의하고 겪을 수있는 클래스를 정의하십시오.

한 튜토리얼은 모든 이론을 잊어 버릴 것이라고 말했다. 실제로 작동하는 방식 (스케줄러 및 대역폭 분포)에 관계없이 다음 "간단한 마인드 모델"에 따라 세 가지 곡선을 상상해보십시오. 실시간은이 클래스가 항상 얻을 수있는 보장 된 대역폭입니다. 링크 공유는이 클래스가 완전히 만족하기를 원하는 대역폭이지만 만족을 보장 할 수는 없습니다. 초과 대역폭이있는 경우 클래스는 만족하는 데 필요한 것보다 더 많은 대역폭을 제공받을 수 있지만 상한값 이상을 사용하지는 않을 것입니다. 이 모든 것이 작동하려면 모든 실시간 대역폭의 합이 회선 속도의 xx %를 초과 할 수 없습니다 (위의 질문 참조, 백분율이 다름). 질문 : 이것이 HSFC에 대해 다소 정확하거나 완전히 오해 되었습니까?

맞습니다.

위의 가정이 실제로 정확한 경우 해당 모델의 우선 순위는 어디에 있습니까? 예를 들어 모든 클래스에는 실시간 대역폭 (보장), 링크 공유 대역폭 (보증되지 않음) 및 상한이있을 수 있지만 일부 클래스는 다른 클래스보다 우선 순위가 더 높습니다. 이 경우 클래스의 실시간 트래픽 중에서도 우선 순위를 정해야합니다. 커브의 기울기로 우선 순위를 정합니까? 그렇다면 어떤 곡선입니까? 실시간 곡선? 링크 공유 곡선? 상한 곡선? 그들 모두? 그들 모두에게 같은 경사를 주거나 다른 경사를 주겠습니까?

예를 들어 HFSC와 HTB의 차이점은 HFSC를 통해 원하는 우선 순위를 정확하게 정의 할 수 있다는 것입니다. 'dmax'값으로 최소 및 최대 경계를 정의하여이를 수행합니다.

마지막으로 대부분의 불일치와 현재 구현이 원본 논문과 어떻게 다른지 설명하는 안내서 :

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

이 안내서에 따르면, HFSC에 관한 많은 다른 안내서 및 포럼 게시물은 전적으로 넌센스입니다. 그것은 단지 전문가처럼 보이고 HFSC를 완전히 이해 한 것처럼 보이는 많은 사람들이 실제로 부분적인 지식 만 가지고 있으며 개념에 대한 오해와 모든 설정이 어떻게 조화를 이루는 지에 따라 허위 진술을하는 것처럼 HFSC가 얼마나 복잡한지를 보여줍니다.

나는 마침내 HFSC를 포기할 것이라고 생각한다. HFSC 설정을 올바르게 수행 할 수 있다면 최상의 QoS가 될 수 있지만 완전히 엉망이 될 가능성은 성공할 가능성보다 훨씬 높습니다.

원래 저자를 보유 할 수 없다면 다음에 시도해보십시오.

1. 리눅스 커널 소스 트리로 가서 "TC 스케줄링 프레임 워크"를 구현하는 C 파일을 찾으십시오.
2. 헤더를보고 코드 작성자를 찾으십시오.
3. "TC 스케줄링 프레임 워크"의 전자 우편 프로그래머는 구현에 대한 문헌을 요구합니다.

이 논문을 인용 한 다른 최신 논문도 확인해보십시오. 이 분야에 대한 연구가 계속 진행되고 있으며 귀하가 묻는 질문에 대한 자세한 정보가 포함 된 최신 논문이있을 수 있습니다.