Em Quarta 24 Maio 2006 15:44, Marcos Vinicius Lazarini escreveu:
> Ronaldo, vamos tentar esclarecer umas coisas.
>
> o fish:// funciona atraves do ssh + scripts em perl na máquina remota
> (entre num diretório como /usr/share ou /usr/share/doc e veja com o top uns
> processos perl aparecendo e sumindo). Já o sftp:// utiliza direto o
> protocolo sftp (existe um comando sftp p/ os desavisados, muito semelhante
> ao ftp). A diferença de desempenho tbm está relacionada com a diferença de
> implementação.
>
> Outra coisa, achei o arquivo que vc testou pequeno, pois transferiu em até
> menos de 10 segundos. Talvez um de + de 1 GB (p/ nao caber nada no cache)
> ou um de 300 MB (p/ caber no cache dos dois).
>
> Os micros são +- rápidos e vc tá trabalhando proximo do limite de saturação
> da rede 100 Mbps (teóricos 12.5 MB/s). Mas pelos seus resultados, o uso de
> CPU deve estar bem alto - pois quando vc liga a compressão, a CPU não dá
> mais conta de comprimir nessa taxa e acaba segunrado a transmissão. Leia na
> manpage do ssh:
>
> [...]
> The compression algorithm is the same used by gzip(1), and the ``level''
> can be controlled by the CompressionLevel option for protocol version 1.
> Compression is desirable on modem lines and other slow connections, but
> will only slow down things on fast networks.
> [...]
>
> deixe rolando uma transmissão e monitore a CPU com o top (ou com o htop)
>
> Outra comentário é que no exemplo vc está tentando comprimir um .mpg, que
> não deve comprimir quase nada... então isso literalmente é esforço jogado
> fora. Se seus dados forem isso, mais um motivo p/ não usar compressão.
>
> Voltando...
> O rsync usa muito I/O de disco e um bom tanto de CPU - se o disco de uma
> máquina for lento, isso pode atrasar todo o processo. Isso acontece
> justamente p/ se evitar transferir muitos dados que já foram transferidos
> atualmente... Muito bem dito pelo admin do kernel.org, o rsync "trades
> bandwidth for CPU horsepower" [1]
>
> Já o unison (nunca usei) tem um trabalho extra que é justamente saber quem
> tem que mandar o que pra onde, e me parece q ele mandem uma série de
> informações num .unison da vida - se algum disco seu tiver uma velocidade
> de I/O ruim, provavelmente vai afetar bastante o desempenho...
>
> Quanto as grandes diferenças de velocidade de transmissão, não sei pq isso
> acontece, mas já tive esses problemas - e nao sei como resolver. No caso da
> linha de comando, é fácil resolver... basta logar na máquina certa. O fato
> é que o ssh é um protocolo pesado, que usa bastante CPU - e nao sei se é
> simetrico em termos de CPU (ambos os hosts, gastam o mesmo tanto?)
>
> [1] http://kerneltrap.org/node/5070
>
>
> --
> Marcos
Marcos,
blz, vou dar uma pensada melhor em suas explicações. Já testei com arquivos
grandes é da no mesmo.
Valeu
Inte
Ronaldo
--
Power corrupts. Absolute power is kind of neat.
-- John Lehman, Secretary of the Navy, 1981-1987
--
|> // | \\ [***********************************]
| ( õ õ ) [Prof. Ronaldo Reis Júnior ]
|> V [UNIMONTES/Depto. Biologia Geral ]
| / \ [36570-000 Viçosa - MG ]
|> /(.''`.)\ [Fone: 31-3899-4007 ]
| /(: :' :)\ [EMAIL PROTECTED] ]
|>/ (`. `'` ) \[ICQ#: 5692561 | LinuxUser#: 205366 ]
| ( `- ) [***********************************]
|>> _/ \_Powered by GNU/Debian Testing
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
