Ultradesempenho (suposições aqui)

Iniciado por zohguy, 03 de Janeiro de 2007, 23:41

tópico anterior - próximo tópico

zohguy

O que vocês acham de uma configuração de sistema com as seguintes especificações:

1. Os arquivos do Sistema Operacional (/ - root) ficariam armazenados num Solid State Drive (ex.: um Samsung PQI Turbo Industrial IFD Flash Disk SATA de 4 GB - US$ 499.00)

2. Quando da inicialização do sistema, os arquivos do sistema operacional seriam jogados para a memória RAM, como num LiveCD. A configuração da memória RAM tiraria proveito da arquitetura Dual Channel, onde poderiam até mesmo ser criados dois drivers virtuais (ramdisks) para operar na arquitetura dual channel como Raid 0 (o objetivo é sugar o máximo de desempenho possível). Com isso abrir os arquivos seria bem rápido, mas gravar não... Sendo que a edição se dá toda na memória RAM, esse seria um problema menor.

3. Os arquivos /home ficariam armazenados num segundo drive SSD, para minimizar o gargalo quando fossem acessados ou modificados (afinal não adianta deixar os programas numa mídia ultra-rápida e os arquivos que seriam trabalhados com esses programas numa mídia ultra-lenta).

4. Os arquivos /var ficariam em discos-rígidos normais por razões de economia.

5. A quantidade de memória RAM necessária poderia ser entre 2x1GB (US$ 239.00) e 2x2GB (US$ 499.00), dependendo do quão enxuto seria o sistema desejado pelo usuário.

6. Quando as configurações do sistema ou o mesmo fosse atualizado, seria necessário que houvesse um script que permitisse a atualização dos seus arquivos no SSD, para que tais modificações não fossem perdidas no caso de uma reinicialização do sistema.

7. Não faria sentido criar uma memória swap nessa configuração, a não ser no caso de se ter certeza de que ela viria a ser necessária, quando então ela poderia ser criada num drive SSD (degradando enormemente a performance do sistema) ou, com o devido investimento, na própria memória RAM (que teria que ser de um tamanho considerável).

........

Tudo bem que não é exatamente um sistema barato, mas acho que é o mais rápido que se pode construir com as peças disponíveis comercialmente.
E o engraçado é que poderia ser mais barato do que alguns computadores topo de linha de marcas famosas.


greylica

#1
Discussões técnicas de alto nível, isso eu adoro também, além de idéias legais, isso é legal, mas tem uns perhaps. :)

Citação de: zohguy online 03 de Janeiro de 2007, 23:41
O que vocês acham de uma configuração de sistema com as seguintes especificações:

1. Os arquivos do Sistema Operacional (/ - root) ficariam armazenados num Solid State Drive (ex.: um Samsung PQI Turbo Industrial IFD Flash Disk SATA de 4 GB - US$ 499.00)

Seria interessante realmente, como em um live-CD, e não precisaria de aferição ou atestação de integridade se fosse um SSD ( Solid State Disk ) com bloqueio de escrita por chaveamento, assim teríamos um sistema inviolável á vírus e rootkits. Mesmo assim teríamos que desviar todos os procedimentos como em um live CD para que os logs fossem guardados em algum lugar. Os SSDs são mais rápidos, porém , sua vida útil é ainda rudimentar se comparado aos HDDs, e no Windows Vista eles são utilizados para acelerar e ao mesmo tempo evitar excessivos seeks de inicialização, o que faz com que os HDDs sejam menos passíveis de erros de seek e possíveis quebras por choque gravitacional nas cabeças. Ler SSDs é melhor do que os gravar, e sinceramente eu realmente prefiro que discos holográficos ou cubos laser sejam utilizados para esta tarefa e que sejam somente legíveis, assim teríamos risco zero se obtivermos o controle sobre essas gravações, não teríamos mais preocupações com segurança praticamente.
Citar2. Quando da inicialização do sistema, os arquivos do sistema operacional seriam jogados para a memória RAM, como num LiveCD. A configuração da memória RAM tiraria proveito da arquitetura Dual Channel, onde poderiam até mesmo ser criados dois drivers virtuais (ramdisks) para operar na arquitetura dual channel como Raid 0 (o objetivo é sugar o máximo de desempenho possível). Com isso abrir os arquivos seria bem rápido, mas gravar não... Sendo que a edição se dá toda na memória RAM, esse seria um problema menor.

Técnicamente isso seria redundância, e além disso, o problema de limite de bandagem da memória poderia até ser aumentado para que diversos  " Cache Flushes " fossem feitos por um ou mais processadores. Não adianta passar dois parafusos iguais pela mesma rosca, e a arquitetura dual channel já resolveria grande parte do problema. Ainda assim temos um limite imposto pelo FSB e Ponte Norte ( no caso de Intel com core duo de 1066 Mhz ) ou no caso do AMD com direct connect ( arquitetura de controladora de RAM incorporada ), isso significa que se um processador tem sua velocidade de cache interno de 22.000 Mbits por segundo, teríamos de ter memórias e controladores de memória que tivessem ou um alto FSB para cortar os wait states ou um chipset com cache e Quad Channel ( A intel já fez isso ), e frequências de operação de 1/4 ou 1/3. ( O máxinmo alcançado por GDDR4 é 900 Mhz Real ou 1800 GDDR4 por que são enviados dois sinais de clock por ciclo de frequencia ) . Só assim teríamos uma bandagem maior, e mesmo assim esse seria o limite, com ou sem raid de RAMdisks.
A única memoria capaz hoje de cortar os wait states são a XDR ( Fabricada pela Rambus ) , GDDR 4 ( caríssima ) ou Mcache ( a mesma dos processadores ), mesmo assim teríamos de rotear isso tudo, o que causaria gargalo e wait states novamente. Não há uma solução mais adequada para a questão das memórias, então mesmo que façamos os raids com os Ramdisks, bateríamos de frente com o limite do subsistema de memória, que é o limite de velocidade com raid ou não. A intel está tentando resolver este problema embutindo controladores de memória nas próprias memórias do tipo FB e serializando a comunicação.

Citar3. Os arquivos /home ficariam armazenados num segundo drive SSD, para minimizar o gargalo quando fossem acessados ou modificados (afinal não adianta deixar os programas numa mídia ultra-rápida e os arquivos que seriam trabalhados com esses programas numa mídia ultra-lenta).

Isso seria um grande problema a menos que sua máquina fosse somente para testes, no dia a dia, nossa pasta /home está sempre ou com MP3, ou com vídeos ou com fotos. O que inviabilizaria SSD para o caso. O mais recomendado seria utilizar o que você disse primeiro para /root e /boot e usar HDs reais para guardar documentos, e desde que o Linux tem um sistema de cache excepcional, basta aumentar o cache de disco para certas tarefas como Mp3 para que isso fosse para direto e inteiro na memória, evitando a leitura do HDD de maneira assíncrona.

Citar4. Os arquivos /var ficariam em discos-rígidos normais por razões de economia.
Esse seria o caso de um bom Ramdisk, principalmente no Ubuntu que tem uma pasta temp para um montão de coisas dentro da /var.

Citar5. A quantidade de memória RAM necessária poderia ser entre 2x1GB (US$ 239.00) e 2x2GB (US$ 499.00), dependendo do quão enxuto seria o sistema desejado pelo usuário.
Do jeito que andamos ( os usuários avançados que não estão nem aí para a máquina e só querem que ela seja rápida e estável para trabalhar e não se preocupar com manutenção ... ) a segunda opção seria básica...

Citar6. Quando as configurações do sistema ou o mesmo fosse atualizado, seria necessário que houvesse um script que permitisse a atualização dos seus arquivos no SSD, para que tais modificações não fossem perdidas no caso de uma reinicialização do sistema.

Command journaling with journaling of metadata + page binding , estou esperando isso faz tempo, apesar de tornar o sistema mais lento, as únicas empresas que ainda estão interessadas em desenvolver isso são a sun e a IBM, nunca mais perderíamos um bit sequer se esse sistema estivesse pronto.

Citar7. Não faria sentido criar uma memória swap nessa configuração, a não ser no caso de se ter certeza de que ela viria a ser necessária, quando então ela poderia ser criada num drive SSD (degradando enormemente a performance do sistema) ou, com o devido investimento, na própria memória RAM (que teria que ser de um tamanho considerável).

Nesse caso com tudo sendo cacheado, os refluxos provocariam a liberação forçada de áreas de memória não paginadas, o sistema poderia ficar instável ou ter comportamentos estranhos como fechamento do konqueror quando da visualização de thumbnails de uma pasta grande de fotos, mas no linux ele avisa que não aguenta mais mesmo :) e se recusa a abrir mais software fornecendo "calloc e malloc returns nill" e graças a Deus ainda dá para debugar.  tente fazer no windows :) ele fecha tudo e vc nem sabe o que foi que aconteceu ???....

........

CitarTudo bem que não é exatamente um sistema barato, mas acho que é o mais rápido que se pode construir com as peças disponíveis comercialmente.
E o engraçado é que poderia ser mais barato do que alguns computadores topo de linha de marcas famosas.

Ideal para isso sem SWAP seria assim:
SSD para dar partida com /boot e /root( 8 ou 16GB ) com opção de bloqueio de escrita
/Home em HDD ( o tamanho que você quiser )
/Var precacheada e assíncrona com disco rígido por agendamento ( assím não perderíamos os Logs e eles seriam escritos em idle )
6 GB a 8GB de memória ECC registrada, sem nenhuma SWAP.

O sistema que você propõe chama-se entre os técnicos de Sky Rocket, normalmente se usa Sky Rocket para Cluster, o Dynebolic faz isso muito bem e ainda monta sua memória em NumaLink...

Mas vamos continuar, quem sabe alguma nova idéia não surge ? Por que não ?

zohguy

#2
Citação de: greylica online 04 de Janeiro de 2007, 03:58
Os SSDs são mais rápidos, porém , sua vida útil é ainda rudimentar se comparado aos HDDs...
Isso é discutível, em um comentário numa página do TFOT um dos usuários diz usar alguns SSDs a mais de 10 anos sem problemas. HDDs comerciais, na prática, tem uma vida útil média de 5 ou 6 anos, depois disso os problemas começam a aparecer.

Citar
Ler SSDs é melhor do que os gravar, e sinceramente eu realmente prefiro que discos holográficos ou cubos laser sejam utilizados para esta tarefa...
Eu também preferia que discos holográficos fossem utilizados para estas e todas as demais tarefas. Essa tecnologia promete muito... quando se tornar disponível. Acredito que, por ser um salto tecnológico muito grande, ainda vai demorar um ano para os primeiros drivers serem disponibilizados no mercado. Primeiro vão nos obrigar a esgotar as possibilidades comerciais de tecnologias que mal foram lançadas e já estão ultrapassadas: HD-DVD e BluRay (afinal os protótipos de discos holográficos já existem e já superam essas tecnologias).

Citar
...e que sejam somente legíveis, assim teríamos risco zero se obtivermos o controle sobre essas gravações, não teríamos mais preocupações com segurança praticamente.
Mas algum meio de gravação deverá ser possível para permitir updates.

Citar
Técnicamente isso seria redundância, e além disso, o problema de limite de bandagem da memória poderia até ser aumentado para que diversos  " Cache Flushes " fossem feitos por um ou mais processadores. Não adianta passar dois parafusos iguais pela mesma rosca, e a arquitetura dual channel já resolveria grande parte do problema.
Na noite que eu escrevi o post tava pensando nisso, não conseguia encaixar uma coisa na outra.. hehehehe. :D

Citar
O mais recomendado seria utilizar o que você disse primeiro para /root e /boot e usar HDs reais para guardar documentos, e desde que o Linux tem um sistema de cache excepcional, basta aumentar o cache de disco para certas tarefas como Mp3 para que isso fosse para direto e inteiro na memória, evitando a leitura do HDD de maneira assíncrona.
Também havia pensado nisso, afinal dentro da abordagem que eu estava fazendo, abrir os documentos ficaria mais rápido, porém gravar as modificações ficaria mais lento. A questão é que grande parte do trabalho real que se faz nos computadores é por meio da edição e leitura de documentos (textos, vídeos, músicas, etc). Mas realmente usar HDDs para armazenar os documentos deve ser o mais indicado, dados os custos e as desvantagens das SDDs nesse quesito.

Citar
Do jeito que andamos ( os usuários avançados que não estão nem aí para a máquina e só querem que ela seja rápida e estável para trabalhar e não se preocupar com manutenção ... ) a segunda opção seria básica...
Especialmente levando em conta que apenas usuários avançados (e abonados) iriam tentar essa configuração... :D

Citar
Nesse caso com tudo sendo cacheado, os refluxos provocariam a liberação forçada de áreas de memória não paginadas, o sistema poderia ficar instável ou ter comportamentos estranhos como fechamento do konqueror quando da visualização de thumbnails de uma pasta grande de fotos, mas no linux ele avisa que não aguenta mais mesmo :)
Meu conhecimento no Linux ainda é bastante limitado, mas as poucas vezes que abri o System Monitor a utilização do Swap está sempre em 0%. Por isso considerei dispensável a utilização dessa memória.

Citar
Ideal para isso sem SWAP seria assim:
SSD para dar partida com /boot e /root( 8 ou 16GB ) com opção de bloqueio de escrita
/Home em HDD ( o tamanho que você quiser )
/Var precacheada e assíncrona com disco rígido por agendamento ( assím não perderíamos os Logs e eles seriam escritos em idle )
6 GB a 8GB de memória ECC registrada, sem nenhuma SWAP.
Perfeito. :D

Citar
O sistema que você propõe chama-se entre os técnicos de Sky Rocket, normalmente se usa Sky Rocket para Cluster, o Dynebolic faz isso muito bem e ainda monta sua memória em NumaLink...

Mas vamos continuar, quem sabe alguma nova idéia não surge ? Por que não ?

Então já estão fazendo isso... Deve ser muito interessante ver um sistema desses rodando. melhor que isso só substituindo a armazenagem em massa por memória holográfica e usando abordagens mais radicais ainda... Mas certamente economicamente inviáveis.

Então quanto sairia para o experimentador caseiro fazer uma máquina dessas?

16GB, 2.5" PQI Turbo Industrial IFD Flash Disk Sata $1399
4x2GB Kingston 184-Pin DDR 400 SDRAM Server Memory $1227.96
TYAN S2877ANRF-RS Dual Socket 940 NVIDIA nForce4 Professional 2200 ATX Server Motherboard - Retail   $259.99
ASUS EN6200TC256/TD/64M GeForce 6200TC supporting 256MB(64MB on board ) DDR PCI Express x16 Video Card  $35.99
1xAMD Dual-Core Opteron 265 Italy 1.8GHz Socket 940 Dual Core 2x1MB $325
1xZALMAN CNPS7000B-AlCu LED 2 Ball Cooling Fan/Heatsink $31.99
2xWestern Digital Caviar SE16 WD3200KS 320GB 7200 RPM 16MB Cache SATA 3.0Gb/s Hard Drive $178
ENERMAX Liberty ELT500AWT 500W Power Supply $109.99
LIAN LI PC-7B plus II Black Aluminum ATX Mid Tower Computer Case $89.99
NEC Black 18X DVD±R Burner With 12X DVD-RAM Write $29.99

Total= $3687.99

Favor notar que estamos falando de um computador com 8GB RAM DDR 400 c/ECC, 656GB de armazenamento (640 GB em 2 HDDs SATA, 16 GB em SDD SATA), placa de vídeo NVIDIA bastante capaz para aplicações OpenGL, processador Opteron Dual Core (podendo ser expandido para 2 processadores).

Pondendo ser mais barato ou mais caro, dependendo da escolha das peças...

Em comparação, um Alienware Aurora ALX custa por volta de $5,949.00 (com 2GB de RAM, 1 Drive 250GB SATA, AMD Athlon 64 FX-62 Processor).
Tenho certeza que nessa faixa de preço dá para manter o SDD a grande quantidade de memória, e equiparar-se nos demais aspectos.


greylica

#3
Realmente, um disco rígido encontra o final de carreira após 8 anos segundo o que se vê por aqui, não é a toa que a garantia máxima para HDDs industriais para empresas seja de 5 anos. Também concordo perfeitamente que estão tentando empurrar um êngodo com DRM no caso do Blue Ray  e HD-DVD, pena para eles por qyue já foi quebradoo protocolo por um hacker chamado de MusliX64, ( Bem , Musli lá é muçulmano ... ). Também o Vista nem saiu e já foi crackeado, me levando a desconfiar da segurança provida pela Microsoft.

Dizem que o preço dos Flash disks vai reduzir pela metade de 1 em 1 ano devido á sua popularidade, discos de 4GB Flash Drive para dar partida como se fossem HDD-USB já estão mais baratos, somente U$230,00. Só que a nível Brazil é caro demais, eu gastaria comprando outro processador e outro gabinete nessa sua configuração,

Concordamos em praticamente tudo, mas a questão do disco poder ser gravado de alguma maneira para não ter sistema modificado, isso deve ser físico e para  o usuário e não para outra empresa oudispositivo, como os bloqueios de disquetes que tínhamos antigamente...

Eu vou estudar mais sobre o Dynebolic e como interligar mais máquinas, vai ser mais um desafio...

Ubuntu Surfer

Como diria um amigo meu ao ser perguntado, após uma longa conversa: "Vc entendeu o que eu disse?"

"Se eu entendi alguma coisa, foi muito pouco!"

Boiei. Rsrsrs

Mas é legal ver a profundidade do assunto.
Parabéns.