[W32/VB6] Nauwkeurige functie ipv Sleep/SleepEx

[Adion]

Ik heb dus een programma, en ik wil ongeveer 200 keer per seconde van alles en nog wat updaten.

Nu heb ik dus een loop die gaat tot het programma beeindigt moet worden, met achteraan DoEvents voor de resterende tijd.
(Dus als 200 fps is ingesteld, en de functie is klaar in 3 milliseconden, wacht ik nog 2 milliseconden met een DoEvents in een loop.

Dit is natuurlijk niet erg efficient, want die DoEvents zorgt er enkel voor dat het programma zelf wat update tijd krijgt, en niet dat er tijd wordt gegeven aan windows voor andere programma's.

Nu had ik al gevonden dat ik hiervoor Sleep kan gebruiken, maar het nadeel hiervan is dat zelfs een sleep met als parameter 1 milliseconden soms langer duurt dan 5 milliseconden (ik gebruik windows xp)
Ik heb ook al ergens gezien dat er in unix een functie nanosleep bestaat, die iets nauwkeuriger zou zijn, maar hier heb ik nog geen windows-variant van gevonden.

Iemand hier die weet hoe ik dit het beste oplos?

[LordLarry]

Kan niet met windows. Wat jij nodig hebt is een Real Time OS. Daar heb je wel de garantie.

Wat je zou kunnen doen is dat process meer prioriteit geven zodat ie vaker aangeroepen wordt in de hoop dat het verbeterd. Maar dat geeft nog geen garantie.

[johnwoo]

Kan wel met windows
Zoek eens op Performance Counters

[edit]
En als je het gebeuren dan nog in een critical section zet, komen er ook geen andere threads doorheen fietsen...

[Adion]

Performance counters zijn geloof ik de dingen die ik al gebruik om de timing exact te maken (dus exact lang genoeg de doevents uitvoeren enzo)
Maar die geven op zich toch geen tijd aan windows voor andere processen?

Het is niet nodig dat ik er volledige garantie over heb, ik wil gewoon het cpu gebruik wat doen dalen zonder de performance teveel te beinvloeden.
Dus gewoon een functie die ongeveer 1 ms de tijd geeft aan andere taken, maar niet langer dan 5ms

[LordLarry]

En is er een harde garantie bij die performance counters dat die altijd kloppen? Volgensmij niet. Als de CPU load erg hoog is gaan er hoe dan ook gaten vallen lijkt mij. Zo is windows nu eenmaal opgebouwd. De beschikbare tijd wordt zo goed als mogelijk verdeeld, maar sommigen krijgen gewoon voorang en wat er niet is is er niet. Geen CPU cycles over? dan wordt je performance counter code niet aangeroepen...

PS: De sleep functie heeft een resolutie van tussen de 5 en 50ms afhankelijk van vele factoren
PSPS: Zie QueryPerformanceCounter() and QueryPerformanceFrequency() voor de Performanec Counters

[Adion]

Ik gebruik dus al QueryPerformanceCounter() and QueryPerformanceFrequency() om zo goed mogelijke timing te hebben.
De timing lukt goed, zolang ik de 100% cpu belasting niet erg vind, zelfs al benut ik er slechts een 60% van.

Ik denk toch wel dat windows in kleinere stukken als 5 ms switched tussen de verschillende taken, dus lijkt het mij dat er toch een soort sleep functie moet bestaan met een hogere resolutie?

Ik ga er in mijn code trouwens ook niet van uit dat ik 200 fps heb, ik gebruik voor verschillende bewerkingen ook wel de deltatime die ik krijg door de performance counter aan het begin te vergelijken met de vorige waarde.

[curry684]

LordLarry schreef op 13 november 2002 @ 14:42:
En is er een harde garantie bij die performance counters dat die altijd kloppen? Volgens mij niet.

Tis een hardware feature dus ik mag hopen van wel.

Als de CPU load erg hoog is gaan er hoe dan ook gaten vallen lijkt mij. Zo is windows nu eenmaal opgebouwd. De beschikbare tijd wordt zo goed als mogelijk verdeeld, maar sommigen krijgen gewoon voorang en wat er niet is is er niet. Geen CPU cycles over? dan wordt je performance counter code niet aangeroepen...

Als je even wat searching doet hiero kun je wel ergens een topic vinden waar ik uitleg hoe je realtime kunt draaien onder Windows... needless to say is dat niet het best mogelijke plan

Btw. je kunt ook korter sleepen door Sleep(0) aan te roepen. Dit staat ook bekend als een 'yield', oftewel dat je programma 'buigt' voor het OS, waardoor die alle draaiende processen 1 timeslice toe kan bedelen waarna jijzelf meteen weer aan de beurt bent.

[.oisyn]

kun je niet gewoon een timer control aanmaken en de interval op 5 ms zetten?
Je code zet je dan in je timer event, en klaar is kees

[Adion]

Thanks, die Sleep(0) ga ik ff proberen dan, eens kijken wat dat geeft.

[LordLarry]

Als je geen garantie wil, maar toch een hogere resolutie in je timing zou ik ook voor de performance timers gaan. Die kunnen je een veel hogere resolutie geven. Je kan daar een sleep functie vervanger mee maken als je wilt. Even zoeken in de google groups en je vind het kant en klare code daarvoor. Maar ik kan niet vaak genoeg herhalen dat het nog geen garantie geeft. Het kan 1ms duren het kan 1s duren. Daarom was mijn eerste tip ook dat je je prioriteit van je process omhoog schroeft zodat je vaker cpu cycles krijgt zodat het de kans kleiner wordt.

PS: Sleep(0) is ook onderdeel van de high res sleep code

[ Voor 0% gewijzigd door LordLarry op 13-11-2002 15:06 . Reden: ps ]

[Adion]

Voor zover ik weet is een vb timer control nog veel erger om mee te timen qua nauwkeurigheid.
En als ik mij niet vergis mis je een event als je terwijl nog bezig was.
Dus als ik er 6 ms over doe, dan zal de code slechts elke 10 ms worden uitgevoerd, terwijl mijn huidige implementatie tenminste zal blijven loopen en dus toch om de 6 ms uitgevoerd worden.

[johnwoo]

Adion schreef op 13 november 2002 @ 15:05:
Voor zover ik weet is een vb timer control nog veel erger om mee te timen qua nauwkeurigheid.
En als ik mij niet vergis mis je een event als je terwijl nog bezig was.
Dus als ik er 6 ms over doe, dan zal de code slechts elke 10 ms worden uitgevoerd, terwijl mijn huidige implementatie tenminste zal blijven loopen en dus toch om de 6 ms uitgevoerd worden.

Ik geloof dat er 1 WM_TIMER message in de queue kan staan, dus als de interval 5 ms is en je doet er 6 ms over, dan zal ie daarna direct beginnen aan de volgende cycle. Maar na de 5e WM_TIMER sla je er dan idd eentje over, alhoewel het interval dan nog steeds 6 ms is, en geen 10. Je krijgt een soort interferentiepatroon.

En de VB timer control is idd vrij onnauwkeurig; ik geloof dat ie slechts tot op ca. 15 ms werkt, en dat zou zelfs nog wel eens hoger kunnen uitvallen.

[curry684]

johnwoo schreef op 13 november 2002 @ 16:58:
[...]

Ik geloof dat er 1 WM_TIMER message in de queue kan staan, dus als de interval 5 ms is en je doet er 6 ms over, dan zal ie daarna direct beginnen aan de volgende cycle. Maar na de 5e WM_TIMER sla je er dan idd eentje over, alhoewel het interval dan nog steeds 6 ms is, en geen 10. Je krijgt een soort interferentiepatroon.

En de VB timer control is idd vrij onnauwkeurig; ik geloof dat ie slechts tot op ca. 15 ms werkt, en dat zou zelfs nog wel eens hoger kunnen uitvallen.

VB timer control is net als de Delphi TTimer een dunne wrapper om WM_TIMER, en dus even (on)betrouwbaar.