MEMORIA DDR3

Componentes, Dispositivos, Equipamentos, etc...

Moderadores: 51, guest2003, Renie

Mensagempor fabim » 16 Mar 2011 11:01

Djalma Toledo Rodrigues escreveu:É obvio que nesses cálculos não esta incluido o tempo de acesso interno da memória ,
a tal latêncis.

DJ

"Elementar meu caro Watson" (Sherlock Holmes).


Num sei se conhece o significado latencia ai pra esse caso, mais quando disse latencia, voce não entendeu. O que significa que você não sabe o que significa latencia. Se a latencia é alta, quer dizer que existe um erro, e não conhecido, pois a latencia ta la. Saca ? waiting cicles, etc... saca?

Por isso que vos digo, o que os fabricantes informam em Gbits é o valor real, em base de simulação e informação. Desconsiderando waiting cicles, latencia etc.

Ou seja, que informa ali coisa de 10GBytes, na verdade chega a no maximo os 3Gbits informados pelo fabricante. Tem aquelas jogadas de pico, etc..
Mano, ve só.
Sou responsável pelo que escrevo!!! E não pelo que você entende !!!
fabim
Dword
 
Mensagens: 5001
Registrado em: 16 Out 2006 10:18
Localização: aqui uái!!!?

Mensagempor msamsoniuk » 16 Mar 2011 12:40

fabim escreveu:esta configuração de 2bit ck, é para DDR3 e constante ? Tipo estra transmissão é 100% do tempo, ou ela pode transferir até 2 bit por ck ? ou seja.


eh como um double data rate funciona:

http://zone.ni.com/devzone/cda/tut/p/id/7284

obviamente a transferencia ou nao de dados validos depende de outros strobes, mas normalmente eh possivel transferir continuamente 2 bits por clock em operacoes de burst na mesma linha.

Para 1333mhz e 16 bits, ele pode transferir na verdade até (1333mhz * 2ck)* 2 bytes = 5.332GBPS.
Sendo assim, como o processador vai utilizar 32 bits de processamento e externamente vai ser 2 * 16bits * 512MB cada.

Esta regra de calculo vai ficar então, (1333mhz * 2ck)* 4 bytes = 10.664GBPS.


barramentos tipicos de memoria possuem 16, 32, 64 ou 128 bits em funcao do bandwidth requerido e nao tem relacao com a largura da palavra de operacao do processador. normalmente, para embarcados, 16 bits fornece bandwidth suficiente para todas as aplicacoes possiveis.

Cara mais tipo. Tu generalizou né ? Nestes 1333MHZ, tem muitos waith states, muitos refreshes, e os dados são transferidos em bancos né ?

Ou seja, na realidade a latencia de dados calculada, é muiiiiito abaixo disso ai, mais se for pelo menos METADE!!!! Ja esta putamente fuck velocity!!!


eh um pouco complicado... mas todos estes problemas jah foram resolvidos em memorias DRAM antigas! :)

uma memoria DRAM antiga eh composta de linhas e colunas de bits. por exemplo, uma memoria de 1Mbit eh composta de 1024 linhas e 1024 colunas. quando vc quer acessar um endereco especifico, primeiro vc fornece o endereco da linha e clocka RAS. uma linha inteira de 1024 bits sera lida, entao vc fornece o endereco da coluna e clocka CAS.

o truque eh que a linha inteira eh escrita novamente, independente de vc ter alterado um bit ou nao. ou seja, qualquer acesso implica em um refresh da linha. outro truque eh que vc leu a linha toda e ela esta disponivel, entao vc pode fornecer uma nova coluna e clockar CAS diretamente, fazendo transferencias em burst.

entao o impacto do tempo de acesso e refresh jah eh minimizado mesmo em uma DRAM. o que as SDR adicionam eh um clock global (RAS e CAS passam a ser linhas normais) e as DDR adicionam capacidade de transferir 2 bits por clock.

o pior caso seria uma rotina composta de duas instrucoes, uma no endereco 1023 e outra no endereco 1024. isso significa que a memoria tem que ler linhas diferentes o tempo todo. mas eh para compensar esse tipo de problema que existem caches! :)

por outro lado, um caso otimizado seria um loop nos enderecos 0 a 1023, onde a memoria soh precisaria mudar de linha para fazer o refresh periodico.

entao, na pratica, o tempo parado eh bem pequeno! :)
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

Mensagempor fabim » 16 Mar 2011 12:58

olha, li isso eim tchelo..

E de todos os 8 sites que li sobre largura de banda etc, Estes 10GBytes na verdade para uma DDR3 chega num maximo absoluto de 2.3GBytes... Isso numa GDDR4..


Sei lá, isso é complicado mesmo... explicar uma diferença tão grande..

kkkk
Mano, ve só.
Sou responsável pelo que escrevo!!! E não pelo que você entende !!!
fabim
Dword
 
Mensagens: 5001
Registrado em: 16 Out 2006 10:18
Localização: aqui uái!!!?

Mensagempor helton » 16 Mar 2011 13:20

Helton Marques
"Priorize as Prioridades"
helton
Byte
 
Mensagens: 146
Registrado em: 16 Out 2006 09:18
Localização: São José-SC

Mensagempor msamsoniuk » 16 Mar 2011 13:39

entao, eh que nao caiu a ficha para vc... os problemas da DDR sao os mesmos da DRAM, se vc escolher mal os enderecos para fazer um loop, a performance vai ser ruim. se vc escolher bem, a performance vai ser boa!

aqui tem umas referencias interessantes sobre como melhorar a performance:

http://www.denali.com/wordpress/index.p ... ies-out-of

eh como cara falou: se vc fizer todos os acessos na mesma pagina e fizer apenas leituras, vc vai ter 100% de eficiencia e uma memoria de 10Gbyte/s vai operar a 10Gbyte/s.

aqui tem um controlador em FPGA que consegue 90% de eficiencia:

http://www.altera.com/literature/wp/wp_ ... ciency.pdf

novamente, se vc ler ali no texto, tem a mesma brincadeira dos 100% de eficiencia! eh soh uma questao de usar corretamente! :)

fabim escreveu:olha, li isso eim tchelo..

E de todos os 8 sites que li sobre largura de banda etc, Estes 10GBytes na verdade para uma DDR3 chega num maximo absoluto de 2.3GBytes... Isso numa GDDR4..


Sei lá, isso é complicado mesmo... explicar uma diferença tão grande..

kkkk
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

Mensagempor fabim » 16 Mar 2011 14:37

Marcelo Samsoniuk escreveu: mimimi


Caiu faz tempo...rsrs
Independe de eu fazer algo como manipular a memoria nos endereços blablabla..
Quem faz isto é o kernel e a mmu..

Quando eu puxo um executavel para linkedição pra carregar na ram, é o kernel que toma as decisões de escolha para o melhor endereço para a melhor performance.. Isso não tem como eu colocar os dedinhos....

Posso sim, atraves de stream escrever e ler dados em posições tais que vai me dar a melhor performace, mais isso apenas e somente para teste... Na prática esquece...
Mano, ve só.
Sou responsável pelo que escrevo!!! E não pelo que você entende !!!
fabim
Dword
 
Mensagens: 5001
Registrado em: 16 Out 2006 10:18
Localização: aqui uái!!!?

Mensagempor polesapart » 16 Mar 2011 14:45

Muito pelo contrário, basta você alinhar corretamente os tipos de dados :D O kernel/mmap/whatever já vai prover o necessário para que o programa performe adequadamente, agora, o programador deste sempre pode criar loops ineficientes & estruturas de dados mal pensadas, e o pior de tudo, loops ineficientes que varrem estruturas de dados mal feitas na pior sequencia possivel, neste caso nem cache salva, aliás, atrapalha :D
Warning: time of day goes back (-163479us), taking countermeasures. :)
Avatar do usuário
polesapart
Byte
 
Mensagens: 477
Registrado em: 19 Nov 2007 12:56
Localização: Curitiba

Mensagempor fabim » 16 Mar 2011 15:08

polesapart escreveu:Muito pelo contrário, basta você alinhar corretamente os tipos de dados :D O kernel/mmap/whatever já vai prover o necessário para que o programa performe adequadamente, agora, o programador deste sempre pode criar loops ineficientes & estruturas de dados mal pensadas, e o pior de tudo, loops ineficientes que varrem estruturas de dados mal feitas na pior sequencia possivel, neste caso nem cache salva, aliás, atrapalha :D


ai meus cocumelo...

Meo, macoisa é tu pegar dados de audio, videos etc, e alinhar bunitinho. Outra coisa é tu pegar um executavel, e rodar ali na ram...

Como eu ja disse por endereçamento eu consigo até no windows fazer escrita e leitura de stream na ram onde eu quiser... ou onde mmu permitir...
fora isso é o kernel que faz a linkedição e ele toma as decisões cabiveis da posição onde irá ficar esse mano véio....

Nem vem que não tem!!!

Se fosse assim fora o fato de maquinas virtual de java, e a P**** do .net e outras gambiarras tecnologicas para ganhar em produção e reduzir tempo.
Nem seria necessario criar processadores quadcore com caches de 4MB cada um para o L1, e ainda aumentar a banda da memoria DDR....

Como é a poha do kernel que tem que manipular isso, e você não tasca o dedim, no maximo pode dizer pra ele que quer ou não que determinada coisa vá para o cache... Ai meo FI... Nem precisava de um L1 de 1,2,3,4,5 sei lá quantos MB, com zero wait states......

Eu posso aqui no keil, criar um aplicativo dedicado... Usando a unha...
E dizer quais procedimentos e quais funções e quais dados irão ficar aonde .... Isso e baixo nivel, sem kernel na jogada.....

Entrou SO meu fiote, ai ja frodinhou tudo... É nisto que os desenvolvedores do kernel unix e linux estão batendo até hoje, deixando o negocio bem inteligente na linkedição... mais como nada faz milagre... hehehehe
Mano, ve só.
Sou responsável pelo que escrevo!!! E não pelo que você entende !!!
fabim
Dword
 
Mensagens: 5001
Registrado em: 16 Out 2006 10:18
Localização: aqui uái!!!?

Mensagempor polesapart » 16 Mar 2011 16:44

Vc não precisa escovar bits pra obter alinhamento correto na ram, a menos que teu port do kernel seja feito por vc mesmo numa cpu com MMU muito relaxada projetada pelo samsoniuk, que esqueceu de prever que o fabim poderia usá-la :D

Mas não se preocupe, todo mundo que veio do mundo PIC não se acostuma assim tão facilmente com o conceito de páginas de vários kb e alinhamentos ocorrerem naturalmente em endereços maiores que 32 bits nunca parece algo deste mundo, até que seja atingido pela bíblia do unix e de repente seja iluminado :P~

Noutras palavras, esquece isso tudo por enquanto fabim. Vá entender a tal da ddr e descobrir como rotear a placa sem que os bits cheguem atrasados. O resto é secundário e vc vai descobrir que a coisa é mais porreta do que parece, embora seja menos do que a gente gostaria :D
Warning: time of day goes back (-163479us), taking countermeasures. :)
Avatar do usuário
polesapart
Byte
 
Mensagens: 477
Registrado em: 19 Nov 2007 12:56
Localização: Curitiba

Mensagempor msamsoniuk » 16 Mar 2011 18:03

#fail: a mmu nao sabe absolutamente nada sobre a geometria das memorias fabim... leia os links q eu passei sobre otimizacao de DDR e perceba que eles se referem a otimizar o acesso de hardware acesso a acesso! e a otimizacao comeca procurando usar ao maximo acessos em burst! :)

daih vem aquela historia:

loop:
move *p++, q*++
repete loop

ou seja, roda a instrucao, move dado, roda instrucao... e fica alternando na memoria leitura/escrita de 32 bits na memoria, o que nao otimiza nada para a memoria... se o processador permitir, melhor seria:

loop:
movem *p++, registros
movem registros, *q++
repete loop

onde registros pode ser 16 registros de 32 bits no 68k/cf. isso permite fazer um burst grande lendo, reconfigurar a memoria e fazer um burst grande escrevendo! :)

fabim escreveu:
Marcelo Samsoniuk escreveu: mimimi


Caiu faz tempo...rsrs
Independe de eu fazer algo como manipular a memoria nos endereços blablabla..
Quem faz isto é o kernel e a mmu..

Quando eu puxo um executavel para linkedição pra carregar na ram, é o kernel que toma as decisões de escolha para o melhor endereço para a melhor performance.. Isso não tem como eu colocar os dedinhos....

Posso sim, atraves de stream escrever e ler dados em posições tais que vai me dar a melhor performace, mais isso apenas e somente para teste... Na prática esquece...
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

Mensagempor fabim » 16 Mar 2011 18:16

nossa, correção... ARM7 e CM0,1,3--- pic não iéca!!! Credo.

Bom, muito se falou, tudo se disse, e todos viram que a parabola dos 10GBPS é lorota das brabas... hehehehe
Mano, ve só.
Sou responsável pelo que escrevo!!! E não pelo que você entende !!!
fabim
Dword
 
Mensagens: 5001
Registrado em: 16 Out 2006 10:18
Localização: aqui uái!!!?

Mensagempor msamsoniuk » 17 Mar 2011 00:34

fabim escreveu:nossa, correção... ARM7 e CM0,1,3--- pic não iéca!!! Credo.

Bom, muito se falou, tudo se disse, e todos viram que a parabola dos 10GBPS é lorota das brabas... hehehehe


$ ./mem_super 1
running 1
memcpy8 5.000 GB R/W in 2157008 us: total bandwidth of 2.318 GB/s
memcpy16 5.000 GB R/W in 994152 us: total bandwidth of 5.029 GB/s
memcpy32 5.000 GB R/W in 548791 us: total bandwidth of 9.111 GB/s
memcpy64 5.000 GB R/W in 513785 us: total bandwidth of 9.732 GB/s
f-vector 600.000 iMACs in 550528 us (1.090 GMAC/s and 6.539 GB/s)
i-vector 600.000 fMACs in 835274 us (0.718 GMAC/s and 4.310 GB/s)

ou seja, bandwidth de 9.7GB/s e utilizando 91% do bandwidth disponivel na memoria! :)
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

Mensagempor fabim » 17 Mar 2011 08:19

marcelo.
Ai fiote, fica facim facim né ?
Pega da qui, joga pra li, em tempo X,
Pega da ali, joga pra aca, em tempo X,

Isso na melhor posição possivel, em brust,...

Quero ver isso no uso normal do kernel!!! com programas rodando ai dentro, etc... hehehehe

Nem vem marcelo!!!!

Kernel ainda vai demorar muito tempo pra poder ser fodidão assim. Na realidade esta muito abaixo disso ai, caso contrario não estariam cada vez aumentando mais o cache......

SE uma memoria roda a 9GBPS, o processador roda a 1.8ghz, e usa DDR3 a 1333mhz...
Use a logica, .....

Bebum!!!
Mano, ve só.
Sou responsável pelo que escrevo!!! E não pelo que você entende !!!
fabim
Dword
 
Mensagens: 5001
Registrado em: 16 Out 2006 10:18
Localização: aqui uái!!!?

Mensagempor Djalma Toledo Rodrigues » 17 Mar 2011 13:38

fabim escreveu:marcelo.
SE uma memoria roda a 9GBPS, o processador roda a 1.8ghz, e usa DDR3 a 1333mhz...
Use a logica, .....

Bebum!!!

É por essas e outras que o MaSanson dora Fabim :D

DJ
Avatar do usuário
Djalma Toledo Rodrigues
Dword
 
Mensagens: 2334
Registrado em: 03 Ago 2008 13:22

Mensagempor polesapart » 17 Mar 2011 14:14

Não sei o que o fabim fuma, mas ele bem que podia avisar, pra ninguém mais cair nessa :P
Warning: time of day goes back (-163479us), taking countermeasures. :)
Avatar do usuário
polesapart
Byte
 
Mensagens: 477
Registrado em: 19 Nov 2007 12:56
Localização: Curitiba

AnteriorPróximo

Voltar para Componentes\Equipamentos Eletrônicos

Quem está online

Usuários navegando neste fórum: Nenhum usuário registrado e 1 visitante

x