[FUG-BR] Comparativo entre SSD Intel Serie 520 e HD VelociRaptor 10kRPM

[AT Matik IT]

Joao Rocha Braga Filho wrote:
> 2012/4/19 AT Matik IT <asstec at matik.com.br>:
>> Joao Rocha Braga Filho wrote:
>>> 2012/4/18 AT Matik IT <asstec at matik.com.br>:
> 
>> lógica e dessa forma os cabeçalhos movem menos e carregam mais
>> SATAS, mesmo com NCQ são mais tipo FIFO, e os cabaçalhos tem que mover
>> muito mais. Não existe HD SATA que ganha SCSI em sistemas de
>> multi-processamento , independente das rotações que fizer
> 
> O SATA II tem o NCQ, mas não sei se realmente funciona, e acho que
> muitos HDs não implementam isto. E mesmo que implemente, pode
> só executar na ordem que recebe, sem reordenar levando em conta
> a rotação do disco.
> 

existem SATA com e sem, o NCQ processa as filas mas mesmo assim não
chega ao desempenho de um SCSI, lembre, falando de ambientes tipo
servidor, máquinas de pequeno porte, desktop, workstation um SATA pode
ser mais rápido que um SCSI, mas a situação inverte-se em proporção de
crescimento da fila


>>
>>>>
>>>> Voltando aos SSD
>>>> Interessante que eles perdem rápido qualquer vantagem depois de algum
>>>> pouco tempo de uso. Quando novos são veloces mas logo, dias ou 2-3
>>>> semanas, aproximam-se aos SATA
>>>
>>> Por que isto? Esta é a parte estranha?
>>>
>>
>> siga
> 
> É estranha a degradação de desempenho. Será que já começam a dar pane
> e remapear setores? Vou der uma pesquisada e ler um material que foi indicado.
> 

não, aparentemente a eletrônica SSD ainda que não está desenhada para
arquivos fragmentados, e naturalmente, os arquivos fragmentam cada vez
mais e mais com o tempo

para melhorar um pouco este efeito existe um parametro trim, "-t enable"
que pode ser aplicado com tunefs em Linux e Unix aos HDs que suportam,
mas na prática não adianta muito, apenas prorroga um pouco o efeito


>>
>>
>>>>
>>>> Assustador, o desempenho negativo na hora de deletar arquivos. A
>>>> lentidão é inaceitável
>>>
>>> Também não faz sentido.
>>
>>
>> siga
> 
> A degradação de desempenho explicaria a lentidão. O estranho é a degradação
> de desempenho.
> 


mesmo motivo de cima, deletar muitos arquivo, o processo é muito
semelhante ao acesso a arquivos fragmentados


>>>>
>>>> um teste simples e da prática real, por exemplo, é o seguinte, manipular
>>>> o ports tree, é isso que +/- acontece numa máquina o dia tudo.
>>>>
>>>> então delete seu /usr/ports, pegue uma versão atualizada com portsnap
>>>> fetch e faz a extração "time portsnap extract"
>>>
>>> Mas este teste, pelo que entendi, depende de Internet, que é um fator
>>> que pesa muito na operação.
>>>
>>> Já pensou em fazer um tar do ports tree, deletar o ports tree, e depois
>>> restaurar à partir deste tar?
>>>
>>
>>
>> desculpe mas vc também parece ser o cientista de plantão ... o que vc
>> acha que o portsnap extract faz? e o que tem a Internet a ver com isso?
>> as vezes é bom ligar a bomba antes de abrir o cano .... :)
> 
> Eu entendi que o portsnap faz download.
> 

portsnap fetch faz o download, obviamente não vinculado ao teste, apenas
para obter os dados para serem usados no teste

portsnap extract já faz que o próprio nome sugere



> 
> Eu falei para você fazer um relatório formal e publicar. Não era para
> te ofender.
> 

que bom

já publiquei demais, foram testes feitos na nossa empresa para
fundamentar o nosso trabalho e serviço ao nosso cliente, na verdade não
são dados para serem divulgados, apenas gostamos saber de que estamos
falando e com que peças estamos lidando


>> quando não ressaltam especificações assume-se que foram usados os
>> padrões, no caso de FreeBSD isso é UFS2,RW,SU
>>
> 
> Eu sugeri variações no teste.
> 

ok, eventualmente fizemos testes assim dentro de nosso interesse, por
exemplo com ZFS e GJournal mas estender isso ao assunto SSD aqui acho
demais e muito específico, mais ainda respeitando o caráter privativo
dos testes


> 
> Relaxe. :^)
> 

essa sim é boa!

:)



-- 

João Martins Eng. Resp. Suporte Técnico


Construimos Wireless Networks desde '97
Serviços para ISP desde '93

http://info.matik.com.br

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://www.fug.com.br/historico/html/freebsd/attachments/20120419/4dd1002c/attachment.bin