Hirdetés

Aktív témák

  • Turmoil

    senior tag

    válasz Genialis #1 üzenetére

    Miért is lenne gáz? Nem kötelező VIA-s alaplapot venni!:)
    Amúgy hallottam olyat, hogy a SiS 746FX elég ütős lesz, szóval választék még mindig marad.

    Aki tud, és tudja hogy tud, az veszélyes. Tőle féljetek. Aki tud, és nem tudja hogy tud, az bölcs. Tőle tanuljatok. Aki nem tud, és tudja hogy nem tud, az okos. Őt tanítsátok. Aki nem tud, és nem tudja hogy nem tud, az hülye. Őt hagyjátok ..

  • twollah

    nagyúr

    válasz Turmoil #2 üzenetére

    Nem akarok HoLyFLaMeet, de en megbizom a VIAban.

  • 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.

  • 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...

    ''A felmerülö problémákra minden jelenlevönek van egy megoldási javaslata - ami nem müködik...''

  • 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...

    Steam/Origin/Uplay/PSN/Xbox: FollowTheORI / BF Discord server: https://discord.gg/9ezkK3m

  • Parci

    HÁZIGAZDA

    válasz MoonFace #5 üzenetére

    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.

    dicranum scoparium + genista pilosa = :)

  • MoonFace

    csendes tag

    válasz Parci #7 üzenetére

    ''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é...

    ''A felmerülö problémákra minden jelenlevönek van egy megoldási javaslata - ami nem müködik...''

  • 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?

    Remember the Linux, that's like a wigwam: no Windows, no Gates, just Apache inside. Two minutes of thinking can save hours of unnecessary work.

  • Parci

    HÁZIGAZDA

    válasz MoonFace #8 üzenetére

    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?)

    dicranum scoparium + genista pilosa = :)

  • 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.....

    Ne egyél a sárga hóból!

  • 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.

  • MoonFace

    csendes tag

    válasz Parci #10 üzenetére

    ''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).

    ''A felmerülö problémákra minden jelenlevönek van egy megoldási javaslata - ami nem müködik...''

  • CsendPenge

    őstag

    válasz DcsabaS #12 üzenetére

    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ó...

    Remember the Linux, that's like a wigwam: no Windows, no Gates, just Apache inside. Two minutes of thinking can save hours of unnecessary work.

  • 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ö)...

    ''A felmerülö problémákra minden jelenlevönek van egy megoldási javaslata - ami nem müködik...''

  • MoonFace

    csendes tag

    válasz MoonFace #15 üzenetére

    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...

    ''A felmerülö problémákra minden jelenlevönek van egy megoldási javaslata - ami nem müködik...''

  • MoonFace

    csendes tag

    válasz MoonFace #16 üzenetére

    ...és még valami, hátha információtartalommal bír: pont ugyan ilyen hatása miatt elönyös a BIOS-okban általában beállítható Bank interleaving.

    Jól elbeszélgetek magammal... :DDD

    ''A felmerülö problémákra minden jelenlevönek van egy megoldási javaslata - ami nem müködik...''

  • 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.

  • karib

    addikt

    Asszem ezt a témát elég jól kitárgyaltuk. Nem is értem minek a hűhó, evidens, hogy alapvetően nem kell az EV6-hoz dual DDR. Integrált video más kérdés, de komoly ember úgysem használ olyat :)

    Department of Redundancy Department

Aktív témák