WindowsForm Timer tappar tid

[sneaky]

Sitter och pular lite med ett projekt i Visual Studio/WinForms/C# och har lite problem med Timers. Programmet ska läsa 0-10 rader från en textfil per sekund men problemet är att timern halkar efter väldigt väldigt fort. Jag är fullt medveten om att dessa timers inte har någon vidare precision men i mitt fall så tappar den cirka 8 sekunder på 10 minuter... Fullt så dåliga är de väl inte?

Min första tanke var att jag försökte göra för mycket i "Tick"-funktionen eller att något annat i mitt program störde men för att utesluta det så skapade jag ett nytt projekt, släppte en Windows Forms Timer och en label med WYSIWYG-editorn. Vid varje tick ökar jag en räknare med 1 och sätter labeln till detta värde. Men, samma problem.

Jag har även provat System.Timers.Timer och System.Threading.Timer (i kombination med en winform timer som uppdaterar labeln) med samma rackiga precision.

Jag behöver ingen superprecision på något vis, +-10 sekunder på tre timmar duger alldeles utmärkt.

Förväntar jag mig för mycket eller gör jag något fundamentalt fel? Jag är väldigt grön på detta område.

[Skogen]

Timern räknar ju millisekunder, 1000 millisekunder=1 sekund
Du får väl justera timern så den går så som du vill ha den. Kör ett långtest och räkna på diffen.
Typ 998 millisekunder=1 sekund eller 1002 millisekunder=1 sekund

[sneaky]

Det blir väl inte direkt portabelt? Om jag vill köra programmet på en annan dator så får jag ju kompilera en version per dator, känns lite bökigt.

[Skogen]

Timern är inte bättre än så.
Du behöver ju dock inte göra olika versioner.
Du kan ha en liten tilläggsrutin i programmet så du kan justera klockan.

[kimmen]

Jag skulle föreslå att programmet tittar på vad klockan är (eller någon liknande källa) och är berett att göra flera operationer åt gången när man får timermeddelandet. Sådana där timers köar inte missade körningar t.ex., men det går ju att ordna själv genom att läsa av klockan varje gång. Skulle jittret bli för stort kan man ju sätta timern på ett kortare intervall, t.ex. på 100 ms, och låta programmet titta på klockan och köra ikapp så långt som går varje gång man får ett timermeddelande.

[sneaky]

Japp, det lutar åt att titta på klockan. Jag kör ett test just nu för att se hur det funkar.

Tack för tipsen.

[Icecap]

Precis som med µC fungerar en delay() inte som tidhållare. Och Timer-funktionen är i grunden en delay().

Polla systime "ofta" och använd den som bas, då har du ett rimligt stabilt system som är porterbart. Behöver du en noggrannhet på ±10 sek på 3 timmar är det inte svårt, problemet är närmast med vilken upplösning du vill utföra funktionen. Kan du acceptera att den jämt har en noggrannhet på -0/+1 sek är det bara att ha en pollning var 500ms för att kolla systime.

[frazer]

Det behövs inte mycket för att en timer, som körs i samma tråd som ditt GUI, ska halka efter.

Jag skulle rekommendera en egen tråd med en egen tidshållning (time:a allt du gör och pausa tråden (Sleep) den återstående tiden.

[BEEP]

Gör som Icecap föreslog, använd systemtiden.
GetTickCount function GetTickCount64 function

Jag tror att det här ska fungera?
--- Vid start av programmet ---
minTid = SystemTid + 1000 (1 sekund)

--- I programmet ---
Om SystemTid > minTid gör följande, minTid = minTid + 1000, läs rader från textfil

[frazer]

Så länge en timer är med i bilden kan du aldrig vara säker på timingen, p.g.a att den delar tråd med GUI (som jag skrev tidigare).

[JimmyAndersson]

Och apropå det, bara så att Sneaky vet, *ifall* det inte hjälper att använda systemtiden:

Tänk på att Windows klocka inte är speciellt stabil.
Systemets bakgrundsprocesser kan låsa datorn korta stunder,
t.ex när Windows Update letar nya uppdateringar.
Det kan iofs bli så även utan något speciellt krävande körs.

Jag vet inte hur det är i Windows 8, men om man har klockan framme
i äldre Windows-versioner så kan man ibland se hur sekundvisaren fastnar korta stunder.
Det kan i värsta fall göra att en rättad klockan går flera sekunder fel efter en minut.
Det verkar alltså som att Windows bara kollar hårdvaru-klockan vi boot.

I arbeten där det är viktigt med rätt tid (t.ex radio med TT-nyheter) så är det nästan standard
att man installerar en separat NTP-klientmjukvara, just pga detta.
(Det finns visserligen en "inbyggd" NTP-klient i Windows, men den körs för sällan.)

[BEEP]

@JimmyAndersson
Och jag som trodde att klockan var synkad med RTC på moderkortet. Själv så har jag aldrig haft några problem med att den släpar efter RTC och det beror nog på att jag håller mina OS rena från onödiga processer.

[JimmyAndersson]

Precis. Det beror garanterat på det.

Vet inte varför Windows inte använder RTC'n hela tiden. Det hade varit mycket smidigt.

[johano]

Det gör det:
http://msdn.microsoft.com/en-us/library ... s.85).aspx

Att sen _klockapplikationen_ kan "fastna" lite ibland är helt naturligt, det är ju ett program som vilket som helst
som får sina timeslices tilldelade av kärnan...

/johan

[JimmyAndersson]

Från länken:
"When the system first starts, it sets the system time to a value based on
the real-time clock of the computer and then regularly updates the time."

Det har jag aldrig märkt...

Det vore intressant att veta hur pass ofta som detta "regulary" är.
Jag menar, om uppdateringen från RTC'n verkligen fungerade så skulle Windows
inte behöva ha någon inbyggd NTC-klient som uppdaterar klockan en gång i veckan.

(Diverse radiostationer skulle dessutom ha kastat pengar i sjön
genom att ha anlitat mig för att lösa det störande problemet med att
datorerna kör igång nyheter och ljudloggor för tidigt eller för sent.)



Men låt säga att uppdateringen från RTC'n fungerar, då blir resultatet alltså såhär:
Först gör diverse bakgrundsprocesser att klockan halkar efter
och sedan gör RTC'n att klockan blir rätt.

Försök att ta tiden (i sekunder) på något genom att titta på en klocka
där en person ibland bromsar sekundvisaren och ibland ställer den rätt.


Som jag skrev tidigare så kan det hända att detta har ändrats i Windows 8
och då kan trådskaparen bortse från mina inlägg. Förutsatt att trådskaparen verkligen kör Windows 8 förstås...





edit:
Kom att tänka på en tråd där jag fick problem pga Windows tids-instabilitet:
http://elektronikforumet.com/forum/view ... 69#p671869

"Mätningarna gjordes var 15e sekund. Vid några tillfällen såg jag att den förväntade tidpunkten i loggen inte stämde,
så jag gjorde ett php-script som gick igenom LogTemp's logfiler och jämförde den senaste avlästa tidpunkten med den förra.
Där såg jag att dessa inställda "var 15e sekund" hade varierat ganska mycket....
Om jag sätter gränsen för vad som ska räknas som fel till >=18 sek så får jag 14.6 % fel."

(Hela den trådens problem försvann när jag bytte till Linux. Tyvärr hjälper ju inte det i det här fallet.)