[gelöst] Zeitauflösung von Sleep und co. erhöhen?

Dobias

@lowbyte_: Ein Betriebssystem wird nicht dadurch zum echtzeitfähig, dass die Zeitauflösung auf Planck-Zeit-Genauigkeit kommt.
Ein Echtzeitbetriebssystem könnte sogar nur auf die Sekunde genau die Zeit ausgeben. Das entscheidende ist, dass es das zuverlässig tut. Das Verhalten muss vorhersagbar sein. Es gibt beispielsweise spezielle Linux-Kernel für soetwas.
Das, was eine SPS macht, passiert beispielsweise auch in "Echtzeit".
Unter normalen Desktop-Betriebssystemen kanns einem immer passieren, dass der Rechner gerade mit irgendwas anderen wie z.B. dem leeren des Festplattencaches oder so beschäftigt ist.

Edith sagt: Mist, GodsHomeboy war schneller.

So ein Unfug! Wenn ich z.B. auf meinen Start Button klicke erscheint das Menu in Echtzeit. Es ist für mich keine Verzögerung feststellbar. Das ist ausreichend um von Echtzeit zu sprechen.

Hi

Ich dachte halt wen du ihn so weit priorisierst das er höhere Priorität hat als alle anderen ink. Sysproc.und Treiber, dann könnte man Echzeit auch auf Windows garantieren. Geht dan aber wohl nur über Treiberprogrammierung. Das waren meine Ansichten.

Lowbyte

Hi

@hustbaer

Dan kannst du das normal sagen, und nicht gleich mit Beleidigungen um dich werfen. ok?
Ich denke vom Kleinkind bist du weit empfernt.!
Dieser Artikel von wiki ist mir natürlich klar.
Hast mich wohl falsch verstanden.

@paule8

Deine Meinung ist falsch..Unter echtzeit versteht man was anderes!

Lowbyte

Wikipedia sagt:

Der Begriff Echtzeit legt lediglich fest, dass ein System auf ein Ereignis innerhalb eines vorgegebenen Zeitrahmens reagieren muss. Der Begriff sagt nichts über die Geschwindigkeit oder Verarbeitungsleistung eines Systems aus.

Das ist in meinem Beispiel der Fall.

Paule8 schrieb:

So ein Unfug! Wenn ich z.B. auf meinen Start Button klicke erscheint das Menu in Echtzeit. Es ist für mich keine Verzögerung feststellbar. Das ist ausreichend um von Echtzeit zu sprechen.

Na dann klick mal auf die Schaltfläche, wenn der Rechner ausgelastet ist, dann ist es vorbei mit deiner "Echtzeit.". Oder hast du noch nie unter Windows darauf gewartet, dass ein Dialog aufgeht?

Was hat das mit Windows zu tun? Das ist bei jedem System so. Wenn du z.B. eine SPS auslastest wird sie ihre Zykluszeit überschreiten.

Zeus

Paule8 schrieb:

Was hat das mit Windows zu tun? Das ist bei jedem System so. Wenn du z.B. eine SPS auslastest wird sie ihre Zykluszeit überschreiten.

Nein es gibst Betriebsysteme, die dir garantieren von X s (x wesentlich kleiner als 1), auf Ereignis zu reagieren. Solche OS sind im Sicherheitsbereich zu finden. Ein Beispiel Radaranlagen mit QNX (http://www.qnx.com/).

So habe ich das auch gelernt. Echtzeitsysteme reagieren immer garantiert in einer bestimmten Zeit, da wartet dann der Rest bis Du fertig bist und nicht wie bei Windows umgekehrt. Windows ist also kein Echtzeitbetriebssystem da z.B ein Update einer Software oder des Systems oder sonst was doch deine Anwendung die Zeit klauen kann. Somit ist die Echtzeit nie garantiert egal mit welchen Zeitintervallen du theoretisch reagieren kannst.

Bitte verkauft niemals an einen Kunden eine Windowsanwendung als Echtzeitanwendung, das ist Betrug und kann sehr teuer werden.

Sicher gibt es das für spezielle Anwendungen, aber für Echtzeit ist das keine Anforderung.

Man muß zwischen weiches Echtzeitverhalten und hartem Echtzeitverhalten unterscheiden. Der Wikipedia Artikel erklärt es eigentlich recht gut.

Zeus

Paule8 schrieb:

Man muß zwischen weiches Echtzeitverhalten und hartem Echtzeitverhalten unterscheiden. Der Wikipedia Artikel erklärt es eigentlich recht gut.

Und Betriebssysteme werden nur dann Echtzeit genannt, wenn Sie harte Echtzeitverhalten haben. Danke, dass wir darüber gesprochen haben.

Damit denke ich kann das Thema ob Windows echtzeitfähig ist nun endlich beendet werden. Es ist definitiv nicht echtzeitfähig, wurde aber auch nie dafür entwickelt und das lässt sich auch nicht umschiffen, es sei denn man ändert den Kernel...viel spass

Hi

Weiches Echtzeitverhalten bietet windows auf jedefal. doch hartes nicht.. ansonnsten ist es so.

Lowbyte

lowbyte_ schrieb:

Hi

Weiches Echtzeitverhalten bietet windows auf jedefal. doch hartes nicht.. ansonnsten ist es so.

Lowbyte

Hahahaha vorhin wusstest nicht mal, was Echtzeit bedeutet, und jetzt machste einen auf FollBrofi!
Du bist echt ne Bereicherung

Hi

@FollBrofi(Hat gerne Brot)

Dumm gelabert ist auch was !

lowbyte

Hi

Vor meinem ersten Posting haben wir noch ga nicht von weicher und harter Echtzeit geredet. Daher meine Ansichten. Und was Echtzeit ist habe ich schon gewusst, da hasst du noch in di Hosen geschissen.

lowbyte

Zeus

Folie 7 lesen, Danke!

http://www.microconsult.de/includes/downloads/kurzvortraege/RTOS.pdf

hustbaer

lowbyte_ schrieb:

Hi

@hustbaer

Dan kannst du das normal sagen, und nicht gleich mit Beleidigungen um dich werfen. ok?

rofl
lies mal deine eigenen beiträge alter

hustbaer

Dobi schrieb:

Setze ich jetzt timeBeginPeriod(1); davor, wird es leider auch nicht besser:

#include <windows.h>
#include <stdio.h>

int main()
{
	timeBeginPeriod( 1 );
	bool waitForTimeChange = true;
	SYSTEMTIME st;
	unsigned long timeInMs( 0 );
	unsigned long timeInMsOld( 0 );
	int outputCount( 0 );
	while ( outputCount < 20 )
	{
		GetSystemTime(&st);
		timeInMsOld = timeInMs;
		timeInMs = 24*60*1000* st.wHour + 60*1000*st.wMinute + 1000*st.wSecond + st.wMilliseconds;
		if ( !waitForTimeChange || ( timeInMs != timeInMsOld ) )
		{
			printf("%d.%d.%d %d:%d:%d.%d\n" ,st.wDay,st.wMonth,st.wYear,st.wHour,st.wMinute,st.wSecond,st.wMilliseconds);
			++outputCount;
		}
	}
	timeEndPeriod( 1 );
	return 0;
}

->

25.6.2010 10:25:56.640
25.6.2010 10:25:56.656
25.6.2010 10:25:56.671
25.6.2010 10:25:56.687
25.6.2010 10:25:56.703
(...)

Dein Code 1:1 bei mir ins VS2010 reingeworfen, compiliert und ausgeführt:

25.6.2010 23:26:38.367
25.6.2010 23:26:38.368
25.6.2010 23:26:38.369
25.6.2010 23:26:38.370
25.6.2010 23:26:38.371
25.6.2010 23:26:38.372
25.6.2010 23:26:38.373
25.6.2010 23:26:38.374
25.6.2010 23:26:38.375
25.6.2010 23:26:38.376
25.6.2010 23:26:38.377
25.6.2010 23:26:38.378
25.6.2010 23:26:38.379
25.6.2010 23:26:38.380
25.6.2010 23:26:38.381
25.6.2010 23:26:38.382
25.6.2010 23:26:38.383
25.6.2010 23:26:38.384
25.6.2010 23:26:38.385
25.6.2010 23:26:38.386

Scheint wohl etwas systemabhängig zu sein. (Meins: Win7 64 Bit, Rest müsste egal sein).
Laut Doku kann timeBeginPeriod() allerdings auch TIMERR_NOCANDO sagen, weswegen ich mir mal folgende kleine Helper-Klasse gebastelt habe:

class TimeBeginPeriodScope : private boost::noncopyable
{
public:
	explicit TimeBeginPeriodScope(UINT min, UINT max = 100) :
		m_effectivePrecision(Init(min, max))
	{
	}

	~TimeBeginPeriodScope()
	{
		if (m_effectivePrecision != 0)
			timeEndPeriod(m_effectivePrecision);
	}

	int GetEffectivePrecision() const
	{
		return m_effectivePrecision;
	}

private:
	static int Init(UINT min, UINT max)
	{
		while (min <= max)
			if (timeBeginPeriod(min) == TIMERR_NOERROR)
				return min;
			else
				min++;
		return 0;
	}

	UINT const m_effectivePrecision;
};

Probier's damit mal.

BTW: timeBeginPeriod() wirkt sich - zumindest auf meinem System - auch auf die Genauigkeit von Sleep() aus. Zumindest das hab' ich auch auf Windows XP SP2 & SP3 (32 Bit) verifizieren können (auf XP laufen einige Programme von mir die Sleep + timeBeginPeriod in einer Timing-Schleife verwenden, und das klappt soweit ganz gut, also mit deutlich besserer Auflösung als den üblichen ~15ms).

BTW: Sleep() scheint immer LÄNGER pennen zu wollen als die angegebene Zeit. Es braucht also auch ein Sleep(1) nach einem (erfolgreichen) timeBeginPeriod(1) im Schnitt 2 ms und nur ganz ganz selten eine (und manchmal mehr, aber das Thema hatten wir ja schon zur Genüge :D).