Os possíveis segredos do SSD da Sony – Parte 2

Os segredos do SSD da Sony passam naturalmente por memórias NAND rápidas, mas isso não chegará. Uma das possibilidades é um SSD bastante alterado. Basicamente ele seria optimizado… para jogos!

Foi recentemente conhecido um conjunto de patentes da Sony relativas a SSDs e que mostram as alterações radicais que a Sony propõem no sentido de os acelerar para sistemas de videojogos, e que poderá ser a solução aplicada pela Sony no seu SSD.

As patentes referem possibilidade de estes alcançarem velocidades inimagináveis até 20 GB/s. E isso certamente seria algo que nenhum disco do mercado faz.

O controlador da Phison que referimos neste post, associado a  futuras versões das memórias referidas na parte 1, poderiam eventualmente conseguir essa velocidade. Mas isso a acontecer será em versões futuras de SSDs. Neste momento, se a Sony conseguisse os 4 GB/s ou até os tais 4.8 GB/s que a Phison falou serem possíveis, já estaríamos perante uma revolução face ao mercado actual onde os SSDs de topo andam por volta dos 2.5 GB/s reais.

As patentes da Sony basicamente abordam as limitações dos SSD num sistema de jogos, e fala exactamente daquilo que o Cerny referiu, de um conjunto de alterações ao hardware e software que melhorar a performance.



Daqui para a frente o artigo vai ser bastante técnico e eventualmente monótono, apesar de acharmos que muito interessante, pelo que caso não o acompanhem ou não queiram ler, podem saltar directo para as conclusões.

Basicamente as patentes referem que num sistema clássico, o sistema operativo usa um sistema de ficheiros virtual que virtualiza um hospedeiro para diferentes aparelhos de Input/output com características diferentes. Sendo que as tarefas do sistema de ficheiros correm no CPU, tais como verificação de integridade de ficheiros, verificação de metadados, desencriptação de dados, compressão de dados, etc, o CPU pode ser um gargalo às transferências do SSD, especialmente no contexto em que ele tem de lidar com quantidades grandes de ficheiros pequenos.

E este é efectivamente o problema que vemos nos actuais SSDs. Discos como os Samsung 970 EVO que anunciam 3.4 GB/s de pico de velocidade de leitura, quando confrontados com casos reais, com discos com milhares de pequenos ficheiros, obtem valores mais realistas na ordem dos 2.5 GB/s. Os pequenos ficheiros revelam-se um gargalo, e os jogos são na maior parte dos casos constituidos por milhares de ficheiros, maioritariamente pequenos.

Os SSD normais funcionam de uma forma genérica, usando blocos de dados, sendo que eles distribuem esses blocos pela memória para distribuir o desgaste e ocupação. Quando é preciso encontrar um ficheiro, o controlador de memória do SSD traduz o pedido para os endereços físicos dos blocos de dados, usando uma tabela de dedos de procura.

Infelizmente essa tabela de dados de procura não é um ficheiro pequeno, e num SSD normal, os blocos de dados podem necessitar de uma tabela de pesquisa de 1 GB para um disco de 1 TB.
Para acelerar isso, os usem uma memória DRAM para manter essa tabela, sendo que o controlador consulta a DRAM para saber onde ir buscar os dados.
Mas mesmo assim, a resposta é o que é, e isso é considerado um gargalo dos SSD.



Eis as diferenças que a Sony propõem face a um SSD normal!

O primeiro passo passa pela troca do tipo de memória usada no SSD: SRAM em vez de DRAM

Esta solução diminui a latência da memória e permite melhores transferências entre o controlador da memória flash e a tabela de dados.

Mas para diminuir os acessos à tabela de pesquisa, a patente propõe então o uso de uma granularidade mais grosseira de acesso a dados para dados que são escritos uma vez e não são reescritos – por ex. dados de instalação do jogo. Esse tipo de bloco maior pode permitir tabelas de consulta de endereço muito mais reduzidas.

Como exemplo, a Sony afirma que elas podem chegar a dimensões tão reduzidas como 32 KB, em vez de 1 GB.



A diferença é de tal forma gigante que facilmente se percebe como o ganho na eficiência da leitura de dados numa tabela tão pequena pode ser gigante! É o mesmo que procurar um pedaço de texto numa folha ou numa enciclopédia.

A melhorar isto tudo, as alterações propõem que os dados lidos pelo controlador de memória também possam ser armazenados em buffer na SRAM para verificações de ECC.

Ao se excluir a DRAM a complexidade e custo do SSD pode à partida ser reduzido, e a redução será maior quando maior for o disco pois à medida que estes aumentam o tamanho também aumenta a dimensão da tabela (2 TB seriam 2 GB, 4TB , 4 GB e por aí fora).

Como outra medidas optimizadoras, a unidade de leitura do SSD é ‘expandida e unificada’ para operações de leitura eficientes. Para isso usar-se-ia um CPU secundário, um DMAC (Direct Memory Access Controller) e um acelerador de hardware para descodificação, verificação de adulteração e descompactação.

Todos estes processadores, o CPU principal, o CPU secundário, o controlador de memória do sistema e o barramento de I/O são conectados por um barramento coerente.



Interessante é ver-se que a patente refere que o CPU secundário pode ser diferente no conjunto de instruções do CPU principal (leia-se um CPU completamente diferente, ou… um GPU a usar o GPGPU ou com um processador ARM embutido), desde que o tamanho de página usado seja o mesmo e ambos estejam ligados por um barramento coerente, algo que nas consolas é comum entre o CPU e o GPU.

O acelerador de hardware e o controlador I/O terão ambos de estar conectados ao barramento I/O como mostra a figura seguinte:

As alterações para optimização do disco terão de passar também pelo software. Mais uma situação que foi referida por Cerny como o segredo do SSD da Sony, o que nos leva a acreditar que efectivamente esta é a patente que a Sony está a usar.

Aqui o sistema terá de acrescentar um novo sistema de ficheiros, o ‘File Archive API’, projetado principalmente para dados de gravação única, como instalações de jogos.



Face a um sistema de arquivos virtual mais genérico, este novo é optimizado para acesso a dados NAND. Ele fica alojado na interface entre o aplicativo, os drivers NAND e os drivers do acelerador de hardware.

Depois a CPU secundária (que seria o GPU) lida com uma prioridade no acesso ao SSD.

Há ainda um sistema de prioridades de leituras que definimos de seguida:

  • Quando as solicitações de leitura são feitas por meio da API do File Archive, todas as outras solicitações de leitura e gravação podem ser proibidas para maximizar a taxa de transferência de leitura.
  • Quando uma solicitação de leitura é feita pela CPU principal, ela é enviada para a CPU secundária, que divide a solicitação em um número maior de pequenos acessos de dados. Isto é feito  por dois motivos
    • Maximizar o uso paralelo dos dispositivos e canais NAND (a “unidade de leitura expandida”)
    • Tornar os blocos pequenos o suficiente para serem armazenados em buffer e verificados dentro da SSD SRAM.

Aqui os metadados que a CPU secundária precisa atravessar são muito mais simples (e, portanto, mais rápidos de processar) do que em um sistema de arquivos virtual típico.

Parece por isso existir aqui uma priorização ao GPU. E isso mostra que a patente é claramente destinada a optimizar um SSD para uma consola destinada a videojogos, e como tal ela pensa nas características especiais de funcionamento da mesma.



O controlador de memória NAND pode ser flexível acerca da granularidade de dados a usar

  • Para solicitações de dados enviadas por meio da API do File Archive, ele usa granularidades que permitem que a tabela de consulta de endereços seja totalmente armazenada na SRAM para um mínimo de gargalos.
  • Outras granularidades podem ser usadas para dados que precisam ser reescritos com mais frequência – dados salvos pelo utilizador, por exemplo. Nesses casos, a SRAM armazena parcialmente as tabelas de pesquisa.

Segundo a patente, quando um SSD deste tipo verifica os dados recuperados, eles são enviados da SRAM do SSD para o kernel na RAM do sistema. O acelerador de hardware, em seguida, usa um DMAC para ler os dados, fazer seu processamento e, em seguida, gravá-los para a memória RAM do sistema.

Eis o esquema:

Outras duas patentes da Sony sobre esta situação podem igualmente estar em causa.



A primeira fala do controlador ser igualmente optimizado para leituras de alta prioridade. Ela sugere que com SSDs de alta velocidade é possível poupar-se memória e largura de banda ao só fazer transferências quando elas são necessárias.

A segunda fala de usar o SSD em alguma SRAM, em vez de memória DRAM, como memória de uso para o sistema operativo em modo Standby, de forma a reduzir consumos.

Conclusões

A patente da Sony é claramente para um SSD dedicado a uma consola ou outro sistema de videojogos. É um sistema com capacidades simplificadas tomando em conta a realidade das consolas, e que permite por isso ganhos tremendos de velocidade.

 

A patente fala mesmo em velocidades incríveis, como mostra a imagem de baixo:



Os dos pontos interessantes da patente é a ligação ao sub CPU que acreditamos ser não outro que o GPU!

Mas diga-se que ver ali na tabela velocidades de 10 GB/s e 20 GB/s quando um disco SSD de topo anuncia 3.5 GB/s teóricos de pico, mas que, por ter um uso genérico, ao ter de lidar muitas vezes com milhares de ficheiros de pequenas dimensões, obtém médias mais realistas na ordem dos 2.5 GB, é sem dúvidas o que mais interesse desperta. Especialmente porque a patente se propõem exactamente eliminar os gargalos com os pequenos ficheiros que descem a performance dos SSD normais.

Não acreditamos muito que a Sony aponte para os valores máximos, mas o certo é que se compararmos as velocidades que a patente refere poder serem atingidas, com os 75.2 MB/s medidos no disco da PS4, ou os 88.1 MB/s da PS4 Pro, o que temos aqui é uma evolução gigante. E seja ou não com as memórias da Sony, com estas alterações aqui explicitadas, os seus SSDs podem ser realmente fantásticos.

Seja como for, esta é apenas uma possibilidade sobre o que pode ser o SSD da Sony. Actualmente, de acordo com o rumor que refere o controlador Phison, a Sony estará com um SSD Toshiba no qual aumentou a Dram para 2 GB para 1 TB de armazenamento, o que está longe do aqui explicitado.



 

 

 

Créditos para Gofreak do Resetera por expor a situação.



error: Conteúdo protegido