DOS-Forum

Hallo zusammen,

ich stelle gerade ein paar Überlegungen hinsichtlich meines Flagschiff-486ers an
Ich habe ein HOT-419 als Grundlage, in der Revision RZ/R1. Ich habe keine Möglichkeit, auf 3,3V zu jumpern, sprich 5V.
Mir ist ein Overdrive DX4-100 ins Auge gesprungen, aber dann bin ich einem AMD DX4-120 begegnet
Wäre es möglich in dieses Board mit Voltage-Zwischensockel den DX4-120 zu stecken, auf 40Mhz FSB zu gehen (VLB-Waitstates einzustellen) und den Prozessor zu betreiben? Ich kann ja davon ausgehen, dass das Board den Prozessor nicht erkennt, wie würde man dann vorgehen?
Was ich noch bemerken muss: Laut Manuals etc. gibt es einen Jumper (J65) mit dem man die Clock einstellen kann, also 2x oder 3x. Bei mir ist dieser Jumper nicht vorhanden, nur die Stelle mit Lötstellen (aber sauber, wie fabrikgewollt). Ich gehe dann davon aus, dass es nicht mehr notwendig ist oder das es gar nicht erst möglich ist, den Multi zu ändern, was ich nicht hoffe.

Das HOT-419 unterstützt doch DX4-CPUs, also auch den 120er. Erkenne jetzt erstmal nicht, warum nicht auch ein 133er gehen sollte.

Bei den VLB-Boards und den Steckkarten kann's unter Umständen zu Problemen mit dem FSB-40 geben.

Edit:
Ups, DX4 ist natürlich nicht DX5-133.^^
Der 120er sollte aber gehen, wobei der "Schub" von 100 auf 120 nicht wirklich relevant sein wird.

Ja, aber erst ab Revision 2. Meine Revision unterstützt nur 5V Prozessoren. Bei stason.org mag das zwar anders aussehen, aber die sind auch nicht das Maß aller Dinge Bei shuttle selbst steht deswegen auch "optional" unter dem Abschnitt 3,3V.

Oder ich habe kein "original" Hot-419 Und nur die Eckdaten sowie die Jumper stimmen überein.

Revision RZ unterstützt nur 5V CPU's, das Board hat keinen Spannungsregler.
Ein DX4-120 ist mit Zwischensockel problemlos möglich. Kein Ding. Aber du kannst auch einen Overdrive DX4-100 kaufen und versuchen, diesen zu übertakten. Die Chancen dafür stehen gut. Außerdem profitierst du dann vom doppelt so großen L1 Cache gegenüber dem AMD Prozessor.

Der "Performanceschub" eines 120ers gegenüber eines 100ers liegt eher an der höheren Speicherbandbreite und Cacheperformance bei 40MHz Bustakt (gegenüber den standardmäßigen 33MHz beim DX4-100).

@FGB: Danke FGB, für die Erklärungen, sehr hilfreich! Eine Frage habe ich noch: Wenn ich den Overdrive einsetze, jumpere ich dann das Board für einen DX33 oder kann ich die DX2-66 Einstellungen lassen? Ich weiß natürlich, dass der Overdrive die Einstellungen ignoriert, aber von iwas muss er ja ausgehen
Der DX4-120 in der WriteBack-Version.... bezieht sich das WB da eigentlich auf den L1 Cache oder auf den L2 Cache? Laut stason,org kann ich das Hot-419 ja auch in den WB Modus stellen...

Das WriteBack vom AMD (wahrscheinlich meist SV8B) meint immer den L1 Cache. Der L2 Cache, der sich normalerweise als DIP-ICs auf dem Mainboard befindet, sollte immer im WriteBack laufen ;)

Mr. Vain hats gesagt..

Als Ergänzung: Meiner Meinung nach wird der WriteBack L1 Modus überschätzt. Für gewöhnlich lässt er die Cacheperformance des Prozessors steigen, die Speicherperformance fällt hingegen etwas ab. Spiele wie doom z.B. profitieren 0,0 vom WriteBack L1 Cache. Bei anderen Spielen liegen die Vorteile bei ca. 5%, in manchen synthetischen Benchmarks auch etwas höher.

FGB hat geschrieben:Mr. Vain hats gesagt..

Als Ergänzung: Meiner Meinung nach wird der WriteBack L1 Modus überschätzt. Für gewöhnlich lässt er die Cacheperformance des Prozessors steigen, die Speicherperformance fällt hingegen etwas ab. Spiele wie doom z.B. profitieren 0,0 vom WriteBack L1 Cache. Bei anderen Spielen liegen die Vorteile bei ca. 5%, in manchen synthetischen Benchmarks auch etwas höher.

Ich habe das mal bei einem 486DX2-66 gebencht WT gegen WB und Doom ist z.B. bei Write Through etwas schneller als bei Write Back. Aber das kann man ja bei dem jeweiligen System umschalten und ggf. ganz schnell austesten.

nach meinem Verstaendnis ist das mit WriteBack und WriteThrough so:

WriteBack macht durchaus Sinn, und zwar bei Daten, die einmal berechnet werden und auf die staendig oder zumindest oft zugegriffen werden muss. Das ist bei Office- oder wissenschaftlichen Programmen der Fall.

WriteThrough legt auch Daten im L1 ab, kuemmert sich aber nicht darum, ob diese Daten spaeter nochmal gebraucht werden. Beim naechsten Taktzyklus vom Frontsidebus werden die Daten einfach wieder in den L2 zurueckgeschrieben. Bei Spielen ist es ja der Fall, dass staendig neue Daten berechnet werden und in der Regel nie ein und das selbe Datum bald wieder verwendet wird. Deshalb macht es auch keinen Sinn, diese Daten im L1 aufzuheben, weil sich der L1 dann zu schnell mit unnuetzem Zeug fuellen wuerde.

Den Vorteil vom WriteBack spuert man/misst man in den jeweiligen Anwendungen schon, nur sind das eben die Programme, die eher begrenzten Spielspass bereiten ;)

Ich wuerde das nicht so allgemein klassifizieren. Es haengt halt von dem ablaufenden Code ab, wie die Performance einer Routine von Cachestrategien abhaengt. Das kann sich selbst innerhalb einer Applikation unterscheiden.