Clock problem caused by a Fortran software

^
^ ^ ^ ^ ^ ^ ^ ^ ^
^ This is a new one for me.. I can't imagine anything that CVF could be
^ doing that makes a difference here.
^
^ However, it helps to understand how the clock is handled by the OS.
^ The OS schedules an interrupt every 10 milliseconds (usually), and
^ when this interrupt fires, it adds a preset value to the variable it
^ uses for the system date. It is not actually reading a hardware
^ clock. There is a mechanism to write the date/time back to the
^ hardware clock, but this typically happens only at shutdown or perhaps
^ infrequently while the system is running.
^
^ I could see the possibility of a highly compute-bound application
^ preventing this interrupt from firing in a timely (!) manner, but the
^ usual effect of that is to make the clock seem slow, not fast.

I have experienced something like this. A very simple stress test
application, written in FORTRAN but making STDCALLs to interact with
imaging devices via TWAIN. Repeated opening and closing of the Data
Source (the software associated with the hardware). One particular
device, the Intel QX3 play microscope, behaved very curiously. On the
first machine I ran the test on, after a few hundred open-close
cycles, the machine had ground to a halt - swapping itself to death,
basically. My log file recorded that the cycle time had suddenly
started to increase dramatically, from around 10 seconds to ultimately
about two and a half minutes before everything finally collapsed in a
heap. Where it got really weird was on the second machine I tried.
This time the log file recorded that the cycle time had stayed rock
solid at around 10 seconds, but the system clock had lost about three
quarters of an hour.

Andy

--
sparge at globalnet point co point uk

We must be fearless
We must have fearlessness
We must not be fearlessnessless
We must not have fearlessnesslessness
We must be fearlessnesslessnessless

This is a new one for me.. I can't imagine anything that CVF could be
doing that makes a difference here.

However, it helps to understand how the clock is handled by the OS.
The OS schedules an interrupt every 10 milliseconds (usually), and
when this interrupt fires, it adds a preset value to the variable it
uses for the system date. It is not actually reading a hardware
clock. There is a mechanism to write the date/time back to the
hardware clock, but this typically happens only at shutdown or perhaps
infrequently while the system is running.

I could see the possibility of a highly compute-bound application
preventing this interrupt from firing in a timely (!) manner, but the
usual effect of that is to make the clock seem slow, not fast.

I have read in the past that some anti-virus software has had a
side-effect of making the clock run slow or fast - how, I don't know.
I haven't experienced this myself. You may want to see if disabling
your anti-virus software makes a difference here.

Please send Visual Fortran support requests to

Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH

User communities for Intel Fortran and Compaq Visual Fortran:
#

Certainly not deliberately... :) Don't see just how it could interact
unless there's something in there to do usage checking and it mucks up
the setting via a system API call somehow (or your driver code is doing
something similar).

I note you're on CVF 6.5, you might consider the 6.6 downloadable
upgrade, but I think it will not have any bearing on this particular
phenomenon.