konstante CPU-Last erzeugen

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

thordk

gibt real time layer für windows. zeitkritische anwendungen für windows zu entwickeln ist zwar banane, aber billig ^^

CMatt

dEUs schrieb:

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

Ok
Dann versuch ich mal auch was produktives beizutragen: krahm dein alle x ein sleep programm noch mal raus und mach ein
SetThreadPriority(GetCurrentThread(),THREAD_PRIORITY_TIME_CRITICAL);
SetProcessPriorityBoost(GetCurrentProcess(),TRUE);
vorne ran.

dEUs

thordk schrieb:

gibt real time layer für windows. zeitkritische anwendungen für windows zu entwickeln ist zwar banane, aber billig ^^

Ich weiß. Auch dafür hat niemand Zeit.

dEUs

CMatt schrieb:

dEUs schrieb:

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

Ok
Dann versuch ich mal auch was produktives beizutragen: krahm dein alle x ein sleep programm noch mal raus und mach ein
SetThreadPriority(GetCurrentThread(),THREAD_PRIORITY_TIME_CRITICAL);
SetProcessPriorityBoost(GetCurrentProcess(),TRUE);
vorne ran.

Hilft auch nix...

CMatt

dEUs schrieb:

CMatt schrieb:

dEUs schrieb:

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

Ok
Dann versuch ich mal auch was produktives beizutragen: krahm dein alle x ein sleep programm noch mal raus und mach ein
SetThreadPriority(GetCurrentThread(),THREAD_PRIORITY_TIME_CRITICAL);
SetProcessPriorityBoost(GetCurrentProcess(),TRUE);
vorne ran.

Hilft auch nix...

Das du ein dual core system? (auf meinem single core reduzieren die 2 zeilen von oben as steurung nähmlich von ~20% auf 5)

dEUs

Nein, ein single core.
Zeig mal den ganzen Code von dir.

CMatt

int main()
{
	SetThreadPriority(GetCurrentThread(),THREAD_PRIORITY_TIME_CRITICAL);
	SetProcessPriorityBoost(GetCurrentProcess(),TRUE);
	while(1)
	{
		for(int x=0;x<999999;x++);
		Sleep(1);
	}
	return 0;
}

als debug compliert, damit der compiler das unnütze zeug nicht einfach raus-optimiert => erbit ne last von 20-25% bei mir

(wobei ich von der Last spreche die im task manager angezeigt ist, also durschnitt, in echt sind das nählich keine 20% CPU load sondern 999999 mal vollgas dann 1ms pause)