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

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

hustbaer

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

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

volkard

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.

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

Zeus

Echtzeitfähig subjektiv auf deine Wahrnehmungsfähigkeit. Das ist deine eigene Definition von Echtzeit in Betriebssysteme.

volkard

lowbyte_ schrieb:

Aber Windows ist bis zu einem gewissen grad Echzeitfähig ( eben nur weiches Echtzeitverhalten).

Klar. Also ein Garagentor würde ich damit schon steuern. Oder eine Farbenfabrik, wo keine Reaktion weniger als 5 Sekunden Zeit hat, um noch rechtzeitig zu sein. Je nach Anforderungen muß halt dies oder jenes am Windows spezialeingestellt werden. Zum Beispiel reicht für's Garagentor, wenn man die automatischen Updates abschaltet und die damit verbundenen Install-Reboot-Pausen.

lowbyte_ schrieb:

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.

Ist bei Echtzeit sehr oft so. Wahrscheinlich, weil 85% der Poster nicht wissen, was Echtzeitfähigkeit ist, nämlich nur, daß Antworten innerhalb spezifizierter Schranken geliefert werden (*). Die Schranken müssen aber keineswegs sowas wie 5ms sein. Und es gibt auch keine Definition, die sagt, ab 1ms ist es Echtzeit. Beim Garagentor brauche ich gar keine harte Echtzeit, sondern mir reicht, wenn man durchschnittlich weniger als 1s und mit einer Wahrscheinlichkeit von unter 1/10000 mehr als 60s warten muß. Beim Farbenwerk geht vielleicht ein Kessel kaputt, wenn ich mal 5s überschreite. Da muß ich halt was besorgen, was 5s garantiert. Tue ich das nicht, darf ich vielleicht den nächsten Kessel selber bezahlen. Oder ich kann glaubwürdig abschätzen, daß ein hübsch eingestelltes Windows die 5s so selten überschreitet, daß man das Risiko eingehen sollte. Ist ja nur eine Farbenfabrik und kein Atomkraftwerk.

lowbyte_ schrieb:

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

Ja. Wenn man so lustig drauf ist, auf dem Prozessrechner Counterstrike zu zocken, ist das eine sehr gute Idee. Aber den Schneid hätte ich nicht. Alle Windowsdienste, die was im Hintergrund machen, sollten bereits auf einer niedrigen Priorität laufen.

(*) Wegen diesem Satz werde ich bestimmt beschimpft werden und werde erfahren müssen, daß in einerm Unternehmen in Bielefeld alle unter Entzeitfähigkeit was ganz anderes verstehen und es auch ein Professor gesagt hat und so...

Hi

Und nochwas, ich bin kein besserwisser, und werde mich in Zukunft sehr genau ausdrücken, dass ich hier ja niemandem auf die Füsse trete.

@Volkard

Sehr gutes Bsp. von dir.

lowbyte

Hi

@Volkard

Nicht dass ich jetz hier einen auf Kumpel machen will, doch mit dir konnte man sich immer anständig unterhalten.

lowbyte

hustbaer

@lowbyte_:
Mich hat nicht so sehr gestört dass du hier was falsches behauptet hast, sondern die Art und Weise wie du ausgeflippt bist und den Thread hier zugespamt nachdem du mit "Schlaumeier" betitelt wurdest. Ist ja auch wirklich ein ganz schlimmes Wort.

Und dass du - wie ein kleines Kind - immer darauf beharrst dass du ja in wirklichkeit doch Recht hattest, nur dich falsch ausgedrückt oder was auch immer. Der Hund wars, der hat die Hausaufgabe gefressen, ja ehrlich.

Aber Windows ist bis zu einem gewissen grad Echzeitfähig ( eben nur weiches Echtzeitverhalten).

Soft-Realtime ist ein dummer Begriff für dumme Leute. Warum? Weil er *nichts* aussagt, ausser dass Soft-Realtime eben nicht Realtime ist. Man kann statt Soft- also genau so gut Nicht- schreiben.

Hi

Eben Ansichtssache...

lowbyte

Hi

Weisst du Hustbaer, realtime ist ein weiter Begriff, denn so wie es scheint nicht alle gleich sehen.
Und am Anfang haben wir noch gar nicht von soft und hard geredet, daher meine Ansichten das Windows Echzeitfähig ist, oder muss wohl besser sagen
(( nur soft-realtime )).Wie gesagt werde mich in zukunft genauer ausdrücken.

lowbyte

Also Leute! Keine Software ist wirklich zu hartem Echtzeitverhalten fähig!

hartes Echtzeitverhalten = Hardware
weiches Echtzeitverhalten = Software

Software kann nur unter ganz genau definierten Bedingungen(CPU Last...)hartes Echtzeitverhalten liefern. Aber das kann dann sogar Windows!

Wir haben mal eine Anlage für einen Autohersteller gebaut die mit Windows NT gesteuert wurde. In der Automobilindustie gelten sehr strenge Bedingungen wie z.B. hartes Echtzeitverhalten. Um das zu garantieren wurde eine Hardware entwickelt die das PNOZ abfallen lässt wenn die vorgeschriebene Reaktionszeit nicht eingehalten wird.

Das passierte dann immer Montag früh, weil Windows einfach keine Woche ohne Neustart durchhält...

Aber zum eigentlichen Thema: Für die Kommunikation mit der SPS hat der Hersteller doch sicher eine Lösung? Falls nicht würde ich sowas eher mit einem Mikrocontroller machen.

Wenn es unbedingt Windows sein soll/muß würde ich keine Funktionen wie Sleep oder so einsetzen sondern lieber etwas CPU-Zeit verschenken um das Timing einzuhalten. Wenn sowiso kein anderer Prozess/Thread im Weg ist der viel CPU-Zeit braucht ist es ja auch total egal. Man sollte dann auch drüber nachdenken ev. einen Assembler einzusetzen.

volkard

moetan schrieb:

Also Leute! Keine Software ist wirklich zu hartem Echtzeitverhalten fähig!

Falsch. Warum sollte das so sein?

moetan schrieb:

hartes Echtzeitverhalten = Hardware
weiches Echtzeitverhalten = Software

Falsch. Siehe zum Beispiel Definition auf Wikipedia.

moetan schrieb:

Software kann nur unter ganz genau definierten Bedingungen(CPU Last...)hartes Echtzeitverhalten liefern.

Kommt drauf an. Also im Allgemeinen falsch.

moetan schrieb:

Aber das kann dann sogar Windows!

Falsch.

moetan schrieb:

weil Windows einfach keine Woche ohne Neustart durchhält...

Falsch. Das war vor 15 Jahren so.

moetan schrieb:

Wenn es unbedingt Windows sein soll/muß würde ich keine Funktionen wie Sleep oder so einsetzen sondern lieber etwas CPU-Zeit verschenken um das Timing einzuhalten. Wenn sowiso kein anderer Prozess/Thread im Weg ist der viel CPU-Zeit braucht ist es ja auch total egal.

Quatsch. Es wird nicht sicherer, weil man die CPU seltener weggezogen kriegt! Im Gegenzeil, frische Zeitscheibenabschnitte sind langlebiger.

moetan schrieb:

Man sollte dann auch drüber nachdenken ev. einen Assembler einzusetzen.

Inwiefern hält das das Windows davon ab, meinen Prozess von der CPU zu nehmen?