Posts by GrandAdmiralThrawn

    Oh, I made a stupid mistake in my last post, thank you for ignoring my blunder. Corrected it! ;)


    As for the unofficial service packs: Others can tell. I never used them. We got this "Installing Windows 98 perfectly" thread by Tweakstone around here though, with lots of pictures, [see here]. It's really extensive and pretty step-by-step. Maybe it'll be of help for you. There he recommends a "Windows 98SE Service Pack 2.1e", but like I said, I never used any such pack on 9x.

    Diese Zählregister werden wohl für mich als Nutzer nur lesbar sein? Aber ist ja egal, ich schau einfach Mal rein mit pciconf oder unter Windows mit WPCREdit! Danke für die Recherche!


    PS.: Paar Euro würde ich für einen garantiert Fehler erzeugenden ECC DDR3 Stein direkt wirklich zahlen. Nur um sicher zu gehen. Weil bei der Herumexperimentiererei kann ich mir auch nie zu 100% sicher sein, ob es nur nicht geklappt hat, weil ich es vielleicht einfach falsch mache. Oder weil das so nicht reicht.

    Wenn er das machen könnte und würde, dann könnte er wahrscheinlich noch Solitär auf der Kiste spielen, aber sonst nicht mehr viel! :topmodel:


    CryptonNite : Das ist sogar etwas mehr als nur das eine oder andere Bild pro Sekunde, wenn man für deutlich mehr Speicherbandbreite sorgt. Ich habe das vor Jahren Mal mit ioquake3 auf einer Intel GMA950 getestet, und Single Channel mit Dual Channel RAM verglichen, ohne sonst etwas zu ändern. Das Ergebnis sah mit einer kurzen, selbst aufgenommenen Demo so aus:

    • ioquake3 1.36, Single Channel DDR-II/667 CL5, GMA950 @ 400MHz: 30.6 fps
    • ioquake3 1.36, Dual Channel DDR-II/667 CL4, GMA950 @ 400MHz: 41.2 fps


    Der GMA950 lief dabei auf maximaler Taktrate von 400MHz. Allerdings skaliert die Leistung auch mit dem Kerntakt, sobald man Mal Dual Channel RAM drin hat. Auch das habe ich getestet, leider nicht mit der exakt gleichen Demo, aber es kommt ca. hin:

    • ioquake3 1.36, Dual Channel DDR-II/667 CL4, GMA950 @ 200MHz: 30.6 fps
    • ioquake3 1.36, Dual Channel DDR-II/667 CL4, GMA950 @ 250MHz: 35.8 fps
    • ioquake3 1.36, Dual Channel DDR-II/667 CL4, GMA950 @ 400MHz: 42.6 fps


    Ohne Dual Channel aber bewegt sich bei den fps kaum was wenn man den GMA hochtaktet. Witzig, auch wenn's nicht exakt das selbe timedemo war: Der GMA950 @ 400MHz mit Single Channel RAM ist ziemlich genau so schnell wie der GMA950 @ 200MHz mit Dual Channel RAM!


    Natürlich ist das nicht 1:1 auf eine Vega umzumünzen, die Hardware ist ja zig Generationen auseinander, aber es demonstriert dennoch ziemlich gut die Abhängigkeit integrierter Grafiklösungen von der verfügbaren Hauptspeicherbandbreite.


    CPU war übrigens ein Core 2 Duo T7600 mit 2.33GHz und die getestete Auflösung war 1400×1050, ein HP nc6320 Notebook. Meine Tests mit mehr technischen Details [hier] (Zu "Edit:" runterscrollen, da sind die Testergebnisse) und [hier], wen's juckt.

    Zum RAM: Der Grafikchip braucht ja teilweise gigabyteweise Daten. Geometrie, Texturen, Framebuffer und so weiter. Da wird - wie CryptonNite völlig richtig sagt - permanent massiv hin- und hergeschoben. Eine GeForce GTX 780 Ti hat eine Speicherbandbreite von 336 GiB/s dafür und für nichts sonst. Wieviel Bandbreite zum System-RAM hat deine kleine Vega in der CPU noch, wenn man Mal das wegrechnet was die CPU schon für sich braucht?


    Ein einzelner DDR4/3200 Kanal bietet 25.6 GiB/s an theoretischem Maximum. Praktisch wird es natürlich weniger sein. Mit zwei Kanälen bist du da im äußersten Optimalfall bei 51.2 GiB/s. FALLS du überhaupt DDR4/3200 Dualchannel RAM drin laufen hast und nicht was langsameres. Am Ende hast wahrscheinlich real ungefähr ein Zehntel der Speicherbandbreite, und davon mußt du noch etwas für die CPU wegrechnen.


    Und das TDP-Limit... also wie man das übersehen kann.. aber gut. Jo, 250W für eine Grafikkarte gegen 15W für eine komplette CPU mit PCI Express Hubs, USB 3.x und Speichercontroller drin plus eine GPU. Die Rechnung kann nie aufgehen. 5-10W für die GPU wenn's hoch kommt. Dazu der massiv beschnittene Speicherdurchsatz, der zusätzlich zur fehlenden Bandbreite auch noch unter viel höheren Latenzen leidet als bei dediziertem VRAM.


    Und schon liegen offenkundige Gründe auf'm Tisch warum sowas nie gehen kann. Da müßte die CPU schon so 200W haben, und das kommt in einem kleineren Notebook ned so gut rüber. ;)

    Na klar kann ich das so einstellen, daß es gar nicht läuft, habe ich ja schon gesagt, aber das ist nicht die Idee dahinter. Die Idee ist es, ihn grade soweit instabil zu machen, daß ich tatsächliche ECC Korrekturen im Memtest 4.20 nachweisen kann...


    Worum es mir geht ist es zu testen, ob das ASUS P6T Deluxe nun wirklich ECC RAM kann oder nicht. Weil diese ganzen "brauchst nur dmidecode schauen"- oder "wenn dir Tool A das im Windows anzeigt wird's schon da sein"-Beiträge, die man überall im Internet findet kann man leider komplett und vollständig vergessen bei dem Thema. Und den kommerziellen memtest kann man leider gleichsam in die Tonne treten was das auf X58 oder sonstigen BIOS Systemen angeht.

    Neuerdings ist ein Typ auf mi zugekommen, der einen PC Emulator entwickelt, und jetzt der Meinung ist (aus welchen Gründen auch immer) die i450GX Quad Socket 8 Plattform darin unterstützen zu müssen. Da er grade versucht, den BIOS Chip zu emulieren, habe ich den der AP450GX Referenzplatine (gelogen: Ist in Wahrheit die Platine des IBM PC Server 704) fotografiert...


    Brutal uninteressantes Foto (Klicken zum Vergrößern)


    Jetzt weiß ich wenigstens, wo auf der Platine die Schreibschutzjumper für's BIOS sind.

    Deltas sind so wie manche Papst Modelle (Der 612NGHH läßt grüßen) besonders für zwei Dinge wohlbekannt: Viel Leistung und noch viel mehr Lärm! Ein Delta mit noch mehr Bauhöhe ließe auf noch und nöcher mehr Leistung und todbringenden Lärm schließen. Wahrscheinlich kannst mit dem Teil Mal wieder Bleistifte häckseln. ;)

    Unterdies hier noch'n Test meiner Ersatzhardware. Im Gegensatz zum x265er habe ich hier die Latenzen reduziert. Gedacht war das als Versuch in Memtest86+ 4.20 ECC Fehler zu provozieren, um das tatsächliche Funktionieren von ECC zu verifizieren. Leider ergebnislos. Je nach gewählter Schärfe booted er entweder gar nicht, oder mit fehlenden Sticks, wo er nur 16-32 GiB von 48 erkennt. Oder er booted normal und ist dann aber leider scheinbar auch komplett stabil, so wie mit dieser Einstellung hier, wo vorher Memtest tagelang fehlerfrei durchgelaufen ist:


    00:43:28.113 | GAT | 1/6/12 | Intel Xeon X5690 3.47GHz | 48GiB ECC DDR3/1333 8-7-7-20-2T | ASUS P6T Deluxe | Intel X58 Tylersburg | FreeBSD 13.0 UNIX (Custom clang 11.0.1 x64 Build, r3081)


    Ich krieg keine Speichereinstellung hin, die auf wackligen Beinen stehen würde... ein Wahnsinn, so schwer kann das doch nicht sein, ihn nur "ein Bißchen" instabil zu machen? :topmodel: Die tatsächliche Verifizierung der ECC Funktion gestaltet sich überraschend schwierig, nachdem man sich auf die Infos vom DMI nicht verlassen kann. ECC Error Injection funktioniert ja mit'm kommerziellen Memtest auch nur unter UEFI, und auch da fast nirgends. Und das hier is noch ein BIOS System...


    Najo, als ungewolltes Nebenprodukt weiß ich jetzt, das der RAM auch mit deutlich schärferen Latenzen läuft, und mit mit welchen genau.

    Das ist aber (denke ich) auch mehr ein Glücksspiel. Hank Semenec meinte damals vor der Reparatur meiner Karte, daß dieser Fehler die Brücke so schnell durchheizt, daß kein Kühler den man draufsteckt das wegbekommen kann. Das legt nahe, daß man als Mensch vielleicht gar nicht schnell genug würde reagieren können, um die Karte im auftretenden Fehlerfall noch zu retten.


    Die Brücke die Anthony verlötet ist denke ich dasselbe, nur unter PLX Banner, die Firma die die HiNT Corp. übernommen hat. Zum Thema Fehlerbereinigung und Anfälligkeit müßte man Anthony einfach direkt fragen. Grade diese Information sollte doch zu bekommen sein? Wobei ich mich frage (ich weiß es wirklich nicht), ob der tatsächliche Fehler in der Brücke oder nicht doch eher sonst irgendwo in der originalen 6000er Karte liegt.


    1986richie : Wird wohl abgebrannt sein, aber nur um sicher zu gehen: Probier's halt noch Mal im Chaintech 7VJL, in dem sie schon funktioniert hat.

    Aus dem recht frisch auf den PC portierten "God of War":


      

    Von im Wald wohnenden Hexen wird scheinbar das Laub rot (Klicken zum Vergrößern)!


    Die Portierung ist recht gelungen würde ich Mal sagen. Nagt zwar auf maximalen Details ein wenig zu sehr an der Grafikkarte bei 2560×1600, aber okay... ich kann damit leben. Habe mich auch kurz mit der Implementierung von AMD FidelityFX SuperResolution in dem Spiel herumgespielt, aber da wird nVidia DLSS wohl doch einen Tick besser sein; Selbst auf "Ultra Quality" sieht man stellenweise noch eine leichte Unschärfe bei aktivem FSR. Aber gut, das schaltet man auch nur ein wenn man nicht genug Grafikleistung hat. Dann ist es wohl zu verschmerzen.

    Habe entgegen deines Wunsches beide eingetragen. Meine Begründung ist hier einfach die, daß das langsamere ein "normales" darstellt, also ohne winterliche Spezialumstände. ;) Das andere habe ich mit einem Link zu deinem Beitrag versehen, eben weil es so nicht ganz typisch ist.


    Zu den Timings: Könntest noch versuchen im neuesten CPU-Z den Report in eine .txt Datei zu speichern. Unten im "Tools" Dropdown, "Save Report as .TXT". Vielleicht steht's da doch wo drin. Ansonsten weiß ich auch nicht sicher wie man an die Latenzen käme.