eh certo que as pessoas tem que comecar com coisas simples para entender as coisas complexas, mas pic tb nao dah neh... eh como eu insisto sempre: tem que estudar algo simples, mas moderno, como os 680x0, para conseguir entender o mundo a sua volta. vamos lah entao, comecando do comeco... pega um 68030 de 25MHz e vamos pendurar o bicho em uma DRAM de 80ns. quando se fala em 80ns, efetivamente alguem esta falando em um ciclo completo de 120ns, dividido em:
- 40ns de tempo de acesso de linha apos a borda de descida do RAS
- 40ns de tempo de acesso de coluna apos a borda de descida do CAS (e aqui temos efetivamente os dados)
- 40ns de intervalo entre dois ciclos sucessivos (RAS e CAS)
com 120ns por transferencia e 4 bytes por transferencia, temos apenas 33MB/s de bandwidth. mas o 68030 permite fazer transferencias em burst. como ele faz isso precisa ser entendido: transferencias em burst sao *sempre* feitas durante erros de cache, ou seja, quando ele puxa uma area da memoria e ocorre um erro de cache, ele puxa uma linha inteira de 16 bytes em burst. portanto, eh uma otimizacao automatica do hardware que sempre ocorre e, com isto, eh possivel recalcular:
- 40ns de tempo de acesso de linha no primeiro acesso
- 40ns de tempo de acesso de coluna para os acessos em modo burst
- 40ns de intervalo entre dois ciclos sucessivos (CAS)
como as transferencias em burst do 68030 sao de 16 em 16 bytes, temos entao 360ns para cada burst de 16 bytes, o que resulta em um bandwidth de 44MB/s. nao melhorou muito, mas talvez seja possivel melhorar um pouco mais utilizando interleaving de dois bancos, assim temos:
- 40 ns de tempo de acesso de linha no primeiro acesso
- 40 ns de tempo de acesso de coluna para acessos em burst pares
- 40 ns de tempo de acesso de coluna para acessos em burst impares
o intervalo entre dois ciclos sucessivos com CAS pulsando continua necessario, porem o ciclo com CAS alto fica embutido no tempo com CAS baixo do outro banco. de forma similar, o ciclo de RAS acaba embutido no acesso, de modo que o total acaba caindo para meros 200ns. assim, com um controlador de memoria capaz de fornecer acesso em burst e interleaving, temos como resultado um bandwidth de 80MB/s.
uma questao obvia seria: um 68030 de 25MHz consegue atingir um pico de 12 MIPS e, para isso, requer apenas 25MB/s de bandwidth. isso eh correto, porem temos que lembrar que o bandwidth do barramento divide instrucoes e dados. com uma cache de 512 bytes, o 68030 consegue algo em torno de 80% de acertos de cache, o que significa que apenas 5MB/s de bandwidth seriam necessarios para manter o processador rodando a 12 MIPS e que 75MB/s estariam disponiveis para transferencias de dados.
mas obviamente nao estamos falando em ficar fazendo memcpy pela memoria!
parece estranho, pq estamos maximizando o bandwidth para nao usar. o dilema eh que, embora mover dados usando o processador seja eficiente, eh um desperdicio de recursos, pois eh mais lucrativo deixar o processador parado em um semaforo de memoria ou parado esperando uma interrupcao do que perder tempo movendo dados. parado, ele vai ter oportunidade de atender a interrupcao ou evento mais rapidamente.
entao a jogada de maximizar o bandwidth eh minimizar o tempo do processador acessando a memoria e maximizar a performance de canais de dma. com 75MB/s de bandwidth, eh perfeitamente possivel colocar duas controladoras fast-ethernet operando em full-duplex ao mesmo tempo e ainda vai sobrar 25MB/s de bandwith para outras operacoes.
obviamente, o controlador de dma precisa suportar acesso em burst para ter acesso a este bandwidth, mas isso realmente nao eh nada dificil e pode ser extendido a qualquer periferico com dma, como video, audio, etc.
e encerramos por aih. ir adiante jah comeca a ser especulacao! por exemplo, supondo que usamos uma memoria DRAM com configuracao de 1K x 1K x 32, temos efetivamente 1024 paginas de 4KB, lembrando que isso nada tem de relacao com paginas da mmu! mas voltando a DRAM, isso significa que podemos receber um frame ethernet inteiro na mesma pagina, o que significaria sustentar um bandwidth de 100MB/s!
eh possivel, mas nao recomendavel, pq implicaria em transferir sucessivamente 1500 bytes. para isso, seria necessario que o controlador fast-ethernet tivesse um FIFO capaz de armazenar um frame inteiro. nao eh algo dificil de se conseguir, mas tambem implicaria em bloquear qualquer outro acesso concorrente durante 15us.
com bursts de 16 bytes vc tem um bandwidth menor, mas bloqueia o barramento por no maximo 200ns.
bom, multiplique isso tudo por 100x e vc vai entender como funcionam as coisas no mundo das super-DDRs!
fabim escreveu: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!!!
