Time

[dstastny]

I know there have been issues reported with RTC but that is not problem I am seeing as the RTC is running fine. My issue is post boot the accuracy of the system time diverges away from the RTC. If I call setclock load it goes back in sync. Now if I remember the Amgia OS was designed to function without a clock so timing was maintained via power supply cycle or vblank timing on the custom chips not sure I remember clearly which. When I look in Ranger that shipped with OS its says these frequencies are both 50. Well Im in USA and I am not aware of any 50 HZ power supply . And if I do the math they amount of time that the Amiga clock is diverging at sure does look like about a 10HZ. So is this a bug with motherboard misreporting or bug in OS? Any settings I can change to fix?

Thanks
Doug

[broadblues]

Your system time is gaining 12 minutes an hour?

[dstastny]

@broadblues. Yeah about that. I didn't notice at first as my coding was crashing a alot. Last few weeks I have had it running and timing. Reset with load hour later it would gain time. Real noticble after few days and no reboot.

Doug

[xenic]

So is this a bug with motherboard misreporting or bug in OS? Any settings I can change to fix?

I am also in the US and just ran "setclock load" after 1 hour 45 minutes of uptime. My system time jumped back 15 seconds; indicating that my system time is gaining about 8.6 seconds per hour. I'll need to try again later to confirm that result. That's nowhere as severe as your time gain but still unacceptable in my view.

I seriously doubt that there is any AC power going to the motherboard from the power supply but you'd need to check the specs for your supply to know for sure.

[broadblues]

So is this a bug with motherboard misreporting or bug in OS? Any settings I can change to fix?

I am also in the US and just ran "setclock load" after 1 hour 45 minutes of uptime. My system time jumped back 15 seconds; indicating that my system time is gaining about 8.6 seconds per hour. I'll need to try again later to confirm that result. That's nowhere as severe as your time gain but still unacceptable in my view.

That's not an unreasonable drift for a standalone machine. If you have PC I bet it's just as bad. My laptop drifts by somewhat more than that. My SAM in the same ballpark, except is lags rather than gains.

What machine are you on?

I seriously doubt that there is any AC power going to the motherboard from the power supply but you'd need to check the specs for your supply to know for sure.

I'm moderatly sure that UNIT_VBLANK etc are emulated on AmigaOS 4machines. Though I can't find the reference that made me think that.

[dstastny]

@Xenic if you run ranger what is it showing for Frequencies?

Doug

[xenic]

That's not an unreasonable drift for a standalone machine. If you have PC I bet it's just as bad. My laptop drifts by somewhat more than that. My SAM in the same ballpark, except is lags rather than gains.

What machine are you on?

I'm using an X5000 that I bought in August of last year. I ran a 6 hour test and the system time gained 52 seconds. My X1000 does far better than that. I never noticed the time drift before because I reboot a lot because of Odyssey crashes/freezes or testing code that I'm debugging.

[xenic]

@Xenic if you run ranger what is it showing for Frequencies?

Doug

CPU Speed: 1995 MHz
Front Bus Side Speed: 798 MHz
Time Base Speed: 24 MHz
Frequencies: VBlank: 50 PSupply: 50 EClock: 24937500 Hz

I think some of the frequencies might be emulated for the benefit of 68k code; not sure though.

[tonyw]

The system clock in all modern machines (not Classic) is derived by dividing the CPU system clock by the appropriate (large) number. Since the system clock is itself generated by a PLL linked to a cheap crystal, it's not by any means accurate and you take what you get.

The division ratio can usually be trimmed to get the free-running clock rate pretty close, but you're talking about U-Boot stuff, well before OS4 starts to run. I don't know if the clock trim can even be adjusted by the time that timer.device gets hold of it. The result should be constant within about 1 part in 10^6, but not necessarily accurate.

[nbache]

I don't know if the clock trim can even be adjusted by the time that timer.device gets hold of it.

That would be quite interesting to know.

If it were possible, somebody could make a small utility program to run a long-term test (say, 8 hours) to compare the system clock to a fetched NTP time and find an according adjustment for the constant, then use the result to make the adjustment in another small command early in Startup-Sequence (or even in a Kickstart module).

Best regards,

Niels