[GTER] RES: Tempo de Resposta esperado em Ethernet - TCP/IP
System Admin
system-admin at grupora.com.br
Thu Jul 5 15:26:07 -03 2007
Tivemos aqui alguns problemas com latência com um software.
No seu caso não seria mais facil, embora tem um custo o uso de citrix ou tarantela e assim funcionaria quase transparente para o usuario remoto.
Ats.
Geraldo Coelho
-----Mensagem original-----
De: gter-bounces at eng.registro.br [mailto:gter-bounces at eng.registro.br] Em nome de Rubens Marins
Enviada em: quinta-feira, 5 de julho de 2007 15:02
Para: Grupo de Trabalho de Engenharia e Operacao de Redes
Assunto: Re: [GTER] Tempo de Resposta esperado em Ethernet - TCP/IP
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.
Em ultimo caso, vamos usar sim Terminal Service ou algo do genero, mas isso sera somente um remendo , e vou somente sugerir isso quando a batalha estiver terminada , e nós os derrotados.
Agradeco os comentários recebidos, espero que estas novas informações possam ajudar os colegas em busca de uuma solução.
--
Rubens Marins
Administrador de Sistemas
rubens.marins at gmail dot com
--
gter list https://eng.registro.br/mailman/listinfo/gter
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.476 / Virus Database: 269.10.0/886 - Release Date: 4/7/2007 13:40
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.476 / Virus Database: 269.10.0/886 - Release Date: 4/7/2007 13:40
More information about the gter
mailing list