[GTER] Overhead Link Dedicado
Rômulo Silva
romulo.silva at gerenciatec.com.br
Wed Jan 30 10:06:29 -02 2019
Duas coisas que eu diria aqui...
Primeiro: eu costumo botar a banda do meu cliente ligeiramente acima do que
ele contrata justamente pra evitar esse problema de banda contratada que
não bate por causa de overhead, mas faço isso pra evitar dor de cabeça,
porque o meu cliente não tem obrigação de conhecer a tecnologia pra
entender isso. Nós, por outro lado, somos os provedores e os técnicos,
então conhecemos a tecnologia e sabemos que overhead existe e é inevitável.
Não vejo sentido em reclamar sobre isso, a não ser que tenhamos planos de
redesenhar todo o protocolo TCP/IP e Ethernet.
Segundo: uma porta de 10Gb nunca vai bater 10Gb por limitação da interface.
Ela vai bater 9.76Gb teóricos (consuderando aproveitamento máximo de 1518
bytes), porque você precisa descontar não só os overheads que vocês
conhecem, mas também o preâmbulo e o espaçamento entre frames (só essa
brincadeira consome 84 bytes por frame). Ou seja: você provavelmente está
mesmo com uma porta de 10Gb, não um link de 10Gb.
Você tá batendo 9.6Gb porque além disso tudo, deve ter algum overhead de
VLAN, adicionando mais 4 bytes na brincadeira.
Se quiser bater 10Gb de fato, vai ter que agregar duas de 10Gb ou botar uma
de 40Gb. Com isso, o seu provedor de upstream vai ter que fazer queue na
mão (em vez de deixar a velocidade da porta como "controle de banda"), e
você vai bater os 10Gb, porque a queue não contabiliza o inter-frame nem o
preâmbulo.
Em ter, 29 de jan de 2019 às 23:53, Tiago SR <listas at tiagosr.com> escreveu:
> Posso estar falando besteira, mas vocês estão considerando overhead de
> qual(is) camada(s)/protocolo(s)? O fato de ser um link IP, e não algum
> serviço Ethernet, não deveria descartar overhead de cabeçalhos camada 2 no
> controle de banda?
>
> Para ter 4% de overhead (400Mbps em um total de 10.000Mbps) descontado da
> banda, não deve ser só overhead do protocolo IP, que é só 1,3% de um MTU de
> 1500B.
>
> No meu ver, ele deveria estar recebendo 10Gbps de banda IP, fora o
> overhead Ethernet. Se a porta 10GbE não entrega isso por causa do overhead
> Ethernet, tem que trocar por uma porta com mais capacidade. Porta 10GbE não
> entrega 10Gbps de banda IP.
>
> E mais: o fornecedor vender 10Gbps IP e ver a porta consumindo mais que
> isso por causa do overhead Ethernet não é problema nem pra ele, já que
> Ethernet fica dentro da rede, não sai para os upstreams IP dele. Considerar
> que 9.6Gbps é normal para quem contrata 10Gbps IP é aceitar o cara pagar
> por 270Mbps (os outros 130Mbps desses 400Mbps são overhead IP) que nem é
> banda IP.
>
>
>
> ---- On Tue, 29 Jan 2019 18:29:35 -0200 fhfrediani at gmail.com wrote ----
>
> On 29/01/2019 18:03, Bruno Souto wrote:
> > e a grande questão, se eu contratar 9.5Gbps ela me entraga sem
> contabilizar
> > o overhead,
> > agora se contrato 10Gbps o overhead entra na conta.
>
> Como é possível certificar-se dessa informação que em um caso é sem
> overhead e na outra é com ? Como isso foi medido ? Essa informação esta
> no mínimo estranha ou carece de verificação.
>
> Na prática é impossível não haver o overhead para haver Internet então
> ele faz parte de todos os cenários além de ter que ser igualmente
> transportado igualmente ao payload por qualquer fornecedor.
> E no caso dos uplinks que suportam Jumbo Frame e portanto diferentes e
> uma maior variedade de tamanhos de MTU passando como fazer para
> descontar o overhead. Não faz sentido.
>
> Fernando
>
> >
> >
> >
> >
> > Em ter, 29 de jan de 2019 às 17:28, Guilherme de Freitas Figueiredo <
> > guilhermefreitasfigueiredo at gmail.com> escreveu:
> >
> >> Acho que a questão não é essa. Seu cliente dedicado ele compra 10Mbps
> com
> >> ou sem overhead? É nessa questão que acho que o Bruno está querendo
> entrar.
> >> Se seu cliente te questionar que a banda dele está dando somente
> 9.8Mbps e
> >> não os 10Mbps conforme contratado, vamos ter que explicar pra ele que
> esses
> >> 0.2Mbps são de overhead? Isso levando em conta um link de 10Mbps.
> >>
> >> Hoje nós vendemos links dedicados, banda larga, sem levar em conta o
> >> overhead que temos. Eu penso que sim, se eu vendo 10Mbps,20,50 ou
> 200Mbps
> >> para o meu cliente o calculo é feito sem overhead e se eu compro isso da
> >> operadora também deveria ser, ja discuti isso com alguns colegas que
> hoje é
> >> melhor você comprar 9.5Gbps ou 11Gbps do que 10Gbps conforme o Rodrigo
> >> informou na ultima mensagem.
> >>
> >> Abraços!
> >>
> >> []s!
> >>
> >> --
> >> Guilherme de Freitas Figueiredo
> >>
> >>
> >> On Tue, Jan 29, 2019 at 4:30 PM Rodrigo Pedrosa <
> rodrigopa.uepb at gmail.com>
> >> wrote:
> >>
> >>> Desculpe a intromissão, mas o intuito é contribuir com o colega. O link
> >>> está saturado? Caso esteja, poderia fazer um pequeno upgrade que
> >> resolveria
> >>> essa questão (teria que ver a viabilidade e prazo antes também com a
> >>> operadora), não poderão entregar na porta de 10G, devem agregar outra
> >> porta
> >>> ou subir numa de 40G.
> >>> Caso esteja com sobra é mais complicado, tem que ver a questão
> >> contratual,
> >>> inclusive se o contrato permite downgrade, mas pode tentar negociar.
> >>> Um detalhe a ser lembrado é que caso seja feito um upgrade, será feito
> um
> >>> aditivo no contrato ou gerado um novo contrato, e precisa verificar a
> >>> questão de fidelidade contratual, que normalmente é renovado o prazo.
> >>> Atenciosamente, Rodrigo Pedrosa de Aguiar
> >>>
> >>> Em ter, 29 de jan de 2019 às 14:32, Fernando Frediani <
> >>> fhfrediani at gmail.com>
> >>> escreveu:
> >>>
> >>>> Mas eles não estão entregando os 10Gb ? Na minha visão estão. Ou a
> >>>> expectativa é que seria entregue sem o overhead que faz parte da
> >>>> tecnologia. Eu particularmente nunca vi isso.
> >>>>
> >>>> Além disso quem gera boa parte desse overhead é você mesmo ou seus
> >>>> clientes então se for pegar nisso a operadora poderia hipoteticamente
> >>>> dizer que você esta fazendo isso de maneira ineficiente utilizando MTU
> >>>> 1500. E ai ?
> >>>>
> >>>> Fernando
> >>>>
> >>>> On 29/01/2019 11:14, Bruno Souto wrote:
> >>>>> Mário exatamente nesse ponto queria chegar.
> >>>>> Eu comprei um link de 10Gbps e não uma porta de 10GE
> >>>>>
> >>>>> se fosse a porta de 10GE não tinha o que discutir, pois estaria
> >>> correto.
> >>>>> agora eu comprei foi um Link IP Dedicado de 10Gbps, e na fatura está
> >>>> sendo
> >>>>> cobrado 1000M
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> Em ter, 29 de jan de 2019 às 05:51, Mário Sapucaia Neto <
> >>>>> mariosapucaia at gmail.com> escreveu:
> >>>>>
> >>>>>> Bom dia!
> >>>>>>
> >>>>>> Mas as semi-carriers, como falava nosso amigo Bogus, vendiam sempre,
> >>>> Fast
> >>>>>> 90M, Gig 900M, então seguindo a matemática... Isso foi motivo de
> >>>>>> controvérsia em 2011... O Bruno comprou uma porta 10Gbe ou um Link
> >> 10
> >>>>>> GIGA????
> >>>>>>
> >>>>>> Em seg, 28 de jan de 2019 às 17:02, Fernando Frediani <
> >>>>>> fhfrediani at gmail.com>
> >>>>>> escreveu:
> >>>>>>
> >>>>>>> Acredito que o mais importante no momento diante de um cenário
> >> aonde
> >>> a
> >>>>>>> maioria dos Links Dedicados (em alguns casos até mesmo em portas de
> >>>>>>> 10Gb) ainda não são ativados com suporte à Jumbo Frame, seria se
> >>>>>>> concentrar nisso como também em garantir que os backbones possuam
> >>>>>>> suporte completo.
> >>>>>>>
> >>>>>>> Feito isso já será possível utilizar de imediato Jumbo Frame para
> >> uso
> >>>> em
> >>>>>>> aplicações específicas o que seria uma vantagem e estímulo para
> >>>> cenários
> >>>>>>> que hoje sequer são considerados para então passar para a discussão
> >>>>>>> sobre a análise e o avanço desse suporte até o usuário final atrás
> >> de
> >>>>>> CPE.
> >>>>>>> Abraços
> >>>>>>> Fernando Frediani
> >>>>>>>
> >>>>>>> On 28/01/2019 08:12, T. Ayub wrote:
> >>>>>>>> Olá Frediani,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Esse é o mesmo raciocínio que muita gente usa para não adotar
> >> IPv6,
> >>> o
> >>>>>>> que é
> >>>>>>>> prejudicial em ambos os casos.
> >>>>>>>>
> >>>>>>>> "Ah, foi sempre assim não vale a pena mudar."
> >>>>>>>>
> >>>>>>>> Vale a pena sim senhor.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Abraços,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Ayub
> >>>>>>>>
> >>>>>>>> Em dom, 27 de jan de 2019 13:09, Fernando Frediani <
> >>>>>> fhfrediani at gmail.com
> >>>>>>>> escreveu:
> >>>>>>>>
> >>>>>>>>> Pois é, são tantos "ses" que na prática não adianta muito e não
> >>>> haverá
> >>>>>>>>> nenhum ganho significativo se o tráfego for majoritariamente de
> >>>>>>> clientes de
> >>>>>>>>> banda larga portsbto a perda devido ao overhead faz parte desse
> >>> tipo
> >>>>>> de
> >>>>>>>>> cenário.
> >>>>>>>>>
> >>>>>>>>> Fernando
> >>>>>>>>>
> >>>>>>>>> On Sun, 27 Jan 2019, 12:49 Douglas Fischer <
> >>> fischerdouglas at gmail.com
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> @Fernando
> >>>>>>>>>> Informação parcialmente inverdadeira!
> >>>>>>>>>>
> >>>>>>>>>> Se:
> >>>>>>>>>> a- Todo o caminho da rede, incluindo CPEs dos seus clientes e a
> >>> Lan
> >>>>>>>>> deles,
> >>>>>>>>>> incluindo o caminho até os servidores de conteúdo, tiverem
> >> suporte
> >>>>>>>>> correto
> >>>>>>>>>> ao Jumbo-Frame L2 e L3.
> >>>>>>>>>> b- Os usuários utilizarem sistemas operacionais razoavelmente
> >>>>>> recentes
> >>>>>>>>> (To
> >>>>>>>>>> falando de Android 5 para cá, e Windows 8 para cá.)
> >>>>>>>>>> c- Não tiver um "Faireuól" configurado por leitor de
> >>>>>>>>>> viva-o-linux(praticante de obscuridade) no meio do caminho, e os
> >>>>>>> pacotes
> >>>>>>>>>> ICMP conseguirem ir e voltar corretamente do Client para o
> >> Server.
> >>>>>>>>>> c.1- Não tô falando só de ping! To falando de Path MTU
> >>>> Discovery
> >>>>>>>>>> Mesmo que o MTU Default dos sistemas operacionais seja 1500,
> >> eles
> >>>> vão
> >>>>>>>>>> conseguir negociar um MTU mais alto, e o JumboFrame (ou Baby
> >>> Jumbo)
> >>>>>> vai
> >>>>>>>>>> funcionar.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> P.S.: @Bruno, peço desculpas por me apossar da thread.
> >>>>>>>>>>
> >>>>>>>>>> Em qua, 23 de jan de 2019 às 14:02, Fernando Frediani <
> >>>>>>>>>> fhfrediani at gmail.com>
> >>>>>>>>>> escreveu:
> >>>>>>>>>>
> >>>>>>>>>>> Se está vatendo ~9600 Mbps então ela está entregando os 10Gb
> >>>>>>> justamente
> >>>>>>>>>>> pelo motivo que você colocou no Subject da mensagem, o
> >> Overhead.
> >>>>>>>>>>> Com MTU a 1500 é dificil ter algo além disso.
> >>>>>>>>>>>
> >>>>>>>>>>> Usando Jumbo Frame sobretudo se o MTU for 9000 ou próximo disso
> >>>>>> seria
> >>>>>>>>>>> possível atingir uma velocidade mais próxima do limite da porta
> >>> mas
> >>>>>> o
> >>>>>>>>>> ponto
> >>>>>>>>>>> é que mesmo que suas portas de uplink e seu backbone
> >> suportassem
> >>>>>> Jumbo
> >>>>>>>>>>> Frame os usuários continuam com MTU em 1500 então não iria
> >> fazer
> >>>>>>>>>> diferença
> >>>>>>>>>>> significativa.
> >>>>>>>>>>>
> >>>>>>>>>>> On Wed, 23 Jan 2019, 13:15 Bruno Souto <soutobruno31 at gmail.com
> >>>>>> wrote:
> >>>>>>>>>>>> Bom dia Senhores,
> >>>>>>>>>>>> estou com uma dúvida, gostaria da opinião de vocês.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Contrato um Link de 10Gbps, a operadora me entrega em uma
> >> única
> >>>>>>>>>> interface
> >>>>>>>>>>>> SFP+
> >>>>>>>>>>>> Então percebo que o link chega no máximo 9600 Mbps.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Porem no Contrato pago 10.000 Mbps.
> >>>>>>>>>>>> Parece pouco, mas dá para comprar um carro de 50 mil por ano!
> >>>> rsrs
> >>>>>>>>>>>> então pergunto aos senhores, não deveria entregar os 10.000
> >>> Mbps ?
> >>>>>>>>>>>> A operadora informa que está entregando os 10Gbps
> >>>>>>>>>>>> --
> >>>>>>>>>>>> gter list https://eng.registro.br/mailman/listinfo/gter
> >>>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> gter list https://eng.registro.br/mailman/listinfo/gter
> >>>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Douglas Fernando Fischer
> >>>>>>>>>> Engº de Controle e Automação
> >>>>>>>>>> --
> >>>>>>>>>> gter list https://eng.registro.br/mailman/listinfo/gter
> >>>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> gter list https://eng.registro.br/mailman/listinfo/gter
> >>>>>>>>>
> >>>>>>>> --
> >>>>>>>> gter list https://eng.registro.br/mailman/listinfo/gter
> >>>>>>> --
> >>>>>>> gter list https://eng.registro.br/mailman/listinfo/gter
> >>>>>>>
> >>>>>> --
> >>>>>> gter list https://eng.registro.br/mailman/listinfo/gter
> >>>>>>
> >>>>> --
> >>>>> gter list https://eng.registro.br/mailman/listinfo/gter
> >>>> --
> >>>> gter list https://eng.registro.br/mailman/listinfo/gter
> >>>>
> >>> --
> >>> gter list https://eng.registro.br/mailman/listinfo/gter
> >>>
> >> --
> >> gter list https://eng.registro.br/mailman/listinfo/gter
> >>
> > --
> > gter list https://eng.registro.br/mailman/listinfo/gter
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
>
More information about the gter
mailing list