Re: [redewan] Velocidade FR x HDLC

[Kevison Dennys Carrilho Bentes]

Date:	Aug 10 2000 07:33:53 EDT
From:	"Kevison Dennys Carrilho Bentes" <[EMAIL PROTECTED]>
Subject:	Re: [redewan] Velocidade FR x HDLC

Oi Luiz, O frame-relay n�o foi feito especificamente para trafegar o sinal de voz. Muito menos o ATM ou o IP. H� tres t�cnicas no momento para trafegar o sinal de voz via rede: Voz sobre IP - VoIP. Voz sobre Frame-relay - VoFR. Voz sobre ATM - VoATM. Enviei uma p�gina que tece considera��es sobre as tres tecnologias. Tecnicamente, o sinal de voz sofre uma degrada��o maior com VoIP. O tr�fego de voz em VoIP consome 50% de tr�fego a mais do que VoFR. Voce consegue usar um canal de voz com VoFR consumindo apenas 8,2 kbps em um link de 64 kbps. Voce s� vai conseguir usar ATM em links maiores que 2 Mbps. O sinal de voz trafega muito bem com frame-relay. � �bvio a melhor rela��o custo/benef�cio do Frame-relay. Grato. Kevison Dennys Carrilho Bentes Engenheiro de Rede Air System Network Bras�lia - DF Brasil Fone: 55 61 313-8002 Fax: 55 61 313-8008 [EMAIL PROTECTED] ----- Original Message ----- From: Luiz Fernando T. Campos To: Lista de Discuss�o Rede Wan Sent: Tuesday, August 08, 2000 9:17 PM Subject: Re: [redewan] Velocidade FR x HDLC Lista de Discuss�o Rede Wan - http://www.networkdesigners.com.br S� uma observa��o, o tipo de encapsulamento do Frame Relay n�o � muito indicado para aplica��es como a transmiss�o de Voz. pois nao mantem um tempo de resposta "real time". o Frame Relay a grosso modo trabalha ao contr�rio do sistema ATM, ele fecha os dados em um pacote maior e envia, o problema � que se houver um erro nesta transmissao, o pacote grande inteiro ter� de ser retransmitido. j� o ATM divide os pacotes em pacotes encapsulados ainda menores, diminuindo assim o tempo de retransmissao em caso de erro, melhorando o tempo de resposta. Numa transmissao de voz, diz-se que eh real-time pois voce nao conseguiria entender uma voz que se cortasse ao longo da transmissao, na verdade se trabalha com um tempo de resposta dentro de 200ms, fato que numa transmissao de dados pura e simples nunca se notaria a diferenca pratica. S� mais uma coisa, a velocidade de transmissao � a mesma, nao interessa o encapsulamento, a �nica coisa que muda � a banda, maior ou menor o tamanho da palavra de bits por segundo, � um v�cio que pegamos de dizer que um link de 2Mbit eh mais lento que um de 45Mbit, na verdade a banda de um eh menor que outro. vou dar uma estudada no HDLC para poder falar dele, mas me parece que ele mantem um bit de controle que o Frame Relay e o ppp nao tem e quando chegam ao maximo da banda eles nao sao gerenciados tao eficientemente como o HDLC. Posso estar falando besteira, mas acho que eh por ai, vou dar uma olhada no material aqui e te falar exatamente porque o HDLC eh melhor. ate mais Luiz Fernando Campos [EMAIL PROTECTED] ----- Original Message ----- From: Edgar Shine To: Lista de Discuss�o Rede Wan Sent: Monday, August 07, 2000 1:37 PM Subject: RE: [redewan] Velocidade FR x HDLC Lista de Discuss�o Rede Wan - http://www.networkdesigners.com.br -----Original Message----- From: Gustavo S. Gaidzinski [mailto:[EMAIL PROTECTED]] Sent: sexta-feira, 4 de agosto de 2000 06:33 Gostaria de saber se alguem teve a experiencia de comparar linhas usando HDLC e FR , com mesma velocidade . Pois pelos os meus primeiros testes , o FR tem se mostrado um pouco mais �lento� que a HDLC . [Shine, Edgar] "mesma velocidade" quer dizer mesma velocidade fisica. Veja, existem alguns exemplos a serem considerados: - Tamanho de header: o HDLC tem um header menor que o FR, portanto para cada pacote que tivesse o mesmo tamanho, um pacote com FR teria que mandar "mais bytes" por frame. - Configuracao em "nuvem": como HDLC nao eh um protocolo de nivel 3 ele nao tem essa capacidade, eh soh pto-a-pto. FR tem algumas funcionalidades em N3 que permitem isso. - Recuperacao de erros: tanto FR como HDLC deixam isso como responsabilidade da aplicacao... O que eu quero dizer com as afirmacoes acima eh que comparar tecnologias distintas de comunicacao de dados com conceitos "eh mais rapido" ou "eh mais lento" nao faz muito sentido. O que para mim faz sentido eh colocar a tecnologia mais adequada em cada caso (nao somente vendo a sua viabilidade tecnica, como vendo custos, planejamento de expansoes futuras...). Se vc pensar em transmissao pura e simplesmente e tiver uma linha de dados privada com alto grau de confiabilidade, melhor mandar os dados puros, sem formatacao e fazer comparacao direto na aplicacao, assim fica mais rapido do que ter protocolo. []s Edgar Hideyuki Shine Nortel Networks