Habe schon vorher ne Mail bekommen, dass mein Server wegen eine HW Defekts umgezogen wird. 
Mal was anderes, gestern abend hat mich meine Mutter panisch angerufen, dass irgendwas mit Ihrem Handy nicht stimmt,
als die dann vom Handy meines Vaters nen Bild geschickt hat, war alles klar.
Sie hat es geschafft in den Tasche den Recovery Modus von Android zu starten xD.
Wenn ich das so versuche brauch ich schon einige Versuche xD
Habe schon vorher ne Mail bekommen, dass mein Server wegen eine HW Defekts umgezogen wird.
Ich auch
Gibt's jemanden, der noch gar keine Mail wegen den Foreshadow-Restarts bekommen hat, oder bin ich alleine?
(hab 17 Server hier und will nicht, dass die alle gleichzeitig dran sind
Hab auch noch keine Mail bekommen alle 6 Server noch unberührt.
ich hab auch noch kein Mail bekommen; lasst euch Zeit die werden Host f. Host durcharbeiten; und die Mglkt., wenn jemand x Server glzt. bestellt hat, daß diese alle auf dem selben Host liegen ist durchaus gegeben;
julian-w dich holt tatsächlich die Vergangenheit ein;
vmk das Hin- und Hergeschubse ist bei Win10 immer noch gegeben;
ob der HT dabei berücksichtigt oder nicht spielt da keine Rolle;
joas es ist bei dedizierten CPUs/Cores das gleiche
ergo mangels Verbesserung keine Notwendigkeit eines Updates;
hier nativ ein Win10 und dieser eine Single-Thread-CPU-Last Prozess
Logical to Physical Processor Map:
*- Physical Processor 0
-* Physical Processor 1
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, 3 MB, Assoc 12, 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
Logical Processor to Group Map:
** Group 0ergo sind wir wieder dort, bei meiner Aussage, der Scheduler von Windows zählt nicht dazu ...
über den von Linux kann ich keine Aussage treffen;
julian-w es ist nur eine Frage unter welchem Betrachtungswinkel man das ganze sieht;
ich hab auch noch kein Mail bekommen; lasst euch Zeit die werden Host f. Host durcharbeiten; und die Mglkt., wenn jemand x Server glzt. bestellt hat, daß diese alle auf dem selben Host liegen ist durchaus gegeben;
Wie kommst du zu dieser Aussage? Sowohl bei gleichzeitiger Bestellung als auch mit zeitlichem Abstand wird hier immer wieder betont, dass man genau das bei netcup vermeidet.
Oder gehst du (ohne es zu erwähnen) von einem unglücklichem Sonderfall aus?
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 
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):
Ein "richtiger" Stresstest mit "stress" wiederum funktioniert einwandfrei, dieser bleibt auf einem Kern:
Der Scheduler kann ja nichts dafür, wenn der Benutzer ihn falsch benutzt
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):
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
Eine korrekt angelegte Single-Thread Workload klappt ohne hin- und hergestupse unter Windows und Linux, gerade selbst getestet.
dann zeige mal Deine Single-Thread-Workload ...
meiner ist einfach
(kurz schematisch)
#include <stdio.h>
#include <math.h>
#define CNT 6250000
/*
* dividiert pull durch 10^16 und liefert den Divisionsrest
*/
unsigned long long division( unsigned long long* pull, unsigned long ulCnt );
int main( int argc, char* argv[] )
{
unsigned long long ullDest[ CNT ], ullSrc[ 2*CNT ];
unsigned long ul;
unsigned int n = 0;
for ( ul = 0; ul < CNT; ul++ )
{
ullSrc[ ul ] = 0xFFFFFFFFFFFFFFFF;
ullSrc[ ul + CNT ] = 0;
}
for ( ul = 0; ul < CNT; ul++ )
{
if ( ( ul % (CNT / 100) ) == 0 )
printf("%d percent done.\r",n++ );
ulDest[ ul ] = division( ulSrc, CNT );
}
printf( "\n\n\n" );
ul = CNT;
while ( ul > 0 )
printf( "%016llu", ullDest[ --ul ] );
return 0;
}erklär mir nicht das wäre fehlerhaft;
dann zeige mal Deine Single-Thread-Workload ...
Hab ich doch: es handelt sich um den HeavyGate Benchmark. Unter Linux "yes" und das "stress" Tool.
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 du
Und 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.
Hohe Last soll man nie, nie, niemals im "GUI" Thread bzw. im interaktiven Thread zur Benutzer-Maschine-Kommunikation (main-Function) laufen lassen,
das ist schon mal ein Blödsinn, denn GUI Programme haben kein main sondern ein WinMain, wir reden ja von Windows ...
wennst unter Windows es so
start /REALTIME calculate
aufrufst, dann gibt es diese Geschubse auch nicht;
eigentlich lernt man das doch von Anfang an, bei einer GUI merkt man ja direkt das dann schlichtweg nichts mehr geht.
diese Argumentation erinnert mich an meine Schulzeit, wo mein Sitznachbar von einem Computer-Virus erzählte:
"man sieht eine entzückende Animation und dann war die Festplatte formatiert"
das ist schon mal ein Blödsinn, denn GUI Programme haben kein main sondern ein WinMain, wir reden ja von Windows ...
Es tut mir leid mit dir zu Argumentieren macht einfach keinen Spaß wenn nur Blödsinn behauptet wird 
Korrekt ist:
Unter Visual C++ gibt es eine "wWinMain" (WinMain unterstützt nur ANSI als Parameter, wWinMain auch Unicode und soll bevorzugt verwendet werden) als Einstiegsfunktion, das ist korrekt, nichtsdestotrotz kann es auch einfach eine "main" sein, ist tausendfach so und vermutlich auch in der Mehrzahl der Programme so, schon nur alle Frameworks wie QT, GTK, ... benutzen eine einfach "main" als Programmeinstieg und diese bildet meist den "GUI-Thread" ab. Im Grunde gibt es die wWinMain nur bei Visual C++, "Standard" C++ benutzt zu 99% die "main". Also bitte nicht den Sonderfall verallgemeinern und als Standard ausrufen.
Ja die Formulierung GUI-Thread ist etwas salopp. Die "main" als Einstieg (bei GUI Programmen) ist aber genauso üblich wie eine wWinMain (eher ist die wWinMain der Exot). Davon ab stellen beide den "GUI-Thread" da (Salopp formuliert). Und auch bei Shell-Programmen gibt es einen "GUI-Thread" oder "main-Thread" oder "intaraktiver-Thread" oder wie man ihn immer nennen mag.
wennst unter Windows es so
start /REALTIME calculate
aufrufst, dann gibt es diese Geschubse auch nicht;
Ich bin mir ziemlich sicher das der Taschenrechner nicht dafür gedacht ist, ewig lange Berechnungen durchzuführen, bei mir konnte ich gar keine provzieren, soviel ich weiß ging das nur in älteren Versionen, aber gut bist ja gerne in der Vergangenheit 
Aber wenn dass das Problem löst und es das Geschubse nicht mehr gibt, ist doch alles gut, zeigt ja einmal mehr das es an deinem unsauberen Code liegt bzw falscher Priorisierung.
diese Argumentation erinnert mich an meine Schulzeit, wo mein Sitznachbar von einem Computer-Virus erzählte:
"man sieht eine entzückende Animation und dann war die Festplatte formatiert"
Und das hat jetzt exakt womit was zu tun? Ich hab dir einen Fehler nach etlichem Hin und Her aufgezeigt. Oder soll ich dir jetzt Dokumente zeigen das eine hohe Arbeitslast im GUI-Thread bzw main-Thread ungünstig ist? Das findest du auch selbst mit Google heraus.
Ich hab mir mal die Mühe gemacht und deinen Code getestet. In der einfachsten Ausführung wie du es hast läuft das bei mir direkt "nur" auf 2 Cores, wird also nicht quer Beet hin und her gestupst. Liegt vielleicht an dem ständigen printf das aufgerufen wird.
Also habe ich das ganze kurz als Thread ausgelagert und konfiguriert und siehe da, alles läuft so wie es laufen soll, kein gestupse oder sonst was und die Ausgaben klappen auch noch.
Den Code findest du hier, der sollte auch ohne Probleme compilierbar sein. Möglicherweise macht mein Code was anderes wie deiner (auf mathematischer Ebene), aber ist ja auch egal bzw du kannst auch lauffähigen C-Code liefern.
// CMakeProject1.cpp: Definiert den Einstiegspunkt für die Anwendung.
//
#include "CMakeProject1.h"
#include <stdio.h>
#include <math.h>
#include <process.h>
#include <Windows.h>
#define CNT 6250
using namespace std;
bool threadFinished = false;
void calc(void *param);
int main()
{
cout << "Hello CMake." << endl;
getchar();
//cout << _beginthread(calc, 0, NULL);
calc(NULL);
while (!threadFinished)
{
_sleep(1000);
}
getchar();
}
void calc(void *param)
{
/*
HANDLE process = GetCurrentProcess();
DWORD_PTR processAffinityMask = 1;
BOOL success = SetProcessAffinityMask(process, processAffinityMask);
cout << success << endl;
*/
unsigned long long ullDest[CNT];
unsigned long long ullSrc[2 * CNT];
unsigned long ul;
unsigned int n = 0;
unsigned int ii = 0;
for (ii = 0; ii < 1000000; ii++)
{
for (ul = 0; ul < CNT; ul++)
{
ullSrc[ul] = 0xFFFFFFFFFFFFFFFF;
ullSrc[ul + CNT] = 0;
}
for (ul = 0; ul < CNT; ul++)
{
ullDest[ul] = ullSrc[ul] / CNT;
}
}
printf("\n\n\n");
ul = CNT;
while (ul > 0)
printf("%016llu", ullDest[--ul]);
threadFinished = true;
}Gelöst
julian-w Dir fehlen anscheinend die Grundlagen; das mit (w|_t)WinMain ist erstens ein Spezifikum von Microsoft und hat nichts zu sagen und zweitens wäre Dein Programm durchgefallen; Worker Threads ohne GUI sind sinnlos;
sieh Dir einfach mal an was der Parameter /ENTRY und der Parameter /SUBSYSTEM des LINK commands bedeuten;
wir reden hier ausschließlich von /SUBSYSTEM:CONSOLE
Du solltest vlt. andere nicht als unwissend hinstellen, besonders dann wenn Dir anscheinend entsprechendes Basiswissen fehlt;
An dieser Stelle versteh ich nur noch Bahnhof. Programmieren kann ich leider nicht.
Gelöst bzw. auch gelöst. Irgendwer hatte das Passwort geändert. Muss man ja auch niemanden mitteilen...
julian-w Dir fehlen anscheinend die Grundlagen; das mit (w|_t)WinMain ist erstens ein Spezifikum von Microsoft und hat nichts zu sagen und zweitens wäre Dein Programm durchgefallen; Worker Threads ohne GUI sind sinnlos;
sieh Dir einfach mal an was der Parameter /ENTRY und der Parameter /SUBSYSTEM des LINK commands bedeuten;
wir reden hier ausschließlich von /SUBSYSTEM:CONSOLE
Du solltest vlt. andere nicht als unwissend hinstellen, besonders dann wenn Dir anscheinend entsprechendes Basiswissen fehlt
Tja seltsamerweise scheinen ihm mehr Leute zuzustimmen als Dir, woran das wohl liegt. Ach ja ich kanns mir schon denken, die haben alle keine Ahnung, nur Du weißt bescheid.
Ist ja nicht das erste mal, dass Du Fakten ignorierst und dich mit irgendwelchen Behauptungen herauszuwinden versuchst.
Evtl. solltest Du einmal zugegeben, wenn Du falsch liegst, so schwer ist das nicht, glaub mir...
Immer wenn ich in letzter Zeit was entwickeln will, finde ich irgendwelche Bugs.
Letztes mal in phpunit beim WSDL-Support und nun SQLite in Doctrine 
Hab nichts gesagt
#Streisand
Tja seltsamerweise scheinen ihm mehr Leute zuzustimmen als Dir, woran das wohl liegt. Ach ja ich kanns mir schon denken, die haben alle keine Ahnung, nur Du weißt bescheid.
in dem Fall scheint es tatsächlich so, mein schematischer Workload war nur der Verständnis wegen in C skizziert; tatsächlich aber ist er in FORTRAN (das können leider die wenigsten) und ein Entwicklungswerkzeug von Dritten;
und sein Programm ist auch aus anderen Gründen sinnlos, es verdampft nur CPU-Zeit und liefert kein Ergebnis; und Fortschritt sieht man auch keinen;
Vlt. solltest Du zugeben, daß Dir mangels Kenntnis etwas fehlt bevor Du anderen Fehler unterstellst, die nicht da sind; so schwer ist das auch nicht;
und spätestens mit dem Kommentar "Windows 2000" (von dem ich nicht gesprochen habe) wußte ich, der hat eh keine Ahnung und will nur Schlau rüberkommen;
Ich werde mir dem Rat, den ich hier auch mehrfach per PN erhalten habe und auch hier im Thread vorhanden ist, anschließen und zukünftig (nach diesem Post) die Regel "never discuss with mainziman" (oder ist es eher "Don't feed the trolls?") beherzigen. Diskutieren im Internet macht Spaß (bzw. kann Spaß machen), da darf man auch etwas streiten. Aber mit mainziman ist es einfach nur sinnlos, wurde hier ja schon zu genüge erwähnt warum. Fehlende Einsicht, kein eingehen auf Argumente, bringt immer wieder krude neue Argumente, notfalls von Ursystemen und kann vor allem keine Fehler eingestehen und will immer Recht haben.
Dir fehlen anscheinend die Grundlagen; das mit (w|_t)WinMain ist erstens ein Spezifikum von Microsoft und hat nichts zu sagen und zweitens wäre Dein Programm durchgefallen; Worker Threads ohne GUI sind sinnlos;
Hier steht schon so viel Blödsinn... Du hast die WinMain zum Standard gehimmelt und ich als Spezifikum von Microsoft (Visual C++) beschrieben... und natürlich machen Worker Thredas ohne GUI Sinn, was denkst du wie nginx, Apache, Datenbanken oder sonst was funktionieren
sieh Dir einfach mal an was der Parameter /ENTRY und der Parameter /SUBSYSTEM des LINK commands bedeuten;
wir reden hier ausschließlich von /SUBSYSTEM:CONSOLE
Was soll das jetzt mit dem ursprünglichen Thema zu tun? Ist das der Teil um "clever" zu klingen?
Du solltest vlt. andere nicht als unwissend hinstellen, besonders dann wenn Dir anscheinend entsprechendes Basiswissen fehlt;
Brauch ich nicht (mehr), du disqualifizierst dich selbst
und sein Programm ist auch aus anderen Gründen sinnlos, es verdampft nur CPU-Zeit und liefert kein Ergebnis; und Fortschritt sieht man auch keinen;
Wir reden die ganze Zeit von "100% Workload", ist doch vollkommen egal was die macht. Wenn du Pi auf 100000 Stellen berechnest oder sonst was ist das genau so unnötig wie eine while-Schleife
Vlt. solltest Du zugeben, daß Dir mangels Kenntnis etwas fehlt bevor Du anderen Fehler unterstellst, die nicht da sind; so schwer ist das auch nicht;
und spätestens mit dem Kommentar "Windows 2000" (von dem ich nicht gesprochen habe) wußte ich, der hat eh keine Ahnung und will nur Schlau rüberkommen;
Hier steht schon so viel Blödsinn... Du hast die WinMain zum Standard gehimmelt und ich als Spezifikum von Microsoft (Visual C++) beschrieben... und natürlich machen Worker Thredas ohne GUI Sinn, was denkst du wie nginx, Apache, Datenbanken oder sonst was funktionieren
stimmt hier steht wirklich Blödsinn, weil Du Anwendungs(programmen/software) mit System(programmen/software) vergleichst ...
(der berümte Apfel mit Birnenvergleich, damit hast Dich jetzt entgültig disqualifiziert)
Brauch ich nicht (mehr), du disqualifizierst dich selbst
Ah ja, siehe Absatz darüber
