[Sammelthread] AMD K7 - Sockel A (462)

Ich habe oben mal Ergebnisse mit und ohne L12 Brücke hinzugefügt. Ich verstehe es nicht wirklich, aber es scheint so das es tatsächlich einen Unterschied macht welche CPU verbaut ist. Jedenfalls hab ich mit dem 166Mhz Jumper kleine Abweichungen im 32M. Insgesamt scheinen die ED Sips aber für den FSB den sie erlauben sehr schnell zu sein. Bei mir schaffe ich mit EBED etwa 5Mhz mehr FSB als mit ED, die Bandbreite ist aber identisch bei max. fsb. Man tauscht also Effizienz gegen max. FSB ein. Kann Sinn machen wenn die Cpu am Limit ist und man keinen passenden Multi hat.

Der Test von weiteren Romsips (6/19XT usw...) steht noch aus. Die X1 Sips von Infrared muss ich auch noch testen. Ich bin gespannt ob man noch mehr Bandbreite rausholen kann ohne viel FSB zu verlieren. Vielleicht bekomme ich ja mein System noch effizienter durch den 32M... :d
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Bei den [ED] romsips, FSB133MHz, sind die Ergebnisse zwischen Interface optimal und aggressive fast gleich. Nicht, dass hier gleiche romsips geladen werden? Normal müsste man schon alleine an AIDA64 einen Unterschied zwischen optimal und aggressive erkennen.
 
Das ist mir auch aufgefallen. Deshalb werde ich wohl beide Ergebnisse nochmal testen, einfach um auszuschließen das ich versehentlich ne falsche Bios Einstellung gesetzt hatte.

Das Rätsel um die L12 Brücken und warum nur 2 Einstellungen setzbar sind ab ich auch endgültig gelöst dank: http://fab51.com/cpu/barton/athlon-e23.html
Es scheint so, das es 2 Brücken für die FSB Vorwahl gibt, soweit so klar. Beim Barton ist aber bei 133Mhz bereits eine Brücke geschlossen, heisst also das nur das schließen der anderen Brücke einen Effekt hat. Das heisst dann (gemäß Link), das ich nur zwischen 133 mit L12[0]=open und L12[2]=close und 200 mit beide=closed wählen kann, da 166Mhz [0]=closed und [2]=open nicht machbar ist.

Trotzdem erklärt das nicht warum mein 133er Tbred B 2400+ ebenfalls nciht auf den 2. Jumper reagiert. Gemäß Tabelle sollten bei dieser Cpu beide Brücken offen sein. Aber gut möglich das auch hier ein Fehler in der Tabelle ist. Vielleicht haben ja ein paar Leute verschiedene Cpus, damit man ne saubere Tabelle aufstellen und das alles abgleichen kann?! Brauchen würden wir Tbred B und Barton mit 133/166/200 Mhz default FSB, sofern verfügbar.
 
Vielleicht ist da eine Brücke geschlossen wie bei den mobile Prozessoren? Dann müsstest du aber nur zwischen 133 und 200 wählen können, nicht 166. So ganz verstehe ich das nicht.
 
Mein 2400+ (133er FSB) und mein 2700+ (166er FSB) haben definitiv verschiedene L12 Brücken geschlossen. Ich mache heute abend mal Fotos und dokumentiere das. Und ja, ich sollte dann zwischen 133 und 200 wählen können. Dafür muss ich mal ein Stock Bios flashen und nochmal genauer untersuchen. Bisher ging ich davon aus das es 133 und 166 ist - anscheinend falsch gedacht. Ich korrigiere das mal in meiner Tabelle.

Laut Fab51 sollen sich Tbred und Barton sowie Barton Mobile auch noch unterscheiden.

Hier die L12 Brücken meiner Cpus:
2400+, 1800+ und 1700+ Tbred A/B (133FSB) hat: cut-close-cut-close
2700+ (166FSB) hat: cut-close-close-close
Barton XP-m (133) hat: close-close-cut-close

Folglich sollten die 133er Cpus eigentlich zu 166 und 200 schaltbar sein. Der XP-m und der 166er Tbred sollten sich nur zu 200 schalten lassen. Eventuell hat das Board versucht bei den 133er Cpus in der 200er Stellung mit vollem Multi zu booten. Das wären 200x15 = 3ghz. Dann wäre es kein Wunder das es nicht klappt...
 
Habe auch mal gerade nachgeschaut hier:

2400+ XP-M (133): close-close-cut-close
2600+ (166): cut-close-close-close
3200+ (200): close-close-close-close
 
  • Danke
Reaktionen: Tzk
digitalbath schrieb:
Bei den [ED] romsips, FSB133MHz, sind die Ergebnisse zwischen Interface optimal und aggressive fast gleich. Nicht, dass hier gleiche romsips geladen werden?
Zum Vergrößern anklicken....

Gut gesehen und getippt. Hab 133Mhz Interface optimal nochmal laufen lassen und bin jetzt gute 10s langsamer. Denke da waren die falschen Sips geladen... Ich tausche das Ergebnis mal aus.

Was nun auffällt: Die Ergebnisse zwischen 133 und 200 ist nahezu identisch bzw. innerhalb der Messtoleranz. Damit wäre wohl für die ED Romsips bewiesen das der FSB der Cpu (abgesehen von den geladenen Romsips) keinen Einfluss hat. Ist das doch der Fall, dann sind wohl die Sips verschieden.
 
Die Ergebnisse sehen gut aus. Sollte jetzt besser passen.

Ich habe mit der neuen Windowsinstallation + anderer Festplatte (WD IDE 80GB) + deaktivieren einiger Komponenten den Zeitunterschied bei 32M halbieren können. Bin dann bei DDED - optimal - 133MHz bei ca. 39m 30,xxx s. Da ist also immer noch ein Abstand. Leider ist mir die Kiste beim update abgestürzt und Windows hat jetzt einen weg. Musste also gestern nochmal Windows installieren + updates fahren lassen.
Win XP akzeptiert meine SSD Festplatte nicht. :grrr: Ich installier erst einmal alle updates, dann sehe ich weiter.
 
Ich hab bei mir wirklich nichts sonst optimiert. Nur WinXP mit SP2 oder 3 (muss ich nachsehen), Komponenten im Bios deaktiviert und Treiber fürs Mainboard und GPU installiert und das Classic Theme von XP. Mehr nicht. Kann später gerne mal posten was ich genau eingestellt hab. Wäre doch gelacht wenn dein System langsamer ist...

SSD läuft nicht? Sollte aber eigentlich auch klappen... Ich überlege derzeit ob ich mir für 10-15€ ne 32 oder 64gb SSD besorge und die dann per IDE->Sata Adapter betreibe. TRIM ist dann zwar ein Problem, aber bei meiner Nutzung kann man das hoffentlich ignorieren.
 
Das glaube ich dir. Bis auf LAN+Sound+Firewire deaktivieren und Windows classic theme habe ich auch nichts gemacht. Mit der SSD wollte ich mal gegentesten, in wie weit das einen Einfluss auf Pi hat. Nach den updates weiß ich vielleicht mehr.

EDIT: Problem gelöst, die SSD läuft. Windows hat die Platte als "GPT Schutzpartition" erkannt. Mit diskpart konnte ich das lösen.
 
Zuletzt bearbeitet:
Ich hab die genaue Version mal nachgesehen. Es ist Win XP SP3 Build 2600.

Für die Grafikkarte (Geforce 4 Ti) nutze ich den Windows Treiber und für den Chipsatz ist der letzte offizielle (v5.10) von Nvidia installiert. Sonst nichts weiter. Ich hab außerdem spaßeshalber mal im Gerätemanager den eingebauten Speedtest für die HDD laufen lassen (Gerätemanager -> IDE Controller -> Nvidia -> Eigenschaften -> "channel" tab -> Speedtest bei der Platte drücken) und komme auf 66mb/s Burst und 38mb/s Sustained. Vielleicht kannst du damit was anfangen?
 
82mb/s burst / 58,3mb/s sustained. Chipsatztreiber nutze ich immer die Version v5.10. Seit gestern zufälliger weise auch eine neu erworbene Geforce4Ti (ASUS v8420). Da habe ich die nVidia Treiber 93.71 genommen.

EDIT: Windows Version müsste auch die selbe sein.
 
Zuletzt bearbeitet:
Auf archive.org lässt sich ein MicroXP v.082 SP3 finden. 200MB nach der Installation. 28-MB Ram Verbrauch. 20 aktive Services gegen >100 vanilla.

Bringt es eigentlich nicht schon einen Boost, wenn man SuperPi von einem schnellen USB-Stick laufen lässt?
 
Gute Frage. Ich vermute, der USB Bus wird das Problem. Ich habe es aber noch nicht mit einem schnellen Stick probiert.

auf der SSD geht Pi jedenfalls schneller. Mit der HDD komme ich nicht an Tzk's Zeiten. komisch. Mit der SSD könnten die Zeiten passen.

@Tzk blöde Frage, hast du vielleicht eine hybrid Festplatte?

EDIT: hat sich erledigt. mit der SSD sind meine Zeiten anscheinend schneller. :fresse:

EDIT2: Da stellt sich mir die Frage, in wie weit die Werte bei superpi überhaupt vergleichbar ist. :fresse: Bei loop 8 bin ich schon ca.7 sec. schneller. Die Festplatte macht hier den Hauptunterschied.
 
Zuletzt bearbeitet:
Meine Test HDD ist eine 2.5" 120gb von 2006... Die sich ganz sicher keine Hybrid :fresse2: Was das System ansich angeht, könnte man sogar mit Win98 benchen. Oder mit Server 2003. Auf letzteres haben die Japaner iirc früher gesetzt, da es minimal schneller sein soll. Ansonsten hab es noch ein spezielles BenchOS von Xtremesystems, das hiess XSOS v2.02. Blöderweise hab ich die ISO verloren und man bekommt es nirgendwo mehr (Copyright...). Das war ein auf 40mb Ramverbrauch abgespecktes WinXP oder 2000.

The Sandman schrieb:
Bringt es eigentlich nicht schon einen Boost, wenn man SuperPi von einem schnellen USB-Stick laufen lässt?
Zum Vergrößern anklicken....
Nein, nicht wirklich. Wir haben ja nur USB2.0 und selbst mit einer USB Einsteckkarte gehen nur 66mb/s (PCI Bus Limit). Da lohnt eine SSD viel mehr. SATA kann 150mb/s und über IDE gehen maximal 133mb/s, wenn alles mitspielt (IDE/SATA Konverter und SSD).

Weitere Alternativen: Ramdisk oder Ramdrive (SATA mit Ram als Speicher). Letzteres sollte auch gut helfen.
 
Die in deinem Link beschriebenen Windows Tweaks helfen übrigens wirklich. Kann ich nur empfehlen... :d Copywaza und so Scherze hab ich dagegen nie genutzt.
 
Ich würde ja vllt. auch ein wenig mitspielen, aber dann nur auf dem NF-7. Ist aber auch schon wieder lame, wenn nur mit dem "langsamen" Bios 240-MHz laufen. Wenn I.nfrA.ed mal wieder hier ist, sollte man ihn mal bezüglich diesem Board ausquetschen. Unsere Quote beim max. FSB auf Abit ist erstaunlich schlecht. Sein Board nimmt ja den Vmod an. Vielleicht gibt es wirklich golden samples oder bestimmte Produktionsdaten. Die Jagd wäre dann aber sicherlich wieder eröffnet.
 
Du kannst auch mal sein "X1" Bios testen. Hat er auf der Bierbude hochgeladen: http://bierbude.spdns.org:2302/USER UPLOADS/I.nfraR.ed/Abit/NF7 v2.0/

Das sollte recht schnell sein und viel FSB erlauben. Ansonsten kristallisiert sich derzeit raus das die ED Romsips von Merlin aus dem Taipan Bios tatsächlich vergleichsweise schnell sind. Von daher bist du nicht sooo weit mit der Performance weg.
 
@Tzk dein OS ist schneller als meins. Mit einer HDD kann ich nicht mithalten. Die SSD ist deutlich schneller als meine HDD. Mit den DD romsips bekomme ich mit der SSD 39m 03,469s.
Was mir auffällt, ich verliere am Anfang viel Zeit bei Pi.
 
Ich schaue gleich mal nach, ob ich nicht doch bereits die oben verlinkten SuperPi Optimierungen gemacht habe... Nicht das mir das entfallen ist. Kann ja eigentlich nicht sein das mein System so viel besser läuft...
 
Some more results from my side. Most of the bioses seem to be in 38m 33s range, with ED-based dropping around 6 seconds.

My X1 bios which seems very similar to one of the trats bioses I tried

screen612.jpg

ED bios from @digitalbath
screen615.jpg

Same ED bios from above, but with the current best register values I'm using (I may have better ones soon)
screen616.jpg

Same as above with tighter timings
screen617.jpg

ED bios required higher VDD, until I changed the ROMSIP registers (3rd and 4th image). Not sure which value helps most though.
Even if two bioses have similar/same values for the exposed registers, there might be a big difference in performance, so some of the other values in the ROMSIP tables give a big boost.
We have to find which ones...

PS: I could not POST at 8.5x260 with the bios from @digitalbath, while 8x260 worked.
All multipliers work on mine, but I haven't compared multiplier table yet.
 
Zuletzt bearbeitet:
@I.nfraR.ed
ED romsips should be Merlins ED romsips. I have no glue why multiplier 8,5 works worse. Looking in the multiplier table, both looks the same.
6941 2100 00ED 1618 vs. 6941 2200 00ED 1618 Interface aggressive
2141 2100 00E4 1618 vs. 2141 2200 00E4 1618 Interface normal
The difference 21 vs. 22 relies on the multiplier, the timings are the same.

As far as I noticed, changes in the exposed register 66+68+6F helps most to get a better stability. But there are more values in the romsips we have to find out. Trats 619r2 romsips has different unexposed values as ED for example (MantaRaysXT also). Maybe it is worth to compare both.

nice results!
 
Zuletzt bearbeitet:
Maybe it's just a matter of luck. I've noticed PCB version 0.53 works best for me. It's modded for VDD and also has an external regulator for the memory.
Can't tell the markings on the chipset right now since it is running, but maybe I can get them for all my boards in the weekend.
I have one "dark brown" NF7 that can't do much more than 250 with same components as the 270 ones. I've also had a board that worked best at 1.4 - 1.5V VDD.
Also had one that scaled up to 2.4V VDD.

My theory about VDD is that Southbridge is connected to the same power rail and runs at the same VDD voltage, while on DFI Ultra/Infinity you can control it independently.
Perhaps that's why it usually gets even worse with higher voltage. Might have to sacrifice one board and try to power the SB separately.

Another thing I realized recently is that DIMM slots on the DFI are enumerated differently than on my NF7. Maybe they are connected in a different way.
 
Zuletzt bearbeitet:
It's an really odd behavior if lower volts result in higher frequency/stability. Kinda like Samsung TCCD in some cases. Where did you check the revision? Never found some marking like 0.53 on mine. According to the DFI you mean that you can controll it with mods, since there's no such option in the BIOS for the SB, right? But yes, would be nice if you could share some intelligence with us. thnx :bigok:
 
Ich habe alle Ergebnisse (bei Post #2.253) bei 32M neu erstellt. Durch die SSD sind die Ergebnisse eher vergleichbar. Trotzdem ist mein Windows XP langsamer als von Infrared/Tzk. Mein bisher bestes Ergebnis:

1588188651469.jpeg
 
I.nfraR.ed schrieb:
Maybe it's just a matter of luck. I've noticed PCB version 0.53 works best for me.
Zum Vergrößern anklicken....
The Sandman schrieb:
Where did you check the revision? Never found some marking like 0.53 on mine.
Zum Vergrößern anklicken....
Found my PCB revisions. It's on the backside of the PCB, where the PS2 connectors for keyboard and mouse are soldered. My 250FSB Board got V0.52 and my "crap" board got V0.51.

Picture of the NF7 backside with Revision marked on the top right corner (IO panel). The cpu socket and chipset is also visible to make locating the revision a bit easier for you.

IMG_20200430_074420.jpg


I.nfraR.ed schrieb:
ED bios required higher VDD, until I changed the ROMSIP registers (3rd and 4th image). Not sure which value helps most though.
Even if two bioses have similar/same values for the exposed registers, there might be a big difference in performance, so some of the other values in the ROMSIP tables give a big boost.
Zum Vergrößern anklicken....

Yes, i also noticed that the exposed romsip registers seem to have a huge effect on stability and bandwidth. Testing was very easy with digitalbaths romsip settings in bios. Now that you made the new tweaker, we can probably test different registern on windows and check stability and 32M. Maybe we can find an even better (like more stable and faster) setting.

@WMDK @stunnedguy
Könnt ihr beide mal bei euren NF7 die revision checken? Bin gespannt was wir zusammentragen können :)
 
Zuletzt bearbeitet:
Anmelden, um zu antworten.

Ähnliche Themen

R
Lesertest Be Quiet! Dark Rock Pro 5
Antworten
0
Aufrufe
745
_roman_
R
R
[User-Review] Lesertest zur Synology DiskStation DS224+
Antworten
0
Aufrufe
6K
_roman_
R
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh