Portál AbcLinuxu, 5. listopadu 2025 07:53
Podle dotazu bych řekl, že jeho autor se ptal na něco jiného a tohle ho nezajímá, nerozumí tomu a asi tomu ani rozumět nechce.
Rád bych ale upozornil každého, kdo by si třeba náhodou přečetl následující blbost a chtěl jí věřit, že to není pravda:
Jen pro jednoduché info: Více než 10 let paměti běží +/- na 200MHz. Paměti DDR (1 rok cca 2002) předávaly data na náběžné a úběžné hraně pulzu. A efektivně tedy jakoby předaly data na 400MHz. DDR2 předaly 2x tolik, DDR3 4x tolik a DDR4 8x tolik dat v jednom pulzu. Efektivně proto mají psané DDR2 800Mhz, DDR3 1600MHz a DDR4 3200MHz, kousek více a nebo méně je trochu změna základní frekvence.
Všechny paměti s rozhraním DDRx předávají nebo přijímají platná data pouze na náběžné a sestupné hraně hodin. Je úplně jedno, jestli se jedná o DDR-400, které pracují s hodinovým signálem 200 MHz nebo DDR3-1600, kde fyzické hodiny mají frekvenci 800 MHz. V jednom hodinovém cyklu se vždy přenesou pouze dvě slova. Jednotlivé generace JEDEC DDRx rozhraní se liší především v elektrické specifikaci rozhraní, kdy novější generace umožňují použít rychlejší signály díky vylepšené signálové integritě.
Existují ještě paměti s rozhraním QDR, které skutečně předávají v jednom hodinovém cyklu čtyři slova. To se ale týká velmi rychlých synchronních statických RAM pro speciální aplikace a ne spotřebních DRAM. Tam se potom používají čtyřfázové hodiny.
- tak poběží automaticky na této frekvenci po vložení do desky? - nebo je musím teprve manuálně v biosu nastavit? - nebo se už jedná o přetaktování?Můžu koupit 3000MHz a přetaktovat je na 3866hz? Díky
Není zač... mimochodem, že DDR3/4 nejsou quad-pumped, to už kolega "hw" vyjasnil/vyvrátil
Pak totiž dává smysl, že paměti fungují bez řečí v trochu širším rozsahu hodinových frekvencí.
Za mě... ať si dekódování SPD dělá klidně BIOS. Ta struktura není zrovna jednoduchá. Zařídit to v BIOSu je možná lepší, než kdyby to dělalo něco v hardwaru Intel (nebo třeba v ME firmware blobu) a kdyby v tom byla chyba, těžko bychom se domáhali opravy. Praktická zkušenost s Intelem. Když spolu v bezchybnosti BIOSu soutěží několik výrobců motherboardů, je to možná lepší situace. Tím neříkám, že by to nešlo udělat v hardwaru... zajímavý nápad
Na dekódování obsahu SPD EEPROM pro zvědavce existuje utilitka decode-dimms = perlový skript z projektu i2c-tools (lm_sensors). Příklad použití je např. tady. Nevím nakolik je ten skript aktuální, nevidím tam zmínky o DDR4. Aha, někdo už to okomentoval přede mnou
Něco málo ukáže také dmidecode - tento nástroj nejde přímo přes I2C na SPD, ale ptá se jakési služby BIOSu (dostane trochu jinou datovou strukturu). i2c-tools a dmidecode by měly být samostatné apt balíky.
[root@carbon ~]# modprobe eeprom [root@carbon ~]# decode-dimms # decode-dimms version 6231 (2014-02-20 10:54:34 +0100) Memory Serial Presence Detect Decoder By Philip Edelbrock, Christian Zuckschwerdt, Burkart Lingner, Jean Delvare, Trent Piepho and others Number of SDRAM DIMMs detected and decoded: 0 [root@carbon ~]#ale to jsou ty DDR4.
>ale to jsou ty DDR4.
Ne, to nejsou ty DDR4.
To je buď chybějící některý z modulů v kernelu (i2c-i801.ko pokud jste na Intelu nebo eeprom.ko) nebo příliš starý kernel, jehož i2c-i801 ještě nezná Váš moderní south bridge. Oboje jsem potkal na svém Broadwellovém ntb pod Debianem Jessie. A bohužel mám DDR3, takže nemám na čem testovat doplnění úprav decode-dimms o dekódování DDR4
A může se jednat ještě o jeden další problém: konkrétně na mém HW se modul eeprom.ko sice natáhne, ale na svém rozhraní v sysfs při pokusu o přečtení obsahu EEPROM vrátí samé 0xFF. Buď je něco blbě v modulu EEPROM, nebo se konkrétnímu modelu švábu 24c02 (nebo co tam je) nelíbí blokové čtení (nebo prostě ta operace, kterou modul eeprom.ko použije).
Zajímavé je, že pokud si natáhnu i2c-dev.ko (a také unloadnu eeprom.ko), dokážu přečíst obsah EEPROMky utilitou i2cdump, a decode-dimms mi pak ze souboru ta data správně rozparsuje.
Tady je zhruba záznam mého dnešního snažení na Debianu, postup by Vám mohl k něčemu pomoci:
# kompilaci a instalaci kernelu 4.4.44 kvůli podpoře čipsetu v i2c-i801 popisovat nebudusu cd /usr/src mkdir DIMM cd DIMM # stáhněte si nejnovější verzi wget http://git.kernel.org/cgit/utils/i2c-tools/i2c-tools.git/plain/eeprom/decode-dimms # nebo použijte moji upravenou v příloze tohoto příspěvku aptitude install i2c-tools aptitude install lm-sensors sensors-detect lsmod | grep i2c #modprobe i2c-i801 # Tahle metoda přečtení EEPROM mi funguje: modprobe i2c-dev ls -l /dev/i2c* i2cdetect -l i2cdetect 0 # DIMMy mívají SPD EEPROMky na adresách 0x50..0x57 i2cdump -y 0 0x50 > i2cdump.txt ./decode-dimms -x i2cdump.txt | less # Naopak tohle nefunguje - buď je vadný driver EEPROM, # nebo mám zmlsaný SPD EEPROM čip na SODIMMu: modprobe eeprom ./decode-dimms # skript decode-dimms dělá ekvivalent tohoto: dd if=/sys/bus/i2c/drivers/eeprom/0-0050/eeprom of=./tmp.bin bs=128 count=1
Prosbička: poslal byste mi prosím (nebo někdo jiný z publika)
i2cdump SPD EEPROMky z nějakého DDR4 modulu?
K této zprávičce přikládám pro zajímavost svoji upravenou verzi decode-dimms (je to jenom perlový skript) odraženou od čerstvého downloadu z GITu z kernel.org. Zatím tam není dekódování DDR4, ale nacpal jsem tam pár ladících výpisů navíc, které ukážou na problém s eeprom.ko (nebo kde je vlastně zakopaný pes).
uname -a Linux carbon 4.8.13-1-ARCH #1 SMP PREEMPT Fri Dec 9 07:24:34 CET 2016 x86_64 GNU/Linuxna notebooku je aktualizovaný arch. na druhou stranu notebook je také nový
description: System Memory
physical id: 2a
slot: System board or motherboard
size: 8GiB
*-bank:0
description: Chip DDR3 Synchronous 1600 MHz (0,6 ns)
product: M471B5674-M0-YK0
vendor: Samsung
physical id: 0
serial: None
slot: ChannelA
size: 4GiB
width: 64 bits
clock: 1600MHz (0.6ns)
*-bank:1
description: Chip DDR3 Synchronous 1600 MHz (0,6 ns)
product: M471B5674-M0-YK0
vendor: Samsung
physical id: 1
serial: None
slot: ChannelB
size: 4GiB
width: 64 bits
clock: 1600MHz (0.6ns)
a s i2cdetect mi dái2cdetect -l i2c-3 i2c i915 gmbus dpd I2C adapter i2c-1 i2c i915 gmbus dpc I2C adapter i2c-6 i2c DPDDC-C I2C adapter i2c-4 i2c DPDDC-A I2C adapter i2c-2 i2c i915 gmbus dpb I2C adapter i2c-0 i2c i915 gmbus vga I2C adapter i2c-7 smbus SMBus I801 adapter at efa0 SMBus adapter i2c-5 i2c DPDDC-B I2C adapterna 0 jsou paměti i tady?
a to jsem netušil, že ten modul je DDR3.
Ve Vašem případě je ta správná sběrnice s DIMM SPD podle mého i2c-7 = SMBus rozhraní v south bridgi Intel 82801 bůhví kolikáté generace.
Ostatní segmenty i2c vypadají, že jsou všechny vytahané z grafického subsystému. Panebože těch ale je... tři výstupní kanály DisplayPort videa, krát dva? Už jsem to dlouho neštudoval... Podle mého na tu i2c sběrnici co slouží DDC (per video port) se lze dostat dvěma způsoby, jeden z nich je "GMBus port" (hardwarový řadič i2c, který programátorovi ušetří bit banging) který sdílí vnější piny s nějakým GPIO registrem. Takže např. i915 gmbus dpc bude totéž jako DPDDC-C (DisplayPort DDC kanál "C").
Tady se k tomu něco málo najde (hledejte řetězec GMBUS).
..., a k čemu potom ty paměti jsou > 4000MHz,..."Just because we can." Výrobca je schopný takú pamäť vyrobiť, marketing ju dokáže predať a existujú zákazníci, ktorí sú za ňu ochotní zaplatiť prémiovú cenu.
Potíž je asi v tom, že Káčkový procesor jsem v ruce zatím nedržel. Pohybuji se spíš na úsporném konci spektra.
Vyšlo mi z toho, že zoberiem dosku, ktorá podporuje DDR4@2400MHz, pamäť s čo najnižšou latenciou, ktorú výrobca certifikuje na 2400MHz, založím, zapnem XMP, a ďalej neriešim. Nemá to proste cenu.A co to znamená. když zapneš XMP? Že to pojede jen na 2400MHz? BTW: Když je u pamětí napsáno XMP verze 2 a deska umí jen XMP bez uvedení verze, znamená to, že se spolu nedomluví?
IMHO ľubovoľnú z frekvencií označených "O.C." podporujúcju XMP2.Tak že tam můžu dát maximálně DDR4 3300Mhz ?
Môžem sa spýtať, prečo tak zúfalo potrebuješ pretaktovávať na tak závratné frekvencie?Jak jsem již psal, když už do toho ty peníze dám, tak ať to stojí za to..
Si si vedomý, že že tak vysoko taktované pamäte budú mať horšie latencie?To nevím
Ako zistíš, či pozitívny efekt vyššej frekvencie pre Tvoje konkrétne zaťaženie bude vyšší, ako zhoršená latencia?To taky nevím.
..., když už do toho ty peníze dám, tak ať to stojí za to..Snažím sa Ti naznačiť, že robíš kravinu: chystáš sa vyplácnuť prémiovú cenu za niečo, o čom netušíš, či Ti to vyrieši nejaký problém, a dokonca ani len to, či efekt tej prémiovej ceny bude merateľný. Obávam sa, že jediný merateľný efekt bude ten finančný.
desku za 3K místo za 15K paměti za 5K místo za 15K procesor za 5K místo za 12K disk za 6K místo za 17K grafiku za 5K místo za 2x20Kdostanu takřka stejný výkon a ještě ušetřím balík peněz? Díky
Jak už se ti mnohokrát snažil cronin říct.. ty prachy hodíš do luftu, ty ten rozdíl nepoznáš.. a hodit 100k za vyšší číslo v benchmarku je naprostá blbost.a vlastně to vyšší číslo je stejně sporné.. může být, nemusí být.. záleží na tom, jakým způsobem dají těm pamětem zabrat.. Prostě kup ramky na 2400MHz, ušetříš a rozdíl bude neznatelný.. Obecně vzato, s tvými znalostmi docela pochybuju o tom že ty 2400MHz paměti dokážeš vytížit na opravdový strop.Môžem sa spýtať, prečo tak zúfalo potrebuješ pretaktovávať na tak závratné frekvencie?Jak jsem již psal, když už do toho ty peníze dám, tak ať to stojí za to..
Dají se najít ve výprodejích starší kousky - nechám na Vás, jestli Vám stojí za to E5 32nm model o dvě generace zpátky - už tehdy mívaly 10 MB cache apod. Ono u starších procesorů zase budete mít starší generaci RAM, tzn. nižší takt a za nějakou cenu menší kapacitu (objem).
Viděl jsem tuším i nějaké jednopaticové boardy pro Xeon E5 (LGA2011). Zkuste se porozhlédnout. Je to sice myslím overkill, reálně by Vám desktopová sestava měla stačit (LGA1151) ale jestli máte peněz na rozhazování, tak si klidně udělejte radost
Xeony E5 mají taky víc kanálů RAM než desktopové sestavy. Bohužel ta RAMka je tuším povinně ECCčková... což svého času znamenalo dvojnásobek ceny (nevím jak dneska). Dělávaly se "workstation" boardy pro jeden nebo dva Xeony E5, tzn. "cílový tržní segment" jste zřejmě přesně Vy. Pokud budete koukat po tomhle, zamyslete se nad chlazením. Prostorná skříň, rozměrné pomalé tiché ventilátory... na vodu se vykašlete, pasivní zdroj je blbost, chce to jenom udělat ve skříni jasně definovaný průvan. A netlačit komponenty na hranu s takty / spotřebou / teplem (v zájmu životnosti).
Xeon E5 a mnohé modely Xeon E3 jsou bez integrované grafiky. A ona ta integrovaná grafika od Intelu na desktopových i7 dodnes není úplně přehnaně výkonná. Dneska je sice výkon IGP s každou generací Intel CPU lepší, ale pořád si myslím, že v OpenGL akceleraci tomu IGPčku základní Nvidia natrhne tričko. Takže kdyby Vám šlo třeba o 3D CAD/modeler, má smysl koupit přídavnou kartu. A nemusí to být kdovíjaké dělo, na práci bych viděl jako vhodné třeba low-end Quadro (čip Nvidia, karta třeba HP) se spotřebou řádově 40 W na plný plyn... radši s ventilátorem než pasiv (nebo pasiv a sám si přidat pomalý velký ventilátor
Zdroj Vám to neutaví, s trochou štěstí se to ani neupeče ve vlastní šťávě a pár let to vydrží šlapat jak hodiny. A když zjistíte, že 40W Quadro je kozí dech, koupíte něco výkonnějšího.
Nakonec je to celé otázka ceny. Kolik na tu sestavu máte dohromady peněz. A pokud volba vypadá tak, že můžete mít Xeon E5 s 16 GB RAM, nebo desktopovou i7 se 32 GB RAM, možná bych šel do desktopové sestavy. Na tu práci co píšete je možná obojí overkill, ale všechno je relativní, záleží na velikosti dat, se kterými pracujete.
Kdysi jsem měl doma 486 DX4 / 120, kterou jsem původně koupil bez L2 cache. L2 cache tehdy bývala na motherboardu v DILových paticích - a kvůli nižší ceně se daly boardy koupit bez cache. Nebo byla neosazená jenom "tag SRAM" ? (devátá patice) Už nevím. Po pár letech jsem měl možnost ty DILové SRAMky levně dokoupit, tak jsem si tuším 256 kB dodatečně koupil, včetně tag SRAM. Byl jsem hrozně zvědavej, co to se strojem udělá - a subjektivně... nic moc. Extáze se nekonala. V Duke Nukemovi jsem si všiml, že ve složitých scénách je FPS pozorovatelně vyšší (posun od dojmu "nehratelně trhané" na "sotva hratelné"). Pod Windows subjektivně beze změn. Nakonec jsem si dal tu práci, a stopnul jsem si 1) jak dlouho startujou Windows95 a 2) jak rychle se enkóduje MP3. A naměřil jsem zkrácení času asi o třetinu, tzn. výkon vyšší o 50% ! Jak říkám, subjektivně žádná velká změna. Pro mě z toho plyne, že řešit nějakých 10 % je v subjektivním dojmu (čekání) zhola zanedbatelné. To bylo v dobách, kdy se počítač na konci práce neuspával, ale vypínal.
Míval jsem pravidlo, že RAMky není nikdy dost - protože RAMka odstraní potřebu swapování. V momentě, kdy můžete mít otevřené trvale všechny aplikace, a při přeskakování mezi nimi si počítač nesáhne na disk, pocítíte nástup swapování velmi bolestivě
Pak ale přišla doba, kdy jsem si všiml, že Windows za určitých okolností (když necháte počítač moc dlouho v klidu?) odswapují neaktivní aplikace "jenom tak, aby nezacláněly v RAMce" - takže mají Windowsy dobrý pocit, že mají hodně RAMky, ale když na počítač (běžící aplikace na liště) sáhnete po dvou hodinách volnoběhu, tak se disk může uchrchlat, jak Windows obnovují aplikace ze swapu. V tomhle byly hrozné Windows 2000. XPčka tuším už měly tohle pořešené. V poslední době mám pocit, že mi dementně zbytečně swapují Win7, ale to může být opět jenom nedostatkem RAM. 4 GB v dnešní době není úplně moc, a mám pocit, že Windows Update má sklon schovávat svoji spotřebu RAM a snad i CPU v device manageru (běží přece "na pozadí") - chová se v tomto ohledu jak malware na bázi rootkitu. Mám pocit, že na stejném hardwaru Windows 8.1 nebo 10 se chovají opět rozumněji/svižněji než Win7. Tradičně velice rozumný a laditelný přístup ke swapování má Linux... co jednou nastartuje, to se na disk zbytečně neodkládá, ale dá se ladit jednak "swappiness", jednak procento a "trpělivost" diskových write-back bufferů apod.
K RAMce mě ještě napadá, že pokud budete vytěžovat externí GPU (gamesením nebo CUDA/OpenCL) a bude potřeba GPU dokrmovat z RAMky (např. průběžné dotahování textur), tak úzkým hrdlem těžko bude takt hlavní RAM počítače - úzkým hrdlem bude PCI-e x16. Tzn. opět nejde o takt RAMky. Ale soudím, že toto využití hardwaru nebude Váš případ...
Meh... ještě jsem našel pro LGA2011 Core i7-6800K - zřejmě sestřička Xeonu E5 v4. Umí 128 GB DDR4 bez ECC.
Datasheety k E5 v4 jsou trochu tajnosnubné, nějak jsem tam nedokázal najít klasické "overview" nebo ukecanou kapitolu ohledně toho jaké paměti, kolik kanálů, kolik ranků, ECC/nonECC apod. V datasheetu vol.2 se lze dočíst, že:
P.S.: odpovídat si na svoje vlastní přípěvky v diskusi je tradičně známkou poruchy osobnosti...
Našel jsem nakonec i vysvětlení, jak je to s jedním vs. dvěma IMC v Xeonech E5 v4. Prostě když je v pouzdru CPU víc jak deset jader, přidá se druhý kruh (nebo půlkruh) - a každý kruh má svůj vlastní IMC. Pokud to správně chápu, na IMC sousedního kruhu už je to o pár taktů dál, než na "svůj vlastní" IMC. To by mě zajímalo, jestli se to tváří jako jeden nebo dva NUMA uzly... Nemám představu, jak se x86 NUMA inicializuje, jak si detekuje shluky jader per uzel (zjistí z BIOSu?), zda existuje "hierarchická NUMA" apod.
A pak jsem potkal ještě zajímavý kus dokumentace firmy Fujitsu k jejich serverům, kde se mluví o podporovaných velikostech DIMMů a je zmíněna závislost max.rychlosti podle počtu osazených DIMMů na kanál.
Reálně myslím cca platí i můj popis: když přijde požadavek na "zas nějakou úplně jinou" adresu, musí se ta "vlaková cesta" každopádně zgruntu přenastavit (nebo přinejmenším velmi pravděpodobně), bez ohledu na to, jak moc a kam je ten nový požadavek třeba zarovnaný. A od toho místa běží dávkový přenos (netuším jak dlouhý). Reálně se tuším přenášejí vždycky minimálně celé řádky cache, tzn. taková je granularita, ale maximální délku bez nového čekání na CAS netuším...
Nedalo mi to a trochu jsem se začetl. Vzpomněl jsem si totiž, že signály CAS/RAS/WE jsem viděl už dávno na RAMkách o velikosti jednotek kB.
Ultra-klasická asynchronní DRAMka 4164 má vstup a výstup (D a Q) o šířce jeden bit
Tzn. pro osmibitový CPU jich bylo potřeba 8 švábů paralelně (sběrnice o šířce 1 Byte).
Oslnivých 64 kilobitů DRAMky 4164 je organizováno v matici 256 řádků (rows) x 256 sloupců (columns). Při dávkových přenosech ("page mode", nepatrně zavádějící název) se čtou postupně bity v řádku. Jako když čtete text v latince. Těžko říct, zda na konci řádku dojde k "wrap-aroundu" a odskoku na nový řádek. Uvnitř jsou dva adresní dekodéry: jeden řádkový a druhý sloupcový. Vnější rozhraní má 8 adresních bitů (A0..A7), takže se adresa přenáší nadvakrát: nejdřív se nakrmí 8bitová adresa do řádkového adresního dekodéru, její "strobe" signál se jmenuje ~RAS. Následně se nakrmí 8bitovou adresou taky sloupcový dekodér, při sestupné hraně signálů ~CAS. První (kratší) povinná pauza zvaná t(RCD) je mezi sestupem ~RAS a ~CAS, tzn. mezi oběma adresními slovy. Druhá (delší) povinná pauza se jmenuje t(CAS) - ta běží od sestupné hrany CAS do okamžiku, kdy se kaskáda hradel adresních dekodérů ustálila. Jde hlavně o sloupcový dekodér, protože řádkový má náskok. Ejhle naše moderní CL. Sloupec zde evidentně znamená granularitu 1 bitu (a je to tak i v moderních DDR DRAMkách) čili CAS Latency = ustálení sloupcového adresního dekodéru = ustálení "ukazatele na konkrétní detailní adresu", na úrovni tohoto čipu 1 bit, na úrovni celé paměti u 8bit CPU 1 byte.
V datasheetu je vnitřní blokové schéma čipu, časovací diagram a asi o stránku výš tabulka s hodnotami těchto časů.
Je k dispozici také časovací diagram pro "page mode", tzn dávkový přenos. Ten se děje tak, že držíte ~RAS aktivní (log.0) a jednotlivé bity (hostitelské adresy) taktujete kladnými pulzy signálu ~CAS, čímž dochází k automatické inkrementaci sloupcového dekodéru. Nenašel jsem v datasheetu zmínku, zda se automaticky inkrementuje také řádkový dekodér...
Rovněž klasická asynchronní DRAMka 41256 má vstup a výstup (D a Q) stále o šířce jeden bit
Tzn. pro osmibitový CPU jich bylo potřeba 8 švábů paralelně (sběrnice o šířce 1 Byte). Má už ale kapacitu 256 kb, tzn. čtyřnásobnou oproti 4164. Ten čtyřnásobek je implementován zvětšením matice na 512 x 512 bitů. Což se projevilo rozšíření adresní sběrnice z 8 na 9 bitů (A0..A8) - tzn. během dvou adresních cyklů přibyly dohromady dva adresní bity, odtud čtyřnásobná naadresovatelná kapacita.
Máte pravdu, že moderní DRAMky obsahují uvnitř několik dílčích "matic" - říká se jim patrně Banky. V odkazovaných (dnes už starších) DDR RAMkách firmy Micron má Bank rozměry matice 8192 řádků X přiměřený počet sloupců (zde 512 nebo 1024 nebo 2048), a tento model DRAM švábu obsahuje takové banky 4. Kromě toho může mít šváb šířku datové sběrnice 4 nebo 8 nebo 16 bitů podle modelu. Na 64b široký DIMM je pak potřeba 16, 8 nebo 4 švábi. Unbuffered šváb má na vstupu 13 adresních bitů (A0..A12), dva bity pro výběr jednoho ze čtyř interních Banků (BA0/1), 4/8/16 bitů DQ (datové signály jsou obousměrné) a stále zde samostatně existují i klasické signály CAS, RAS a WE. Čili i zde platí, že signál CAS na sestupné hraně latchuje adresu jednotlivého adresního místa v RAMce a pak se čeká na jeho vzestupnou hranu, při které už RAMka má mít vystavená data na výstup. Na vnějším rozhraní švába je vidět také signál CS = chip select, který v DIMM modulu odpovídá jednomu "ranku" (který je patrně někdy nazýván také "side" nebo "row", asi kvůli zmatení nepřítele). DIMM může mít "ranků" několik. Zdá se, že "bank select" signály BA0/1 nejsou zaměnitelné s adresními signály A0..An - protože adresa se přes A0..An předává ve dvou cyklech, zatímco BA musí ukazovat na tentýž bank v průběhu celé transakce. Z toho plyne, že pro správnou funkci musí hostitelský řadič RAM vědět, kolik banků používají švábi na daném DIMMu. Ostatně by měl znát také rozměry matice Banku (kolik řádků a sloupců), aby správně půlil adresu na signálech A0..An.
Pokud se podívám na pinout DIMMů, tak DDR3 unbuffered DIMM má 16 bitů adresy (A0..A15), 3 bity pro "bank select" (BA0..BA2 = až 8 banků v rámci čipu) a ještě navíc 4 chip-selecty (tzn. quad-rank max). To by mělo stačit na mnohem větší DIMMy, než jsou běžně dostupné 8GB moduly 
U DDR4 je pár změn: adresní signály A0..A17, Banky ač čtyři (BA0/1) ovšem přibylo další patro zvané Bank Groups (BG0/1). Čili už ne 8 Banků max jako u DDR3, ale až 16 Banků. A zdá se, že přibyl údaj Page Size (v bajtech) - pokud správně chápu, "page" odpovídá jednomu DRAM řádku. V uvedeném PDF se mluví o geometriích cca 64k řádků X kolem 1k sloupců (bitů na řádek). A signály CAS/RAS/WE mají odejít do důchodu (nahradí je jinak kódovaný "command"). Trochu se v tom začínám ztrácet
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.