Linux und 128 MB RAM
wizzard
Hallo Linux-Gemeinde ... ;o)
Ich hab mir letzte Woche nochmals 64 MB RAM gegoennt und so auf obige
Summe aufgeruestet. Nun stellt sich aber ein Problem. Wenn ich LInux boote,
dann erkennt der Kernel nur 64 MB. Man sagte mir, das die mit einem Eintrag
in der lilo.conf behoben werden koennte. Ich hab dies nun mit
append = "mem=128" bzw.
append = "mem=128M" bzw.
append "mem=128" bzw.
append "mem=128M" bzw.
getestet, jedoch ohne Erfolg. Was mache ich falsch ??? Bin fuer Hilfe
sehr dankbar.
Gruss, root ;o)
wizzard
Ach ja, ich vergass noch zu erwaehnen, das es sich um
Slackware Linux 3.4 handelt. Kernel 2.0.30
Thomas Dettmar
wizzard schrieb:
>
> Ich hab mir letzte Woche nochmals 64 MB RAM gegoennt und so auf obige
> Summe aufgeruestet. Nun stellt sich aber ein Problem. Wenn ich LInux boote,
> dann erkennt der Kernel nur 64 MB.
hallo wizzard,
hatte das problem mit gigabyte boards in aehnlicher form. obwohl das handbuch
aussagt es koennen 512 mb eingebaut werden ging oberhalb von 64 mb nichts mehr.
linux akzeptierte nur 64 mb und nt ist gleich abgekachelt.
nach einbau eines tag rams lief alles wunderbar. das ein tag ram erforderlich
ist, hat das handbuch aber verschwiegen.
vieleicht hilft dir das weiter.
auf bald
thomas
Robert Fendt
Thomas Dettmar <thomas....@metronet.de> writes:
>> Ich hab mir letzte Woche nochmals 64 MB RAM gegoennt und so auf obige
>> Summe aufgeruestet. Nun stellt sich aber ein Problem. Wenn ich LInux boote,
>> dann erkennt der Kernel nur 64 MB.
>
> linux akzeptierte nur 64 mb und nt ist gleich abgekachelt.
> nach einbau eines tag rams lief alles wunderbar. das ein tag ram erforderlich
> ist, hat das handbuch aber verschwiegen.
Jupp. Der Cachable Bereich ist der Haken. TX-Chipsaetze z.B. koennen nur 64
MB cachen - da hilft nur auf DIMMs umsteigen. HX und VX Boards koennen
prinzipiell bis zu 512 MB cachen - dazu ist aber ein groesseres Tag-Ram
erforderlich, als normalerweise auf dem Brett drauf ist. Austauschen und
gluecklich werden :-)
Tschau,
Robert
--
Robert Fendt <fe...@student.physik.uni-dortmund.de>
public PGP key available !
--
Hiermit untersage ich die Nutzung und Uebermittlung meiner Daten zu
Werbezwecken oder fuer die Markt- bzw. Meinungsforschung gemaess
Par. 28 Abs. 3 Bundesdatenschutzgesetz.
Marek Luthardt
Robert Fendt schrieb in Nachricht <6ftqhp$q...@nx2.HRZ.Uni-Dortmund.DE>...
:Jupp. Der Cachable Bereich ist der Haken. TX-Chipsaetze z.B. koennen nur 64
:MB cachen - da hilft nur auf DIMMs umsteigen.
Interessant. Ich hab ein Chaintech 5TTM1 mit TX-Chipsatz und einem
32-MB-SDRAM-DIMM. In den nächsten Tagen steck ich nochmal das gleiche dazu.
Ich dachte immer, damit meine TX-begrenzte Cacheable Area ausgereizt zu
haben. Seit wann ist das CA-Problem bei DIMMs gar keins ?
Ciao
Marek
--
Web.Service Marek Luthardt
Max-Planck-Ring 16/038 - D-98693 Ilmenau
---------------------------------------------------------------------
http://www.luthardt.de
email: sol...@gmx.net / in...@luthardt.de
Robert Fendt
> Interessant. Ich hab ein Chaintech 5TTM1 mit TX-Chipsatz und einem
> 32-MB-SDRAM-DIMM. In den nächsten Tagen steck ich nochmal das gleiche dazu.
> Ich dachte immer, damit meine TX-begrenzte Cacheable Area ausgereizt zu
> haben. Seit wann ist das CA-Problem bei DIMMs gar keins ?
Steinen gar nicht gecachet werden koennen. Aber Vorsicht: es soll auch
EDO-DIMMs geben, auch wenn ich persoenlich noch keins in der Hand hatte
Marek Luthardt
Robert Fendt schrieb in Nachricht <6fu4kg$t...@nx2.HRZ.Uni-Dortmund.DE>...
:> Interessant. Ich hab ein Chaintech 5TTM1 mit TX-Chipsatz und einem
:> 32-MB-SDRAM-DIMM. In den nächsten Tagen steck ich nochmal das gleiche
dazu.
:> Ich dachte immer, damit meine TX-begrenzte Cacheable Area ausgereizt zu
:> haben. Seit wann ist das CA-Problem bei DIMMs gar keins ?
:Weil DIMMs 10-12 ns Zugriffszeit haben, und daher von den 12-15 ns Cache-
:Steinen gar nicht gecachet werden koennen. Aber Vorsicht: es soll auch
:EDO-DIMMs geben, auch wenn ich persoenlich noch keins in der Hand hatte
Aha. Das bedeutet, sobald ich nur SDRAM einsetze, kann ich mir den Cache
sparen ?!
Wieso finde ich dann soviele Komplettsysteme mit Boards mit Cache, bei
welchen nur SDRAM drinsteckt ? Da wäre doch mal wieder was zu sparen für die
Board/System-Hersteller ...
Oder ist das ein kleiner Aprilscherz ?
Ingo Matthaes
In article <6ftr6b$69d$1...@piggy.rz.tu-ilmenau.de>, Marek Luthardt wrote:
>
>Interessant. Ich hab ein Chaintech 5TTM1 mit TX-Chipsatz und einem
>32-MB-SDRAM-DIMM. In den nächsten Tagen steck ich nochmal das gleiche dazu.
>Ich dachte immer, damit meine TX-begrenzte Cacheable Area ausgereizt zu
>haben. Seit wann ist das CA-Problem bei DIMMs gar keins ?
Stimmt definitiv nicht, siehe anderes Posting.
mfg
Ingo
-------------------------------------------------------------------
Ingo Matthäs E-Mail: IMat...@online-club.de
Lötterfelder Str. 15 Phone : +49 2132 760206
40667 Meerbusch PGP-Key on request
Ingo Matthaes
In article <6ftqhp$q...@nx2.HRZ.Uni-Dortmund.DE>, Robert Fendt wrote:
>Jupp. Der Cachable Bereich ist der Haken. TX-Chipsaetze z.B. koennen nur 64
>MB cachen - da hilft nur auf DIMMs umsteigen.
Was sollen dir den die Dimms bringen ? Der 430TX kann grundsätzlich nur
64 MB cachen, egal in welcher Form du den Speicher reinsteckst und wie breit
du das Tag-Ram machst. (Performancevorteile bringen die SDRAMS bei normalem
Bustakt übrigens auch nicht)
>HX und VX-Boards koennen
>prinzipiell bis zu 512 MB cachen - dazu ist aber ein groesseres Tag-Ram
>erforderlich, als normalerweise auf dem Brett drauf ist. Austauschen und
>gluecklich werden :-)
Halbwahrheiten !! Der HX Chipsatz ist definitiv der letzte Socket-7 Chipsatz
von Intel mit einer cachable Area >64 MB. Der VX ist auch schon kastriert.
Darüber hinaus ist der SDRAM-Support des VX grottenschlecht.
Außerdem muß man nicht prinzipiell das Tag-Ram upgraden, bei neueren
Boardrevisionen von Asus z.B. ist schon alles zum glücklichwerden drauf.
!! F'up gesetzt
Martin Neumann
In article <98033122500700.00166@wizzard>,
wizzard <ro...@wizzard.studwerk.fh-merseburg.de> writes:
> Man sagte mir, das die mit einem Eintrag in der lilo.conf behoben werden
> koennte.
Das ist richtig.
> append="mem=128M"
Dies ist die korrekte Variante.
> getestet, jedoch ohne Erfolg. Was mache ich falsch ???
Damit der Parameter beim Booten an den Kernel dann auch
wirklich übergeben wird, musst du nach einer Änderung an
der lilo.conf den Bootblock neu mit lilo schreiben.
(lilo -C /etc/lilo.conf)
> Gruss, root ;o)
Deinem Smiley entnehme ich, daß du schon weisst, was ich dir sagen
will. Trotzdem: never ever do your daily work as root.
Martin
--
Martin Neumann, Lindenbreede 14, 49124 Georgsmarienhütte
»Das Usenet wird vielleicht eher durch die Killfiles gerettet. Wer
keine Antwort kriegt langweilt sich und geht wieder zur Therapie.«
~ Oliver Gassner in <3521a5f3...@news.pf.bawue.de>
Bertram Wegener
wizzard schrieb:
>
> Ich hab mir letzte Woche nochmals 64 MB RAM gegoennt und so auf obige
> Summe aufgeruestet. Nun stellt sich aber ein Problem. Wenn ich LInux boote,
> in der lilo.conf behoben werden koennte. Ich hab dies nun mit
>
> append = "mem=128" bzw.
> append = "mem=128M" bzw.
> append "mem=128" bzw.
> append "mem=128M" bzw.
Probier doch mal
append MEM=128
ohne diese Anführungszeichen.
Und vergiß nicht /sbion/lilo auszuführen...
bertram
Oliver Bandel
wizzard <ro...@wizzard.studwerk.fh-merseburg.de> wrote:
> Hallo Linux-Gemeinde ... ;o)
> Ich hab mir letzte Woche nochmals 64 MB RAM gegoennt und so auf obige
Wahnsinn!
Willst Du ein Druckhaus aufmachen, oder wozu brauchst Du 128 MB?!
Ich bin mit 32 MB eigentich schon ganz gut dran. :-)
Aber 128 MB? Da kann man ja einige Sauereien mit machen, oder? :-)
Tschüß,
Oliver
P.S.: Braucht man für so etwas nicht spezielle mainboards? Viele
machen doch bei 64MB schon schlapp (zu wenig Cache).
--
Robert Fendt
"Marek Luthardt" <sol...@gmx.net> writes:
> Aha. Das bedeutet, sobald ich nur SDRAM einsetze, kann ich mir den Cache
> sparen ?!
> Wieso finde ich dann soviele Komplettsysteme mit Boards mit Cache, bei
> welchen nur SDRAM drinsteckt ? Da wäre doch mal wieder was zu sparen für die
> Board/System-Hersteller ...
> Oder ist das ein kleiner Aprilscherz ?
wurde nur eingefuehrt, um die langsamen Zugriffe auf die EDOs und FPs
zu beschleunigen. Das Besondere an statischen cache-Steinen ist, dass
sie synchron zum Systemtakt laufen koennen. Genau das koennen SDRAMs
aber auch; nicht umsonst heissen sie 'Synchronous DRAMS'. Da die
SDRAM-DIMMs vergleichbare bzw. schnellere Zugriffszeiten haben wie SRAMs,
wird die Verwendung von Cache in der Tat witzlos. Der TX kann z.B. ja auch
angeblich 256 MB EDO verwalten, aber die Geschwindigkeit der Zugriffe waere
dann eher 386er maessig. Die Adressierung des Speichers ist
normalerweise kein Problem, da schon 486er *theoretisch* 256MB
adressieren konnten.
Meistens sind trotzdem Cache-Steine auf den Boards, weil es fuer den
Hersteller billiger ist, sowas in Grosserie zu produzieren, anstatt
fuer Aldi ne Extra Wurst zu braten. Ansonsten: Schau mal nach, wie viel
onboard-cache ein P2-Board hat :-) Der P2 selber hat zwar 'L2'-cache,
aber das hat imho nochmals geringere Zugriffszeiten und ist mit dem
klassischen onboard-SRAM nicht zu vergleichen.
Zum Schluss: Das ganze ist denn doch so langsam off-topic
hier. Vielleicht sollten wir mit den Interessierten ne Mailing-Liste
machen :-)) Ich jedenfalls habe diese group wg. Linux bestellt, nicht
um ueber 'Muss SDRAM gecachet werden oder nicht' zu streiten.
Harald Anlauf
fe...@student.physik.uni-dortmund.de (Robert Fendt) writes:
> War eigentlich nicht so gemeint. Cache-Steine sind SRAMs. Der Cache
> wurde nur eingefuehrt, um die langsamen Zugriffe auf die EDOs und FPs
> zu beschleunigen. Das Besondere an statischen cache-Steinen ist, dass
> sie synchron zum Systemtakt laufen koennen. Genau das koennen SDRAMs
> aber auch; nicht umsonst heissen sie 'Synchronous DRAMS'. Da die
> SDRAM-DIMMs vergleichbare bzw. schnellere Zugriffszeiten haben wie SRAMs,
> wird die Verwendung von Cache in der Tat witzlos.
Das ist definitiv falsch. Die *Latenz* ist bei SDRAM fuer den ersten
Zugriff deutlich groesser als fuer PB-Cache (z.B. 5 vs. 3 Memory-Bus
Takte), selbst wenn allere weiteren Zugriffe "pipelined" sind.
(siehe auch entsprechende Mainboard-Tests bei der c't, u.a. die
*gemessenen* Bandbreiten zum L2-Cache und RAM).
--
Ciao,
-ha
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Harald Anlauf | Phone: +49-6151-16-2972 (office)
TH Darmstadt | +49-6151-370157 (private)
Institut f. Kernphysik | Fax: +49-6151-16-2421
Schlossgartenstr. 9 | Email: anl...@hep.tu-darmstadt.de
64289 Darmstadt | Harald...@cern.ch
Germany | (PGP public key available)
wizzard
Ich danke Euch allen fuer Eure Tips und Hinweise. Ich hab das Problem mit
jetzt geloest.
c u all next time
Florian Friesdorf
wizzard wrote:
> Ich hab mir letzte Woche nochmals 64 MB RAM gegoennt und so auf obige
> Summe aufgeruestet. Nun stellt sich aber ein Problem. Wenn ich LInux boote,
> dann erkennt der Kernel nur 64 MB. Man sagte mir, das die mit einem Eintrag
> in der lilo.conf behoben werden koennte. Ich hab dies nun mit
>
> append = "mem=128" bzw.
> append = "mem=128M" bzw.
> append "mem=128" bzw.
> append "mem=128M" bzw.
>
> getestet, jedoch ohne Erfolg. Was mache ich falsch ??? Bin fuer Hilfe
> sehr dankbar.
Ich habe mal gehört, das es bei manchen Boards zu Problemen mit den
64MB SDRAM Modulen kommt.
Falls du SDRAM Module hast, kannst du sie ja mal tauschen.
Bye Flo
Ulrich Schmitz
Robert Fendt wrote:
> > Aha. Das bedeutet, sobald ich nur SDRAM einsetze, kann ich mir den Cache
> > sparen ?!
> > Wieso finde ich dann soviele Komplettsysteme mit Boards mit Cache, bei
> > welchen nur SDRAM drinsteckt ? Da wäre doch mal wieder was zu sparen für die
> > Board/System-Hersteller ...
> > Oder ist das ein kleiner Aprilscherz ?
Ja, es ist ein Aprilscherz!
> War eigentlich nicht so gemeint. Cache-Steine sind SRAMs. Der Cache
> wurde nur eingefuehrt, um die langsamen Zugriffe auf die EDOs und FPs
> zu beschleunigen.
Der Cache wurde eingefuehrt, um die langsamen Zugriffe auf DRAMs
allgemein zu beschleunigen! SRAMs sind auch noch eine ganze Ecke
schneller, als SDRAMs - schon allein, weil SRAMs keinen Refresh
benoetigen - SDRAms (wie alle DRAMs) aber schon. [SRAMs sind
mit FlipFlops aufgebaut, DRAMs mit Transistor und Kondensator,
daher auch der Preisunterschied]
> Das Besondere an statischen cache-Steinen ist, dass
> sie synchron zum Systemtakt laufen koennen.
Nein, siehe oben - SRAMs brauchen keinen Refresh.
> Genau das koennen SDRAMs
> aber auch; nicht umsonst heissen sie 'Synchronous DRAMS'. Da die
> SDRAM-DIMMs vergleichbare bzw. schnellere Zugriffszeiten haben wie SRAMs,
> wird die Verwendung von Cache in der Tat witzlos.
Auf gar keinen Fall werden die Witzlos - Cache kann immernoch um
den Faktor 1,75 schneller sein, als SDRAMs - beim P2 oder PPro nochmal
ganz erheblich mehr (weil die den Cache schneller takten).
> Die Adressierung des Speichers ist
> normalerweise kein Problem, da schon 486er *theoretisch* 256MB
> adressieren konnten.
BTW: Der 386DX/486/Pentium koennen alle bis zu 4GB adressieren,
die Beschraenkung, die Du meinst liegt beim Chipsatz.
> Meistens sind trotzdem Cache-Steine auf den Boards, weil es fuer den
> Hersteller billiger ist, sowas in Grosserie zu produzieren, anstatt
> fuer Aldi ne Extra Wurst zu braten.
Unsinn, auch mit SDRAMs bremmst man sein Linux ohne Cache mal
schnell auf 50% bis 70% seiner moeglichen Leistung runter!!!
> Ansonsten: Schau mal nach, wie viel
> onboard-cache ein P2-Board hat :-)
Das ist nicht relevant, denn....
> Der P2 selber hat zwar 'L2'-cache,
... wie Du siehst sitzt der Cache im Prozessor, der
sitzt also _nur an einer anderen Stelle_!!!
> aber das hat imho nochmals geringere Zugriffszeiten und ist mit dem
> klassischen onboard-SRAM nicht zu vergleichen.
Die Zugriffszeit ist in diesem Fall nicht so interesannt,
denn die Zugriffszeit bei SDRAms wird anders ermittelt, als
bei SRAMs oder herkoemmlichen DRAMs - soll heissen, diese
Zahlen sind nicht ohne weiteres zu vergleichen!
> Zum Schluss: Das ganze ist denn doch so langsam off-topic
> hier. Vielleicht sollten wir mit den Interessierten ne Mailing-Liste
> machen :-)) Ich jedenfalls habe diese group wg. Linux bestellt, nicht
> um ueber 'Muss SDRAM gecachet werden oder nicht' zu streiten.
Hmm, ich das Hardware, oder IST das Hardware? ;-)
cu
Ulrich
--
Name: Ulrich Schmitz
Organization: FH-Koeln
E-Mail: bt...@mail.dvz.fh-koeln.de
Frank Klemm
On 1 Apr 1998 17:49:56 GMT, Robert Fendt <fe...@student.physik.uni-dortmund.de> wrote:
>> Interessant. Ich hab ein Chaintech 5TTM1 mit TX-Chipsatz und einem
>> 32-MB-SDRAM-DIMM. In den nächsten Tagen steck ich nochmal das gleiche dazu.
>> Ich dachte immer, damit meine TX-begrenzte Cacheable Area ausgereizt zu
>> haben. Seit wann ist das CA-Problem bei DIMMs gar keins ?
>Steinen gar nicht gecachet werden koennen. Aber Vorsicht: es soll auch
>EDO-DIMMs geben, auch wenn ich persoenlich noch keins in der Hand hatte
>
Ah, wieder auf die Werbung reingefallen! Oder ein guter Aprilscherz. DIMMs
ist eine Bauform, genauso wie SIMMs. Was Du meinst, ist FP (Fast Page)-RAM,
EDO (extended data output)-RAM und SD (Synchron dynamic)-RAM.
Bei FP/EDO war es üblich, die Lead-In-Zeit anzugeben, bei SD-RAM wird die
Burst-Zeit angegeben. Die Bezeichnung wäre daher richtig als FP 70ns/40ns
oder als EDO 60ns/25ns oder SD-RAM 60ns/12ns. Und da sind Caches immer noch
schneller mit 20ns/10ns. Ein paar Beispiele (der 35 ns EDO wird nicht für
MB, sondern für 3D-GK eingesetzt, der 100 MHz-SD-RAM kommt wahrscheinlich
mit dem PII-400/100 heraus):
minimal Burst bei xx MHz (Gesamtzeit in ns)
LeadIn Burst 60 66 75 83 90 100
100 ns dRAM 100 ns 100 ns
80 ns PM-RAM 80 ns 60 ns
70 ns FP-RAM 70 ns 40 ns 5-333 (232) 6-333 (225)* 6-444 (240) 7-444 (228)
60 ns FP-RAM 60 ns 40 ns 5-333 (232) 5-333 (210)* 6-444 (240) 6-444 (216)
60 ns EDO-RAM 60 ns 25 ns 5-222 (183) 5-222 (165) 6-222 (160)* 6-333 (180)
50 ns EDO-RAM 50 ns 25 ns 4-222 (167) 4-222 (150) 5-222 (147)* 5-333 (168)
12 ns SD-RAM 60 ns 12 ns 5-111 (133) 5-111 (120) 6-111 (120) 6-111 (108)* 7-222 (144) 7-222 (130)
10 ns SD-RAM 60 ns 10 ns 5-111 (133) 5-111 (120) 6-111 (120) 6-111 (108) 7-111 (111) 7-111 (100)*
35 ns EDO-RAM 35 ns 18 ns 3-222 (150) 3-222 (135) 4-222 (133) 4-222 (120) 4-222 (111)* 5-222 (110)*
100 MHz-SD-RAM 40 ns 10 ns 3-111 (100) 4-111 (105) 4-111 ( 93) 4-111 ( 84) 5-111 ( 89) 5-111 ( 80)*
PB-Cache sRAM 20 ns 10 ns 2-111 ( 83) 2-111 ( 75) 3-111 ( 80) 3-111 ( 72) 3-111 ( 67) 3-111 ( 60)*
Interne 2nd-Level-Caches:
PPro200 10 ns 5 ns
PII233 17.1 ns 8.6 ns
PII400 10 ns 5 ns
Bei einem Fehltritt auf den Hauptspeicher muß ein 233 MHz-Prozessor bei EDO
wie bei SD ca. 19 Takte warten. 8 Takte auf den 2nd-Level-Cache sind da
schon milder. Nicht berücksichtigt wurden hierbei noch Seitenwechsel
(nochmal 18 Takte) oder Write-back-Bursts des Caches (39 Takte), die einen
Prozessor doch eine ganze Zeit lahmlegen können. Auch wenn das selten
auftritt, sind das erhebliche Verluste. Daher ist der Pentium sehr weit weg
von den 2 Befehlen pro Takt (laut Intel 0.35 Befehle pro Takt), ähnliches
beim PPro 0.5 Befehle pro Takt). Hier haben die Chiphersteller (und die
Programmierer !!!!!) noch erhebliche Reserven.
Noch eine Zuordnung Prozessor/RAM (wird aber durch die Chipsätze bestimmt)
8086 dRAM
286 dRAM/PM-RAM
386 PM-RAM
486 FP-RAM/EDO-RAM
Pentium FP-RAM/EDO-RAM/SD-RAM
PII EDO-RAM/SD-RAM
--
Frank Klemm
/------\ /-----------------------------------------------------\
| eMail: || p...@uni-jena.de | home: p...@schnecke.offl.uni-jena.de |
| Tel: || | home: +49 (3641) 390545 |
| sMail: || Frank Klemm, Ziegesarstr. 1, D-07747 Jena, Germany |
\------/ \-----------------------------------------------------/
Frank Klemm
On 2 Apr 1998 08:17:48 GMT, Robert Fendt <fe...@student.physik.uni-dortmund.de> wrote:
> "Marek Luthardt" <sol...@gmx.net> writes:
>> Aha. Das bedeutet, sobald ich nur SDRAM einsetze, kann ich mir den Cache
>> sparen ?!
>> Wieso finde ich dann soviele Komplettsysteme mit Boards mit Cache, bei
>> welchen nur SDRAM drinsteckt ? Da wäre doch mal wieder was zu sparen für die
>> Board/System-Hersteller ...
>> Oder ist das ein kleiner Aprilscherz ?
>
static random access memory
>wurde nur eingefuehrt, um die langsamen Zugriffe auf die EDOs und FPs
>sie synchron zum Systemtakt laufen koennen.
sRAM hat nichts mit synchronem Design zu tun.
>Genau das koennen SDRAMs
>aber auch; nicht umsonst heissen sie 'Synchronous DRAMS'.
Das Synchron heißt nur, daß die Bausteine intern die richtigen Signale
erzeugen und nur noch einen Mastertakt benötigen. Dadurch können
Sicherheitszeiten (der Baustein kennt sich selbst am besten) und Latenzen
(1.7 Takte müssen auf 2 Takte aufgerundet werden) entfallen. Das schnelle
Bursten wird durch mehrere ge'interleaved'te Bänke ermöglicht. Leider
entsteht dabei auch etwas mehr Overhead, was das Lead-In etwas verlangsamt.
>Da die SDRAM-DIMMs vergleichbare bzw. schnellere Zugriffszeiten haben wie
>SRAMs, wird die Verwendung von Cache in der Tat witzlos.
Halbwissen ist peinlich! Besonders wenn man es hinaustrompetet.
>Der TX kann z.B. ja auch angeblich 256 MB EDO verwalten, aber die
>Geschwindigkeit der Zugriffe waere dann eher 386er maessig.
Polikerlaufbahn? Lange keinen 386er unten den Händen gehabt.
>Die Adressierung des Speichers ist normalerweise kein Problem, da schon
>486er *theoretisch* 256MB adressieren konnten.
>
Nein 4 GB. Genauso wie der 386DX (der 386SX kann nur 16 MB).
Robert Underberg
In article <3523672B...@hoehe.studwerk.fh-merseburg.de>,
Dann lass uns nicht dumm sterben. Was hast Du getan?
--
Robert Underberg, Munich
mailto:Robert.U...@vsm.bauwesen.tu-muenchen.de
Wolf-Dietrich Materna
In article <6fvlqm$d...@nx2.hrz.uni-dortmund.de>,
fe...@student.physik.uni-dortmund.de (Robert Fendt) writes:
>
> War eigentlich nicht so gemeint. Cache-Steine sind SRAMs. Der Cache
> zu beschleunigen.
> Das Besondere an statischen cache-Steinen ist, dass
> sie synchron zum Systemtakt laufen koennen.
sie Standart.
> Genau das koennen SDRAMs
> aber auch; nicht umsonst heissen sie 'Synchronous DRAMS'. Da die
> SDRAM-DIMMs vergleichbare bzw. schnellere Zugriffszeiten haben wie SRAMs,
> wird die Verwendung von Cache in der Tat witzlos.
F"ur SDRams wird die mittlere Zyklenzeit angegeben und nicht die
mittlere Zugriffszeit, wie f"ur SRam und andere DRams "ublich.
Die Zugriffszeit f"ur SDRams liegt bei etwas 40-50 ns und das ist
erheblich mehr als f"ur Cachebausteine mit < 15ns.
Diese bestimmt im Wesentlichem, wie schnell bei einem Einzelzugriff
bzw. den ersten Zugriff beim Burst auf den Speicher zugegriffen
werden kann. F"ur SRams ergeben sich bei 66 Mhz Takt 0 Waitstates,
also 1 Takt. Bei SDRams sind es mindestens 2 WS bzw. 3 Takte.
Die darauffolgenden "Ubertragungen im Burstmode erfolgen dann
schneller. Die Geschwindigkeit wird durch die Zyklenzeit bestimmt:
10-15ns bei 66Mhz ergeben 1 Takt pro Maschinenwort.
Im Burstmode ben"otigt die CPU (f"ur 4 Worte) ingesamt
3+1+1+1 = 6 Takte bei SDRam, f"ur SRam dagegen nur 4.
(Eventuell stimmt die Rechnung so nicht ganz, die wahren Experten
m"ogen mir verzeihen ;-)
> Der TX kann z.B. ja auch
> angeblich 256 MB EDO verwalten, aber die Geschwindigkeit der Zugriffe waere
> dann eher 386er maessig. Die Adressierung des Speichers ist
> normalerweise kein Problem, da schon 486er *theoretisch* 256MB
> adressieren konnten.
Wie andere schon sagten 2^32 = 4G. Die Begrenzungen kommen auch
dort vom Chipset, meist 64 MB.
> Meistens sind trotzdem Cache-Steine auf den Boards, weil es fuer den
> Hersteller billiger ist, sowas in Grosserie zu produzieren, anstatt
> fuer Aldi ne Extra Wurst zu braten. Ansonsten: Schau mal nach, wie viel
> onboard-cache ein P2-Board hat :-)
Das ist totaler Unsinn. Die Hersteller h"atten den Cache l"angst
weggelassen, wenn sie Geld sparen k"onnten bei gleicher Leistung.
Wahrscheinlich bist Du einfach auf die Angabe '10ns' reingefallen,
wie von diversen Herstellern beabsichtigt.
> Der P2 selber hat zwar 'L2'-cache,
> aber das hat imho nochmals geringere Zugriffszeiten und ist mit dem
> klassischen onboard-SRAM nicht zu vergleichen.
> Zum Schluss: Das ganze ist denn doch so langsam off-topic
> hier. Vielleicht sollten wir mit den Interessierten ne Mailing-Liste
> machen :-)) Ich jedenfalls habe diese group wg. Linux bestellt, nicht
> um ueber 'Muss SDRAM gecachet werden oder nicht' zu streiten.
Das ist allerdings wahr. de.comp.os.linux.hardware w"are passender,
sonst de.comp.sys.ibm-pc
Nichts f"ur ungut.
Wolf-Dietrich
Sebastian Kaps
>>>> Robert Fendt writes:
> aber auch; nicht umsonst heissen sie 'Synchronous DRAMS'. Da die
> SDRAM-DIMMs vergleichbare bzw. schnellere Zugriffszeiten haben wie SRAMs,
> wird die Verwendung von Cache in der Tat witzlos. Der TX kann z.B. ja
Hör doch bitte auf solchen ungeprüften Schwachsinn zu verbreiten!
Ich poste mal zwei Testergebnisse von ctcm V 1.5b. Das ganze lief auf einem
Gigabyte 586ATX Board mit TX-Chipsatz, 512k PB Cache und 2x32MB SDRAM mit
je 10 ns Zugriffszeitm, iP5-133.
1.) Ohne L2 Cache:
-----
PROZESSOR- und CACHEMESSER c't 3/96/ Andreas Stiller V1.5b
(...)
Sekundär-Cache : nicht vorhanden oder nicht aktiv oder >= 8fach assoziativ
(...)
Beste Zeit für 8K MOVSD (Cache /Page Hits) : 15 µs => 544.1 MByte/s
mittlere " für 8K MOVSD (Miss + Hit) : 168 µs => 48.7 MByte/s
mittlere " für 8K MOVSD (bei clean) : 168 µs => 48.6 MByte/s
mittlere " für 8K MOVSD (bei dirty) : 168 µs => 48.7 MByte/s
Schlechteste " 8K MOVSD (Cache misses) : 169 µs => 48.6 MByte/s
im Mittel unter DOS (640K): 149 µs => 54.9 MByte/s
im Mittel unter Windows (4MB) : 149 µs => 54.9 MByte/s
-----
2.) Mit L2 Cache:
-----
PROZESSOR- und CACHEMESSER c't 3/96/ Andreas Stiller V1.5b
(...)
Sekundär-Cache : 512 KByte, direct mapped
Write-Strategie L2 : Write Back
(...)
Beste Zeit für 8K MOVSD (Cache /Page Hits) : 15 µs => 544.2 MByte/s
mittlere " für 8K MOVSD (Miss + Hit) : 122 µs => 67.0 MByte/s
mittlere " für 8K MOVSD (bei clean) : 153 µs => 53.5 MByte/s
mittlere " für 8K MOVSD (bei dirty) : 153 µs => 53.5 MByte/s
Schlechteste " 8K MOVSD (Cache misses) : 177 µs => 46.2 MByte/s
im Mittel bei 512 KB L2-Cache /DOS (640K) : 112 µs => 73.0 MByte/s
im Mittel bei 512 KB L2-Cache /Win (4M ) : 136 µs => 60.2 MByte/s
-----
--
Ciao, Sebastian
* Email: toy...@sauerland.de
* HP: www.sauerland.de/~toyland/ PGP-Key available