Aktív témák
-
#18
DcsabaS
senior tag
CsendPenge
#14
DcsabaS
senior tag
válasz
CsendPenge
#14
üzenetére
Rövidítésnél tényleg előfordulhat, hogy nem egyértelmű a jelentés, ezért az első alkalommal kívánatos a teljes nevén megadni a dolgot.
A 2, vagy több csatornás adattovábbítás és -tárolás számottevő mértékben nem változtatja meg a hozzáférési sebességeket. Ámde számottevően (csaknem arányosan) megnövelheti az időegység alatt átvihető adatmennyiséget, FELTÉVE, hogy az adatok az átvitelhez rendelkezésre is állnak. A dual-DDR memória azért okoz csupán minimális gyorsulást egy Athlon proci mellett, mert a processzor (ami az adatátvitel legfőbb célpontja) átviteli sebessége a 64 bit-es, jelenleg max. 166 MHz-es, DDR átvitelű rendszerbusza miatt pont annyi, mint 1 db 1-csatornás, szintén 64 bit-es, szintén DDR átvitelű, 166 MHz-es órajelű DDR333-as SDRAM-é. Magyarán, egy 166-os FSB-jű Athlonhoz tulajdonképpen már a DDR400 is tulzás (nem is gyorsul sokat). Nagyjából az van, hogy egy 100 MHz-es FSB-jű Duronhoz DDR200, egy 133 MHz-es FSB-jű Athlonhoz DDR266, egy 166 MHz-es FSB-jű Athlonhoz pedig DDR333-as memória dukál, és ha gyorsabbat illesztünk hozzá, a javulás már csak minimális lesz. (Ha az AMD kijön egy 200 MHz-es FSB-jű Athlon verzióval, egyből értelme lesz a DDR400-as SDRAM-nak.)
Az Intel a maga részéről már beígérte a 200 MHz-es és QDR rendszerbuszú (effektíve 800 MHz-es FSB-jű) P4-eseit, azok pedig mindjárt 2 db DDR400-as RAM modult is ki tudnak majd használni.
A Hammer-ek környékén még van bizonytalanság. Az eredeti tervek szerint a kisebb Hammer (ma Athlon64) 1 db integrált RAM vezérlőt tartalmazott volna, max. DDR333-as RAM-hoz. Ez azonban már ma is igen kevésnek látszik, tekintve a következőket:
1.) Magasabb órajelen relatíve egyre nagyobb visszahúzó erő lesz a lassú RAM sebesség.
2.) Már az AthlonXP FSB-jét is föl kellett emelni 166 MHz-re.
3.) A Hammer órajelenként több utasítást hajt végre (hatékonyabb), ezért még azonos frekin is érzékenyebben függ a RAM sebességétől. -
MoonFace
csendes tag
Hja, ha az elözöeket a Raid-es példára szeretném lefordítani, akkor ez azt jelenti, hogy két vinyó mégiscsak dupla annyi adatot tárol, így a fej mozgatása (lassú track-váltás) nélkül is dupla mennyiségü adatot érhet el, vagyis megnö annak valószinüsége, hogy a következö adatblokk átviteléhez nem kell a fejet mozgatni...
-
#15
MoonFace
csendes tag
CsendPenge
#14
MoonFace
csendes tag
válasz
CsendPenge
#14
üzenetére
''melyiknél van/lehet előnye a dual ddr vezérlőnek? Mert eddig csak azt hallom, hogy mennyire nem ér semmit, pedig tök jó...''
Alapvetöen egyik szempontjából sincs jelentösége, mert egyik technológia sem a CPU-memória kapcsolatra vonatkozik...
Viszont azért kategórikusan azt sem lehet kijelenteni, hogy nem ér semmit...
Pl. azzal, hogy minden cacheline adata fele-fele arányban két memóriamodulon helyezkedik el, effektíve megduplázódik az SDRAM aktív bankjának lapmérete (mivel legalább két aktív bank van) és ezzel a Fast Page módon elérhetö címtartomány is, ami (és itt meg kell követnem Parci-t) valóban csökkentheti az átlagos késleltetést (igaz, nem a késleltetés csökken, hanem a kisebb késleltetésü tranzakciók valószinüsége nö)... -
#14
CsendPenge
őstag
DcsabaS
#12
CsendPenge
őstag
Ajjaj, asszem megint lusta voltam, és így félreérthető :( Ha jól vettem ki a szavaidból, akkor te a HyperThreading-re gondoltál. Én meg eredetileg a HyperTransportra. (bár arról is keveset tudok) Szóval akkor melyik? És melyiknél van/lehet előnye a dual ddr vezérlőnek? Mert eddig csak azt hallom, hogy mennyire nem ér semmit, pedig tök jó...
-
MoonFace
csendes tag
''mivel a két fej egyszerre mozog, ezért fele annyi ideig kell várni az ''összesített fejre'', hogy mozduljon. Vagy rosszul gondolom?''
Namost, ha az egyik HDD feje mondjuk 3 ms alatt éri el a kívánt pozíciót, meg a másiké is, akkor ha a kettö egyszerre dolgozik, akkor mindkettö egyszerre fogja azt elérni, de továbbra is 3 ms alatt, tehát a kezdeti késleltetésünk nem változott. Ha ehhez még hozzávesszük azt, hogy mondjuk a Raid kontrollerünk egy olyan buszra csatlakozik, ami még egy vinyó átviteli sebességét is csak éppen át tudja magán préselni, akkor már egész helyénvalónak tünik a példa, vagyis a teljes blokkátvitel eredö késleltetése sem javult az egy vinyós konfighoz képest. Na ez itt is a helyzet...
Azt kell megérteni (és ezért jó a Raid-es példa), hogy egyetlen cacheline átviteléhez is szükség van mindkét csatornára, mert a fele az egyikröl, fele a másikról érkezik. Ha nem így lenne, akkor gyakorlatilag semmi értelme nem lenne a dual-channel-nek, mert pont a nagyobb sávszélességét nem lehetne kihasználni, ugyanis semmi biztosíték nem lenne rá, hogy két egymást követö tranzakció olyan memóriacímekre vonatkozzon, ami külön csatornán elérhetö (vagyis két külön memóriamodulra). -
#12
DcsabaS
senior tag
CsendPenge
#9
DcsabaS
senior tag
válasz
CsendPenge
#9
üzenetére
A HT-nél természetesen igen, de HT csak a P4-nél van (legalábbis egyelőre), ott meg HT nélkül is ki lehet használni a dual DDR-es megoldásokat, tekintve, hogy a P4 rendszerbusza 4-szeresen pumpált, szemben az Athlon 2-szeresen pumpáltjával, így azonos órajelen dupla átviteli sebességű. Éppen passzol a dual DDR memóriához.
-
#11
Clyde22_
tag
FollowTheORI
#6
Clyde22_
tag
válasz
FollowTheORI
#6
üzenetére
Ráadásul (ajánlott) tökugyanolyat....
Bár nem ötelezö, csak akkor a Dual-channel fölösleges..... -
A RAID Stripe-os példánál maradva: valóban nem mozog gyorsabban egyik fej sem. De, mivel a két fej egyszerre mozog, ezért fele annyi ideig kell várni az ''összesített fejre'', hogy mozduljon. Vagy rosszul gondolom?
Ha mondjuk 6 ns a latency, és én megkezdem egy 64 kb-os szegmens olvasását, 6 ns-ot várok. Ha közben meg tudom kezdeni egy másik szegmens olvasását a másik csatornán, mondjuk 1 ns-mal később, akkor 7 ns alatt kétszer kezdtem olvasási ciklust, pedig single channelnél ez biztosan 12 ns lett volna.
***
(itt érveltem sokat, hogy miért van igazam...)
***
A fenti példában az a legnagyobb bökkenő, hogy a szűk FSB miatt meg sem tudom kezdeni a második szegmens olvasását, mert az első szegmens átvitele fullra leköti a rendszerbuszt.
(a fix memóriacímre írást én sem gondolom másképp, de ha mondjuk felváltva írnék és olvasnék, és fsb is lenne elég, akkor a fenti példa már működne mindkét irányba... nem?) -
#9
CsendPenge
őstag
CsendPenge
őstag
Nos, erre én is kíváncsi leszek. (hogy mit tud) Amúgy akkor most hol lehet maxra kihasználni a dual ddr megoldásokat? A HT-nél?
-
MoonFace
csendes tag
''Először is, az írási ciklusok előtt is várni kell a memóriára, márpedig itt segít a kétcsatornás elérés (oda ír, ahol szabad a pálya).''
Ahogy mondani szokták: ez így ebben a formában nem igaz.
Egyrészt a procinak szinte soha nem kell várnia az írásra, hiszen egy általa végrehajtott írás eredménye ott van neki a cache-ben, az, hogy mikor kerül ki a memóriába, az számára irreleváns.
Másrészt az ''oda ír, ahol szabad a pálya'' (amellett hogy nagyon szép lennne) szintén több szempontból sem müködhet:
- az, hogy én melyik memóriacímre írok, egyértelmüen meghatározza, hogy melyik memóriamodul melyik chip-jének melyik bankján belül melyik rekeszbe kell ezt tennem, úgyhogy a használandó ''pálya'' kötött.
- a kétcsatornás vezérlönek csak akkor van értelme, ha olyan address-interleaving-et használunk, hogy minden egyes cacheline átvitele használja mindkét csatornát (pl. a páros 8 bájtok az egyikröl, a páratlanok a másikról érhetöek el), így viszont a ''pálya'' pont annyira lehet szabad, mint single-channel-nél.
''Ha a memóriába kerülő adatokat sem folyamatosan, az egyik helyre írja a program, hanem kétfelé, akkor később a visszaolvasásnál is kevesebb késleltetéssel tudja azokat begyűjteni.''
Gondolj pl. egy RAID-Strip-re! Attól, hogy a beolvasandó adat két vinyón van elosztva, még nem kerül a fej gyorsabban egy meghatározott szektor fölé... -
Először is, az írási ciklusok előtt is várni kell a memóriára, márpedig itt segít a kétcsatornás elérés (oda ír, ahol szabad a pálya). Azt sem feltétlen mondanám, hogy a rendszer RAM-jánál az olvasás a szinte kizárólagos művelet. Ez nem egy adatbázis (pl a PROHARDVER! adatbázisa), amit tényleg mindenki olvas, és nagyon ritkán ír. A rendszermemóriát folyamatosan írják-olvassák a programok, bár tény, hogy az olvasás a gyakoribb művelet.
Ha a memóriába kerülő adatokat sem folyamatosan, az egyik helyre írja a program, hanem kétfelé, akkor később a visszaolvasásnál is kevesebb késleltetéssel tudja azokat begyűjteni.
A cache-ek és a prefetch-ek is segítenek, mint ahogy azt írtad is. A lényeg tehát az, hogy a plusz sávszélességet nem tudja az EV6 miatt kihasználni a rendszer, de az egyéb gyorsulásokat igen, márpedig itt főleg a késleltetés csökkentése marad. -
#6
FollowTheORI
nagyúr
Pontosan... én abszolúte nem temetném a VIA-t...
Megmutatta már hogy az A mennyit jelent néha... ;)
Egyébként az sem elhanyagolható előny, hogy nem kell két modult venni... -
MoonFace
csendes tag
Mondjuk a valóságtartalom hiánya (vagy a félreérthetö megfogalmazás) miatt ezt az igét nem hirdetném, hogy:
''A dual-DDR megoldások tehát leginkább a memória késleltetések (latency) csökkentésében tudják kifejteni áldásos hatásukat, ami ugyan számít, de nem sokat''
A helyzet ugyanis az, hogy szinte kizárólag a memóriaelérések (olvasás) eredö késleltetése számít, és pont ez az, amibe a K7 plattform esetén a DualDDR nem nagyon tud beleszólni.
Az persze igaz, hogy az nForce prefetch-logikája szabadabban garázdálkodhat a memóriabusz (nagyobb) üres idejében, valamint az esetleg fölöslegesen (akár az AthlonXP, akár a north-bridge által) megkezdett spekulatív tranzakciók kevésbé rontják az összteljesítményt, de ha a processzormagnak valamire szüksége van, ami csak a memóriából elérhetö, akkor az ö várakozási idején a DualDDR semmit nem segít, hiszen a tranzakció pont azon részét gyorsítja (az elsö adatblokk átvitele utáni folyamatos burst részt), amit az EV6 korlátjai miatt úgy sem tud szegény kihasználni... -
DcsabaS
senior tag
A VIA a KT333 és a KT400 esetében sem deklarálta jóelőre a 166 MHz-es FSB támogatását, csak miután az AMD hivatalosan bejelentette az ilyen FSB-jű Athlon-ok megjelenését. Szóval szereintem valószínű, hogy a KT400A esetében is csak akkor fogják hivatalossá tenni a 200 MHz-es FSB támogatását, miután az AMD is hivatalosan bejelentette az ilyen Athlon-ok megjelenését.
A DDR400-ra való optimalizálás tényleg ráfér a KT400A-ra, hiszen a magasabb FSB nyújtotta előnyöket csak így lehet(ne) kihasználni.
Megjegyzem, hogy 133 MHz-es FSB-ig a valós alkalmazásokban a KT400 egy picit még gyorsabb is a 2-csatornás nForce2-nél (és ezeket a méréseket még nem is a VIA Hyperion 4in1 Driver-rel végezték!), vagyis az nForce2 5-15 százalékos fölénye 166 MHz-es FSB-nél aligha a 2 csatornájából származott. Inkább csak arról lehet szó, hogy az nVIDIA chipsetje lényegesen kevesebb várakozási ciklussal is beéri a stabil működéshez, és ennek hatása, hogy magasabb frekin számottevően gyorsabb. Ha pedig így áll a helyzet, akkor a KT400A 166 MHz-en is lehet majd ugyanolyan gyors, mint az nForce2, és talán 200 MHz-en sem lesz (sokkal) lassabb. Mindezt alacsonyabb áron.
A 2-csatornás DDR SDRAM vezérlő Athlon procikhoz csak akkor kifizetődő, ha van integrált grafika is, vagy ha elterjednek a gigabit-es hálókártyák, 150-es SATA vezérlők és hasonlók, és NEM a PCI buszra lesznek kötve, hanem külön illesztést kapnak a déli hídhoz. Ezért elképzelhető, hogy a VIA fejlesztés alatt álló KM400-as chipsetje majd tényleg 2-csatornás DDR RAM vezérlőt kap.
Aktív témák
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7800X3D 32/64GB RAM RX 9070 XT GAMER PC termékbeszámítással
- Xiaomi Redmi Note 10 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
- ÁRGARANCIA!Épített KomPhone i5 13400F 16/32/64GB RAM RTX 5060 Ti 16GB GAMER PC termékbeszámítással
- Konzol felvásárlás!! Nintendo Switch
- Egyedi ékszerdobozka
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest