Re: [FUG-BR] RES: teste de tráfego - ponto a pont o
Em Tue, 30 Jun 2009 08:47:52 -0300 João Luiz Pedrosa Viana , conhecido consumidor de drogas (BigMac's com Coke) escreveu: > Se você tiver nas pontas maquinas, > Se não me engano funciona bem sobre o winne > impraticável - são roteadores com Linux versão "pelada" embarcado. :) -- saudações, irado furioso com tudo Linux User 179402/FreeBSD BSD50853/FUG-BR 154 Não uso drogas - 100% Miko$hit-free Lida propriamente, a Bíblia é a força mais potente para o ateísmo jamais concebida. Isaac Asimov - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] RES: teste de tráfego - ponto a pont o
Bom dia, Se você tiver nas pontas maquinas, o pessoal do Mikrotik desenvolveu um sistema chamado BTEST, ele é gratuito e pode ser usado tanto como cliente quanto servidor para teste de banda. Uso ele aqui justamente para o fim que vc disse. Se não me engano funciona bem sobre o winne Abaixo segue o link http://www.mikrotik.com/download/btest.exe Até breve João Luiz Pedrosa Viana -Mensagem original- De: freebsd-boun...@fug.com.br [mailto:freebsd-boun...@fug.com.br] Em nome de Leandro F Silva Enviada em: segunda-feira, 29 de junho de 2009 15:15 Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) Assunto: Re: [FUG-BR] teste de tráfego - ponto a ponto SNMP ! 2009/6/29 irado furioso com tudo > > > boas tardes, galera :) > > preciso fazer um teste entre dois pontos - tunel vpn - e não encontro > um soft apropriado; a idéia é fazer com que haja uma "tempestade" de > pacotes entre dois pontos (via tunel vpn) para avaliar a eventual perda > de pacotes, latência, essas coisas relacionadas à qualidade de conexão. > > alguém tem alguma sugestão? > > grato, > > -- > saudações, > irado furioso com tudo > Linux User 179402/FreeBSD BSD50853/FUG-BR 154 > Não uso drogas - 100% Miko$hit-free > mesmo a melhor das cobras, é cobra - provérbio árabe > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] RES: teste de tráfego - ponto a pont o
Tem o netperf[1] também, já usei port win32, freebsd e Linux. [1] http://www.netperf.org/netperf/ > -Mensagem original- > De: freebsd-boun...@fug.com.br [mailto:freebsd-boun...@fug.com.br] Em > nome de Edinilson - ATINET > Enviada em: segunda-feira, 29 de junho de 2009 17:10 > Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) > Assunto: Re: [FUG-BR] teste de tráfego - ponto a ponto > Prioridade: Alta > > É para Windows, mas talvez sirva: > http://www.mikrotik.com/download/btest.exe > > > Edinilson > - > ATINET-Professional Web Hosting > Tel Voz: (0xx11) 4412-0876 > http://www.atinet.com.br > > > - Original Message - > From: "irado furioso com tudo" > To: "fug" > Sent: Monday, June 29, 2009 1:55 PM > Subject: [FUG-BR] teste de tráfego - ponto a ponto > > > > > boas tardes, galera :) > > preciso fazer um teste entre dois pontos - tunel vpn - e não encontro > um soft apropriado; a idéia é fazer com que haja uma "tempestade" de > pacotes entre dois pontos (via tunel vpn) para avaliar a eventual perda > de pacotes, latência, essas coisas relacionadas à qualidade de conexão. > > alguém tem alguma sugestão? > > grato, > > -- > saudações, > irado furioso com tudo > Linux User 179402/FreeBSD BSD50853/FUG-BR 154 > Não uso drogas - 100% Miko$hit-free > mesmo a melhor das cobras, é cobra - provérbio árabe > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > > > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: Teste de link
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Alessandro > de Souza Rocha > Sent: quarta-feira, 23 de janeiro de 2008 18:16 > To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) > Subject: Re: [FUG-BR] RES: Teste de link > > Em 23/01/08, Cristiano Maynart Pereira<[EMAIL PROTECTED]> escreveu: > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of Marcio A. Sepp > > > Sent: quarta-feira, 23 de janeiro de 2008 15:34 > > > To: 'Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)' > > > Subject: [FUG-BR] RES: Teste de link > > > > > > > > > Oi Giancarlo, > > > > > > > > > Vou explanar aqui como está a minha rede, para ver se conseguimos > > > detectar onde estou errando. > > > Abaixo segue um cenário fictício que montei aqui na empresa > > > simulando o problema real do cliente, porém, no meu caso, > com apenas > > > 02 interfaces de saída. > > > > > > Os ips externos são: > > > 192.168.254.185/24 gw -> 192.168.254.254 > > > 192.168.0.185/24 gw -> 192.168.0.1 > > > > > > A saída da placa de rede 192.168.254.185 é: > > > traceroute to uol.com.br (200.221.2.45), 64 hops max, 40 byte > > > packets > > > 1 192.168.254.254 (192.168.254.254) 0.370 ms 0.371 ms > 0.313 ms > > > 2 189.30.89.254 (189.30.89.254) 35.500 ms 34.515 ms 36.289 ms > > > 3 * BrT-VL7-5-1-fnses300.brasiltelecom.net.br > > > (201.10.235.133) 53.250 ms > > > * ... > > > ... > > > > > > Observe o segundo nó da rede (189.30.89.254). Este é o gateway do > > > meu modem adsl (no meu caso). > > > Este é o ip que eu quero pingar para testar a conectividade. > > > Teoricamente o ping deveria percorrer o seguinte caminho: > > > sair da placa de rede 192.168.254.185, passar pelo meu gateway > > > (192.168.254.254) e ir até o ip 189.30.89.254. > > > > > > Este é o ping que estou executando: > > > ping -I 192.168.254.185 -q -c 1 -w 1 189.30.89.254 > > > > > > Se eu rodar o comando acima, o ping funciona, porém se eu > retirar o > > > cabo de rede da outra interface externa, o ping para de > funcionar, o > > > que me leva a crer que na verdade ele está saindo pela outra > > > interface. > > > > > > As rotas de saída são adicionadas da seguinte forma: > > > -bash-3.2# cat /etc/hostname.xl1 > > > inet NONE > > > !route add -mpath default > > > > > > Acreditei que o problema era o firewall, mas retirei as > regras dele > > > que fazem o route-to e o problema persiste. > > > > > > > > > > > > -- > > > Att. > > > Márcio > > > > > > Olá. > > > > O que pode estar acontecendo é que o route-to está sendo > aplicado apena para a sua rede interna e o FreeBSD/OpenBSD > não está caindo nesta regra. Assim, você pode criar rotas > estáticas no sistema, por exemplo (para o caso que você informou): > > route add -host 189.30.89.254 192.168.254.254 > > > > E também adicionar a rota para a outra saída. > > route add -host x.x.x.x 192.168.0.1 > > > > > > > > Cristiano Maynart Pereira > > > > > > > > - > > Histórico: http://www.fug.com.br/historico/html/freebsd/ > > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > > > > prefiro fazer 2 nats do que usar o route. > -- > Alessandro de Souza Rocha > Administrador de Redes e Sistemas > Freebsd-BR User #117 > - Para fazer o NAT terá que ser no modem e como você provavelmente tem 2 modems não vai conseguir que um NAT em um modem saia pelo outro. Então, a solução para o que precisa é mesmo criar as rotas, mais simples, mais fácil e mais funcional. Cristiano Maynart Pereira - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: Teste de link
Em 23/01/08, Cristiano Maynart Pereira<[EMAIL PROTECTED]> escreveu: > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Marcio A. Sepp > > Sent: quarta-feira, 23 de janeiro de 2008 15:34 > > To: 'Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)' > > Subject: [FUG-BR] RES: Teste de link > > > > > > Oi Giancarlo, > > > > > > Vou explanar aqui como está a minha rede, para ver se > > conseguimos detectar onde estou errando. > > Abaixo segue um cenário fictício que montei aqui na empresa > > simulando o problema real do cliente, porém, no meu caso, com > > apenas 02 interfaces de saída. > > > > Os ips externos são: > > 192.168.254.185/24 gw -> 192.168.254.254 > > 192.168.0.185/24 gw -> 192.168.0.1 > > > > A saída da placa de rede 192.168.254.185 é: > > traceroute to uol.com.br (200.221.2.45), 64 hops max, 40 byte packets > > 1 192.168.254.254 (192.168.254.254) 0.370 ms 0.371 ms 0.313 ms > > 2 189.30.89.254 (189.30.89.254) 35.500 ms 34.515 ms 36.289 ms > > 3 * BrT-VL7-5-1-fnses300.brasiltelecom.net.br > > (201.10.235.133) 53.250 ms > > * ... > > ... > > > > Observe o segundo nó da rede (189.30.89.254). Este é o > > gateway do meu modem adsl (no meu caso). > > Este é o ip que eu quero pingar para testar a conectividade. > > Teoricamente o ping deveria percorrer o seguinte caminho: > > sair da placa de rede 192.168.254.185, passar pelo meu gateway > > (192.168.254.254) e ir até o ip 189.30.89.254. > > > > Este é o ping que estou executando: > > ping -I 192.168.254.185 -q -c 1 -w 1 189.30.89.254 > > > > Se eu rodar o comando acima, o ping funciona, porém se eu > > retirar o cabo de rede da outra interface externa, o ping > > para de funcionar, o que me leva a crer que na verdade ele > > está saindo pela outra interface. > > > > As rotas de saída são adicionadas da seguinte forma: > > -bash-3.2# cat /etc/hostname.xl1 > > inet NONE > > !route add -mpath default > > > > Acreditei que o problema era o firewall, mas retirei as > > regras dele que fazem o route-to e o problema persiste. > > > > > > > > -- > > Att. > > Márcio > > > Olá. > > O que pode estar acontecendo é que o route-to está sendo aplicado apena para > a sua rede interna e o FreeBSD/OpenBSD não está caindo nesta regra. Assim, > você pode criar rotas estáticas no sistema, por exemplo (para o caso que você > informou): > route add -host 189.30.89.254 192.168.254.254 > > E também adicionar a rota para a outra saída. > route add -host x.x.x.x 192.168.0.1 > > > > Cristiano Maynart Pereira > > > > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > prefiro fazer 2 nats do que usar o route. -- Alessandro de Souza Rocha Administrador de Redes e Sistemas Freebsd-BR User #117 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: Teste de link
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Marcio A. Sepp > Sent: quarta-feira, 23 de janeiro de 2008 15:34 > To: 'Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)' > Subject: [FUG-BR] RES: Teste de link > > > Oi Giancarlo, > > > Vou explanar aqui como está a minha rede, para ver se > conseguimos detectar onde estou errando. > Abaixo segue um cenário fictício que montei aqui na empresa > simulando o problema real do cliente, porém, no meu caso, com > apenas 02 interfaces de saída. > > Os ips externos são: > 192.168.254.185/24 gw -> 192.168.254.254 > 192.168.0.185/24 gw -> 192.168.0.1 > > A saída da placa de rede 192.168.254.185 é: > traceroute to uol.com.br (200.221.2.45), 64 hops max, 40 byte packets > 1 192.168.254.254 (192.168.254.254) 0.370 ms 0.371 ms 0.313 ms > 2 189.30.89.254 (189.30.89.254) 35.500 ms 34.515 ms 36.289 ms > 3 * BrT-VL7-5-1-fnses300.brasiltelecom.net.br > (201.10.235.133) 53.250 ms > * ... > ... > > Observe o segundo nó da rede (189.30.89.254). Este é o > gateway do meu modem adsl (no meu caso). > Este é o ip que eu quero pingar para testar a conectividade. > Teoricamente o ping deveria percorrer o seguinte caminho: > sair da placa de rede 192.168.254.185, passar pelo meu gateway > (192.168.254.254) e ir até o ip 189.30.89.254. > > Este é o ping que estou executando: > ping -I 192.168.254.185 -q -c 1 -w 1 189.30.89.254 > > Se eu rodar o comando acima, o ping funciona, porém se eu > retirar o cabo de rede da outra interface externa, o ping > para de funcionar, o que me leva a crer que na verdade ele > está saindo pela outra interface. > > As rotas de saída são adicionadas da seguinte forma: > -bash-3.2# cat /etc/hostname.xl1 > inet NONE > !route add -mpath default > > Acreditei que o problema era o firewall, mas retirei as > regras dele que fazem o route-to e o problema persiste. > > > > -- > Att. > Márcio Olá. O que pode estar acontecendo é que o route-to está sendo aplicado apena para a sua rede interna e o FreeBSD/OpenBSD não está caindo nesta regra. Assim, você pode criar rotas estáticas no sistema, por exemplo (para o caso que você informou): route add -host 189.30.89.254 192.168.254.254 E também adicionar a rota para a outra saída. route add -host x.x.x.x 192.168.0.1 Cristiano Maynart Pereira - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] RES: Teste de link
Oi Giancarlo, Vou explanar aqui como está a minha rede, para ver se conseguimos detectar onde estou errando. Abaixo segue um cenário fictício que montei aqui na empresa simulando o problema real do cliente, porém, no meu caso, com apenas 02 interfaces de saída. Os ips externos são: 192.168.254.185/24 gw -> 192.168.254.254 192.168.0.185/24 gw -> 192.168.0.1 A saída da placa de rede 192.168.254.185 é: traceroute to uol.com.br (200.221.2.45), 64 hops max, 40 byte packets 1 192.168.254.254 (192.168.254.254) 0.370 ms 0.371 ms 0.313 ms 2 189.30.89.254 (189.30.89.254) 35.500 ms 34.515 ms 36.289 ms 3 * BrT-VL7-5-1-fnses300.brasiltelecom.net.br (201.10.235.133) 53.250 ms * ... ... Observe o segundo nó da rede (189.30.89.254). Este é o gateway do meu modem adsl (no meu caso). Este é o ip que eu quero pingar para testar a conectividade. Teoricamente o ping deveria percorrer o seguinte caminho: sair da placa de rede 192.168.254.185, passar pelo meu gateway (192.168.254.254) e ir até o ip 189.30.89.254. Este é o ping que estou executando: ping -I 192.168.254.185 -q -c 1 -w 1 189.30.89.254 Se eu rodar o comando acima, o ping funciona, porém se eu retirar o cabo de rede da outra interface externa, o ping para de funcionar, o que me leva a crer que na verdade ele está saindo pela outra interface. As rotas de saída são adicionadas da seguinte forma: -bash-3.2# cat /etc/hostname.xl1 inet NONE !route add -mpath default Acreditei que o problema era o firewall, mas retirei as regras dele que fazem o route-to e o problema persiste. -- Att. Márcio -Mensagem original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em nome de Giancarlo Rubio Enviada em: terça-feira, 22 de janeiro de 2008 17:31 Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) Assunto: Re: [FUG-BR] Teste de link Marcio: Eu uso com -I e funciona normalmente, tenho usado no ifstated a mesma flag que vc. A sugestao que dou e retirar o cabo ate descobrir quem e o kra que ele esta saindo, creio que vc esta se confundindo em algo. ps. em vez de usar ping voce poderia usar snmp ja que e muito mais confiavel Em 22/01/08, Marcio A. Sepp<[EMAIL PROTECTED]> escreveu: > > Boa tarde, > > > Postei a dúvida abaixo na lista do OpenBSD, porém não obtive solução e > por isso estou postando nesta lista. > > Aproveito para agradecer ao Giancarlo Rubio pela ajuda postada em > outras ocasiões sobre este assunto. > > > --- Recorte do email --- > > Tenho um roteador OpenBSD 4.1 com 4 links de acesso a internet > conectados a ele e 1 interface interna. O balanceamento do tráfego de > saída é feito através do pf + route-to com o round robin. > Com isso, consigo resolver meu problema de balanceamento de tráfego > perfeitamente (inclusive indico a solução para quem precisar). > > Contudo, esbarro no problema de um ou mais links estarem inoperantes > quando envio o tráfego para ele. Por isso preciso encontrar uma forma > de testar se o link está operante ou não e encaminhar o tráfego para > os links operantes caso um deles caia. Pensei em utilizar um ping para > verificar o status do link. Vejam: > ping -I -q -c 1 -w 1 ping > -I -q -c 1 -w 1 ... > ... > > > Teoricamente o script acima deveria enviar um pacote para o gateway do > meu link (segundo hop do tráfego de saída) através da interface a qual > o link está conectado. > > Este ping poderia ser colocado no ifsated e teoricamente me daria o > status da interface. > Infelizmente, por algum motivo que eu desconheço, o ping acima não > funciona como o esperado. Fiz um teste rodando o ping abaixo: > ping -I > > e desconectei o cabo de rede da interface_4 enquanto o ping estava > rodando e o mesmo continuou a enviar e receber pacotes sem apresentar > perdas. Isso me faz crer que o ping estava saindo por outra rota, que > não envolvia a interface_4. Então porque o parametro -I não funcionou corretamente? > > Alguém conhece alguma forma de testar a disponibilidade de um link? > > > -- > Att. > Márcio > > > > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > -- Giancarlo Rubio - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: Teste
tambe fique sem receber tambem. Em 19/10/07, Marcio A. Sepp<[EMAIL PROTECTED]> escreveu: > Eu comecei a receber agora, mas fiquei alguns dias sem receber tbm. > > Att. > Márcio A. Sepp > > > -Mensagem original- > > De: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Em nome de Renato Barucco > > Enviada em: sexta-feira, 19 de outubro de 2007 12:21 > > Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) > > Assunto: Re: [FUG-BR] Teste > > > > Eu recebo diariamente uma porção... > > > > Acho q não estamos com problemas... > > > > Em 18/10/07, Giancarlo Rubio <[EMAIL PROTECTED]> escreveu: > > > > > > Faz 2 dias q nao recebo email. Estamos com problemas? > > > > > > -- > > > Giancarlo Rubio > > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] RES: Teste
Eu comecei a receber agora, mas fiquei alguns dias sem receber tbm. Att. Márcio A. Sepp > -Mensagem original- > De: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Em nome de Renato Barucco > Enviada em: sexta-feira, 19 de outubro de 2007 12:21 > Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) > Assunto: Re: [FUG-BR] Teste > > Eu recebo diariamente uma porção... > > Acho q não estamos com problemas... > > Em 18/10/07, Giancarlo Rubio <[EMAIL PROTECTED]> escreveu: > > > > Faz 2 dias q nao recebo email. Estamos com problemas? > > > > -- > > Giancarlo Rubio - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: teste
Obrigado! gethostbyname Bruno R. Rosa escreveu: > Sim > > > > -Mensagem original- > De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em nome > de gethostbyname > Enviada em: segunda-feira, 19 de fevereiro de 2007 13:52 > Para: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)" > Assunto: [FUG-BR] teste > > Teste. Por favor, tem alguém me lendo? > > obrigado, > gethostbyname > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > > - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] RES: teste
Sim -Mensagem original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em nome de gethostbyname Enviada em: segunda-feira, 19 de fevereiro de 2007 13:52 Para: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)" Assunto: [FUG-BR] teste Teste. Por favor, tem alguém me lendo? obrigado, gethostbyname - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] RES: teste
Acabei de assumir o provedor, foi colocado em 2003, fiz varios testes de relay, e em todos o servidor atual passou, a DSBL não deixa eu tirar ate os servidores de DNS reversos estiverem configurados corretamente, entao estou trabalhando nisso atualmente e espero que com o passar do tempo tudo possa ser resolvido, obrigado pela ajuda irado Atenciosamente Uily Roberto Neves Neto Gerente Wireless Elyte Tecnologia de Informatica Ltda (92) 2126 7812 - (92) 8112 1150 Email: [EMAIL PROTECTED] -Mensagem original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em nome de irado furioso com tudo Enviada em: quarta-feira, 18 de outubro de 2006 07:48 Para: freebsd@fug.com.br Assunto: Re: [FUG-BR] teste Em Tue, 17 Oct 2006 18:02:51 -0400 "Uily Neves" <[EMAIL PROTECTED]> escreveu: > Desculpem o teste, é que meu ip estava na lista da DSBL e troquei para > um outro. se alguém estiver usando o seu MTA para fazer spam, em breve vc estará na DSBL de novo. Daí, novo ip, até que se esgotem. É melhor verificar PORQUE vc caiu lá e remover-se (após eliminar o relay). -- saudações, irado furioso com tudo Linux User 179402/FreeBSD BSD50853/FUG-BR 154 100% Miko$hit-free o que se pode esperar de um povo que elege maluf, clodovil, joao cunha e outros como seus representantes? - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd __ Informação do NOD32 IMON 1.1809 (20061018) __ Esta mensagem foi verificada pelo NOD32 sistema antivírus http://www.eset.com.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: teste de hd (stress)
On Tue, 5 Sep 2006 21:28:47 -0300 "Rafael Henrique Faria" <[EMAIL PROTECTED]> escreveu assim: > sysctl kern.geom.debugflags=16 > > Essa linha vai alterar o valor d kern.geom.debugflags, de 0 para 16, > assim desativando a trava para mexer com a MBR dos discos. hmmm.. eu vou experimentar isso aí. O security level não é, pq está desativado (-1), mas isso aí leva jeito. Veremos. Obrigado :) -- saudações, irado furioso com tudo Linux User 179402/FreeBSD BSD50853/FUG-BR 154 Um país que se diz democrático não pode ter voto obrigatório. Vote - 99 - NULO - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: teste de hd (stress)
Bela dica On Tue, 2006-09-05 at 21:28 -0300, Rafael Henrique Faria wrote: > Irado, eu não sei se é o caso, mas a um tempo atraz eu tive alguns problemas > para trabalhar com partições no FreeBSD, ao adicionar um disco novo, eu não > conseguia modificar as partições, nem apagar, nem nada. > > Depois de muita busca, descobri que o FreeBSD tem um sistema de proteção > para evitar que alguem apague acidentalmente uma partição ou um slice em > algum disco do sistema. Assim, quem tentar apagar algum disco velho, ou > alguma partição desejada, não vai conseguir, usando o sysinstal, ou nem > mesmo o "dd". Eu não se o mesmo se aplica para criar novos slices. > Para desativar temporariamente este recurso, desative o kern_securelevel no > rc.conf. (Eu tive q desativar porque sempre utilizo o kern_securelevel no > nível 3) > > sysctl kern.geom.debugflags=16 > > Essa linha vai alterar o valor d kern.geom.debugflags, de 0 para 16, assim > desativando a trava para mexer com a MBR dos discos. > > Agora vc pode usar o sysinstal normalmente, apagar suas partições, criar > novas, sem problema. > E basta reiniciar o FreeBSD para q tudo volte ao normal. > > Não sei como deixar essa configuração permanente, talvez alguém da lista > aqui saiba. Complementando Coloca no /etc/sysctl.conf -- Freebsd-BR User #88 --- Giancarlo Rubio - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] RES: teste de hd (stress)
Irado, eu não sei se é o caso, mas a um tempo atraz eu tive alguns problemas para trabalhar com partições no FreeBSD, ao adicionar um disco novo, eu não conseguia modificar as partições, nem apagar, nem nada. Depois de muita busca, descobri que o FreeBSD tem um sistema de proteção para evitar que alguem apague acidentalmente uma partição ou um slice em algum disco do sistema. Assim, quem tentar apagar algum disco velho, ou alguma partição desejada, não vai conseguir, usando o sysinstal, ou nem mesmo o "dd". Eu não se o mesmo se aplica para criar novos slices. Para desativar temporariamente este recurso, desative o kern_securelevel no rc.conf. (Eu tive q desativar porque sempre utilizo o kern_securelevel no nível 3) sysctl kern.geom.debugflags=16 Essa linha vai alterar o valor d kern.geom.debugflags, de 0 para 16, assim desativando a trava para mexer com a MBR dos discos. Agora vc pode usar o sysinstal normalmente, apagar suas partições, criar novas, sem problema. E basta reiniciar o FreeBSD para q tudo volte ao normal. Não sei como deixar essa configuração permanente, talvez alguém da lista aqui saiba. Muito interessante esse recurso do Free, porém acho que devia ser um pouco mais explicito isso. Porque eu não encontrei aviso em lugar algum do sistema dizendo que os slices não podem ser modificados de dentro do sistema. Só depois de muito google que eu consegui encontrar algumas informações sobre o assunto, mas mesmo assim essa sysctl foi algo difícil de encontrar. Rafael Henrique Faria Delegacia da Receita Federal da 8a. Região -Mensagem original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em nome de irado furioso com tudo Enviada em: terça-feira, 5 de setembro de 2006 14:30 Para: lista fugsp-br Assunto: [FUG-BR] teste de hd (stress) boa tarde, galera. Tenho um hd aqui com comportamento estranho (é um IDE). Uso o sysinstall pra particionamento e labels e, quando digo pra 'W'rite aparece o êrro de que não conseguiu gravar as informações. Posteriormente, não monta :(, diz que não há sistema de arquivos válido lá. Minha suspeita é da controladora do HD, mas preciso de um script bash ou coisa que o valha que me permita fazer um teste de stress dêsse hardware. Tempos atrás (muitos verões) vi qualquer coisa como o dd /dev/nul para /dev/ad0.. mas, francamente, não achei nada no google. alguém tem lembrança ou url onde eu possa achar um script/aplicativo apropriado? TIA -- saudações, irado furioso com tudo Linux User 179402/FreeBSD BSD50853/FUG-BR 115 Um país que se diz democrático não pode ter voto obrigatório. Vote - 99 - NULO - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: Teste PerformancePostgreSQLFreeBSD Linux e Windows2003Server
> Eu concordo com o Patrick. > Benchmark é uma coisa complicada. De um lado o pessoal acha que a > instalação > padrão é a melhor. De outro que o sistema tunnado é o ideal. Porém muitas > coisas interferem além disso. O hardware utilizado, memória, placa mãe, > HDs, > fonte, cabos. Também concordo com tudo que o Patrick falou, mas eu queria dizer mais uma coisa: Acho que muita gente está confundindo o objetivo do benchmark enviado pelo membro da lista. Ele fez um benchmark por necessidades próprias e resolveu disponibilizar os resultados para a lista, sem ofender ninguém, sem ofender nenhum sistema SO e sem dizer que aquela seria a maneira ideal de se fazer um benchmark. Ficou bem claro no último e-mail enviado pelo autor. Moral da história: Estão criando uma discussão em vão, quem achar que o benchmark pode ser melhorado, por favor também publique os resultados para na lista também... ;-) []s Ronan - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: Teste Performance PostgreSQLFreeBSD Linux e Windows2003Server
blá. 2006/8/24, Rafael Henrique Faria <[EMAIL PROTECTED]>: > Eu concordo com o Patrick. > Benchmark é uma coisa complicada. De um lado o pessoal acha que a instalação > padrão é a melhor. De outro que o sistema tunnado é o ideal. Porém muitas > coisas interferem além disso. O hardware utilizado, memória, placa mãe, HDs, > fonte, cabos. > > Agora vou colocar alguns pontos. > > Dizer que o melhor é a instalação padrão, existem controvérsias. Isso seria > o mesmo que entrar em uma competição de performance de carros com um carro > original de fabrica. Com o carro original ele vai ter apenas 70% do > desempenho real do carro. Isso é feito para que quando alguém sair > acelerando no máximo do carro, ele não explodir na hora. Mas tunnar o carro, > deixar ele a 100% do desempenho que ele pode atingir, sem adicionar nada > novo (sem NOS, turbo e coisas do tipo) vc vai estar ganhando desempenho com > o original do carro. > O mesmo aplicaria aos SO, uma instalação padrão é feita para rodar em tudo > quanto eh lugar, pecando em varias aspectos. Optimizar ele para o hardware > usado, para a aplicação que se deseja utilizar, não estriamos fazendo nada > anormal, exagerado, apenas fazendo o SO rodar ao máximo de seu desempenho. > Optimizar um SO nós vamos estar utilizando recursos que foram adicionados ao > sistema para quem ele realmente funcione em sua melhor forma, em seu melhor > desempenho. > > A um tempo atraz, eu participei de um teste de desempenho de hardware, > usando o software SuperPI, onde o programa calcula o valor exato de PI com 1 > milhão de dígitos após a virgula, e o desempenho do hardware era obtido pelo > tempo levado no calculo. O software não continha nenhuma optimização para > hardware. Então ele rodava do mesmo modo em todos os processadores. Mas > depois apareceram algumas versões com optimização para instroções SSE, SSE2, > 64 bits, etc... Mas os resultados obtidos com essas versões optimizadas > foram descartados. Eu achei injusto. > Realizar um teste de desempenho em um processador, sem usar os seus recursos > é o mesmo que testar uma rodovia de alta velocidade com um fusca. > Um teste realizado com o software original, apresentava 47 segundos para > realizar os cálculos em um determinado processador, e o mesmo processador > com o software optimizado para ele, chegava a 32 segundos. > Agora, acredito que assim, cada pessoa, deveria utilizar o software > apropriado para o seu processador, com os recursos disponíveis no > processador para obter o verdadeiro resultado de quanto o processador dele > demora para realizar o calculo. Se um processador tem apenas SSE, então é o > maximo que ele vai conseguir, mas se um processador tem SSE3, HT, 64 bits, > então é claro que ele vai ter uma performance muito melhor. > E o mais incrível, durante os testes que eu realizei, apenas uma troca de > memória (não de tamanho, mas apenas de modelo de memória, eu utilizava 4 > pentes de Samsung 400Mhz, 512mb cada, troquei por 5 Samsung TCCC 400Mhz, > 512mb cada), eu tive uma redução de 2 segundos no calculo. Até modelo de > memória influencia e muito no desempenho de um computador. E eu com um > Pentium 4 Prescott com 3,0Ghz, 2Gb d ram, placa mãe ASUS P4C800 com chipset > intel i875, fiquei atraz de um cada com um Pentium 4 Prescott com 2,6Ghz, > com 512mb d Ram, e placa mãe Intel. Só pela palca ser diferente, a maquina > teve um desempenho melhor, mesmo tempo um processador mais lento. > > Enfim, por isso eu acho que nos benchmarks, os SO devem ser otimizados ao > maximo, para ser utilizados todos os seus recursos. > Mas o cenário nunca será real. Estes testes somente devem servir como > referencia do que poderia ser atingido com uma configuração parecida. > Só de termos uma placa mãe diferente, um processador diferente, memória > diferente, da utilizada no teste, nós nunca conseguiremos um desempenho > parecido, pode ser melhor, como pode ser pior. > > Eu já vi propagandas da Oracle dizendo que conseguiu realizar mais de 1 > bilhão de consultas em não sei quanto tempo, utilizando 3 maquinas Sparc com > Solaris e não sei mais o que... isso é completamente fora do cenário real da > maioria das pessoas. O que importa se o Oracle fez 1 bilhão de consultas em > tal maquina, se eu utilizo um Pentium 4 como servidor? > > Optimização de SO é algo complicado, cada um tem suas experiências, suas > dores de cabeça, sua melhor solução, por isso ninguém concorda com as > optimizações que foram feitas em benchmarks, onde o seu sistema preferido > saiu perdendo, vc com certeza dirá: se eu tivesse feito a optimização o > teste seria diferente. Certo, mas temos que entender que naquela situação, > não teria sido diferente, pq aquele foi o resultado obtido. Cada vez que o > teste for feito, em lugar diferente, pessoas diferentes envolvidas, hardware > diferente, o teste vai ter um resultado diferente. > > O benchmark está longe de ser uma ciência exata. Essa é a verdade. > > O melhor que temos q fazer, é escolher um SO, um SGB
[FUG-BR] RES: Teste Performance PostgreSQLFreeBSD Linux e Windows2003Server
Eu concordo com o Patrick. Benchmark é uma coisa complicada. De um lado o pessoal acha que a instalação padrão é a melhor. De outro que o sistema tunnado é o ideal. Porém muitas coisas interferem além disso. O hardware utilizado, memória, placa mãe, HDs, fonte, cabos. Agora vou colocar alguns pontos. Dizer que o melhor é a instalação padrão, existem controvérsias. Isso seria o mesmo que entrar em uma competição de performance de carros com um carro original de fabrica. Com o carro original ele vai ter apenas 70% do desempenho real do carro. Isso é feito para que quando alguém sair acelerando no máximo do carro, ele não explodir na hora. Mas tunnar o carro, deixar ele a 100% do desempenho que ele pode atingir, sem adicionar nada novo (sem NOS, turbo e coisas do tipo) vc vai estar ganhando desempenho com o original do carro. O mesmo aplicaria aos SO, uma instalação padrão é feita para rodar em tudo quanto eh lugar, pecando em varias aspectos. Optimizar ele para o hardware usado, para a aplicação que se deseja utilizar, não estriamos fazendo nada anormal, exagerado, apenas fazendo o SO rodar ao máximo de seu desempenho. Optimizar um SO nós vamos estar utilizando recursos que foram adicionados ao sistema para quem ele realmente funcione em sua melhor forma, em seu melhor desempenho. A um tempo atraz, eu participei de um teste de desempenho de hardware, usando o software SuperPI, onde o programa calcula o valor exato de PI com 1 milhão de dígitos após a virgula, e o desempenho do hardware era obtido pelo tempo levado no calculo. O software não continha nenhuma optimização para hardware. Então ele rodava do mesmo modo em todos os processadores. Mas depois apareceram algumas versões com optimização para instroções SSE, SSE2, 64 bits, etc... Mas os resultados obtidos com essas versões optimizadas foram descartados. Eu achei injusto. Realizar um teste de desempenho em um processador, sem usar os seus recursos é o mesmo que testar uma rodovia de alta velocidade com um fusca. Um teste realizado com o software original, apresentava 47 segundos para realizar os cálculos em um determinado processador, e o mesmo processador com o software optimizado para ele, chegava a 32 segundos. Agora, acredito que assim, cada pessoa, deveria utilizar o software apropriado para o seu processador, com os recursos disponíveis no processador para obter o verdadeiro resultado de quanto o processador dele demora para realizar o calculo. Se um processador tem apenas SSE, então é o maximo que ele vai conseguir, mas se um processador tem SSE3, HT, 64 bits, então é claro que ele vai ter uma performance muito melhor. E o mais incrível, durante os testes que eu realizei, apenas uma troca de memória (não de tamanho, mas apenas de modelo de memória, eu utilizava 4 pentes de Samsung 400Mhz, 512mb cada, troquei por 5 Samsung TCCC 400Mhz, 512mb cada), eu tive uma redução de 2 segundos no calculo. Até modelo de memória influencia e muito no desempenho de um computador. E eu com um Pentium 4 Prescott com 3,0Ghz, 2Gb d ram, placa mãe ASUS P4C800 com chipset intel i875, fiquei atraz de um cada com um Pentium 4 Prescott com 2,6Ghz, com 512mb d Ram, e placa mãe Intel. Só pela palca ser diferente, a maquina teve um desempenho melhor, mesmo tempo um processador mais lento. Enfim, por isso eu acho que nos benchmarks, os SO devem ser otimizados ao maximo, para ser utilizados todos os seus recursos. Mas o cenário nunca será real. Estes testes somente devem servir como referencia do que poderia ser atingido com uma configuração parecida. Só de termos uma placa mãe diferente, um processador diferente, memória diferente, da utilizada no teste, nós nunca conseguiremos um desempenho parecido, pode ser melhor, como pode ser pior. Eu já vi propagandas da Oracle dizendo que conseguiu realizar mais de 1 bilhão de consultas em não sei quanto tempo, utilizando 3 maquinas Sparc com Solaris e não sei mais o que... isso é completamente fora do cenário real da maioria das pessoas. O que importa se o Oracle fez 1 bilhão de consultas em tal maquina, se eu utilizo um Pentium 4 como servidor? Optimização de SO é algo complicado, cada um tem suas experiências, suas dores de cabeça, sua melhor solução, por isso ninguém concorda com as optimizações que foram feitas em benchmarks, onde o seu sistema preferido saiu perdendo, vc com certeza dirá: se eu tivesse feito a optimização o teste seria diferente. Certo, mas temos que entender que naquela situação, não teria sido diferente, pq aquele foi o resultado obtido. Cada vez que o teste for feito, em lugar diferente, pessoas diferentes envolvidas, hardware diferente, o teste vai ter um resultado diferente. O benchmark está longe de ser uma ciência exata. Essa é a verdade. O melhor que temos q fazer, é escolher um SO, um SGBD, e nos dedicarmos ao máximo para optimizar eles em nossos servidores, com nossos softwares, para nossos sistemas, etc, etc, etc, etc O teste de desempenho realizado pelo nosso amigo foi muito bom, mostr
