Acho que cortar mais do que isto o e-mail perde o sentido. Eu j� tinha cortado
antes uma boa parte.
Renato Frederick wrote:
... [cut!]
Engra�ado Jo�o, aqui uso 3com e brincando com o NETPERF, fiz testes com placas wireless, equipamentos wireless indoor, tanto no *NIX e Windows.
Resumidamente no Windows e no *NIX placas que n�o tinham o "paralell tasking" havia maior consumo de CPU.. Pelo que sei esse recurso � desenvolvido justamente pr� poupar o processador.
Mas no meu ultimo teste, em minha rede usando hub consegui 6MB com 3com em
atlon xp 1.6 e 4MB com realtek, na mesma m�quina, o HUB 3com de 10MB.
Fiz uma m�dia ponderada de 3 testes, no mesmo hardware, com as 2 placas na
mesma m�quina, cada hora usando uma. A outra m�quina era identica. Teste de
3com pra 3com e realtek pra realtek
Eu usei o FreeBSD 4.6, se n�o me engano, nos testes. Pode ser que os drivers tenham
melhorado de l� para c�, e pode ser que a 3Com tenha fornecido as informa��es para
fazer o driver. Parece que a pessoa que tinha implementado os drivers para a 3Com n�o
tinha as informa��es necess�rias, e fez o driver meio �s cegas.
Na verdade o teste foi s� pra fazer um stress na m�quina, verificando, depois com o cpuburn se ela n�o ia travar, j� que era uma m�quina montada por n�s.
Acho estranho voc� estar com esses problemas com 3com, ali�s nunc tive problemas graves assim com nenhuma placa, realtek ou 3com ou sis (onboard).
Seria legal um dia marcamos de fazer testes mesmo! :)
Eu adoraria refazer os testes. De onde voc� �? Eu sou do Rio de Janeiro, e estou
"dispon�vel" no momento.
O teste que eu fiz, na realidade, n�o foi exatamente de tr�fego. Acho que seria
descrito melhor como consumo de CPU por tr�fego, e o �ndice de medida era o tr�fego.
Pois quanto mais tr�fego, mais gasto de CPU no nat. Se o driver comsumir muita CPU,
menos sobrar� para o NAT, limitando o tr�fego. Acho que eu n�o estou sendo claro.
Digamos que o NAT consome X de tempo por MB processado, e o driver da interface
de rede Y de tempo por MB processado. Ou seja, temos tempo por MB de cada parte.
1 segundo = A * ( X + Y )
Sendo A a quantidade de tr�fego pela interface. Ent�o a diminui��o de qualquer um
dos fatores X e Y implicaria em um aumento de A para manter 1 segundo. No meu teste
X era constante, j� que o NAT era o mesmo. Ent�o a troca de interfaces promoveu uma
varia��o no Y. Na realidade, o meu teste n�o foi em uma situa��o absolutamente controlada,
pois tinham no jogo duas interfaces de rede, e ent�o t�nhamos Y1 e Y2:
1 segundo = A * ( X + Y1 + Y2)
Mas como eu s� alterava uma das interfaces, ent�o X e um dos Ys estavam contantes.
Por isto � que mencionei que gostaria de fazer um teste s� com uma interface de rede.
Na realidade � f�cil determinar a diferen�a de eficiencia entre duas placas de rede.
Digamos que temos a placa "a" e a "b", e assim temos Ya e Yb. o que implica em Aa e Ab:
( X + Ya ) Aa = 1 => X + Ya = 1/Aa
( X + Yb ) Ab = 1 => X + Yb = 1/Ab
=> Ya - Yb = 1/Aa - 1/Ab => Ya = Yb + ( 1/Aa - 1/Ab )
Portanto pode-se obter a diferen�a de efici�ncia entre as duas placas. Corrigindo, placas e
drivers. Mas ainda n�o se tem como obter os valores de X, Ya e Yb. S�o 3 vari�veis para 2
equa��es.
Existe um outro problema. os fatores X, Ya e Yb podem variar de entrada para sa�da. Ou
seja, uma interface pode ser eficiente na sa�da dos dados, mas n�o na entrada. Ent�o o teste
deve ser feito nos 2 sentidos.
( Xi + Yai ) Aai = 1 => Xi + Yai = 1/Aai
( Xi + Ybi ) Abi = 1 => X + Ybi = 1/Abi
=> Yai - Ybi = 1/Aai - 1/Abi => Yai = Ybi + ( 1/Aai - 1/Abi )
E
( Xo + Yao ) Aao = 1 => Xo + Yao = 1/Aao
( Xo + Ybo ) Abo = 1 => Xo + Ybo = 1/Abo
=> Yoa - Ybo = 1/Aao - 1/Abo => Yao = Ybo + ( 1/Aao - 1/Abo )
Pode-se tamb�m conduzir testes de tr�fego atravessando a m�quina, por exemplo, entrando
pelo NAT e saindo por outra interface.
( Xi + Yai + Ybo ) Aab = 1 => Xi + Yai + Ybo = 1/Aab
Mas o valor de Xi + Yai � conhecido, ent�o:
1/Aai + Ybo = 1/Aab => Ybo = 1/Aab - 1/Aai
E assim obtemos a capacidade de transmiss�o de uma interface, ali�s, o tempo de CPU usado
pela interface para cada MB transmitido. Com testes e dados parecidos podemos obter os outros
fatores. Mas tem um problema s�rio. Isto tudo � aproximado, pois um programa para gerar tr�fego
de rede entre as m�quinas n�o dever� consumir praticamente nenhuma CPU. E o mesmo valeria
para o resto do sistema operacional. Talvez o melhor fosse fazer 2 programas. Um de escrita de
uma grande bloco de dados, tipo 200 Mega Bytes, e outro de leitura, e eles mesmo fazerem a
conex�o entre si. Primeiro dispara-se o de leitura, e depois o de escrita.
Acho que seria um teste muito interessante. Eu gostaria de faz�-lo. Acho que preciso arranjar
um emprego em uma revista de inform�tica que tenha laborat�rio. :^) Alguma a� precisando de
um cara detalhista que adora fazer experi�ncias? :^)
Jo�o Rocha.
Abra�os.
_______________________________________________________________ Sair da Lista: http://lists.fugspbr.org/listinfo.cgi Historico: http://www4.fugspbr.org/lista/html/FUG-BR/
