dann Verwendest du ein komisches Betriebssystem und Browser.
http://www.xin.at/x265 nutzt kein SSL.
Der Fehler sollte wenn überhaupt bei SSL eintreten. Also bei https://www.xin.at/x265
dann Verwendest du ein komisches Betriebssystem und Browser.
http://www.xin.at/x265 nutzt kein SSL.
Der Fehler sollte wenn überhaupt bei SSL eintreten. Also bei https://www.xin.at/x265
Verwende Windows 11 22H2 und Edge, also nichts Komisches. Mit http geht es, mit https nicht.
Zum Verbindungsproblem
Dieses Verhalten bzgl. HTTPS ist mittlerweile völlig normal und nichts außergewöhnliches mehr, ich hatte es früher im Thread schon Mal erwähnt. Das übersieht man natürlich, weil kein Mensch wird alle Seiten lesen.
Grund, Kurzfassung (fast): Der Server der XIN.at serviert ist ein Homeserver und er ist in der Zwischenzeit antik, wahrscheinlich der letzte seiner Art, der weltweit noch in Betrieb ist. Der gehört in Wahrheit eigentlich in's Museum. Damit geht einher, daß Teile der Serversoftware auch antik sind. Für einige Dienste ist es mir gelungen, neuere Softwarekomponenten von Quellcode auf das alte System zurückzuportieren (Darunter auch OpenSSL für SSL/TLS). Leider klappt das nicht so easy mit dem Webserver, auch wenn ich's sehr gern hätte. Da bräuchte man wohl ein ganzes Entwicklerteam dafür.
Der Webserver bietet schon optionale Verschlüsselung via HTTPS an, allerdings nur alte Protokolle (SSLv3, TLS 1.0) und Cipher sowie Hashes. Moderne Browser unterstützen das entweder gar nicht mehr (Chromium) oder nur mit manueller Rekonfiguration der fortgeschrittenen Einstellungen (Firefox). Das SSL Zertifikat jedoch ist von Let's Encrypt und gültig. Wenn man hier nichts verstellen oder gar den Browser wechseln will - was ich einsehe - muß man einfach HTTP nehmen. Leider ist HTTPS heute für diverse Browser die Standardeinstellung, d.h. wenn der Server HTTPS anbietet, dann versucht der Browser auch nur das, schlägt fehlt und gibt auf.
Ich habe auch schon einen freien, professionellen Entwickler drauf angesetzt den kompletten Stack zurückzuportieren, aber der Brocken ist denke ich einfach zu groß, um von einem Einzelnen nebenher erledigt zu werden. Auch wenn er ein bereits erfahrener Backporter für solch alte Plattformen ist.
Ich bitte das zu entschuldigen, aber aktuell bin ich technisch nicht in der Lage, modernes TLS / HTTPS über'n Webserver anzubieten.
Zum Crash
Wenn du den Benchmark irgendwie zum Versterben zwingst, kann es schon sein, daß er Fehler erzeugt. Auch wenn ich den deinen noch nicht kenne. Aber ich habe auch noch keinen gezielten Abbruch auf Windows 11 versucht.
Macht aber nichts weiter. Du kannst den Test in einen sauberen Zustand zurückversetzen, indem du ihn entweder einfach löschst und neu entpackst, oder im Benchmarkverzeichnis auf einer cmd oder Powershell Kommandozeile folgendes Kommando ausführst: .\lauch_x265benchmark.bat /x
Sollte dann ca. so aussehen:
X:\x265benchmark>.\launch_x265benchmark.bat /x
launch_x265benchmark invoked at 11:00 on 12.12.2022!
Running initial checks:
colorecho............................. OK [`.\bin\colorecho.exe`]
VC++ 2015/2017 runtime libraries...... OK ['C:\WINDOWS\System32\MSVCP140.DLL']
NOTE: `.\bin\colorecho.exe` and VC++ 2015/2017 x64 redistributable
detected, switched to color output on the terminal.
Cleaning up...
DONE
Press any key to continue . . .
Alles anzeigen
Alle weiteren Optionen siehst du mit .\lauch_x265benchmark.bat /?
Sag ich doch, komischer Browser und komisches Betriebssystem
So ein Mist!
Wie es aussieht, werde ich die 10 h Marke mit dem CenTaur unter Windows 11 wohl um 10 min verpassen...
Seltsamerweise läuft das System unter Windows 11 im Gegensatz zu openSUSE Tumbleweed völlig stabil. Nicht ein Systemabsturz während des Benchmarks oder sonstiger Spielereien bisher.
Da muß ich wohl noch einmal an der Taktschraube drehen...
Die 10 h unter Windows 11 mit dem CenTaur sind gefallen:
9h 46m 59,708 sec
War sonst alles gleich wie beim letzten Ergebnis von der Maschine? Bzw. RESULTS.txt?
Danke!
Nein. Gib mir noch 2 Tage und bekommst Du die vollständige Ergebnisliste - sollten 6 Stück werden - inkl. Results.txts. Dann kannst Du alles en block im Burstmodus eintragen oder das, was Dir interessant erscheint, einzeln rüberschieben.
P.S. Vielleicht wären 3 Tage und 7 Ergebnisse sogar besser. Dann könnte ich den Linuxlauf von oben nochmal mit denselben Einstellungen unter Windows 11 wiederholen und hätte dann auch die Latenzzeiten für den RAM, die ich unter Linux ja nicht auslesen konnte. Oder reicht Dir da einfach ein CPU-Z Report unter Windows 11 mit denselben Einstellungen ohne Extralauf.
Wenn das unter Windows und Linux gleich eingestellt ist, dann ist das völlig okay mit einfach einem CPU-Z Report. Ich hätte einfach nur gerne einen so vollständigen Report wie es halt geht. Einfach alles klar und deutlich raushauen, damit ich die Ergebnisliste entsprechend vollständig aktualisieren kann!
Dank dir!
Ich hätte einfach nur gerne einen so vollständigen Report wie es halt geht. Einfach alles klar und deutlich raushauen, damit ich die Ergebnisliste entsprechend vollständig aktualisieren kann!
Das ist gar nicht soo leicht, wie Du Dir das vorstellst. Ich hab schon vor einer Woche festgestellt, daß das BIOS und CPU-Z unter einem gewissen Umstand nicht dieselbe RAM-Geschwindigkeit anzeigen. Daher brauche ich noch einen zusätzlichen Referenzlauf, um entscheiden zu können, wer von beiden bei der Taktung Recht hat. Bei den Timings kann ich das (noch) nicht mit Sicherheit feststellen. Zu dem Ganzen gibt es noch ein gesondertes Thema. Somit bleibt es dann doch bei 7 Ergebnissen in 3 Tagen...
Wäre der Systemfirmware im Falle so exotischer Hardware nicht eher zu vertrauen als CPU-Z? Weil CPU-Z kann ja mit so mancher sehr alter oder sehr exotischer Plattform hin und wieder Mal nicht richtig umgehen. Habe ich selbst auch schon erlebt, auch wenn der Entwickler (Frank Delattre) da sehr motiviert ist, auf Userfeedback entsprechend zu reagieren.
Dem würde ich in Anbetracht der Zwischenzeit nach dem ersten Durchgang zustimmen. Aber ich will ja
1. sicher sein und
2. interessiert mich das Ergebnis auch im Vergleich zu Maniac81s Wert.
Nachtrag der Speichertimings hier.
Nachdem der Benchmark unter openSUSE Tumblweed ständig zum totalen Systemausfall führt und ich nicht wußte, wo ich mit der Suche anfangen soll, hab ich zunächst den
Crucial Ballistix DDR4-3200 w/XMP 16-18-18-36 1,35V
gegen
Micron VLP DDR4-3200 22-22-22-52 1,2V ECC unbuffered
ersetzt in der Hoffnung, der langsamere Speicher würde das System stabilisieren. Weit gefehlt! Die Probleme blieben. Ein Durchlauf klappte aber auch hier:
11:26:17.290s | Lotosdrache | 1/8/8 | CenTaur Technology CHA 2.00GHz | 2x 16 GiB DDR4 @ 2400-18-18-16-40-56-1T | Centaur Technology CHA001 Rev. D | Zhaoxin ZX-200 | openSUSE Tumbleweed 20221112 64Bit
RESULTS_SUSE_CPU_1_1V_2-0_GHz_auto__RAM_ECC_2-4_manual_SPD.txt
(auch hier wurden die Speichertimings wieder nachträglich unter Windows 10 21H1 mit CPU-Z bei ansonsten gleichen BIOS/CPU/RAM-Einstellungen ausgelesen)
Und ich weiß nun, daß unbuffered ECC auf dem Board läuft.
Danach bin ich dann zum aktuellen Windows 11 gewechselt. Das ging zwar wie erwartet im Schneckentempo zu Werke aber wenigstens lief es stabil.
Das Board unterstützt Intels XMP nicht. Da der Ballistix für seine schnellste Taktung jedoch nur eine Konfigurationstabelle in Intels XMP-Format zur Verfügung stellt, taktet die Autokonfig des UEFIs ihn nur mit 2666 nach einer der JEDEC-Tabellen. Beim ECC-RAM sieht das anders aus. Der unterstützt XMP nicht, sondern weist alles nur nach JEDEC-Standard aus. Damit wird er automatisch mit DDR4-3200 getaktet.
Es folgt nun die Suche nach dem schnellstmöglichen noch stabilen CPU-Takt bei RAM-3200 ECC:
12:12:54.815s | Lotosdrache | 1/8/8 | CenTaur Technology CHA 2.00GHz | 2x 16 GiB DDR4 @ 3200-22-22-22-52-2T | Centaur Technology CHA001 Rev. D | Zhaoxin ZX-200 | Windows 11 22H2 64Bit
RESULTS_Win11_CPU_1-1V_2-0GHz_auto__RAM_ECC_3-2_auto_SPD.txt
11:06:43.965s | Lotosdrache | 1/8/8 | CenTaur Technology CHA 2.00GHz @ 2,20GHz | 2x 16 GiB DDR4 @ 3200-22-22-22-52-2T | Centaur Technology CHA001 Rev. D | Zhaoxin ZX-200 | Windows 11 22H2 64Bit
RESULTS_Win11_CPU_1-1V_2-2GHz_FUSE__RAM_ECC_3-2_auto_SPD.txt
10:11:04.651s | Lotosdrache | 1/8/8 | CenTaur Technology CHA 2.00GHz @ 2,40GHz | 2x 16 GiB DDR4 @ 3200-22-22-22-52-2T | Centaur Technology CHA001 Rev. D | Zhaoxin ZX-200 | Windows 11 22H2 64Bit
RESULTS_Win11_CPU_1-1V_2-4GHz_FUSE__RAM_ECC_3-2_auto_SPD.txt
9:46:59.708s | Lotosdrache | 1/8/8 | CenTaur Technology CHA 2.00GHz @ 2,50GHz | 2x 16 GiB DDR4 @ 3200-22-22-22-52-2T | Centaur Technology CHA001 Rev. D | Zhaoxin ZX-200 | Windows 11 22H2 64Bit
RESULTS_Win11_CPU_1-2V_2-5GHz_FIDVID__RAM_ECC_3-2_auto_SPD.txt
Hierfür mußte die CPU-Spannung von 1,1 V auf 1,2 V angehoben werden.
Jetzt hab ich mich gefragt, warum mein System über 1 h 10 min schneller ist als das von Maniac81? Im Verdacht stand natürlich zunächst der höhere Speichertakt. Da ich auch noch wissen wollte, ob der Ballistix besser performt als der ECC-RAM, hab ich ab hier wieder den Gaming- -Speicher installiert.
Es folgt nun die (Nicht-)Skalierung mit dem RAM-Takt (Crucial Ballistix):
9:46:18.205s | Lotosdrache | 1/8/8 | CenTaur Technology CHA 2.00GHz @ 2,50GHz | 2x 16 GiB DDR4 @ 3200-24-24-22-52-2T | Centaur Technology CHA001 Rev. D | Zhaoxin ZX-200 | Windows 11 22H2 64Bit
RESULTS_Win11_CPU_1-2V_2-5GHz_FIDVID__RAM_Bali_3-2_manual_SPD.txt
9:46:47.765s | Lotosdrache | 1/8/8 | CenTaur Technology CHA 2.00GHz @ 2,50GHz | 2x 16 GiB DDR4 @ 2666-20-20-18-44-1T | Centaur Technology CHA001 Rev. D | Zhaoxin ZX-200 | Windows 11 22H2 64Bit
RESULTS_Win11_CPU_1-2V_2-5GHz_FIDVID__RAM_Bali_2-6_manual_SPD.txt
9:47:45.955s | Lotosdrache | 1/8/8 | CenTaur Technology CHA 2.00GHz @ 2,50GHz | 2x 16 GiB DDR4 @ 1600-12-12-12-28-1T | Centaur Technology CHA001 Rev. D | Zhaoxin ZX-200 | Windows 11 22H2 64Bit
RESULTS_Win11_CPU_1-2V_2-5GHz_FIDVID__RAM_Bali_1-6_manual_SPD.txt
Lange Benchmarks, kurzer Sinn
Der RAM-Takt war's nicht...
Dann dachte ich so bei mir, vielleicht hat M$ Windows 11 im Vergleich zum Vorgänger ja mal optimiert und beschleunigt. Also noch ein Versuch unter Windows 10 21H1:
9:46:24.660s | Lotosdrache | 1/8/8 | CenTaur Technology CHA 2.00GHz @ 2,50GHz | 2x 16 GiB DDR4 @ 2666-20-20-18-44-1T | Centaur Technology CHA001 Rev. D | Zhaoxin ZX-200 | Windows 10 21H1 64Bit
RESULTS_Win10_CPU_1-2V_2-5GHz_FIDVID__RAM_Bali_2-6_manual_SPD.txt
Das war's auch nicht.
Der letzte Gedanke war, daß meine Konfiguration mit 2x 16 GiB RAM schneller ist als Maniac81s 4x 8 GiB. Also noch den x264 laufen lassen, da der werte Kollege da auch 2x 16 GiB installiert hatte:
Aber auch dort ist mein System 8 min schneller. Stört mich jetzt nicht , aber ich wüßte schon gerne warum.
So bin ich etwas ratlos und schieb es entweder auf Windows und irgendwelche Treiber/Hintergrundprozesse, die ich nicht laufen bzw. abgeschaltet habe, oder auf unterschiedliche RAM-Module.
Noch nicht tätig werden, da kommt noch einiges. Ich schicke das zwischendurch nur ab und zu mal ab, damit ich nicht alles neu schreiben muß, falls ich mich verklicke oder sonst ein Unbill mir geschieht.
Ich denke, daß war's von meiner Seite aus zu diesem Thema erst ein Mal. Nach all den Sitzungen wandert das Teil bis auf weiteres in die Vitrine zu seinen CPU-Ahnherren.
P. S. GrandAdmiralThrawn Du solltest wirklich nicht alle Ergebnisse in Deine Liste übernehmen. Such Dir nur aus, was sinnvoll erscheint. Die RAM-Skalierung ist es definitiv nicht.
Ich glaub' das schau ich mir gemütlich am Wochenende durch.
Der Link zum "x265 Benchmark Ergebnisliste" ist offline.
Darfst kein HTTPS nutzen. Bedank dich dafür bei Gerald Hoden oder wie der hieß.
Oder bei mir und meiner weniger als stabilen Steinzeit-IT!
Mein Server ist einfach antik beyond recognition! Leider crashed der Webserver ehrlicherweise auch hin und wieder, wenn Botnets ihn angreifen. Spezifisch, wenn sie meinen Wordpress Weblog angreifen. Das ist Security by Sluggishness! Wenn zuviele Angriffe stattfinden, stirbt der Server entweder, weil er nichts mehr innerhalb sinnvoller Timeouts anbieten kann, oder es explodiert der Speicherbedarf des Webservers einfach jenseits der 32-bit Userspace Begrenzung von 2 GiB, was einen fatalen Crash bedeutet. Mein selbst geschriebener Watchdog kümmert sich zwar darum, aber hin und wieder erwischt ein Nutzer das schmale Fenster wo er noch nicht up ist. Oder es kommt zu einem fundamentaleren Crash, den mein (scheissiger) Watchdog nicht erkennnen kann. Eine diesbezügliche Optimierung steht noch aus, ich möchte die dafür nötige Software im Q1/2023 implementieren.
Das "HTTPS Everywhere" Bestreben von Let's Encrypt hat aber auch einen Eindruck hinterlassen. Server, die beides für eine Ressource anbieten (HTTP & HTTPS) werden in der Regel standardmäßig per HTTPS angeprochen; Das ist insofern ein Problem, als das mein Server nur TLS v1.0 mit sehr alten Ciphersuites und Hashing Algorithmen anbietet. Damit hat auch CryptonNite recht; Wer den Server ohne http:// Prefix bzw. Protocol Handler anspricht, wird wahrscheinlich nicht weit kommen. Ich habe zwar für mehrere meiner Serverdienste (FTP, Mail, IRC, usw.) meine selbst zurückportierte OpenSSL Bibliothek implementieren können, aber speziell beim Webserver ist die Lage extrem schwierig; Hierzu müßte der komplette WAMPS Stack von Quellcode neu gebaut werden. Das ist extrem schwer. Ich habe einen C/C++ Entwickler aus Slovenien darauf angesetzt, aber das Problem ist so massiv, daß hier keine baldige Lösung (oder irgendeine) zu erwarten ist.
Just retro things...
Lotosdrache : Habe drei Ergebnisse ausgewählt und eingetragen! Die nachgereichten Speicherlatenzinfos des vorangegangenen Ergebnisses habe ich ebenfalls nachgetragen, und noch ein paar (unwichtige) Dateneingabefehler nachkorrigiert.
Warum du so deutlich schneller unterwegs warst als Maniac81 ist mir aber auch ein Rätsel.
HellScream2 : CryptonNite's Kurzfassung trifft's. Einfach kein HTTPS nutzen, dann geht's. Wenn das auch nicht mehr geht, dann ist der Webserver wohl einfach grade im Arsch. Oder Google und Mozilla haben "HTTP" aus den Browsern rausgeworfen.
Wie schon im x264er geposted, unser neuer Qemu/KVM Hypervisor:
01:20:22.957 | 2/16/32 | Intel Xeon Silver 4314 2.4GHz | 256 GiB Reg. ECC DDR4/2666 | HPE ProLiant DL360 G10+ | Intel C621A Lewisburg | RedHat Enterprise Linux 9.1 (GCC 11.3.1)
Leistet echt nicht schwach das Zeug, wenn man bedenkt daß die Chips nur so um die 2.7 GHz gependelt haben!