millsecond in windows?

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
bcoffee
Posts: 3
Joined: Sat Apr 07, 2007 9:11 pm

millsecond in windows?

Post by bcoffee »

WE obtain the system clock at one second resolution from PC's CMOS.such as 21:23:22.
But people can access system time with a resolution at one millsecond in WINDOWS by API. such as 21:23:22.296.
Where WINDOWS gets the millsecond time (from PIT?)? And how Windows keep it at a certain accuracy?
User avatar
Kevin McGuire
Member
Member
Posts: 843
Joined: Tue Nov 09, 2004 12:00 am
Location: United States
Contact:

Post by Kevin McGuire »

http://www.beaglesoft.com/mainfaqclock.htm

Google "Real Time Clock"

In Linux I access the real time clock when writing software where I need precision timing.
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re: millsecond in windows?

Post by Brendan »

Hi,

bcoffee wrote:WE obtain the system clock at one second resolution from PC's CMOS.such as 21:23:22.
But people can access system time with a resolution at one millsecond in WINDOWS by API. such as 21:23:22.296.
Where WINDOWS gets the millsecond time (from PIT?)? And how Windows keep it at a certain accuracy?


Most OSs read the RTC once during boot, and then keep track of time internally using some other timer while they're running - the PIT, or the RTC's "periodic interrupt", etc.

Most OSs are also inprecise. For example, they might return milliseconds but keep track of time in 10 millisecond intervals, so that if you read the time at 1 ms intervals you might actually read 21:23:22.01 ten times before you read 21:23:22.02 (rather than reading 21:23:22.010, 21:23:22.011, 21:23:22.012, etc).

None of the timers in a typical computer are accurate for long periods of time. To improve accuracy you could use a utility to adjust the amount of time added to the timer each IRQ. For example if the PIT is set to generate an IRQ every 1 ms you could add 1.02 ms to the time count, where the difference has been set by users (from earlier measurements) to improve long term accuracy.

Also it's possible to use something like NTP (Network Time Protocol) to set the time on one or more machines according to the time on another (more accurate) machine. In this case you could also use NTP to fine-tune the amount you add to the time count. For e.g. if you check NTP every ten minutes and NTP says the PIT is slow then you could increase the amount you add to the timer count each IRQ to improve the timers accuracy between NTP time checks.


Cheers,

Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
bcoffee
Posts: 3
Joined: Sat Apr 07, 2007 9:11 pm

thanks!

Post by bcoffee »

I will use the CPU counter to measure the time interval of PIT.
User avatar
mystran
Member
Member
Posts: 670
Joined: Thu Mar 08, 2007 11:08 am

Re: millsecond in windows?

Post by mystran »

bcoffee wrote:WE obtain the system clock at one second resolution from PC's CMOS.such as 21:23:22.
But people can access system time with a resolution at one millsecond in WINDOWS by API. such as 21:23:22.296.
Where WINDOWS gets the millsecond time (from PIT?)? And how Windows keep it at a certain accuracy?


The method I've got, modelled basicly after Linux, is to read RTC at boot, then start counting from there. I actually keep my internal time in seconds and microseconds, but at boot I simply assume that the microseconds is 0. In most cases the RTC will be wrong several seconds anyway, so doesn't matter.

Currently I support PIT as timer, which is set to around 10ms by default. When I get an interrupt, I add "clock_ticklen_usec" to clock_time_usec, moving full seconds to clock_time_sec which is Unix time. The only really interesting part is clock_ticklen_usec, which in the PIT case is set to 10008 which is what one theoretically gets from a PIT when one aims for 10ms (at least if one prefers overshooting).

Ofcourse PITs aren't that accurate. But the key of having a variable, means that it can be adjusted at runtime. So if you synchronize with a NTP, you can adjust the clock_ticklen_us variable (with system calls) until your clock moves as fast as the NTP clock, and then temporarily increase/decrease it to have your local time slowly move into sync with the NTP clock.
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
bcoffee
Posts: 3
Joined: Sat Apr 07, 2007 9:11 pm

Does it easy got in windows?

Post by bcoffee »

Does it easy got in windows? I want adjust time in windows.
User avatar
mystran
Member
Member
Posts: 670
Joined: Thu Mar 08, 2007 11:08 am

Post by mystran »

This being an OS development forum, we can help with issues faced in developing new operating systems. For questions specific to some existing OS (like Windows) there's probably better places to ask.

That said, in Windows the easiest way to set time is to double click the clock in the task bar, and use the resulting window. That let's you adjust up to seconds. If you need more accuracy, the easiest thing to do is synchronize with NTP, which Windows 2000 SP4 and later support out of the box. In XP you can set that from the same place (get time automatically or something like that), for Windows2000, Google for "W32Time" and work from there. I've not been able to play around with Vista yet, but I'd guess it works similar to XP.

edit: don't worry if "net time" says it can't find a time server if you set it to use SNTP (simple NTP, any normal NTP server will do). That seems to be normal. Just set the clock manually off by few seconds, and restart the Windows Time service and see if it sets the correct time.
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
Post Reply