System clock running fast
Rich Raffenetti
Pentium II-based computer in our test network. The system is an Active
Directory domain controller. After the whole process is performed, the
system looks fine but the clock runs at approximately 1.57 times the real
time. It is not the BIOS time that runs fast, just the running system. Any
ideas? I can provide more details if needed.
<©¿©>
going fast or it may go real slow. Change the batery on the mobo and see if
that cures the clock.
Rich Raffenetti
The clock in the MB does not run fast. What runs fast is the clock in the
OS. That is, if we turn off the machine, the clock doesn't gain or lose
time. We think that the BIOS clock would be affected by a weak battery more
than the OS. We could be surprised...
Moreover, we have done this three times to two different restoration
platforms. There were three different source systems, two similar Compaq
Proliant 3000 machines and one fairly generic tower PC. All of them
resulted in fast running systems on the restored hardware. Each of the
source systems was a separate Windows 2000 Server AD domain controller in
our production network. The tower PC was generationally closer to the
restoration platforms. All of them showed the same 1.57 time gain.
We are doing this partly as a test of disaster recovery and partly to
establish a clone of our production network in a test environment for
exchange migration testing. With the test domain controller unable to keep
time, we expect the test enviroment to be of little value.
"<©¿©>" <us...@127.0.0.1> wrote in message
news:uVgK7.376$Pu1.3...@paloalto-snr1.gtei.net...
Jeroen Roovers
Well, call THEM! They built the thing apparently.
Jeroen.
"Rich Raffenetti" <raffe...@home.com> schreef in bericht
news:ewTPcrWcBHA.1988@tkmsftngp02...
Rich Raffenetti
"support licensing"! Compaq told us we would need to open a support call to
get help and the hardware warranty doesn't cover that. I don't understand
why I should have any other support. We have three domain controllers and
can run quite well on two.
We do think that Compaq would want to clear up this issue. But as you know,
you call support and you just talk to one person and that person becomes the
spokesperson for the company!
However, we do not see this as a Compaq problem. We observed the same clock
speedup when we restored the generic PC (see below). Right now we believe
it is an operating system issue and we've opened a support incident with
Microsoft. If we get a solution, we'll post it!
"Jeroen Roovers" <j.e.roovers(r-e-mo-ve)@planet.nl> wrote in message
news:9tipck$kq5$1...@reader06.wxs.nl...
> > "<ŠżŠ>" <us...@127.0.0.1> wrote in message
Jeroen Roovers
and other groups regularly get help requests from people obviously operating
high quality equipment. The support issue seems to hold: if a company like
Compaq delivers some version of Windows with a machine, it is usually bound
to deliver appropriate support for that version of Windows, at least in
driver support (updates and patches). Trouble is, they will usually try to
duck support, as employing 3 driver developers for a week simply costs too
much.
So if you call in on Usenet with a shiny supported machine, you ought to
have grasped the problem and seen where it actually is. If your installation
of Windows has a problem with timing, you contact the machine's maker, and
they ought to fix it. If nothing helps, you may call on Microsoft, but be
aware that they may very well send you back to the OEM that built your
machine + OS, or ask for your thankful dollars.
You are doing a good job asking around in newsgroups though, because it of
course provides a much faster way for information to get around than the
internal corporate moves played out to decide who supports (read: fixes)
what.
Notice also, that this reply to your message will actually help you get a
solution, as messages get older and are removed from the lists, and every
new addition to a thread will add to the proliferation of the call for a
solution to a certain problem. So keep posting for this case, and maybe
provide more (text) information as regarding the actual problem, because it
still is quite meager.
Jeroen.
"Rich Raffenetti" <raffe...@home.com> schreef in bericht
news:uV6ZDaidBHA.1936@tkmsftngp02...
Rich Raffenetti
2. I know that people shy away from reading lots of long rambling
discussions of problems so I try to avoid complex descriptions.
3. The problem is rather simple. We restored a complete backup of Windows
2000 Server for a root domain controller from a big Compaq box to a lesser
Gateway PC for use in our test network. The clock in the restored OS runs
fast. The clock gains .57 hours for every hour the system runs. We have
observed that the clock in the MB BIOS doesn't gain or lose time.
4. We observed the same for two different Compaq domain controllers as
source and for a quite generic PC domain controller as source. All of their
clocks in the restored systems ran 1.57 times the wall clock. We restored
to two different Gateway PC's.
"Jeroen Roovers" <j.e.roovers(r-e-mo-ve)@planet.nl> wrote in message
news:9tuoka$3qg$1...@reader07.wxs.nl...
> > > > "<©¿©>" <us...@127.0.0.1> wrote in message
Rich Raffenetti
Remember that in restoring a W2K root domain controller in an isolated test
network, the time of the restored machine started running at about 1.55
times the wall clock time. We were restoring the system to different
hardware but at this time we believe that different hardware is just a "red
herring".
In our test network we have not had a time server. Our dns machine was
running time service (NTP) but it was not configured as a "stratum 1"
server. Hence, when the DC asked that machine for time to synchronize, it
was told that the time was not authoritative. Here's where we think the
Microsoft code went wrong and computed the wrong clock skew!
When we had someone fix our dns box to be an authoritative NTP, then the
issue with the wrong clock speed went away!
So, we think there is a bug in the code that computes a skew of 1.56... when
no authoritative NTP server is available.
Seems like a sanity check would be in order! Or an event log message! I
would say that whenever a clock skew of greater than 1% is active, then
there should be appropriate messages to the event log. It's a signal that
something is wrong! A skew of 56% definitely sends a signal but without
some messages like the event log, it's as if no one recognized that it could
possibly be a problem!
You can run w32tm -v to determine the current clock skew in your W2K system.
It's a parameter called Adj and in my system the output shows
W32Time: Adj 100144 , Incr 100144 fAdjust 1
Note that the skew shown here is .144%
"Rich Raffenetti" <raffe...@home.com> wrote in message
news:uV6ZDaidBHA.1936@tkmsftngp02...
RobH
system onto a Pentium II- ... ' , is there any possibility that the o/s has
any processor-specific timing code in certain files that may differ between
III/II processors?
I suppose this information would only be found in the hardware
specs/programming guides for the processor, motherboard, and o/s re- timers,
etc.. Just wondering...
Regards, RobH.
"Rich Raffenetti" <raffe...@home.com> wrote in message
news:OOfWo7XhBHA.2412@tkmsftngp02...
Rich Raffenetti
Microsoft on this and they have been scratching their heads. It is obvious
from our observations that the Adj time value is set improperly and is not
corrected at bootup if a defective NTP server is queried for the time. The
NTP server was saying something like "I am not authoritative since I have
been unable to contact an authoritative time source". Until the time server
was made equivalent to a time source, our restored DC could not get a good
time. Because of that, we believe it traversed code that is seldom tested
and which has faulty logic. It would probably have been better to not have
any time source!
If you run w32tm the time values used by the OS, including Adj, are listed.
If we get a more definitive answer to our query, I'll be happy to post it.
"RobH" <ro...@telusplanet.net> wrote in message
news:OPFoUpfiBHA.2112@tkmsftngp04...
> > > > > "<©¿©>" <us...@127.0.0.1> wrote in message
Rich Raffenetti
Here's the scoop. It's a bug. There is a workaround.
For us the bug manifested itself because our time server in our isolated
test network did not get its time from a level 1 time server - god to time
servers. Therefore, when our DC asked for the time, it got a response which
said something like "here's the time but by the way you shouldn't trust me
because I can't get reliable time". Well, the programmer who wrote the code
evidently didn't expect to get such a response and she put in (or defaulted
to) a time skew of 56%! Have you ever seen a clock off by 56%? She didn't
write anything to the error log, to the display, or to any other log file.
Seems like it would have been a courtesy to do that!
Anyway, when we made our time server a level 1, then the DC got reliable
time and a good time skew.
This is the friendly version, there are some technical facts which might
interest you but I don't have them on hand. There's a program called w32tm
that will display its dialog with a time server. I think you have to
disable the time service before you run it. Early in the output three
numbers appear with some variable names. The one called ADJ, the first one,
is the time skew. Our number was 156xxx and a good number is 1001xx. This
means your system clock differs from the time server by 56.xxx and 0.1xx
percent respectively.
Well, you have to ask yourself if your situation is like ours was.
Possibly there are other circumstances where the time service gets a
response that was not programmed and also gets the bad (56%) skew value.
Hope this helps. We were told that the fix would probably not appear in
SP3 since that was in processing. It will be in SP4 I guess. We were not
given a patch. But it was categorized as a bug!
Rich
"Rich Raffenetti" <raffe...@home.com> wrote in message
news:e4OKKnoiBHA.2260@tkmsftngp07...