We are having a problem where the time returned by the command time() will start providing inaccurate time. The time will start to speed up very rapidly and the time will increase by minutes every second.

We have historically used windows 95 and windows 98 but recently we started rolling out XP computers. This problem does not occur on the win95/98 workstations. We had some batch and index servers running on NT 4.0 that were experiencing the problem as well.

We are able to counteract the symptoms of the problem on the batch servers by comparing the time and running the "NET TIME /SET /Y" NT command when we see that the time varies too long in our batch processes. However, now that we are rolling these computers out to the general user population, it is becoming a more significant problem.

We are running AREV 2.12 on an NT network with many users running CPUPLUS.

I saw an online discussion from Dana Corson from 1999 that sounded similar but with no resolution to the problem. Does anyone have a solution for this problem?

Thanks,

Dan Duffy

Primacy Relocation

The time on a Windows XP computer is synchronized in the following way:

W32Time will periodically compare its time with a time source, generally the authenticating domain controller.

(Look at the possibility your domain controller is overclocked or has a bad BIOS time chip! Failing that, we simply need to load W32TIME for NT on your server - so that the Newer XP W32time interface can synchronize with the server properly) See -

http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B246145

During startup, on the workstation, W32Time checks time every 45 minutes, until the local and server clocks have matched three times. After that, 8 hour intervals are used for checks. If there is a failure to obtain a timestamp, or a validation failure, the process starts over.

W32time uses the following algorithm:

If the local clock time of the client is behind the time received from the time source, W32Time will change the local clock time immediately.

If the local clock time of the client is more than three minutes ahead of the time source, W32Time will change the local clock time immediately.

If the local clock time of the client is less than 15 seconds ahead of the time source, W32Time will halve the clock frequency for long enough to bring the clocks into sync.

If the local clock time of the client is 15 seconds or more ahead of the time source, W32Time will quarter the clock frequency for long enough to bring the clocks into sync.

NOTE: The amount of time that the clock spends running at an unusual frequency depends on the size of the offset that is being corrected.

The standard MaxClockRate is 100144 and it is located at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config.

Also, users may be running a background task which messes with the system clock. Virus checkers, comms products, video drivers etc may well be culprits.

There is a fairly good explanation of your problem at

http://www.greyware.com/software/domaintime/product/w32time.asp

You could try a Charles Petzold PC Magazine utility "Clockrack"

http://www.pcmag.com/article2/0,4149,10202,00.asp

which offers a way of synchronizing to an internet based time server.

Steve

The Sprezzatura Group

World Leaders in all things RevSoft

Interesting information, but I would simply suggest using one computer for work time and the other for vacation time, thus maximizing fun!

Steve:

Thank you for your response. I think it might help if I give a little further explanation of the actual situation that is occurring:

1) The problem does not happen everytime that AREV is run on an XP or NT computer, it only happens sporadically. However, every XP or NT computer has the problem from what I can tell except the Index Server. The index server is an NT4.0 workstation and is running CPUPLUS with no post indexing processes and the batch servers are NT4.0 and are running different jobs than the index server and are NOT running CPUPLUS. All of the XP computers are running CPUPLUS.

2) The clock on the pc (on the task bar…lower right corner) stays correct, only the results returned inside of the AREV application using time() returns a rapidly increasing time.

3) Once the problem occurs on a particular XP workstation, the only true solution is to logout of AREV. The net time command just resets the time back to the pc time but unless I could run NET TIME every 5 seconds or so, the time will continue to drift off signicantly. For example, I am currently running NET TIME in the post read process of all AREV templates, and the time is correct upon reading the record, but by the time the user completes data entry and saves the record which could take 5 minutes if they get a phone call, the time at presave process may be off by hours.

4) The date never is affected by the problem… the time apparently must just loop within the current day.

5) All of the pc's at startup sync with one NT server's time. This includes the pc's on win 95/98 as well as the XP computers. The NT 4.0 batch/index servers sync directly via the internet to NIST time servers. Based on this, we didn't suspect the sync source as being the problem especially since it only affects time() inside AREV and not the clock on the desktop.

I hope this additional information might help and again if I am missing something in your response please let me know. Hopefully this additional information will help bring to light the problem.

Dan Duffy

Primacy Relocation

Dan,

If CPUPLUS was involved you'd expect the time to run slower in AREV, so I don't think this is part of the situation. CPUPLUS doesn't touch the clock in any way.

The fact that you get hours creeping (occasionally) within minutes suggests that there's some other task (virus scanning ???) that is involved, or else a memory corruption of the time register memory (in AREV or in DOS/BIOS).

Either that or else the PCs are overclocked somehow (possibly on a motherboard jumper setting).

Some more "fishing" questions for you:

Are you using any TSR's ahead of AREV ???

Are these on Intel CPUs ?

Is any powersave software active?

What brand of virus scanner is active?

Is the *.OV filespec excluded from scanning?

If you look at a directory listing in DOS, does it show crazy times on the time-date stamps (look in REVBOOT) ?

When you look at the Windows task manager - what processes are getting the most timeslice - typically what percentage?

If you isolate one XP PC from the network and run it for 24 hours, is the clock wrong at any stage ?

Steve

The Sprezzatura Group

World Leaders in all things RevSoft

Dan - a late thought - when you put the search words "overclocking utility" into google.com, you get a swag of video accelerator cards listed. What video cards are in use on your XP boxes?

Steve

The Sprezzatura Group

World Leaders in all things RevSoft

Steve:

Thanks again for your response. Based on your comments, I did some more research and found the following:

1) I spoke with a support person at revtech and he said that they do not recommend using AREV with XP or NT because this is a known bug. He said that the time() function uses an interrupt to get the time instead of getting it from dos. The person I spoke with said they do not know which interrupt it uses and they have no documentation on the interrupt that it uses.

2) I spoke with Dana Corson who had the similar problem and had requested help via the online discussion back in 1999. He said that they had narrowed it down to Word Perfect 5.1. He said that they found that one of 3 scenarios would occur:

After returning from a call of WP:

a) No problem would occur with the time.

b) The time would change but the time would increment correctly from the invalid time.

c) The time would start changing dramatically and would even loop but would not impact the date.

His scenarios do seem to correspond to our problems and we do use WP51 to generate all merged forms.

Based on this, absent from dumping AREV or WP (both of which I do not see as great alternatives), it sounds like we need to fix the interrupt after returning from suspending and executing WP.

Do you have any advice on this?

Again, thanks for all of your help.

Dan Duffy

Primacy Relocation

[email protected]

Dan,

I am aware of which interrupts are used for time() in AREV. I suspect that WP 5.1 is doing something (possibly in keyboard macros) which upsets the clock.

I guess this would require a little effort to resolve, as it requires some low-level assembly language routines to (a) diagnose the fault and (b) remedy it.

We could test the BIOS and DOS and Windows and the clock chip readout separately to see if any of the times were unaffected. We could then reset the faulty time buffer from a good/different source.

If the Windows time holds we could always reset the DOS time from Windows again. The SENL Eric Emu article on the $timeset routine is already available, and could be extended to do what you require in about two or three days. [email protected] for more details.

Steve

The Sprezzatura Group

World Leaders in all things RevSoft

Dan-

Something must have gotten mixed up in translation.

Arev works fine with NT/2000/XP with the usual DOS to 32-bit caveats.

We do know what the interrupts are, we do have documentation. We will not be modifying the code.

Thanks-

Mike Ruane

Mike:

I tried to get in touch with you and was headed off by the first level of support. I did not mean to misquote him, and I do think AREV is a wonderful product… in fact I was surprised with the impression I received from him when I asked the questions.

I'm sorry if I came across as if I had any problems with AREV or Revelation Technologies… just trying to get as much information as possible to get a problem solved.

Dan

Steve:

Thank you, this sounds like the solution. I will contact you to pursue this.

Dan

You're most likely on a network, in which case you'd like all users to be using the same time, so why not simply synchronize to the server time? I know a lot of sites do this at boot time or when launching Arev, but there's no reason you couldn't do it after completing your wp51 task.

View this thread on the forum...