Motherboard / real time clock

My system clock (on my P/I-P55TP4N ASUS) loses time big time. That is Minutes/day or more.

I cannot obtain any help from ASUS so I try here.

Does anyone know what chip is used for the real time clock on this board?

Does anyone know if the CPU has suspend power over the real time clock?

Does the real time clock depend upon the system clock for its functioning or is is completely independent?

When the real time clock loses time it appears that the computer is locked up.

I currently suspect my motherboard is acting up in an intermittant way but have not been able to verify it.

Can someone suggest a GOOD diagnostic program that will allow me to look into these kinds of problems?

I have found an outfit in Australia that has 2 P/I-P55TP4 boards for sale at $58.00 AU and am on the brink of committing in that direction. I would like to have my feet more firmly planted before I risk the money.

Thanks

Rod

 

http://www.windowsbbs.com/showthread.php?s=&threadid=6488

 

Brett?
Step away from the computer and go get a coffee!
You just pointed right back to this same thread!

Daizy

 

OK!!

As the fates have it I went browsing one more time to see what I could find on the net about this problem. The following popped up.

http://www1.rm.com/docs/PC/00/1257.asp

The description of the problem found at this address matched exactly my problem.

It seems that the audio files:

Kmixer.sys, Portcls.sys, Usbaudio.sys and Wdmaud.sys located in C:\Windows\System32 needed updating.

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q242937 is Microsoft's contribution to the discussion.

The rm.com site mentioned above contains a link for downloading updated versions of the system drivers. I found the dates listed for the drivers on the rm.com site did not match the dates I obtained when I installed the drivers. The version numbers matched.

I'll report back in a week or so and let you know if my problems have dissappeared.

Have a good one!!

 

Daizy wrote:

Two quotes from Einstein spring to mind:

and

 

You have noooooooo idea of the link you were gonna post do ya my water logged friend?

 

No. None whatsoever

 

Well,

It did not take me a week to discover that Microsoft's touted solution to the problem did not work for me.

My Real time clock has lost 15 minutes in less than 24 hours.

This makes my original posting on this thread active and awaiting constructive suggestions.

How did Brett and Daizy get in here?

 

The institutions were all full and we had to go somewhere

This is the thread I initially intended to link to:-

http://www.windowsbbs.com/showthread.php?s=&threadid=6388&highlight=clock

Is it helpful?

BTW - to avoid confusion, what you refer to as the RTC, I've referred to as the system clock in that other post.

 

Brett,

Thanks for the reply. My system is under Seti most of the time. I did not notice a problem in the early years. In fact I noticed the problem what in synchronization with the presence of Onstream's Echo software installation before I noticed any other program sensitivity. Echo was installed years after I started 24hr/day Seti.

I have Atomic Clock V2.6 as a 2 week ago addition to my arsenal. As indicative I have removed Echo and exited Seti and sychronized my RTC (#@$%^), I just got autosynchronized and lost the accuracy of having my prior synchronization 06/30/02. This data run starts anew

I would not be bonkers about this situation were it not for the fact that the operating system freezes for the duration that the RTC is set back in time. I have prior data to show this.

I have not gotten far enough in my studies to know whether or not a clock resynchronization eliminates the freeze periods.

The freeze periods get longer and longer as the computer up time increases. The only fix I have found for this thus far is to power down and up.

So could it be that my system clock is balking or is it that there is a program loop that acts maniacal?

Listening to the radio (tuned to a convienent frequency in the AM band) says the computer is still clocking away but failing to do its normal stuff.

Hearing is one thing. Seeing is better. That is why I asked about a program that would allow one to look around in the guts of the system.

Yes, I'm a retired Electrical Engineer. I have a scope and the tools necessary to do some detailed looking.... Should I know the pinouts on the motherboard... which I don't.

If I cannot find any "free" help along these lines or with my software investigations, I guess I'll have to revert to my speciality and the details.

My RTC has lost 4 seconds in 17 minutes as configured and noted above.

 

OH boy!

....problem what in synchronization...

Should read... problem was in synchronization...

 

This is a bit of a mystery to me. The OS clock (or ticker) reads the time from the RTC at boot and the RTC is thereafter not referenced until the next reboot (during uptime the OS clock is maintained via hardware interrupt IRQ0).

So ... if a reboot results in the time being corrected then the problem must be related to software interfering with the IRQ0 processes (which would also explain the freezes) whereas if a reboot does not result in a correction, the issue is almost certainly battery/motherboard related.

I'd suggest that you try disabling some startup programs to see whether you can, through a process of elimination, identify the cause of the interference.

 

I keep looking on the net and keep finding resources that I did not find previously.

Microsoft's Q189706 also addresses this problem. I have noted that a hot boot does not reset the clock.

It was the process of shutting down programs that revealed that Echo was a contributor to the problem. While trying to get the latest firmware flash to take on the Onstream Drive, I discovered that there was something wrong with the drive. It refused to be flashed. (probably had a body hate syndrome or something ). It took me a month to get through that.

I'm trying to establish a baseline now that Echo/Onstream has been dealt with. No Seti. No Onstream. Problem is weather keeps getting between me and the goal. Power line bumps out here in the country on the end of a transmission line browns me and blacks me out.

Process is... Synchronize. Check time loss at approximately 24hr intervals for 3 days. End of three days... Power down. Power up. Check time loss. Repeat 24 hr interval checks for another three days. Power down. Power up. Check time loss.

Of course regular computer usage continues through the test period. This complicates understanding but I (and my granddaughter) are keeping a log of program usage.

I'll check back when I have something definitive.

 

RTC is hardware - Windows has its own clock.

When you reboot - if the time resets and is correct then your RTC and system battery are fine.

Once windows boots - it has taken a time sample from the RTC then it runs a "software clock" applet.

Depending on system load it will begin to go out of sync. - I have a K6-300 system with no modem or printer - running W98, its system resources are at 99%. - It runs fast (the clock) it gains time.

Now a twin of that system - (same MBD, CPU, & MEM) running limewire 24/7 will lose 30hrs over 8 days. Reboot the system and the clock is spot on.

Anything that is eating up alot of CPU cycles will afect clock function - when using system in an office enviroment - I recomend 3 reboots a day. - Once on arrival, when you leave for lunch, and when you leave for the day. (this assumes they want the systems left on - ours were because the IT dept did an anti-virus update push between 2-4am.

 

Profgab101

Thanks for the comments. I'm onto this. I'm currently building up a time loss so that I may reboot and check what happens.

So far I have 00:56:45 accumulated. I want the hour to contain a digit before I reboot.

My current idle time Processor usage is around 24% per the sytem monitor and peaks around 30% while typing this message.

Over the last three days of continuous up time, my clock has lost 10.56, 13.55 & 17.49 minutes/day. The corresponding computer use time over and above base line for my test has been 23, 182 & 38 minutes. (I'm logging my computer useage.)

The increase in time lost per day is 2.99 & 3.94 minutes/day with the 182 minutes computer use corresponding to the 2.99 minutes/day increase in time lost per day and the 38 minutes computer use corresponding to the 3.94 minutes/day increase in time lost per day.

My tenative conclusion on this minscule bit of data is that running Excel 7.0, IE 6.0, Outlook Express, the printer, a copy utility, the address book, does not affect the daily rate of time loss significantly.

 

I have isolated the culprit.

It is Microsoft!

My hardware clock keeps time well. I obtained Atomic Clock to insure 9 second accuracy.

To many programs in the system tray results in Windows starting to do funny things. My audio monitoring with an AM band radio of the RF leakage from my computer case indicates that the operating system is locked in some tight loop during the I/O freezes I experience.

These freezes apparently lock everything including disk, monitor, keyboard, etc. Thus the loss of clock time and long program loads.

The length of these freeze periods increase in polynomial time and are reset to zero whenever the computer is rebooted.

I sent a polynomial fit to Microsoft that described my data. They did not seem interested and tried to deflect me to their pay for service support. I dropped the matter at that point. Maybe a competitor will wake them up. I HOPE!

The freezes are related to the number of programs competeing(sp?) for CPU cycles. The problem lessened when I "emptied" my system tray.

This ends this thread for me.

Thanks folks,

 

Hi folks,

It has been a while but I have made it to the end of my study of this problem.

Microsoft's operating system looks at the clock once for every boot. From then on it 'flies by the seat of its pants' so to speak. This system software clock keeps time by using a counter and and interrupt.

That's not too smart. When you get too many programs in the system tray the interrupts begin to occur less often. The result is that the counter is not updated regularily and precisely.

That's problem number one.

Problem number two is that somewhere in the bowels of Windows there must exist a programming loop that waits for some escape condition to develop. For reasons unidentified Windows gets caught in this loop. The result of this is that ALL I/O ceases until Windows comes out of the loop.

This loop is affected by the number of programs in the system tray. It is reasonably independent of the system software clock.

I obtained Atomic Clock which updates my system software clock via the internet. Keeping the system software clock on time did not change the performance of Windows when it came to exiting its pathological loop.

Removing some of the programs from the system tray is the only thing I could find that would modify the looping behavior. I still have to periodically shut down and restart my computer to escape the problem.

The bottom line is... Keep few programs in the system tray and reboot often.

A comment on Atomic Clock for those that might seek it out. I sets the clock to the correct time minus 3 to x seconds. This is due to internet delays being variable. If you want more accurate timeing that this, I suggest you use a digital watch that you synchronize to WWV and then synchronize the system software clock to the digital watch. Of course you can leave the digital watch synchronization out if you wish. I have found that I can obtain a Watch to System Software Clock synchronization error of 1 second this way.

Have a good one.