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

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

  • ?

    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.

    0
  • ?

    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?

    0
  • ?

    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.

    0
  • Z

    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/).

    0
  • ?

    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.

    0
  • ?

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

    0
  • ?

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

    0
  • Z

    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.

    0
  • ?

    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 😃

    0
  • ?

    Hi

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

    Lowbyte

    0
  • ?

    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 👍

    0
  • ?

    Hi

    @FollBrofi(Hat gerne Brot)

    Dumm gelabert ist auch was !

    lowbyte

    0
  • ?

    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

    0
  • Z

    Folie 7 lesen, Danke!

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

    0

  • 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

    0

  • 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).

    0

  • p.S.:
    Die Genauigkeit von GetTickCount() steigt durch timeBeginPeriod() übrigens NICHT. Im Fall des Falles also timeGetTime() verwenden!

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

#include <boost/utility.hpp>

#include <MMSystem.h>
#pragma comment(lib, "winmm.lib")

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;
};

int main() 
{ 
	TimeBeginPeriodScope scope(1, 100);

	printf("effective precision: %d ms\n", scope.GetEffectivePrecision());

    bool waitForTimeChange = true; 
    SYSTEMTIME st; 
    unsigned long timeInMs( 0 ); 
    unsigned long timeInMsOld( 0 ); 
    int outputCount( 0 ); 
    while ( outputCount < 20 ) 
    { 
		Sleep(1);
        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 -- %d -- %d\n" ,st.wDay,st.wMonth,st.wYear,st.wHour,st.wMinute,st.wSecond,st.wMilliseconds, GetTickCount(), timeGetTime()); 
            ++outputCount; 
        } 
    }

    return 0; 
}

    ergibt bei mir

    effective precision: 1 ms
25.6.2010 23:53:25.142 -- 5523406 -- 5523397
25.6.2010 23:53:25.144 -- 5523406 -- 5523399
25.6.2010 23:53:25.146 -- 5523406 -- 5523401
25.6.2010 23:53:25.148 -- 5523406 -- 5523403
25.6.2010 23:53:25.150 -- 5523406 -- 5523405
25.6.2010 23:53:25.152 -- 5523421 -- 5523407
25.6.2010 23:53:25.154 -- 5523421 -- 5523409
25.6.2010 23:53:25.155 -- 5523421 -- 5523411
25.6.2010 23:53:25.157 -- 5523421 -- 5523413
25.6.2010 23:53:25.159 -- 5523421 -- 5523415
25.6.2010 23:53:25.161 -- 5523421 -- 5523417
25.6.2010 23:53:25.163 -- 5523421 -- 5523419
25.6.2010 23:53:25.165 -- 5523421 -- 5523421
25.6.2010 23:53:25.167 -- 5523437 -- 5523423
25.6.2010 23:53:25.169 -- 5523437 -- 5523425
25.6.2010 23:53:25.171 -- 5523437 -- 5523426
25.6.2010 23:53:25.173 -- 5523437 -- 5523428
25.6.2010 23:53:25.175 -- 5523437 -- 5523430
25.6.2010 23:53:25.177 -- 5523437 -- 5523432
25.6.2010 23:53:25.179 -- 5523437 -- 5523434
    0
  • ?

    Hi

    @hustbaer

    Aber ich bin nie der Initiator von Beleidigungen. Musst es vieleicht mal so sehen!
    Ich habe kein Problem mit dir, aber du wohl mit mir. Eigentlich schade ...

    lowbyte

    0
  • V

    lowbyte_ schrieb:

    Aber ich bin nie der Initiator von Beleidigungen.

    Naja, Du hast in Deinen Fachbeiträgen wie

    Klar ist Windows Echtzeit fähig !

    oder dem fulminanten Versuch, mit SetPriorityClass() dafür zu sorgen, daß die Platte weniger als 2 Sekunden braucht, um Wiederanzufahren, um Teile meiner Exe-Datei einzulagern,
    schon gelegentlich ein wenig um Kosenamen gebettelt. 🤡

    0
  • ?

    Hi

    Ja da hast du recht.
    Aber Windows ist bis zu einem gewissen grad Echzeitfähig ( eben nur weiches Echtzeitverhalten). Und nur weil ich das am Anfang nicht so genau genomen habe hacken zwei hier im Forum auf mir herum. Konnte ja nicht wissen das es manche hier so eng sehen, oder das ich sogar manchen auf die Füsse trette.

    Das mit SetPriorityClass() war nicht so toll, aber man muss ja nicht gleich mit höchster priorität fahren, und dabei das System noch mehr ausbremsen. Aber es schadet sicher nicht einem Prozess bisschen höhere Priorität zu geben, so das er bei einem ausgelasteten System nicht zu kurz kommt und wenigstens (weiches echtzeitverhalten einhält, wobei hier die Range undefiniert ist).

    lowbyte

    0
Anmelden zum Antworten