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

[Marcio de Freitas Minicz]

Rubens,

Você está com um belo problema de especificação.

Você poderia dizer qual o protocolo de transporte que é utilizado (TCP,
UDP ou SCTP)?

Já que a licitação fala de Ethernet-TCP/IP, por que você não monta uma
rede com vários hubs, coloca os equipamentes de teste o mais longe
possível e ainda por cima coloca uns geradores de tráfego aleatórios.
Com uma configuração bem feita você pode não chegar a saturar a rede
Ethernet e conseguir um bom atraso, o que vai "equiparar" aos enlaces de
rádio.

Outra coisa que é necessário pensar é que as redes atuais são IEEE
802.3. Em outras palavras, não é possível montar uma rede puramente
Ethernet, a não ser que você tenha alguns equipamentos da década de 80
em funcionamento. Talvez isso possa ser discutido com o departamento
jurídico, isto é, assumir que o edital da licitação tem erro técnico
(quem é o responsável?!?!?) e com isso negociar uma correção no edital e
por conseqüência no programa.

Informe o andamento da análise, por favor.

[]'s


Márcio Minicz

Rubens Marins escreveu:
> Caros,
>
> Estou tentando ajudar um orgão do governo com o seguinte problema:
>
> Este orgão licitou uma solução envolvendo hardware e software para
> monitoramento o status de determinados equipamentos . Estes
> equipamentos estão instalados a 300 Km de distãncia da sala de onde
> ser quer monitorar, a região é de dificil acesso, assim foi feita uma
> rede via rádio para ligar os dois pontos.
>
> A rede de rádio funciona bem,  com boa largura de banda, o delay de um
> ponto  ao outro pela rede é de 40-50 ms.
>
> O Software esta apresentando muitos problemas, causado por esse delay
> , ele  somente foi testado e projetado para rede local, onde o delay é
> desprezivel. Os problemas são graves pois ele não avisa simplesmente
> que não conseguiu ler informação do dispositivo X , ou se ele  esta em
> OFF, o software trava por completo, as vezes levando o SO junto.
>
> A licitação que especificou o software foi mal feita, especificando
> somente que o programa deve funcionar em "Ethernet - TCP/IP", não diz
> qual o tempo de resposta que o programa deve suportar.
>
> A empresa do programa diz que não vai corrigir o software, pois ele
> funciona bem( testando onde tudo esta ligado no mesmo switch), e que o
> problema é do link de comunicação.
>
> Agora é que vem minha pergunta:  Existe algo nas especificações do
> TCP/IP ou da Ethernet, que mencione que um programa TCP/IP deve
> aceitar/permitir  algum atraso na comunicação entre os dois pontos ?
>
> Isso por que temos de dizer que o software não esta conforme o
> especificado, para poder demonstrar , que ele não atende os
> requisitos. O Software custou mais de 7 Milhões e desde janeiro não
> esta funcionando nada  e o prazo onde pode ser reclamado algo esta
> esgotando. Passar fibra optica de um ponto ao outro vai custar mais
> milhões, e demorar anos para ficar pronta.
>
>
> Desde já agradeço as opniões dos colegas,
>
>
>