나는 원작을 읽었다SIGCOMM '97 포스트스크립트 논문HFSC에 대해서는 기술적으로는 매우 어렵지만 기본 개념은 이해합니다. 거의 모든 다른 스케줄링 알고리즘과 마찬가지로 선형 서비스 곡선을 제공하는 대신 볼록하거나 오목한 서비스 곡선을 지정할 수 있으므로 대역폭과 지연을 분리할 수 있습니다. 그러나 이 문서에서는 사용되는 일종의 스케줄링 알고리즘(실시간 및 링크 공유)에 대해 언급하더라도 항상 스케줄링 클래스당 하나의 곡선만 언급합니다(디커플링은 이 곡선을 지정하여 수행되며 해당 곡선에는 하나의 곡선만 필요함). ).
이제 HFSC는 다음을 사용하여 BSD(OpenBSD, FreeBSD 등)용으로 구현되었습니다.ALTQ 스케줄링 프레임워크그리고 Linux를 사용하여 구현되었습니다.TC 스케줄링 프레임워크(iproute2의 일부). 두 구현 모두 두 가지 추가 서비스 곡선을 추가했습니다.아니다원래 종이에! 실시간 서비스 곡선과 상한 서비스 곡선. 다시 한 번 원본 문서에서는 두 가지 스케줄링 알고리즘(실시간 및 링크 공유)을 언급했지만 해당 문서에서는 둘 다 하나의 단일 서비스 곡선으로 작동합니다. 현재 BSD와 Linux에서 볼 수 있듯이 둘 중 하나에 대해 두 개의 독립적인 서비스 곡선이 있었던 적이 없습니다.
더 나쁜 것은 ALTQ의 일부 버전이 HSFC에 추가 대기열 우선순위를 추가하는 것 같습니다(원본 문서에도 우선순위 같은 것이 없습니다). 나는 이 우선순위 설정을 언급하는 여러 BSD HowTo를 발견했습니다(최신 ALTQ 릴리스의 매뉴얼 페이지에는 HSFC에 대한 그러한 매개변수가 없기 때문에 공식적으로는 존재하지도 않습니다).
이 모든 것이 HFSC 스케줄링을 원본 문서에 설명된 알고리즘보다 훨씬 더 복잡하게 만들고 인터넷에는 종종 서로 모순되는 수많은 튜토리얼이 있습니다. 하나는 다른 하나와 반대라고 주장합니다. 이것이 아마도 HFSC 스케줄링이 실제로 어떻게 작동하는지 아무도 이해하지 못하는 주된 이유일 것입니다. 질문을 하기 전에 일종의 샘플 설정이 필요합니다. 아래 이미지와 같이 매우 간단한 것을 사용하겠습니다.
대체 텍스트 http://f.imagehost.org/0177/hfsc-test-setup.png
튜토리얼이 서로 모순되기 때문에 대답할 수 없는 몇 가지 질문은 다음과 같습니다.
실시간 곡선이 필요한 이유는 무엇입니까? A1, A2, B1, B2가 모두 128kbit/s 링크 공유(둘 중 하나에 대한 실시간 곡선 없음)라고 가정하면 루트에 배포할 512kbit/s가 있으면 각 링크는 128kbit/s를 얻습니다. 물론 A와 B는 모두 256kbit/s입니다. 그렇죠? A1과 B1에 128kbit/s의 실시간 곡선을 추가로 제공하는 이유는 무엇입니까? 이게 무슨 용도로 좋을까요? 이 두 가지에 더 높은 우선순위를 부여하려면? 원본 논문에 따르면 다음을 사용하여 더 높은 우선순위를 부여할 수 있습니다.곡선, 그것이 결국 HFSC의 전부입니다. 두 클래스 모두 [256kbit/s 20ms 128kbit/s]의 곡선을 제공함으로써 둘 다 A2 및 B2보다 자동으로 두 배의 우선순위를 갖습니다(여전히 평균 128kbit/s만 얻음).
실시간 대역폭이 링크 공유 대역폭에 포함됩니까? 예를 들어 A1과 B1이 모두 64kbit/s 실시간 및 64kbit/s 링크 공유 대역폭만 갖고 있다면 실시간으로 64kbit/s로 제공되면 링크 공유 요구 사항도 충족된다는 의미입니까? 초과 대역폭을 얻지만 잠시 무시하겠습니다) 아니면 링크 공유를 통해 추가로 64kbit/s를 얻는다는 의미입니까? 그렇다면 각 클래스에는 실시간과 링크 공유라는 대역폭 "요구 사항"이 있습니까? 또는 링크 공유 곡선이 실시간 곡선보다 높은 경우 클래스는 실시간 곡선보다 더 높은 요구 사항만 갖습니까?(현재 링크 공유 요구 사항은 지정된 링크 공유 요구 사항에서 이미 제공된 실시간 대역폭을 뺀 값과 같습니다. 수업)?
상한 곡선은 실시간에도 적용됩니까, 링크 공유에만 적용됩니까, 아니면 둘 다에 적용됩니까? 일부 튜토리얼에서는 한 가지 방식으로 말하고 일부에서는 다른 방식으로 말합니다. 일부에서는 상한이 실시간 대역폭 + 링크 공유 대역폭의 최대값이라고 주장하기도 합니다. 진실은 무엇입니까?
A2와 B2가 모두 128kbit/s라고 가정할 때 A1과 B1이 128kbit/s 링크 공유 전용이거나 64kbit/s 실시간 및 128kbit/s 링크 공유이면 차이가 있습니까? , 무슨 차이가 있나요?
클래스의 우선순위를 높이기 위해 별도의 실시간 곡선을 사용한다면 왜 "곡선"이 필요합니까? 왜 실시간은 균일한 가치가 아니고 링크 공유도 균일한 가치가 아닌가? 왜 둘 다 곡선입니까? 클래스당 해당 종류의 속성이 하나만 있기 때문에 곡선의 필요성은 원본 논문에서 명확합니다. 하지만 이제 세 가지 속성(실시간, 링크 공유 및 상한)이 있는데 왜 각 속성에 곡선이 필요한가요? 왜 곡선을 원할까요?모양(평균 대역폭이 아니라 기울기)이 실시간 및 링크 공유 트래픽에 대해 다를 수 있습니까?
사용 가능한 작은 문서에 따르면 실시간 곡선 값은 내부 클래스(클래스 A 및 B)에 대해 완전히 무시되며 리프 클래스(A1, A2, B1, B2)에만 적용됩니다. 그것이 사실이라면 왜ALTQ HFSC 샘플 구성(검색해 보세요3.3 샘플 구성) 내부 클래스에 실시간 곡선을 설정하고 이것이 해당 내부 클래스의 보장된 비율을 설정한다고 주장합니까? 그건 전혀 무의미한 일이 아닌가? (참고: pshare는 ALTQ에서 링크 공유 곡선을 설정하고 실시간 곡선을 조정합니다. 이는 샘플 구성 위의 단락에서 확인할 수 있습니다.)
일부 튜토리얼에서는 모든 실시간 곡선의 합이 라인 속도의 80%보다 높을 수 없다고 말하고, 다른 튜토리얼에서는 라인 속도의 70%보다 높으면 안 된다고 말합니다. 어느 것이 옳습니까? 아니면 둘 다 틀렸을 수도 있습니다.
한 튜토리얼에서는 모든 이론을 잊어버리게 될 것이라고 말했습니다. 실제로 작동하는 방식(스케줄러 및 대역폭 분배)에 관계없이 다음 "단순화된 마인드 모델"에 따른 세 가지 곡선을 상상해 보십시오. 실시간은 이 클래스가 항상 얻을 수 있는 보장된 대역폭입니다. link-share는 이 클래스가 완전히 만족하기를 원하는 대역폭이지만 만족을 보장할 수는 없습니다. 대역폭이 초과되는 경우 클래스는 만족하는 데 필요한 것보다 더 많은 대역폭을 제공받을 수도 있지만 상한값보다 더 많이 사용할 수는 없습니다. 이 모든 것이 작동하려면 모든 실시간 대역폭의 합이 회선 속도의 xx%를 초과할 수 없습니다(위 질문 참조, 백분율은 다양함). 질문: 이것이 어느 정도 정확합니까, 아니면 HSFC에 대한 완전한 오해입니까?
그리고 위의 가정이 정말 정확하다면 해당 모델에서 우선순위는 어디에 있습니까? 예를 들어 모든 클래스에는 실시간 대역폭(보장), 링크 공유 대역폭(보장되지 않음) 및 상한이 있을 수 있지만 여전히 일부 클래스는 다른 클래스보다 우선순위가 더 높습니다. 그런 경우에는 해당 클래스의 실시간 트래픽 중에서라도 어떻게든 우선순위를 지정해야 합니다. 곡선의 기울기에 따라 우선순위를 정해야 합니까? 그렇다면 어떤 곡선인가요? 실시간 곡선? 링크 공유 곡선? 상한 곡선? 그들 모두? 그들 모두에게 동일한 경사를 주거나 각각 다른 경사를 부여하고 올바른 경사를 찾는 방법은 무엇입니까?
나는 HFSC를 진정으로 이해하고 이 모든 질문에 정확하게 답할 수 있는 사람들이 이 세상에 최소한 한 손이라도 존재한다는 희망을 여전히 잃지 않았습니다. 그리고 답변에서 서로 모순되지 않고 그렇게 하는 것은 정말 좋을 것입니다 ;-)
답변1
HFSC와 그 사촌에 관한 논문을 읽는 것은 그것을 이해하는 좋은 방법이 아닙니다. HFSC 논문의 주요 목표는 작동 방식을 설명하는 것이 아니라 주장에 대한 엄격한 수학적 증거를 제공하는 것입니다. 실제로 HFSC 논문만으로는 어떻게 작동하는지 이해할 수 없으며, 참조하는 논문도 읽어야 합니다. 주장이나 증거에 문제가 있는 경우 논문 작성자에게 연락하는 것이 좋은 생각일 수 있습니다. 그렇지 않으면 그들이 귀하의 의견을 듣고 싶어할 것 같지 않습니다.
나는 다음을 썼다.HFSC 튜토리얼. 아래 설명이 명확하지 않다면 읽어보세요.
실시간 곡선이 필요한 이유는 무엇입니까? A1, A2, B1, B2가 모두 128kbit/s 링크 공유(둘 중 하나에 대한 실시간 곡선 없음)라고 가정하면 루트에 배포할 512kbit/s가 있으면 각 링크는 128kbit/s를 얻습니다. 물론 A와 B는 모두 256kbit/s입니다. 그렇죠? A1과 B1에 128kbit/s의 실시간 곡선을 추가로 제공하는 이유는 무엇입니까? 이게 무슨 용도로 좋을까요? 이 두 가지에 더 높은 우선순위를 부여하려면? 원본 논문에 따르면 곡선을 사용하여 더 높은 우선순위를 부여할 수 있습니다. 이것이 결국 HFSC의 전부입니다. 두 클래스 모두 [256kbit/s 20ms 128kbit/s]의 곡선을 제공함으로써 둘 다 A2 및 B2보다 자동으로 두 배의 우선순위를 갖습니다(여전히 평균 128kbit/s만 얻음).
실시간 곡선과 링크 공유 곡선은 서로 다른 방식으로 평가됩니다. 실시간 곡선은 전체 역사에서 클래스가 수행한 작업을 고려합니다. 정확한 대역폭과 대기 시간 할당을 제공하려면 그렇게 해야 합니다. 단점은 대부분의 사람들이 직관적으로 생각하는 것과 다릅니다.공정한. 실시간으로, 누구도 원하지 않을 때 클래스가 대역폭을 빌린 경우 나중에 다른 사람이 다시 원할 때 페널티가 적용됩니다. 이는 실시간 보장 하에서 클래스가 아무도 원하지 않을 때 더 일찍 사용했기 때문에 오랜 기간 동안 대역폭을 얻을 수 없음을 의미합니다.
링크 공유는 여유 대역폭 사용에 대해 클래스에 불이익을 주지 않는다는 점에서 공정합니다. 그러나 이는 강력한 대기 시간 보장을 제공할 수 없음을 의미합니다.
대기 시간 보장 제공과 링크 공유를 분리하는 것은 HFSC가 제공하는 새로운 기능이며 이 문서는 첫 문장에서 다음과 같이 설명합니다.본 논문에서는 지연(우선순위)과 대역폭 할당이 분리된 링크 공유와 보장된 실시간 서비스를 모두 지원하는 계층적 자원 관리 모델과 알고리즘을 연구합니다. 해당 문장의 핵심 단어는 분리되어 있습니다. 번역하면 사용되지 않은 대역폭을 ls와 공유하는 방법을 말하고 rt에 필요한 실시간 보장(대기 시간 보장이라고도 함)을 지정해야 함을 의미합니다. 둘은 직교합니다.
실시간 대역폭이 링크 공유 대역폭에 포함됩니까?
예. HFSC 문서에서는 클래스가 백로그된 이후(즉, 전송 대기 중인 패킷이 있는 경우) 클래스가 보낸 내용을 기준으로 대역폭을 정의합니다. rt와 ls의 유일한 차이점은 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 패킷이 다른 어떤 것보다 빠르게 전송되도록 보장하여 전자 메일의 대기 시간이 길어지는 대신 VOIP에 낮은 대기 시간을 제공하는 것입니다.
앞서 말했듯이 링크 공유는 기록을 확인하지 않기 때문에 지연 시간을 보장할 수 없습니다. VOIP와 같은 실시간 트래픽에는 견고한 보장이 필요합니다. 그러나 평균적으로 링크 공유 볼록 곡선은 여전히 트래픽에 대한 대기 시간 증가를 제공합니다. 단지 보장되지는 않습니다. 이메일을 통한 웹 트래픽과 같은 대부분의 경우에는 괜찮습니다.
사용 가능한 작은 문서에 따르면 실시간 곡선 값은 내부 클래스(클래스 A 및 B)에 대해 완전히 무시되며 리프 클래스(A1, A2, B1, B2)에만 적용됩니다. 이것이 사실이라면 ALTQ HFSC 샘플 구성(3.3 샘플 구성 검색)이 내부 클래스에 실시간 곡선을 설정하고 해당 내부 클래스의 보장된 속도를 설정한다고 주장하는 이유는 무엇입니까? 그건 전혀 무의미한 일이 아닌가? (참고: pshare는 ALTQ에서 링크 공유 곡선을 설정하고 실시간 곡선을 조정합니다. 이는 샘플 구성 위의 단락에서 확인할 수 있습니다.)
문서가 정확합니다. 계층 구조(및 내부 노드)는 실시간 계산에 전혀 영향을 미치지 않습니다. ALTQ가 왜 그렇게 생각하는지 말할 수 없습니다.
일부 튜토리얼에서는 모든 실시간 곡선의 합이 라인 속도의 80%보다 높을 수 없다고 말하고, 다른 튜토리얼에서는 라인 속도의 70%보다 높으면 안 된다고 말합니다. 어느 것이 옳습니까? 아니면 둘 다 틀렸을 수도 있습니다.
둘 다 틀렸습니다. 트래픽의 70% 또는 80%에 실시간으로 지정해야 하는 하드 대기 시간 요구 사항이 있는 경우 실제로는 사용 중인 링크로는 이를 충족할 수 없다는 것이 거의 확실합니다. 더 빠른 링크가 필요합니다.
누군가가 트래픽의 80%를 실시간으로 지정해야 한다고 생각할 수 있는 유일한 방법은 실시간을 우선 순위 향상으로 삼는 경우입니다. 예, 대기 시간을 보장하기 위해 실제로 일부 패킷의 우선 순위를 높이는 것입니다. 하지만 이는 밀리초 동안만 수행되어야 합니다. 이것이 링크가 처리할 수 있고 여전히 대기 시간 보장을 제공할 수 있는 전부입니다.
대기 시간 보장이 필요한 트래픽은 거의 없습니다. VOIP는 하나이고 NTP는 또 하나입니다. 나머지는 모두 링크 공유를 통해 수행되어야 합니다. 웹이 빠르기를 원한다면 대부분의 링크 용량을 할당하여 웹을 빠르게 만듭니다. 그 몫~이다장기적으로 보장됩니다. 평균적으로 낮은 대기 시간을 원할 경우 링크 공유 아래에 볼록한 곡선을 제공합니다.
한 튜토리얼에서는 모든 이론을 잊어버리게 될 것이라고 말했습니다. 실제로 작동하는 방식(스케줄러 및 대역폭 분배)에 관계없이 다음 "단순화된 마인드 모델"에 따른 세 가지 곡선을 상상해 보십시오. 실시간은 이 클래스가 항상 얻을 수 있는 보장된 대역폭입니다. link-share는 이 클래스가 완전히 만족하기를 원하는 대역폭이지만 만족을 보장할 수는 없습니다. 대역폭이 초과되는 경우 클래스는 만족하는 데 필요한 것보다 더 많은 대역폭을 제공받을 수도 있지만 상한값보다 더 많이 사용할 수는 없습니다. 이 모든 것이 작동하려면 모든 실시간 대역폭의 합이 회선 속도의 xx%를 초과할 수 없습니다(위 질문 참조, 백분율은 다양함). 질문: 이것이 어느 정도 정확합니까, 아니면 HSFC에 대한 완전한 오해입니까?
좋은 설명 상한입니다. 링크 공유 설명은 엄격히 정확하지만 오해의 소지가 있습니다. 진정한 링크 공유는 실시간처럼 하드 대기 시간을 보장하지는 않지만 CBQ 및 HTB와 같은 경쟁사보다 클래스에 대역폭 할당을 더 효과적으로 제공합니다. 따라서 링크 공유가 "보장을 제공하지 않는다"는 것은 다른 스케줄러가 제공할 수 있는 것보다 더 높은 표준을 유지한다는 의미입니다.
실시간 설명은 둘 다 정확하지만 오해의 소지가 있어 잘못되었다고 부르고 싶습니다. 이름에서 알 수 있듯이 실시간의 목적은 보장된 대역폭을 제공하는 것이 아닙니다. 이는 보장된 대기 시간을 제공하는 것입니다. 즉, 패킷은 링크 사용 방법에 따라 나중에 임의의 시간이 아닌 지금 전송됩니다. 대부분의 트래픽에는 보장된 대기 시간이 필요하지 않습니다.
즉, 실시간도 완벽한 대기 시간을 보장하지 않습니다. 링크가 링크 공유에 의해 관리되지 않으면 그럴 수도 있지만 대부분의 사용자는 두 가지를 모두 가질 수 있는 추가적인 유연성을 원하며 이는 무료로 제공되지 않습니다. 실시간은 하나의 MTU 패킷을 보내는 데 걸리는 시간으로 인해 대기 시간 마감일을 놓칠 수 있습니다. (만약 그렇다면 즉시 보내야 하는 짧은 기한의 패킷을 받았을 경우 실시간으로 링크를 유휴 상태로 유지하면서 몰래 들어간 MTU 패킷 링크 공유였기 때문일 것입니다. 이것이 링크 공유의 또 다른 차이점입니다. 실시간 보장을 제공하기 위해 전송할 패킷이 있더라도 의도적으로 회선을 유휴 상태로 유지할 수 있으므로 링크 활용률은 실시간과 달리 항상 100%를 사용합니다. , "작업 보존"이라고 할 수 있습니다.)
실시간이 하드 대기 시간을 보장한다고 말할 수 있는 이유는 지연이 제한되어 있기 때문입니다. 따라서 1Mbit/초 링크에서 20ms 대기 시간 보장을 제공하려고 하고 링크 공유가 MTU 크기(1500바이트) 패킷을 보내는 경우 해당 패킷 중 하나를 보내는 데 12ms가 소요된다는 것을 알 수 있습니다. 따라서 실시간으로 8ms 대기 시간을 원하는 경우 절대 보장을 통해 20ms 기한을 충족할 수 있습니다.
그리고 위의 가정이 정말 정확하다면 해당 모델에서 우선순위는 어디에 있습니까? 예를 들어 모든 클래스에는 실시간 대역폭(보장), 링크 공유 대역폭(보장되지 않음) 및 상한이 있을 수 있지만 여전히 일부 클래스는 다른 클래스보다 우선순위가 더 높습니다. 그런 경우에는 해당 클래스의 실시간 트래픽 중에서라도 어떻게든 우선순위를 지정해야 합니다. 곡선의 기울기에 따라 우선순위를 정해야 합니까? 그렇다면 어떤 곡선인가요? 실시간 곡선? 링크 공유 곡선? 상한 곡선? 그들 모두? 그들 모두에게 동일한 경사를 주거나 각각 다른 경사를 부여하고 올바른 경사를 찾는 방법은 무엇입니까?
우선순위 모델이 없습니다. 진지하게. 트래픽에 절대적인 우선순위를 부여하려면 pfifo를 사용하세요. 그것이 바로 그 이유입니다. 그러나 웹 트래픽에 이메일 트래픽보다 절대적인 우선순위를 부여하는 경우 이는 웹 트래픽이 링크를 포화시켜 이메일 패킷이 통과하지 못하게 한다는 것을 의미합니다.조금도. 그러면 모든 이메일 연결이 종료됩니다.
실제로는 누구도 그런 종류의 우선순위를 원하지 않습니다. 그들이 원하는 것은 HFSC가 제공하는 것입니다. 실제로 실시간 트래픽이 있는 경우 HFSC가 이를 제공합니다. 그러나 그것은 전부일 것입니다. 나머지 부분에 대해 HFSC에서는 "혼잡한 링크에서 웹에 90%를 할당하고 이메일이 10%로 흐르게 하고, 이상한 DNS 패킷을 빨리 보내되 누군가가 나에게 DOS를 실행하도록 허용하지 마세요"라고 말할 수 있습니다.
답변2
다른 이름으로 곡선을 정의할 수 있습니다.
- rt, 실시간 곡선, 대역폭/지연 보장.
- ls, 링크 공유 곡선, 대역폭/지연 공유(인접 리프 구성 기반)
- ul, 상한 곡선, 도달할 수 있는 최대 대역폭/지연.
실시간 곡선이 필요한 이유는 무엇입니까? A1, A2, B1, B2가 모두 128kbit/s 링크 공유(둘 중 하나에 대한 실시간 곡선 없음)라고 가정하면 루트에 배포할 512kbit/s가 있으면 각 링크는 128kbit/s를 얻습니다. 물론 A와 B는 모두 256kbit/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의 실시간 곡선은 여전히 최소 64kbit/s를 전송할 수 있음을 보장합니다.
클래스의 우선순위를 높이기 위해 별도의 실시간 곡선을 사용한다면 왜 "곡선"이 필요합니까? 왜 실시간은 균일한 가치가 아니고 링크 공유도 균일한 가치가 아닌가? 왜 둘 다 곡선입니까? 클래스당 해당 종류의 속성이 하나만 있기 때문에 곡선의 필요성은 원본 논문에서 명확합니다. 하지만 이제 세 가지 속성(실시간, 링크 공유 및 상한)이 있는데 왜 각 속성에 곡선이 필요한가요? 실시간 및 링크 공유 트래픽에 대해 곡선 모양(평균 대역폭이 아니라 기울기)이 달라지기를 원하는 이유는 무엇입니까?
실시간 곡선은 인접 리프 간에 트래픽을 공유하지 않지만 링크 공유 곡선은 공유합니다.
사용 가능한 작은 문서에 따르면 실시간 곡선 값은 내부 클래스(클래스 A 및 B)에 대해 완전히 무시되며 리프 클래스(A1, A2, B1, B2)에만 적용됩니다. 이것이 사실이라면 ALTQ HFSC 샘플 구성(3.3 샘플 구성 검색)이 내부 클래스에 실시간 곡선을 설정하고 해당 내부 클래스의 보장된 속도를 설정한다고 주장하는 이유는 무엇입니까? 그건 전혀 무의미한 일이 아닌가? (참고: pshare는 ALTQ에서 링크 공유 곡선을 설정하고 실시간 곡선을 조정합니다. 이는 샘플 구성 위의 단락에서 확인할 수 있습니다.)
내부 클래스에서는 실시간 곡선이 무시되고 리프 클래스에만 적용된다는 것은 사실입니다. 그러나 내부 클래스에 정의된 실시간 곡선은 리프 클래스 계산 시 고려됩니다.
일부 튜토리얼에서는 모든 실시간 곡선의 합이 라인 속도의 80%보다 높을 수 없다고 말하고, 다른 튜토리얼에서는 라인 속도의 70%보다 높으면 안 된다고 말합니다. 어느 것이 옳습니까? 아니면 둘 다 틀렸을 수도 있습니다.
그 의미는 다음과 같습니다. 모든 트래픽에 우선순위를 지정할 수는 없습니다. 패킷에 우선순위를 부여할 때마다 다른 패킷의 우선순위가 낮아져야 합니다. 과도하게 보증하면 알고리즘이 무의미해집니다. 우선순위를 얻는 클래스를 정의하고, 어려움을 겪을 수 있는 클래스를 정의합니다.
한 튜토리얼에서는 모든 이론을 잊어버리게 될 것이라고 말했습니다. 실제로 작동하는 방식(스케줄러 및 대역폭 분배)에 관계없이 다음 "단순화된 마인드 모델"에 따른 세 가지 곡선을 상상해 보십시오. 실시간은 이 클래스가 항상 얻을 수 있는 보장된 대역폭입니다. link-share는 이 클래스가 완전히 만족하기를 원하는 대역폭이지만 만족을 보장할 수는 없습니다. 대역폭이 초과되는 경우 클래스는 만족하는 데 필요한 것보다 더 많은 대역폭을 제공받을 수도 있지만 상한값보다 더 많이 사용할 수는 없습니다. 이 모든 것이 작동하려면 모든 실시간 대역폭의 합이 회선 속도의 xx%를 초과할 수 없습니다(위 질문 참조, 백분율은 다양함). 질문: 이것이 어느 정도 정확합니까, 아니면 HSFC에 대한 완전한 오해입니까?
이것은 정확합니다.
그리고 위의 가정이 정말 정확하다면 해당 모델에서 우선순위는 어디에 있습니까? 예를 들어 모든 클래스에는 실시간 대역폭(보장), 링크 공유 대역폭(보장되지 않음) 및 상한이 있을 수 있지만 여전히 일부 클래스는 다른 클래스보다 우선순위가 더 높습니다. 그런 경우에는 해당 클래스의 실시간 트래픽 중에서라도 어떻게든 우선순위를 지정해야 합니다. 곡선의 기울기에 따라 우선순위를 정해야 합니까? 그렇다면 어떤 곡선인가요? 실시간 곡선? 링크 공유 곡선? 상한 곡선? 그들 모두? 그들 모두에게 동일한 경사를 주거나 각각 다른 경사를 부여하고 올바른 경사를 찾는 방법은 무엇입니까?
예를 들어 HFSC와 HTB의 차이점은 HFSC를 사용하면 원하는 우선순위를 정확히 정의할 수 있다는 것입니다. 'dmax' 값으로 최소 및 최대 경계를 정의하면 됩니다.
답변3
마지막으로 대부분의 불일치를 설명하고 현재 구현이 원본 논문과 어떻게 다른지 설명하는 가이드입니다.
http://manpages.ubuntu.com/manpages/precise/man7/tc-hfsc.7.html
이 가이드에 따르면 HFSC에 관한 다른 많은 가이드와 포럼 게시물은 완전히 말도 안되는 내용입니다. 전문가인 것처럼 보이고 HFSC를 완전히 이해한 척하는 많은 사람들이 실제로는 부분적인 지식만 갖고 개념에 대한 오해와 모든 설정이 함께 작동하는 방식에 근거하여 잘못된 진술을 하기 때문에 HFSC가 얼마나 복잡한지 보여줄 뿐입니다.
결국 HFSC를 포기하게 될 것 같아요. HFSC 설정을 올바르게 할 수 있다면 얻을 수 있는 최고의 QoS일 수 있지만 완전히 엉망이 될 확률은 성공할 확률보다 훨씬 높습니다.
답변4
원본 작성자를 파악할 수 없다면 다음에 다음을 시도하겠습니다.
- 리눅스 커널 소스 트리로 가서 "TC 스케줄링 프레임워크"를 구현하는 C 파일을 찾으세요.
- 헤더를 보고 코드 작성자를 찾으세요.
- "TC 일정 프레임워크"의 프로그래머에게 이메일을 보내 구현에 대한 문헌을 요청합니다.
또한 이 논문을 인용한 다른 최신 논문을 확인해 보세요. 이 분야에 대한 연구를 계속하는 최신 논문이 있을 수 있으며 귀하가 묻는 질문에 대한 추가 정보가 포함될 수도 있습니다.