Érdekes. Ami felmerült bennem az a latency kérdése. Ez nem plusz egy réteg, amitől nagyobb lesz a RAM elérés latency-je? Gondolom hogy nagyon nem lesz nagyobb, hiszen akkor szóba se jönne egy ilyen megoldás. Van erről valami infó?
Ill ha inkabb bandwith kell, mint latency, ugyan annyi pinbol,
high-end serdes el, nagyobb bandwith hozhato ki.
troughput-ra meno szervereke eseteben a nagyobb latency, ha
nem okoz tul sok vegrehajto egyseg ehezest (pl a tobb CPU thread miatt),
nem feltelen okoz gondot.
Masutt ez problemas lehet.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
Ettől még a probléma jogos. Én igazából meglepőnek találom, hogy a RAM a mai napig nem differenciális jelátvitelt használ, mindenhol máshol már lecseréltük kb. (ahol nagysebességű kapcsolat kell).
Más kérdés, hogy ez a felvázolt interfész jó-e, vagy inkább mást kellett volna választani esetleg? Véleményem szerint az a chip, ami ott a kódolást csinálja, szoftvert/firmware-t nem tartalmazhat, nincs az a szoftver, ami ilyen sebességet meg tud hajtani.
Az valószínű egy ASIC lesz inkább. Persze manapság mindenbe tesznek valamilyen MCU core-t is, mert miért ne? Abban lehet lesz valami management firmware, de a lényegi részt tuti ASIC fogja csinálni.
Majd akkor lesz még mellé pár réteg cache, meg még több processzoron belüli optimalizáció (mint a spekulatív memória olvasás). Ami szomorú lenne, mert már eddig is láttuk, hova vezet a túlzott bonyolítás.
DDR5 DIMM szinten ez evben varhto, ami 64 bites interfacet 2x32 bitesre cserili.
5.2GT/s -van DDR5 -re irva 64 vonalon az ~ 332Gbit/sec nagysagrendileg.
A latencia velhetoleg, tobb lesz a serial link miatt, de ha tobb link van...
Ha annyival kevesebb pin kell egy modulhoz, akkor 2 modul per channel helyett
akkar joval tobb, onalo egyetlen modulos channel is lehet.
power10 egy coron belul 4/8 HT -van lehet kevesbe banjak a nagyobb latenciat,
es inkabb szeretnenek nagyobb savszelt.
szerk:
tovabb olvasva, joval lassabb serial linkrol van szo.
Egy modul , valoszinuleg 8 x 25/32G vonalon menne, +10ns latency. 16 ilyen modul ferne be.
Jelenleg ez desktopon es mobilon nem tunik jo otletnek,
ahol felhasznalaokan fontos egyetlen szal milyen gyors.
Ha soros memoria iranyba megyunk, velhetoleg masok is novelni fogjak thread/core szamot.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
Soros átvitelhez azért sokszoros órajel kell, hogy helyettesíthesse a pérhuzamosat.
Egyébként szervereknél régebben is volt már olyan, hogy nem natívan címezgette a kontroller a ram chipeket, hanem közbülső réteg kezelte azokat. A nagy kapacitású szerver ramoknál R-dimm- LR-dimm és FB-dimm is régi játékos már https://en.wikipedia.org/wiki/Registered_memory
Az fb-dimm soros megoldást használt, teljesítmény, fogyasztás és melegedés problémákkal.
Hozzászólások
Érdekes. Ami felmerült bennem az a latency kérdése. Ez nem plusz egy réteg, amitől nagyobb lesz a RAM elérés latency-je? Gondolom hogy nagyon nem lesz nagyobb, hiszen akkor szóba se jönne egy ilyen megoldás. Van erről valami infó?
Igazából az a kérdés, hogy a jelenlegi és a jövőbeli ram sebességek mellett tényleg az-e a szűk keresztmetszet?
Nezopont kerdese.
Mondhatod ~10% nak, vagy akkar fele olyan gyorsnak. A DRAM eleres fugg atol is, hogy milyen kozel volt az elozo eleres.
https://www.7-cpu.com/cpu/Power9.html
https://en.wikipedia.org/wiki/CAS_latency
https://www.reddit.com/r/hardware/comments/7qqmwl/dragontamers_understa…
A joveben, serial link sebbege feljebb mehet meg,
mint emlittem 112G talan elojohet a kozel jovoben
224G:
https://www.anandtech.com/show/16020/intels-new-224g-pam4-transceivers
Utana, fene se tudja mi lesz.
Ill ha inkabb bandwith kell, mint latency, ugyan annyi pinbol,
high-end serdes el, nagyobb bandwith hozhato ki.
troughput-ra meno szervereke eseteben a nagyobb latency, ha
nem okoz tul sok vegrehajto egyseg ehezest (pl a tobb CPU thread miatt),
nem feltelen okoz gondot.
Masutt ez problemas lehet.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
Ettől még a probléma jogos. Én igazából meglepőnek találom, hogy a RAM a mai napig nem differenciális jelátvitelt használ, mindenhol máshol már lecseréltük kb. (ahol nagysebességű kapcsolat kell).
Más kérdés, hogy ez a felvázolt interfész jó-e, vagy inkább mást kellett volna választani esetleg? Véleményem szerint az a chip, ami ott a kódolást csinálja, szoftvert/firmware-t nem tartalmazhat, nincs az a szoftver, ami ilyen sebességet meg tud hajtani.
Az valószínű egy ASIC lesz inkább. Persze manapság mindenbe tesznek valamilyen MCU core-t is, mert miért ne? Abban lehet lesz valami management firmware, de a lényegi részt tuti ASIC fogja csinálni.
Majd akkor lesz még mellé pár réteg cache, meg még több processzoron belüli optimalizáció (mint a spekulatív memória olvasás). Ami szomorú lenne, mert már eddig is láttuk, hova vezet a túlzott bonyolítás.
112G https://www.rambus.com/interface-ip/serdes/112g-phy/ SerDes ez evebne varhato.
Ha kep nem kamu, akkor annyi pinen tobb is elfer.
DDR5 DIMM szinten ez evben varhto, ami 64 bites interfacet 2x32 bitesre cserili.
5.2GT/s -van DDR5 -re irva 64 vonalon az ~ 332Gbit/sec nagysagrendileg.
A latencia velhetoleg, tobb lesz a serial link miatt, de ha tobb link van...
Ha annyival kevesebb pin kell egy modulhoz, akkor 2 modul per channel helyett
akkar joval tobb, onalo egyetlen modulos channel is lehet.
power10 egy coron belul 4/8 HT -van lehet kevesbe banjak a nagyobb latenciat,
es inkabb szeretnenek nagyobb savszelt.
szerk:
tovabb olvasva, joval lassabb serial linkrol van szo.
Egy modul , valoszinuleg 8 x 25/32G vonalon menne, +10ns latency. 16 ilyen modul ferne be.
Jelenleg ez desktopon es mobilon nem tunik jo otletnek,
ahol felhasznalaokan fontos egyetlen szal milyen gyors.
Ha soros memoria iranyba megyunk, velhetoleg masok is novelni fogjak thread/core szamot.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
Soros átvitelhez azért sokszoros órajel kell, hogy helyettesíthesse a pérhuzamosat.
Egyébként szervereknél régebben is volt már olyan, hogy nem natívan címezgette a kontroller a ram chipeket, hanem közbülső réteg kezelte azokat. A nagy kapacitású szerver ramoknál R-dimm- LR-dimm és FB-dimm is régi játékos már
https://en.wikipedia.org/wiki/Registered_memory
Az fb-dimm soros megoldást használt, teljesítmény, fogyasztás és melegedés problémákkal.