[GTER] Tempo de Resposta esperado em Ethernet - TCP/IP

[Henrique Terada]

Infelizmente problema de latencia nao é exclusividade desse fornecedor de
software.

Solucao pratica pra isso, ou reescreve-se a aplicacao, ou utiliza-se
produtos de Wan Optimization, para otimizar a aplicacao .
Entre os fornecedores, tem Cisco, Riverbed, e alguns outros.



On 7/5/07, João Carlos Mendes Luís <jonny at jonny.eng.br> wrote:
>
> Rubens Marins wrote:
> > Sem muitos detalhes, a solucao permite habilitar remotamente, bombas
> > d'agua assim como comportas, entres outros equipamentos.
> >
> > Existem dois Centro de operação, um pŕoximo dos equipamentos e outro a
> > 300Km. O fundamental é que funcione o Centro que esta próximo, e este
> > funciona , mas foi pago pra uma solução para dois centros , e queremos
> > os dois .
> > O link de rádio tem uma largura de banda de 10Mbps / Full Duplex, ele
> > foi testado com tudo que voce imaginar , login em dominio, impressão
> > remota , tudo funciona perfeito, inclusive video conferencia, somente
> > nao funciona o software de monitoramento. Voce pode inclusive dar ping
> > flood no linux que ele nao perde pacotes. No momento não usamos para
> > mais nada além de tentar rodar o software, a ideia é no futuro colocar
> > qos.
> >
> > A parte do link de comunicação foi licitado  separado do software que
> > monitora, e não temos motivo nenhum para crer que o link de
> > comunicação possa ter problemas, por que a empresa que presta o link
> > se colocou a disposição para qualquer coisa, e realmente não vejo que
> > seja o problema do link, já que ele tem boa performance, uma nova
> > licitação adquirindo mais um novo link exigindo uma baixa latência tem
> > um preço estratoférico.
> >
> > Nós medimos com mrtg , uma maquina usando o software durante um dia
> > todo em ambiente local, dá pico de 300Kpbs de uso , logo largura de
> > banda não é problema. A perda de pacotes no links é menor do que 0.2%,
> > a unica diferença de um centro de operações para outro é a latência.
> >
> > Como foi licitado e projetado no governo anterior , não podemos fazer
> > nada quanto a fugir da solução, o máximo que podemos e provar que a
> > solução entregue difere da solução licitada, e exigir que ela
> > funcione, agora temos de resolver o problema para que o dinheiro
> > publico não vá para o ralo, comprando uma solução que não funciona
> > direito.
> >
> > Não temos duvida que o software não é adequado, mas o fornecedor esta
> > dizendo que o problema não é dele , assim precisamos de base para
> > levar o caso para o juridico, se preciso for.
> >
>
> Que tal comecar nos dando o nome do fornecedor do software?  Acredito
> que isso não seja contra a lei, certo?
>
> Com um pouco de sorte, o google acha os logs desta lista, e futuros
> compradores vao querer saber com voce se o problema foi solucionado...
> ;-)
>
>
> Voltando ao aspecto mais prático, software travando é defeito.  Ele
> poderia até dizer que há erro de comunicação, e não mostrar nada, mas
> travar É defeito.
>
> Se quiser replicar o defeito em rede local, coloca um roteador de baixa
> capacidade no meio do caminho, e sobrecarrega ele com algum tipo de ping
> flood, processos dessnecessários, etc..  Daí não podem mais dizer que o
> problema é do link, e toda a sua solução é de rede Ethernet local.  E
> tambem não podem reclamar da latência pois todo mundo sabe que Ethernet
> é uma rede Best Effort, que não garante NADA.  Perda e latência são
> aceitáveis dentro do protocolo, e se não gostarem, que usem outros
> protocolos acima para minimizar esse problema, por exemplo, o bom e
> velho TCP.
>
> Acredito que o seu link de rádio seja melhor que muitas redes locais que
> eu tenho visto.  Ele não pode ser usado como desculpa.
>
>                                         Jonny
>
> --
> João Carlos Mendes Luís - Networking Engineer - jonny at jonny.eng.br
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter