konstante CPU-Last erzeugen

Hab mal ein bisschen rum probert. Solange die CPU Zeit von meinem Prozess über 50% war konnte man es durch ändern der Werte ganz gut einstellen, aber alles was drunter war, hat nur noch kurzzeitige schwankungen und keine konstante CPU Zeit erzeugt.

int main() {
	double m = 20;
	double n = 9;
	while(true) {
		for(int j = 0; j<130; j++){
			if(j == 0) Sleep(1);
			for(long i = 0; i< 500; i++) {
				m += cos(sqrt(m));
				m -= cos(sqrt(m));
				n *= cos(m);
				m += n;
				n -= sin(m + i);
				m -= n;
			}
		}
	}
	std::cout<<m;
}

thordk

wie wärs, nen real time thread zu starten, der entsprechend der nötigen last alle paar system ticks wieder schlafen gelegt wird?

dEUs

@TomasRiker:
Der Speicherverbrauch ist einfach zu extrem. 1,5GB bei 1500 Threads!

@rapso:
Runtertackten und Thread anhalten sind beides keine Optionen.
Das mit dem Paketen versteh ich nicht - wofür die Pakete?

@ha lustig:
Werde ich mal austesten, danke.

@thordk:
Habe so etwas ähnliches schon versucht, werde es aber genau so nochmals testen.

Danke für die rege Beteiligung!

Gerard

probie doch mal ob mal mit vmware, virtual pc, quemu usw. aus

wahrscheinlich kann man da die last einstellen, entwäder läst du dann deine app in der virtuelen umgebung laufen oder in der virtuelen umgebung ein thread der 100% auslastung in der vm erzeugt (aber da die vm eingestelt ist auf eine bestimte last, erzeugt er auf deiner maschiene z.b. nur 50%)

dEUs schrieb:

TomasRiker schrieb:

dEUs schrieb:

klappt nicht.

Mit Sleep(1) kriegt man verschiedene Werte hin, nicht nur nahe 100%.
Z.B. haben 5000 Threads bei mir eine Auslastung von ca. 25% erzeugt. Bei 10000 war die Auslatung dann allerdings schon bei 90%.

Das ist keine Option. Erstens ist das auch nciht konstant und zweitens verbrauchen schon 500 Threads bei mir knapp ein halbes GB virtuellen Arbeitsspeicher!

dann lasse die threads etwas mehr machen als while(true)sleep(1) dann brauchst du keine 500 threads mehr

unter linux erzeuge ich immer last in den ich auch cat /dev/random > /dev/null lesen lasse, ich glaube wenn man die daten vorher durch dd sendet kann man auch einstellen wie viel byte pro sek gelesen werden

ich denke du hast auch ein problem mit den messen, was windows unter cpu last versteht ist wahrscheinlich zu ungenau für dich, wobei ich mich sowieso frage was macht es für ein sin zu sagen "unser applikation läuft gut mit 50% cpu last, diese 50% last müssen aber konstant sein" was in der relaität aber ehr die ausnahme ist

phlox81

dEUs schrieb:

@TomasRiker:
Der Speicherverbrauch ist einfach zu extrem. 1,5GB bei 1500 Threads!

mit was erzeugst du denn die Threads?

TomasRiker

Ach, jetzt weiß ich auch, was du meintest, dEUs.
Für jeden Thread muss ja im virtuellen Adressraum ein Bereich reserviert werden. Ich hatte nur den tatsächlichen Speicherverbrauch gesehen. Mit einem 64-Bit-OS ist das kein Problem

man kann ja die stack size kleinerer machen

TomasRiker

Jo, das klappt tatsächlich:

CreateThread(0, 16, threadProc, 0, STACK_SIZE_PARAM_IS_A_RESERVATION, &id);

rapso

dEUs schrieb:

@rapso:
Runtertackten und Thread anhalten sind beides keine Optionen.
Das mit dem Paketen versteh ich nicht - wofür die Pakete?

wenn du einen thread auf critical priority stellst bekommst du 0 reaktion vom rechner, hast du eine blocked socket verbindung, steht der thread und du hast doch noch cpu-zeit fuer andere dinge. und wieviel gewartet wird kannst du dann mit dem anderen pc kontrollieren indem du halt haeufiger daten schickst fuer mehr auslastung und seltener fuer weniger auslastung. der critical priority thread ist deswegen so "nett" weil er vermutlich immer gleich viel rechenzeit dann zieht, egal wieviele normal-priority dinge du startest.
ansonsten kannst du dich nicht drauf verlassen, da abhaengig von IO usw. jedes OS die threads anders scheduled.

dEUs

Und wo ist der Unterschied zu nem Sleep?

thordk

dEUs schrieb:

Und wo ist der Unterschied zu nem Sleep?

sehe keinen. besonders nicht unter "consumer OSes", die sich jeden fitzel möglicher resourcen gleich unter den nagel reissen und wild verteilen.

rapso

dEUs schrieb:

Und wo ist der Unterschied zu nem Sleep?

mit sleep bekommst du wohl nur ne aufloesung von 10ms oder schlechter, bei nem blocked socket koenntest du (iterrupts usw. sei dank) sehr viel feiener die unterbrechungen machen.

thordk

also jetzt mal ganz von der eigentlichen diskussion ab: warum ist es nötig, ein programm unter einer bestimmten cpu last zu testen? läuft es immer nur auf einem bestimmten rechner? solange ein programm ausschließlich von rechenzeit abhängig ist, sind jegliche tests auf last unnötig, da es linear skalieren wird.

pale dog

thordk schrieb:

warum ist es nötig, ein programm unter einer bestimmten cpu last zu testen? läuft es immer nur auf einem bestimmten rechner? solange ein programm ausschließlich von rechenzeit abhängig ist, sind jegliche tests auf last unnötig...

das sehe ich genau so. vielleicht sollte dEUs mal genauer beschreiben, was er testen will...

dEUs

Das System ist äußerst komplex.
Es sind mehrere externe Systeme angeschlossen die Daten liefern (SPS etc). Diese Daten müssen abgespeichert werden. Dafür ist ein Zeitstempel notwendig. Und der wird auf dem Rechner erzeugt. Und wenn der unter Last steht, werden die Zeitstempel zu spät erzeugt und die Daten sind unbrauchbar.

Der Sinn des Tests ist ganz einfach:
"Leute, wenn ihr sinnvolle Daten wollt, dann guckt, dass eure CPU-Auslastung unter x% bleibt. Wenn ihr das nicht gewährleisten könnt, dann holt euch ne dickere Maschine"

rapso

eine sehr seltsame art minspec heraus zu finden, wir haben dafuer immer verschiedene rechner und benchmarken wie es auf denen laeuft, statt ein programm nebenbei kuenstlich last erzeugen zu lassen.

zudem gibt es andere lasten als cpu z.b. stalls wegen HDD die 0 cpu-last haben.

dEUs

Viel Spaß das auf diese Art bei diesem Produkt zu machen

pale dog

dEUs schrieb:

Das System ist äußerst komplex.
Es sind mehrere externe Systeme angeschlossen die Daten liefern (SPS etc). Diese Daten müssen abgespeichert werden. Dafür ist ein Zeitstempel notwendig. Und der wird auf dem Rechner erzeugt. Und wenn der unter Last steht, werden die Zeitstempel zu spät erzeugt und die Daten sind unbrauchbar.

dann mach doch den empfang von daten und die zeitstempelung in einen thread mit sehr hoher priorität. dann ist es (fast) egal, wie viele andere programme noch laufen. wenn du aber ganz sicher gehen willst, dass die daten rechtzeitig abgestempelt werden, dann solltest du vielleicht über den einsatz einer realtime extension nachdenken...

CMatt

Vergesst mal alle diesen ganzen prioritäts-quatsch wieder... das ist Windows kein echtzeit OS. Wenn der Sheduler meint pagefile durch die gegend schieben, das zeug was der USB driver grad macht, My Documents nach Redmond schicken, ... sei gerade wichtiger ist das so und das wird dann auch gemacht. Den interessiert nicht das dein tool jetzt in die bedrulie kommt mit timestamps generieren.

Aus eigener Erfahrung: lass das sein. Kauf dir irgend nen billig chip, schreib ein kleines timestamp-generier-programm und stöpsle ihn zwischen SPS un PC.
Solche sachen auf windows machen kannst du komplett vergessen, das bleibt ein Glückspiel anbänhig von HDD, RAM, CPU, GPU, Wetter, Winstärke... und kommt mit voller wucht wieder zurück sobald dem Kunden klar wir was für ein labiles konstrukt du ihm da andreht hast (hab windows auch schon mal als real-time OS missbrauchen wollen, deshalb: LASS ES SEIN!!!)

dEUs

Ich hab da keine Entscheidungsgewalt. Jeder weiß hier, dass das Quatsch ist das so zu machen. Niemand hat aber die Zeit, das ins Realtime zu ziehen