Beiträge von julian-w

Zitat von mainziman

dann zeige mal Deine Single-Thread-Workload ...

Hab ich doch: es handelt sich um den HeavyGate Benchmark. Unter Linux "yes" und das "stress" Tool.

Zitat von mainziman

erklär mir nicht das wäre fehlerhaft;

Ist es aber leider, was soll ich sagen... für dich kann ich ja schlecht die Fakten verdrehen...

Hohe Last soll man nie, nie, niemals im "GUI" Thread bzw. im interaktiven Thread zur Benutzer-Maschine-Kommunikation (main-Function) laufen lassen, aber genau das tust duUnd das ist der große Fehler, eigentlich lernt man das doch von Anfang an, bei einer GUI merkt man ja direkt das dann schlichtweg nichts mehr geht. Deine Shell dürfte aber auch recht träge werden, da sämtliche Last im "interaktiven User Thread" läuft. Da am Shell-Prozess ganz viel dran hängt, kann so ein Thread nicht gut gescheduled werden, somit ist schlichtweg dein Code fehlerhaft. Schau dir mal den Code von Linux "stress" an (https://people.seas.harvard.edu/~apw/stress/) den ich oben benutz habe, der hat einmal die main-function, macht aber für jede "100%-Last" einen eigenen Thread auf und wartet im main nur auf das terminieren der Child-Threads, die 100% Last erzeugen. Die main-function selbst erzeugt keine Last.

Es gibt auch einen "Windows-Port" hier (https://github.com/RichardKav/Stress-for-Windows), der erzeugt auch die Last in externen Threads.

Wenn du deine Last in einen externen Thread auslagerst und in der main-function wartest bis diese terminiert (natürlich nicht busy-waiting), dann sollte das klappen, kann das nachher mal selbst testen und deinen Code korrigieren. Aber die main-function für 100% Lasten zu missbrauchen ist nie gut.

Zitat von mainziman

vmk das Hin- und Hergeschubse ist bei Win10 immer noch gegeben;

ob der HT dabei berücksichtigt oder nicht spielt da keine Rolle;

Bei deiner Workload die keiner kennt, vielleicht ist es ja gar keine Single-Thread Last, sondern eine Endlosschleife im Terminal was sich auf bis zu 3 Threads verteilen kann Und natürlich spielt HT eine Rolle, du würdest dich bedanken wenn Windows die CPU-lastigen Threads auf einen HT-Core legen würde während die anderen nichts tun

Zitat von mainziman

ergo sind wir wieder dort, bei meiner Aussage, der Scheduler von Windows zählt nicht dazu ...

über den von Linux kann ich keine Aussage treffen;

Unter Linux ist es das gleiche: der einfache Befehel "yes" der einfach nur "Y" in Endlosschleife ausgibt wird ebenfalls, wie deine Workload unter Windows, hin und her geschubst (da er nicht weiter optimiert ist vermute ich mal, warum auch):

pasted-from-clipboard.png

Ein "richtiger" Stresstest mit "stress" wiederum funktioniert einwandfrei, dieser bleibt auf einem Kern:

pasted-from-clipboard.png

Der Scheduler kann ja nichts dafür, wenn der Benutzer ihn falsch benutzt

Zitat von mainziman

julian-w dich holt tatsächlich die Vergangenheit ein;

Eher dich die Settings (oder irgendwelche Steinzeit Benchmarks von Win98-Zeiten). Die meisten Benchmarks laufen mit "niedriger als normal", was oftmals zu deinem Verhalten führen kann. Kein Wunder, du sagst dem Scheduler "ey lass das mal laufen, aber ist nicht so wichtig, alles andere ist wichtiger"... warum sollte der Scheduler dann einen kompletten Kern reservieren!? Sobald man die Benchmarks mit "normal" oder höher als Priorität laufen lässt, erscheint oftmals folgendes Bild (HeavyLoad Benchmark, mit einem "Kern", nur einen "Core" gibt es leider nicht als Settings, aber er benutzt ja ganz korrekt nur einen Kern):

pasted-from-clipboard.png

Genau was du erwartest, kein gestupse oder sonstiges. Er nutzt sogar die zwei Threads eines physikalischen Kernes, macht also alles korrekt. Das Problem was du Andeuten willst existiert so nicht. Das tritt einzig und allein auf wenn die Workload "falsch" initialisiert worden ist, und für fehlerhafte Infos kann der Scheduler nichts, Fehler von Benutzer ausbügeln kann er noch nicht

Ein simple Endlosschleife in eine Batch-File funktioniert z.B. nicht, weder unter Windows/Linux noch sonst einem mir bekannten System.Eine korrekt angelegte Single-Thread Workload klappt ohne hin- und hergestupse unter Windows und Linux, gerade selbst getestet.

Ich meine mich auch düster an die "Operating Systems" Vorlesung zu erinnern wo genau das erwähnt wurde was ich oben schon gesagt habe: der Scheduler weiß nicht wie viel CPU-Zeit ein Thread in Zukunft brauchen wird, daher weiß er nie ob es Sinn macht ihm einen ganzen Kern "zu opfern", könnte ja sein das plötzlich noch 10 andere Threads kommen die auch CPU-Zeit wollen oder der Thread danach beendet oder ein Thread mit höherer Priorität viel CPU-Zeit will oder oder oder... und da der Scheduler-Code so klein wie nur möglich sein soll (da unzählige Male pro Sekunde ausgeführt), kann man da nicht ganz so wild spekulieren. Wenn man dem Scheduler aber seine Wünsche mitteilt (eine Zeile Code), werden die unter Windows und Linux berücksichtigt. Eine eierlegende Wollmilchsau ist es halt nicht

Zitat von mainziman

so sieht die Definition der CPUs am Host f. die VM aus

Um welche Software zur Virtualisierung handelt es sich denn hierbei? Das sieht irgendwie nach WinXP oder davor aus, also eine ältere Software? Oder benutzt du nur gerne den alten Stil unter Windows

Und das der Gast keine HT-Cores sieht ist doch logisch, es sind ja schließlich keine eingestellt im Hypervisor soweit man das dem Screenshot entnehmen kann.

Aber irgendwie passen deine Coreinfo ausgaben überhaupt nicht, hier das ganze unter Windows 10 x64 mit einem Core i5-4771 (4 Kerne + HT):

Logical to Physical Processor Map:
**------  Physical Processor 0 (Hyperthreaded)
--**----  Physical Processor 1 (Hyperthreaded)
----**--  Physical Processor 2 (Hyperthreaded)
------**  Physical Processor 3 (Hyperthreaded)

Logical Processor to Socket Map:
********  Socket 0

Logical Processor to NUMA Node Map:
********  NUMA Node 0

No NUMA nodes.

Logical Processor to Cache Map:
**------  Data Cache          0, Level 1,   32 KB, Assoc   8, LineSize  64
**------  Instruction Cache   0, Level 1,   32 KB, Assoc   8, LineSize  64
**------  Unified Cache       0, Level 2,  256 KB, Assoc   8, LineSize  64
********  Unified Cache       1, Level 3,    8 MB, Assoc  16, LineSize  64
--**----  Data Cache          1, Level 1,   32 KB, Assoc   8, LineSize  64
--**----  Instruction Cache   1, Level 1,   32 KB, Assoc   8, LineSize  64
--**----  Unified Cache       2, Level 2,  256 KB, Assoc   8, LineSize  64
----**--  Data Cache          2, Level 1,   32 KB, Assoc   8, LineSize  64
----**--  Instruction Cache   2, Level 1,   32 KB, Assoc   8, LineSize  64
----**--  Unified Cache       3, Level 2,  256 KB, Assoc   8, LineSize  64
------**  Data Cache          3, Level 1,   32 KB, Assoc   8, LineSize  64
------**  Instruction Cache   3, Level 1,   32 KB, Assoc   8, LineSize  64
------**  Unified Cache       4, Level 2,  256 KB, Assoc   8, LineSize  64

Logical Processor to Group Map:
********  Group 0

So in etwa sollte das bei jedem Core iX-XXXX aussehen der Hyperthreading unterstützt. Bei dir sieht es halt komplett anders aus.

Am Host sind die Caches nicht korrekt zugeordnet, zu den CPUs gibt es gar keine Infos, und im Gast kommt eh nur noch einzelne Dinge an. Kein Wunder das der Task-Manager da keinen korrekten Wert finden kann. Irgendwas läuft da schief bei dir

Edit: Dein Host meint das alle Caches von allen CPU-Kernen direkt zugegriffen werden können, daher kann der auch munter Threads zwischen den CPU-Kernen verschieben Und laut Dump hast du nur einen physikalischen Kern der 8 Hyper-Threading Kerne simuliert oder sowas in der Art...

Zitat von mainziman

damit wird in der VM sehr wohl die Info zum Cache und so angezeigt,

Bei dir im Screenshot sehe ich nur "nicht zutreffend" (ich vermute mal das soll es heißen). Von daher werden die Infos wohl nicht ganz korrekt angezeigt an der Stelle wo sie es sollten.

Zitat von mainziman

es werden damit 8 physikalische Einzel-CPUs angezeigt an Stelle von einer CPU mit 8 Cores (4 HT Cores)

Das klingt aber eher so als ob die Virtualisierung da was nicht ganz durchgibt. Ich kenne dein Setup nicht, von daher kann ich nichts weiter dazu sagen zu deinem Test. Nur soviel: von sich aus wird qemu/KVM oder sonstige Virtualisierungslösungen wie VirtualBox keine HT-Cores als "HT-Cores" durchreichen. Schon nur weil du mehr CPUs simulieren kannst wie der Host hast oder auch weniger durchreichst. Der Scheduler ändert dann je nachdem noch den Core und schwupp macht eine (automatische) Zuordnung keinen Sinn, und on-the-fly dem Gast die CPUs ändern ist eher eine schlechte Idee. Wenn man das ganze manuell per Hand einrichtet (CPU Pinning etc.) dann mag es möglich sein, weiß ich aber nicht. Bei VirtualBox hab ich noch nie eine Funktion zum anlegen von HT-Cores gesehen.

Von daher hättest du am besten die Ausgabe von Coreinfo gepostet, so ist das nur ein rätselraten was Windows hier erkennt, laut Screenshot nichts korrektes.

Zitat von mainziman

julian-w Multi-Threaded-Programme sollen SetThreadAffinityMask verwenden; SetProcessAffinityMask setzt dies f. alle Threads eines Prozesses;

diese sind dann aber was die Verwendbarkeit auf anderen System angeht eingeschränkt;

In deinem Beispiel ging es doch um Single-Thread Last oder täusche ich mich da? Von daher passt das doch (bzw. würde beides passen).

Zitat von killerbees19

Nur weil man Postfächer und Aliase anlegen kann, müssen diese ja noch nicht aktiv sein. Die Domain und alle damit verknüpften Einträge könnten erst aktiviert werden, wenn die Domain vollständig verifiziert ist. Das machen einige Anbieter so bzw. würde ich es so lösen, wenn ich dieses Feature brauchen würde.

Wenn Plesk das intern nicht unterstützt, wird netcup daran nur wenig ändern können. Außer es als Feature Request einzubringen.

Und genau das ist glaub ich der Punkt. Es gab schon mal einen Thread dazu und da war das genau der Knackpunkt wenn ich mich recht erinnere, also wenn es in Plesk eingerichtet ist, ist es für alle anderen Server direkt aktiv...

Zitat von mainziman

oder wie erklärst sonst obiges Bild?

Vielleicht einfach unsauber programmiert falls es wichtig ist das der Thread auf einem Core läuft bzw. dadurch tatsächlich mehr Performance bringt Windows unterstützt Core Affinitäten (SetProcessAffinityMask). die man zur Laufzeit setzten kann/soll/muss. Davon ab ist die Meinung dazu "der Scheduler weiß besser wie du was er macht, lass ihn seinen Job tun", Initial ging es auch eher darum ob es für Windows egal ist ob es ein HT-Core ist oder ein physikalischer Core, und genau darauf achtet Windows penibel (siehe Screenshot von vmk).

Davon ab hast du bei jedem Context-Switch den Fall das die Register meist geflusht und die L1/L2-Caches nutzlos werden, da ein anderer Thread meist einen anderen Code ausführt und auf einem anderen Daten-Bereich arbeitet. Daher macht es in den meisten Fällen wohl keinen großen Unterschied wenn der Kern getauscht wird (L3-Cache ist ja noch da), und da wo es wirklich einen macht kann der Programmierer das entsprechend mitteilen. Außer man teilt dem System explizit mit auf einem Kern nur einen Thread laufen zu lassen. Das kann der Scheduler aber schwer entscheiden, da er ja nicht weiß wie viel CPU der Thread im nächsten bzw. aktuellen Zyklus brauchen wird. Von daher wird erst mal alles "nach Prioritäten" verteilt, sodass jeder irgendwie irgendwann dran kommt. Jedem Thread der mal etwas CPU gebraucht hat direkt einen kompletten Core zu reservieren kann wohl schnell nach hinten losgehen, gerade unter Windows wo im Hintergrund unzählige Threads laufen die gerne auch mal etwas mehr CPU fressen, da will man nicht das die alle einen Core blockieren.

Falls es wirklich Sinn macht (und die Workload ist wohl eher selten, auf einem fetten Multicore System einen fetten Single-Thread Task laufen zu lassen) muss man dies halt von Hand festlegen, bzw einfach die CPU-Affinität so setzten das der Thread nur auf einem Kern laufen darf. Das ist bei dir wohl schlichtweg nicht der Fall.

Das ganze ist auch in Wiki schön erklärt: https://en.wikipedia.org/wiki/Processor_affinity

Wichtig ist aber das wenn 4 Cores (bei einer 4-Core CPU => 8HT-Core CPU) die mit 4 Threads zu 100% belastet wird, diese 4 Threads alle auf physikalischen Kernen laufen und nicht zwei zusammen auf einem HT-Core und das klappt so auch (siehe Screenshot vmk)

https://serverfault.com/questi…balanced-across-cpu-cores

https://superuser.com/question…thread-spread-across-cpus

https://docs.microsoft.com/en-…hread/multiple-processors

Zitat von mainziman

dich hat die Vergangenheit eingeholt,

Das bezweifel ich, ich komme hier nicht direkt mit Win3.11, DOS oder sonstwas an wenn mir etwas nicht passt bzw ich was als "nicht state-of-the-art" darstellen will Und wie du bei vmk siehst wird da nix wild durch die Gegend geschoben.Was du immer hier an Sonderfälle ranpackst wird es immer geben, dafür sind Systeme zu vielfältig, du findest sicher auch irgendein Exoten-OS wo heutzutage nicht mit HT umgehen kann.

Edit: das virtuelle hab ich auch überlesen, da der Scheduler dadurch keinerlei Informationen über CPU-Aufbau oder ähnliches hat (er kennt nicht mal den L1-Cache), ist das natürlich alles hinfällig und er "ignoriert" die Hardware, was will er auch sonst machen er weiß ja nichts über die Hardware

mainziman schwelgt halt gerne in alten Erinnerungen, anders kann ich mir den Exkurs zu WinG und Win3.1 im letzten Beitrag auch nicht erklären oder warum er immer mit so Urzeitsystemen vergangener Tage ankommt wenn er was allgemeines über den Task-Manager schreibt und dann mit WinXP ankommt. Damit rechnet man heutzutage nicht mehr

Aber wie vmk schreibt, alle Scheduler der letzten 10 Jahre (grob) können ordentlich mit HT umgehen und schieben auch keine CPU-lastigen Threads wild durch die Gegend. Sofern man ein halbwegs aktuelles OS betreibt, braucht man sich also darum keinerlei Sorgen machen

Zitat von mainziman

zum Windows Scheduler hat ThomasChr es schon gesagt; und das hat die Konsequenz, daß aus Sicht des Schedulers, der Core/Thread mit der niedrigsten Auslastung der beste ist, und schon wird, wenn nichts dagegen spricht 'geschoben' mit allen Konsequenzen

Aber gerade da wird doch erwähnt, das der Scheduler auf die Core-Konfiguration achtet: "taking into account [...] as well as the configuration of the multiprocessor system." Und vmk hat das ja noch passend ergänzt: "Windows XP and Windows Server 2003 are hyperthreading-aware."

Und das es Rechenkerne mit anderen Konfiguration gibt wie 2 logische Cores pro physikalischem Core ist ja erst mal egal, das ist halt nur der einfachste Fall. Von daher wird der Windows Scheduler vermutlich eher einen neune CPU-lastigen Thread auf einen zu 5% belegten physikalischen Core legen, anstatt ihn auf den "HyperThread-Core" eines physikalischen Cores zu legen, der zu 100% bereits ausgelastet ist. Erst wenn alle "physikalischen Cores" zu sind, macht es Sinn die HT-Cores zu nutzen (in den meisten Fällen). Okay die Benennung ist etwas doof, aber ich denke man versteht es

Zitat von mainziman

und das hat die Konsequenz, daß aus Sicht des Schedulers, der Core/Thread mit der niedrigsten Auslastung der beste ist

Nur vor Windows XP, ab dann nicht mehr Bei Linux finde ich gerade die Kernel-Version nicht

Zitat von mainziman

nicht mehr supported ist gut; zum Zeitpunkt als ich mir den Rechner kaufte gabs den Support noch;

Security is a Journey, Not a Destination

Zitat von JohnBoy

Das mag stimmen, dass Mails vonm netcup Mailserver direkt an das "neue" Postfach ausgeliefert werden, aber das ist ein eher geringes Problem - finde ich.

99,9% der Mails bekommen wir nicht von Natcup-Adressen

Das ist aber für netcup das größte Problem, da vermutlich das Briefgeheimnis etc.verletzt werden würde. Mit bösen Absichten könnte man da schon viel Unfug mit treiben. Und eben wie erwähnt, bei 50 Mitarbeitern plus lohnt sich vermutlich ein kleines managed Hosting auf dezidiertem Server, dort hat man all diese Probleme nicht Bei 50 Mitarbeitern macht das unter 1€ pro Mitarbeiter pro Mail, das sollte machbar sein

Und unter Linux gibt es passend dazu "CONFIG_SCHED_SMT" (SMT (Hyperthreading) scheduler support) als Konfigurationsparameter für den Kernel.

Von daher achtet jedes (halbwegs moderne) Betriebssystem schon darauf auf was für Kerne es läuft und erkennt einen Unterschied zwischen zwischen 8 physikalischen Kerne (ohne HT) und 8 logischen Kernen die nur auf 4 physikalische Kerne (dankt HT) abbilden. Und meist wird dies auch dem Nutzer direkt angezeigt bzw. man kann es abfragen

Zitat von mainziman

bei mir sieht es so aus

Konnte ja nicht wissen das wir hier von Systemen reden, die seit Jahren nicht mehr supported werden, zu der Zeit gab es glaub nicht mal Hyper-Threading (Win 2000 vermute ich mal)

Zitat von mainziman

der von Windows zählt hier nicht dazu

Warum nicht? Unter Linux gibt es auch Task-Viewer die das anzeigen, außerdem findet man das recht schnell in der Konsole raus Und der Scheduler ist sich bewusst wenn Hyper-Threading vorhanden ist, das zwei logische Cores auf einen physikalischen Core abbilden. Kann ja auch sinnvoll sein zu wissen was der Hyperthread-Core ist und was nicht, falls man z.B. CPU-Pinning oder ähnliches nutzt (gibt Fälle da sind zwei physikalische Cores besser, aber auch Fälle wo zwei Hyper-Threaded Cores besser sind die auf eine physikalische CPU abbilden, Caching etc.).

Zitat von mainziman

was sich dem Benutzer präsentiert hat dieser z.B. im Task-Manager keinen Unterschied ob es eine CPU mit z.B. 4 Kernen ohne HT od. eine Dual-Core CPU mit HT od. 2 Dual-Core CPUs ohne HT ist/sind ...

Das stimmt so aber nicht, im Taskmanager sieht man sehr wohl einen Unterschied

pasted-from-clipboard.png

Und die meisten Scheduler versuchen schon, wenn sie z.B. zwei Threads (von zwei verschiedenen Programmen) haben die viel CPU brauchen, diese auf physikalisch getrennte Cores laufen zu lassen und nicht auf einem zwei logischen Cores die auf einen Core abbilden.

Zitat von demlak

welches ich auch nicht unbedingt unmittelbar mitbekomme

Eigenes Monitoring schalten?

Zitat von demlak

Externer DNS hat auch immer die _Möglichkeit_ von MITM-Attacken. Hinzu kommen unnötige Datenspuren in Logs von externen Anbietern (Thema Datenschutz),

Was meinst du mit MITM? Das hast du doch immer, DNS-Abfragen sind auch (meist) nur unverschlüsselter, unauthentifizierter Traffic. Und Datenspuren hinterlässt du auch so, ich meine du willst ja deine IP weltweit bekannt und abrufbar machen, jeder kann diese loggen wenn er möchte, man muss einfach nur alle 5min eine DNS-Abfrage starten Viel mehr weiß dein DynDNS-Anbieter auch nicht, gut er kann noch den http-Header auswerten vom API-Call, da kannst du aber selbst bestimmen was du mit sendest.

Zitat von demlak

Wenn da Mist gebaut wird und/oder der Service eingestellt wird, hab ich ein (möglicherweise längeres) Problem

Naja bei DynDNS sollte die TTL sehr klein sein, von daher sollte das Problem nicht lange dauern, ein neuer Anbieter findet sich recht flott und ist i.d.R. superschnell eingebunden (egal ob Fritz!Box oder Linux). Und davon ab ist mir bei den "großen" Anbietern nichts wirklich bekannt, wie z.B. bei dyn.com

Zitat von JohnBoy

Wünschenswert in meinen Augen wäre es, wenn man direkt nach dem Kauf der Domain und vor der wirklichen Übertragung bereits mit der Einrichtung der Webseite und der Emails anfangen könnte.

Mit der Website wäre es noch möglich, E-Mails sind schlichtweg nicht möglich (oder nur mit zusätzlichem Aufwand, ich glaube Plesk unterstützt das aber nicht)

Folgendes Problem: angenommen du transferierst "gmail.com" zu netcup und sagst "jaja, Authcode liefere ich später nach, richtet als mal ein". Dann würden alle E-Mails, die vom Server an diese Domain versendet werden nicht mehr an diese Domain gesendet, sondern direkt lokal zugestellt, da der Server sich schon zuständig fühlt. Somit könntest du sämtlichen E-Mail Verkehr einer Domain innerhalb netcups abfangen.

gmail.com ist jetzt nur ein krasses Beispiel, aber im Grunde besteht das Problem bei jeder Domain die noch nicht zu netcup transferiert wurde: netcup weiß nicht ob du den Auth-Code noch liefern wirst und ob dir die Domain wirklich gehört. Bei gmail.com wäre es noch offensichtlich, bei anderen Domains halt nicht.

Zitat von JohnBoy

Gerade bei vielen Mailadressen und einer komplexen Webseite kan das sicher eine Weile dauern, in der evtl. Emails abgelehnt werden, weil die Mailadresse nicht existiert und die Leute nur eine "hier entsteht eine neue Webseite"-Seite sehen.....

Direkt ein Catch-All einrichten sollte das Problem lösen, danach muss man halt eventuell etwas nachsortieren. Und eine kurze "Website wird gewartet, schauen sie in 30min wieder vorbei"-Seite sollte auch nicht all zu tragisch sein, man wechselt seinen Hoster ja nicht jeden Monat

Davon ab könnte es auch noch Probleme mit der DNS TTL geben, je nachdem was dein alter Hoster da eingestellt hat kann es von dieser Seite aus auch etwas dauern bis ein Umzug überhaupt überall angekommen ist.

Könnte man in die Benachrichtigung E-Mails nicht den Spitznamen des Servers einfügen?

Mit diesem kann ich mehr anfangen wie mit der v22016XXXXXXXXXXXXX Nummer die mir meist gar nichts sagt. So muss ich immer nachsehen welcher Spitzname der Server hat um herauszufinden welches System jetzt neugestartet wird.

Zitat von H6G

Wie kann man sich den Typen denn freiwillig geben? Ist sein Server-Raum noch nicht abgefackelt?

Warum sollte der abfackeln? Er hat doch extra in einem Video gezeigt das sein "Dämm-Material" nicht brennbar ist, war glaub sein Aprilscherz Finde ihn ansonsten auch ganz unterhaltsam.

Zitat von vmk

Und wenn Intel sich Teile einer AMD GPU auf den Die packt, dann ist es immer noch nicht die Intel CPU, welche die Videos decodiert. Ich kann echt nicht nachvollziehen, wieso du das dan plötzlich zur Intel CPU dazu zählen würdest.

Intel hat auch einen integrierten Beschleuniger bei einigen Modellen (im Grunde alle Serien außer der Xeon wenn ich nichts übersehe), die ist nur bei manchen nicht sonderlich ausgeprägt. Oder würdest du die iGPU der Intel Atoms oder Core i-3/5/7/9 auch als dezidierte Grafikkarte zählen?

Die Intel CPU mit AMD Grafik waren tatsächlich zwei physikalisch getrennte und an verschiedenen Orten produzierte Dies, die nur auf einer Platine zusammen platziert wurden, quasi wie eine richtige dezidierte Grafik, nur platzsparender

Zitat von H6G

Das Ding hat selbst einen eigenen Co-Prozessor für Fließkommaoperationen, der dediziert aktiviert werden muss.

Zählt das auch als Extra Prozessor, wenn ja wie berechne ich mit dem Hauptprozessor den FLOPS Wert?

Das ist ja so in etwa ein Teil der Ideologie hinter ARM: der Core wird gestellt, alles andere Regeln (herstellerspezifische) Erweiterungen.

Zitat von vmk

Android auf x86 gibt es noch als Nische. Ganze tot ist es nicht.

Darum ging es ja Aktuelle Geräte gibt es aber nicht, offiziellen Support von Google gibt es nicht und für Android 8 existiert erst ein Release Candidate während Google Android 9 schon in Startposition bringt.

Zitat von vmk

Ein Rasperry kann nie und nimmer H264 in HD@30fps abspielen. Du spielst die Videos über eine dedizierte Grafikkarte ab: https://en.wikipedia.org/wiki/VideoCore

Nicht ganz korrekt, es ist keine dezidierte Grafikkarte, der "Beschleuniger" ist ein direkter Teil des SoC und auf einem Die und wird daher meist dazu gezählt. Davon ab gibt es im ARM-Segment noch viele weitere interessante "Erweiterungen/Beschleuniger" die die CPU unterstützen und direkt auf dem Die integriert sind Da könnten sich einige Intel Atoms eine Scheibe von abschneiden

Zitat von vmk

https://www.heise.de/preisvergleich/?cat=nbtabl&xf=2174_Intel%7E2187_Android&asuch=&bpmin=&bpmax=400&v=e&hloc=at&hloc=de&plz=&dist=&sort=p&bl1_id=100&togglecountry=set

Und welches Modell davon ist aktuell? Viele sind nur noch gebraucht zu erhalten. Hab die teuersten mal schnell durchgeklickt, die sind fast alle von 2016 oder noch älter, mit Intel CPUs von teils 2014 und davor. Android 6 haben die meisten, also im Grund nichts aktuelles, was ich ja sagte, es gibt keine aktuellen Android x86 Tablets. Es gibt nicht mal welche mit dem aktuellen Android 8. Das es das früher mal gab hab ich ja nie bestritten, nur jetzt gibt es sowas nicht mehr bzw. nur noch Restbestände/alte Modelle die ein Nischendasein fristen.

Zitat von julian-w

Vielleicht bei irgendwelchen Chinesen wo es noch Restbestände gibt, aktuelle Geräte waren keine auffindbar.

Ich gebe zu, ich lege aktuelle aus als "nicht älter wie ein, zwei Jahre". Wenn man aber sagt das Modelle aus 2016 mit 2014er CPU und einem Android aus 2015 noch als "aktuell" gelten, dann hab ich natürlich unrecht.

Zitat von vmk

*unterschreib*

Zitat: "eine CPU nur bei entsprechenden BogoMIPS-Wert auch entsprechend leistungsfähig sein kann"

Wenn das nur nicht da stehen würde, würde ich es auch unterschreiben. Das wäre dann aber äquivalent der Aussage "ein Auto in heller Farbe kann schnell sein" die zwar korrekt ist, mich aber kein bisschen schlauer macht. So gilt aber nach deiner Aussage:

• hoher BogoMIPS-Wert => kann leistungsfähig sein
• niedriger BogoMIPS-Wert => auf keinen Fall leistungsfähig (das ergibt sich aus dem nur, da nur bei bei entsprechenden BogoMIPS-Wert eine Chance auf Leistungsfähigkeit existiert)

Von daher weiß ich auch nicht welche Umkehrung ich dir unterstelle. Im Gegenteil, ich sage doch das die Umkehrung gerade nicht gilt, also aus hoher Leistungsfähigkeit nicht ein hoher BogoMIPS-Wert folgt und aus niedriger ein niedriger Wert (eben weil BogoMIPS keinen richtigen Bezug zur Leistung abbildet).

Wer will meine RPi1 nun erklären das es ab jetzt wegen seines geringen BogoMIPS-Wertes nicht mehr "leistungsfähig sein kann" und keine 1080p h.264 Videos mehr abspielen darf

Zitat von mainziman

das stimmt nicht; Aldi verkauft keine Einzelstücke, von dort hatte ich meines

Wie gesagt:

Zitat von julian-w

Aber ein reines Android-Tablet auf x86 Basis konnte ich nicht finden, direkt kaufen kann ich sowas wohl nicht, wirklich haben will das demnach wohl keiner direkt.

Aktuell sind die wohl recht tot, ich finde keins auf dem Markt. Vielleicht bei irgendwelchen Chinesen wo es noch Restbestände gibt, aktuelle Geräte waren keine auffindbar.

Zitat von mainziman

wenn man sagt, daß alle Autos mit über 100 Dinostärken die gleiche Leistung haben, macht das genauso wenig Sinn ...

Dann sag mir doch wie du mit den BogoMips unterscheidest, immerhin hast du die These aufgestellt das BogoMips ein unabdingbarer Indikator für Leistungsfähigkeit ist. Nur mir erschließt sich nicht wie.

Davon ab sind PS/kW (das meinst du wohl ) ein wissenschaftlich definiertes Maß zum messen von mechanischer/elektrischer/... Leistung die überall alle Geräteklassen auch wirklich vergleichbar ist, ein Motor mit 100 Watt liefert immer 100 Watt, egal von welchem Hersteller (Unterschiede im Drehmoment, RPM etc. abgesehen, geht ja nur um Leistung) oder welchem Energieträger (Strom, Benzin, Diesel, Gas). Während eine CPU mit 2000 BogoMips die gleiche Rechenleistung haben kann wie eine mit 500 BogoMips.

Man kann aber sagen: alle PKWs mit mindestens 120PS können gut einen kleinen Anhänger ziehen, für ein Wohnmobil sollten es 170PS sein. Eine Heizung für einen Raum der Größe X sollte 1kW haben und man kann das noch endlos fortführen aber dies ist ein Maßeinheit die für Vergleiche taugt. Das funktioniert mit den BogoMips nicht, Thesen wie: ab 1000/2000/5000 BogoMips läuft h.264 flüssig funktionieren einfach nicht.

Zitat von mainziman

wenn man nur schwarz und weiß kennt, macht es Sinn;

du siehst doch hier nur schwarz/weiß und unterscheidest in leistungsfähig und nicht leistungsfähig, oder "laut BogoMips vielleicht leistungsfähig" und "laut BogoMips auf keinen Fall leistungsfähig". Gerade mit dem Beispiel ARM Router und h.264 Playback wollte ich dir doch zeigen, das eine Unterscheidung keinen Sinn macht, vor allem nicht wenn man da "irgendwie" die BogoMips als Maß nimmt

Zitat von mainziman

ich würds anders formulieren: ARM CPUs sind weniger leistungsfähig als Intel CPUs

Und hier sind wir wieder beim schwarz/weiß Es gibt ARM CPUs die können h.265 in 4k decodieren was selbst einige i7 CPUs nicht auf die Reihe kriegen.

Das war doch das was dir hier alle im Thread sagen wollte und nach und nach aufgaben: es gibt nicht ein allgemeines "mehr leistungsfähig" in der heutigen CPU-Welt. Zu deiner Zeit mag das so gewesen sein, aber heute sind CPUs zum Teil so spezialisiert auf ein gewisses Gebiet, dass allgemeine Vergleiche keinen Sinn machen (vor allem beim BogoMips-Wert der sowieso schon keine Aussagekraft hat). Es geht hier nicht nur um Video Decoding, das ganze Spiel kann man noch mit IP Handling, De/Encryption, Neural Networking etc. treiben, wo es immer ARM CPUs gibt die (moderne) x86_64 CPUs schlagen. Der nächste wichtige Punkt ist dann Effizienz, wie viel Strom muss ich aufwenden um Algorithmus X auszuführen.