Li o artigo original do SIGCOMM '97 PostScript sobre o HFSC, é muito tecnicamente, mas entendo o conceito básico. Em vez de fornecer uma curva de serviço linear (como em praticamente todos os outros algoritmos de agendamento), você pode especificar uma curva de serviço convexa ou côncava e, portanto, é possível desacoplar a largura de banda e o atraso. No entanto, mesmo que este documento mencione o tipo de algoritmo de agendamento utilizado (tempo real e compartilhamento de link), ele sempre menciona apenas UMA curva por classe de agendamento (o desacoplamento é feito especificando essa curva, apenas uma curva é necessária). )
Agora, o HFSC foi implementado para o BSD (OpenBSD, FreeBSD, etc.) usando a estrutura de agendamento ALTQ e foi implementado o Linux usando a estrutura de agendamento TC (parte do iproute2). Ambas as implementações adicionaram duas curvas de serviço adicionais, que NÃO estavam no documento original! Uma curva de serviço em tempo real e uma curva de serviço com limite superior. Novamente, observe que o documento original menciona dois algoritmos de agendamento (tempo real e compartilhamento de link), mas nesse documento ambos trabalham com uma única curva de serviço. Nunca houve duas curvas de serviço independentes para nenhuma delas, como você encontra atualmente no BSD e Linux.
Pior ainda, algumas versões do ALTQ parecem adicionar uma prioridade de fila adicional ao HSFC (também não existe prioridade no documento original). Eu encontrei vários HowTo do BSD mencionando essa configuração de prioridade (mesmo que a página de manual da versão mais recente do ALTQ não conheça esse parâmetro para o HSFC, então oficialmente ele nem existe).
Isso tudo torna o agendamento do HFSC ainda mais complexo do que o algoritmo descrito no artigo original e existem muitos tutoriais na Internet que muitas vezes se contradizem, um reivindicando o oposto do outro. Essa é provavelmente a principal razão pela qual ninguém parece realmente entender como o agendamento do HFSC realmente funciona. Antes que eu possa fazer minhas perguntas, precisamos de um exemplo de configuração. Vou usar um muito simples, como pode ser visto na imagem abaixo:
texto alternativo http://f.imagehost.org/0177/hfsc-test-setup.png
Aqui estão algumas perguntas que não posso responder porque os tutoriais se contradizem:
Para que eu preciso de uma curva em tempo real? Supondo que A1, A2, B1, B2 sejam todos os compartilhamentos de 128 kbit / s (sem curva em tempo real para qualquer um), cada um deles receberá 128 kbit / s se a raiz tiver 512 kbit / s para distribuir (e A e B são ambos 256 kbit / s, é claro), certo? Por que eu daria adicionalmente a A1 e B1 uma curva em tempo real com 128 kbit / s? Para que isso seria bom? Para dar a esses dois uma prioridade mais alta? De acordo com o artigo original, eu posso dar a eles uma prioridade mais alta usando uma curva , é disso que se trata o HFSC. Ao dar a ambas as classes uma curva de [256kbit / s 20ms 128kbit / s], ambas têm o dobro da prioridade que A2 e B2 automaticamente (ainda obtendo apenas 128 kbit / s em média)
A largura de banda em tempo real conta para a largura de banda de compartilhamento de link? Por exemplo, se A1 e B1 possuem apenas largura de banda de 64kbit / s em tempo real e de 64kbit / s de compartilhamento de link, isso significa que, uma vez que são atendidos 64kbit / s em tempo real, o requisito de compartilhamento de link também é atendido (eles podem obter excesso de largura de banda, mas vamos ignorá-lo por um segundo) ou isso significa que eles recebem outros 64 kbit / s via compartilhamento de link? Então, cada classe tem um "requisito" de largura de banda em tempo real mais compartilhamento de link? Ou uma classe possui apenas um requisito mais alto que a curva em tempo real se a curva de compartilhamento de link for maior que a curva em tempo real (o requisito atual de compartilhamento de link é igual ao requisito especificado de compartilhamento de link menos a largura de banda em tempo real já fornecida para este classe)?
A curva do limite superior também é aplicada em tempo real, apenas ao compartilhamento de link ou talvez a ambos? Alguns tutoriais dizem uma maneira, outros dizem a outra maneira. Alguns até afirmam que o limite superior é o máximo para largura de banda em tempo real + largura de banda de compartilhamento de link? O que é a verdade?
Supondo que A2 e B2 sejam 128 kbit / s, faz alguma diferença se A1 e B1 forem apenas compartilhamento de link de 128 kbit / s ou compartilhamento de link de 64 kbit / s em tempo real e compartilhamento de link de 128 kbit / s? , que diferença?
Se eu usar a curva separada em tempo real para aumentar as prioridades das classes, por que eu precisaria de "curvas"? Por que o tempo real não é um valor fixo e o compartilhamento de link também é um valor fixo? Por que ambas as curvas? A necessidade de curvas é clara no artigo original, porque há apenas um atributo desse tipo por classe. Mas agora, tendo três atributos (tempo real, compartilhamento de link e limite superior), para que eu ainda preciso de curvas em cada um? Por que eu gostaria que a forma das curvas (não a largura de banda média, mas suas inclinações) fosse diferente para o tráfego em tempo real e de compartilhamento de link?
De acordo com a pouca documentação disponível, os valores da curva em tempo real são totalmente ignorados para as classes internas (classes A e B), são aplicados apenas às classes foliares (A1, A2, B1, B2). Se isso é verdade, por que a configuração de amostra do ALTQ HFSC (pesquise 3.3 Configuração de amostra ) define curvas em tempo real nas classes internas e afirma que elas definem a taxa garantida dessas classes internas? Isso não é completamente inútil? (nota: pshare define a curva de compartilhamento de link no ALTQ e classifica a curva em tempo real; você pode ver isso no parágrafo acima da configuração de amostra).
Alguns tutoriais dizem que a soma de todas as curvas em tempo real não pode ser superior a 80% da velocidade da linha, outros dizem que não deve ser superior a 70% da velocidade da linha. Qual deles está certo ou ambos estão errados?
Um tutorial disse que você deve esquecer toda a teoria. Não importa como as coisas realmente funcionem (planejadores e distribuição da largura de banda), imagine as três curvas de acordo com o seguinte "modelo mental simplificado": em tempo real é a largura de banda garantida que essa classe sempre terá. link-share é a largura de banda que essa classe deseja tornar-se totalmente satisfeita, mas a satisfação não pode ser garantida. Caso haja excesso de largura de banda, a classe poderá até oferecer mais largura de banda do que o necessário para ficar satisfeita, mas nunca poderá usar mais do que o limite superior diz. Para que tudo isso funcione, a soma de todas as larguras de banda em tempo real pode não estar acima de xx% da velocidade da linha (veja a pergunta acima, a porcentagem varia). Pergunta: Isso é mais ou menos preciso ou um mal-entendido total do HSFC?
E se a suposição acima é realmente precisa, onde está a priorização nesse modelo? Por exemplo, toda classe pode ter uma largura de banda em tempo real (garantida), uma largura de banda de compartilhamento de link (não garantida) e talvez um limite superior, mas ainda assim algumas classes têm necessidades de prioridade mais altas do que outras classes. Nesse caso, ainda devo priorizar de alguma forma, mesmo entre o tráfego em tempo real dessas classes. Eu priorizaria pela inclinação das curvas? E se sim, qual curva? A curva em tempo real? A curva de compartilhamento de links? A curva do limite superior? Todos eles? Eu daria a todos eles a mesma inclinação ou cada uma diferente e como descobrir a inclinação correta?
Ainda não perdi a esperança de que exista pelo menos uma mão cheia de pessoas neste mundo que realmente entenderam o HFSC e sejam capazes de responder a todas essas perguntas com precisão. E fazer isso sem se contradizer nas respostas seria muito bom ;-)
Respostas:
Ler os jornais sobre o HFSC e seus primos não é uma boa maneira de entendê-lo. O objetivo principal do artigo do HFSC é fornecer uma prova matemática rigorosa de suas alegações, sem explicar como ele funciona. Na verdade, você não consegue entender como funciona apenas a partir do trabalho do HFSC, também precisa ler os trabalhos a que se refere. Se você tiver algum problema com a reivindicação ou suas provas, entrar em contato com os autores dos artigos pode ser uma boa ideia; caso contrário, duvido que eles estejam interessados em receber notícias suas.
Eu escrevi um tutorial para o HFSC . Leia se minhas explicações abaixo não forem claras.
A curva em tempo real e a curva de compartilhamento de links são avaliadas de diferentes maneiras. A curva em tempo real leva em consideração o que uma classe fez ao longo de toda a sua história. Isso deve ser feito para fornecer alocação precisa de largura de banda e latência. A desvantagem não é o que a maioria das pessoas pensa intuitivamente como justa . Em tempo real, se uma classe empresta largura de banda quando ninguém mais a quer, ela é penalizada quando alguém a quer de volta mais tarde. Isso significa que, sob a garantia em tempo real, uma classe não pode ter largura de banda por um longo período, porque a usou mais cedo, quando ninguém a queria.
O compartilhamento de links é justo, pois não penaliza uma classe por usar largura de banda sobressalente. No entanto, isso significa que ele não pode fornecer fortes garantias de latência.
A separação do compartilhamento de links do fornecimento de garantias de latência é a novidade que o HFSC traz para a mesa, e o artigo diz o mesmo em sua frase de abertura: neste artigo, estudamos modelos e algoritmos hierárquicos de gerenciamento de recursos que suportam compartilhamento de links e garantia serviços em tempo real com atraso desacoplado (prioridade) e alocação de largura de banda. A palavra-chave nessa frase é dissociada. Traduzido, significa que você deve dizer como a largura de banda não utilizada deve ser compartilhada com ls e especificar quais garantias em tempo real (também conhecidas como garantias de latência) são necessárias com a rt. Os dois são ortogonais.
Sim. No artigo do HFSC, eles definem a largura de banda em termos do que a classe enviou desde que a classe ficou em atraso (ou seja, há pacotes aguardando para serem enviados). A única diferença entre rt e ls é que rt aguarda a cada vez que a classe fica com backlog e calcula a menor largura de banda garantida desse conjunto, enquanto o compartilhamento de links fica apenas com a última vez que a classe se torna backlog. Portanto, rt leva mais bytes em consideração do que ls, mas todos os bytes considerados são também considerados por rt.
O limite superior não impede o envio de pacotes para satisfazer a condição de tempo real. Os pacotes enviados sob a condição de tempo real ainda contam para o limite superior e, portanto, podem atrasar o envio de um pacote sob a condição de compartilhamento de link no futuro. Essa é outra diferença entre o compartilhamento em tempo real e o link.
Sim, isso faz diferença. Conforme explicado acima, se você usar o tempo real, as latências são garantidas, mas o link não é compartilhado de maneira justa (e, em particular, a classe pode sofrer falta de largura de banda), e os limites superiores não são impostos. Se você usar o compartilhamento de links, a latência não será garantida, mas o compartilhamento será justo, não haverá risco de inanição e o limite superior será imposto. O tempo real é sempre verificado antes do compartilhamento do link, no entanto, isso não é necessário, pois o compartilhamento do link será ignorado. Isso ocorre porque os pacotes são contados de maneira diferente. Como o histórico é considerado em tempo real, um pacote pode não ser necessário para atender à garantia em tempo real (por causa de um número incluído no histórico), mas é necessário para satisfazer o compartilhamento de link porque ignora o pacote histórico.
A curva para controles em tempo real permite negociar latência restrita para uma classe de tráfego específica (por exemplo, VOIP) por latência ruim para outras classes de tráfego (por exemplo, email). Ao decidir qual pacote enviar sob restrição de tempo real, o HFSC escolhe aquele que concluirá o envio primeiro. No entanto, ele não usa a largura de banda do link para calcular isso, usa a largura de banda alocada pela curva em tempo real. Portanto, se tivermos pacotes VOIP e e-mail do mesmo tamanho, e o pacote VOIP tiver uma curva convexa que dará um aumento de 10 vezes sobre a curva côncava para e-mail, 10 pacotes VOIP serão enviados antes do primeiro pacote de e-mail. Mas isso só acontece no tempo de burst, que deve demorar no máximo o tempo necessário para enviar alguns pacotes - isto é, mili segundos. Depois disso, a curva VOIP deve achatar, e o VOIP não terá impulso futuro, a menos que se retire por um tempo (o que, dado que o VOIP é um aplicativo de baixa largura de banda, deveria). O resultado líquido de tudo isso é garantir que os primeiros pacotes de VOIP sejam enviados mais rapidamente do que qualquer outra coisa, fornecendo ao VOIP baixa latência às custas de e-mails com alta latência.
Como eu disse anteriormente, como o compartilhamento de link não olha para o histórico, não pode dar garantias de latência. Uma garantia sólida é o que é necessário para o tráfego em tempo real como o VOIP. No entanto, em média, uma curva convexa compartilhada de link ainda fornecerá um aumento de latência em seu tráfego. Simplesmente não é garantido. Isso é bom para a maioria das coisas, como o tráfego da Web por email.
A documentação está correta. A hierarquia (e, portanto, os nós internos) não afeta o cálculo do tempo real. Não sei dizer por que a ALTQ pensa que sim.
Ambos estão errados. Se 70% ou 80% do seu tráfego possui requisitos de latência rígidos que devem ser especificados em tempo real, a realidade é que você quase certamente não pode satisfazê-los com o link que está usando. Você precisa de um link mais rápido.
A única maneira de alguém pensar que especificar 80% do tráfego deveria ser em tempo real é se eles estivessem pisando em tempo real como um aumento de prioridade. Sim, para fornecer garantias de latência, você está efetivamente aumentando a prioridade de alguns pacotes. Mas deve ser apenas por milissegundos. É tudo o que um link pode suportar e ainda fornecer as garantias de latência.
Há muito pouco tráfego que precisa de garantias de latência. VOIP é um, NTP outro. O resto deve ser feito com o compartilhamento de links. Se você deseja que a Web seja rápida, você a torna rápida alocando a maior parte da capacidade de links. Essa parcela é garantida a longo prazo. Se você deseja que ela seja de baixa latência (em média), ofereça uma curva convexa no compartilhamento de links.
É uma boa descrição do limite superior. Embora a descrição do compartilhamento de links seja estritamente precisa, ela é enganosa. Embora seu compartilhamento de link verdadeiro não ofereça garantias de latência rígida, como o tempo real, ele faz um trabalho melhor ao atribuir à classe sua largura de banda e alocação do que seus concorrentes, como CBQ e HTB. Portanto, ao dizer que o compartilhamento de link "não fornece garantias", ele o mantém em um padrão mais alto do que qualquer outro agendador pode fornecer.
A descrição do tempo real consegue ser precisa, mas tão enganosa que eu chamaria de errado. Como o nome indica, o objetivo do tempo real não é garantir largura de banda garantida. É para fornecer latência garantida - ou seja, o pacote é enviado AGORA, não uma quantidade aleatória de tempo posteriormente, dependendo de como o link é usado. A maioria do tráfego não precisa de latência garantida.
Dito isto, o tempo real também não oferece garantias perfeitas de latência. Poderia, se o link também não fosse gerenciado pelo compartilhamento de links, mas a maioria dos usuários deseja a flexibilidade adicional de ter os dois e não é de graça. O tempo real pode perder o prazo de latência pelo tempo necessário para enviar um pacote MTU. (Se isso acontecer, será porque o compartilhamento de link de pacote MTU se esgueirou enquanto o tempo real mantinha o link inativo, caso o pacote recebesse um prazo curto que tivesse que ser enviado imediatamente. Essa é outra diferença entre o compartilhamento de link. Para fornecer suas garantias, o tempo real pode deliberadamente manter a linha ociosa, mesmo que haja pacotes a serem enviados, fornecendo menos de 100% de utilização do link. O compartilhamento de link sempre usa 100% da capacidade disponível dos links. ,
A razão pela qual o tempo real pode oferecer garantias de latência rígida é que o atraso é limitado. Portanto, se você está tentando oferecer uma garantia de latência de 20ms em um link de 1Mbit / s, e o compartilhamento de link está enviando pacotes de tamanho MTU (1500 bytes), você sabe que um desses pacotes levará 12ms para enviar. Portanto, se você informar em tempo real que deseja uma latência de 8ms, ainda poderá cumprir o prazo de 20ms - com uma garantia absoluta.
Não há um modelo de priorização. A sério. Se você deseja dar prioridades absolutas ao tráfego, use o pfifo. É pra isso que isto serve. Mas também tem cuidado que se você der o tráfego web prioridade absoluta sobre o tráfego de e-mail, que significa deixar o tráfego web saturar o link e, portanto, nenhum pacote de e-mail recebendo através, em tudo . Todas as suas conexões de email morrem.
Na realidade, ninguém quer esse tipo de priorização. O que eles querem é o que o HFSC fornece. Se você realmente possui tráfego em tempo real, o HFSC fornece isso. Mas será tudo. Quanto ao resto, o HFSC permite que você diga "em um link congestionado, aloque 90% para a Web e deixe o email chegar a 10%, e envie o pacote DNS estranho rapidamente, mas não deixe que alguém me faça com ele".
fonte
Você pode definir as curvas com nomes diferentes:
Quando você define no HFSC apenas com taxas, ele define automaticamente 'dmax' como 0. O que basicamente significa que não leva em conta o atraso. Uma boa configuração do HFSC deve incluir os limites de largura de banda e atraso que você deseja usar para sua classe, caso contrário, o algoritmo não pode descobrir exatamente quanta prioridade uma classe deve ter.
Sempre que você der prioridade aos pacotes, outros terão que ter sua prioridade diminuída. Com base nos valores 'dmax' e 'rate', todas as classes serão multiplexadas usando temporizadores virtuais. Consulte tc-hfsc (7) para obter mais informações.
Se o fluxo não ultrapassar os limites da definição de compartilhamento de link da classe, a curva em tempo real nunca será usada. Definir uma curva em tempo real neste caso permite, por exemplo: garantir um certo 'dmax'.
Se suas definições de compartilhamento de link forem perfeitas, você não precisará de curvas em tempo real. Você poderia apenas definir curvas de serviço (sc), mas isso dificultaria sua configuração.
A curva de limite superior da sua classe é aplicada apenas ao compartilhamento de link, quando você define uma curva de limite superior, DEVE definir uma curva de compartilhamento de link. No entanto, a curva do limite superior das classes pai ainda é aplicada.
Há uma pequena diferença, por exemplo A2 = 0 kbits / se B2 = 256 kbits / s. Então, o tempo virtual para A2 estará no máximo. Sempre que os pacotes forem classificados em A2, eles serão processados instantaneamente. No entanto, a curva em tempo real de B2 ainda garantirá que é capaz de transmitir pelo menos 64 kbit / s
As curvas em tempo real não compartilham tráfego entre as folhas vizinhas, as curvas de compartilhamento de link compartilham.
É verdade que as curvas em tempo real são ignoradas para classes internas, elas são aplicadas apenas às classes folha. No entanto, as curvas em tempo real definidas nessas classes internas são levadas em consideração para os cálculos nas classes de folhas.
O que eles querem dizer é: você não pode priorizar todo o tráfego ... Sempre que você der prioridade aos pacotes, outros terão que ter sua prioridade diminuída. Se você garantir demais, o algoritmo se torna inútil. Defina as classes que ganham priorização e defina as classes que podem sofrer.
Isto está correto.
A diferença entre, por exemplo, HFSC e HTB, é que o HFSC permitirá definir exatamente quanta priorização você deseja que ele tenha. Você faz isso definindo limites mínimos e máximos com o valor 'dmax'.
fonte
Finalmente, um guia que parece explicar a maioria das inconsistências e também como a implementação atual é diferente do artigo original:
http://manpages.ubuntu.com/manpages/precise/man7/tc-hfsc.7.html
De acordo com este guia, muitos outros guias e postagens no fórum sobre o HFSC são totalmente sem sentido; mostra apenas o quão complicado é o HFSC, pois muitas pessoas que parecem ser especialistas e pretendem ter compreendido completamente o HFSC, na verdade têm apenas um conhecimento parcial e fazem declarações falsas com base no mal-entendido do conceito e em como todas essas configurações são executadas em conjunto.
Acho que vou finalmente desistir do HFSC. Se você conseguir acertar a configuração do HFSC, pode ser a melhor QoS possível, mas as chances de você estragar completamente são muito maiores do que as chances de sucesso.
fonte
Se você não conseguir se apossar dos autores originais, tentarei o seguinte:
Tente também verificar outros artigos mais recentes que citam este. Pode haver trabalhos mais recentes por aí que sejam uma continuação da pesquisa nessa área e possam incluir mais informações sobre as perguntas que você está fazendo.
fonte