Re: [Dev-C++] [Warning] Clock skew detected. Your build may be incomplete.

[Mac R. <re...@no...>]

At 06:15 PM 6/28/02 +0200, Colin Laplace wrote:
>Hello,
>
>Just to say you can set a delay before the compiler will be called (in 
>Compiler Options), if you really want to get rid of this message.
>
>Greetings,
>Colin
>
>On Friday 28 June 2002 13:45, you wrote:
>> On Fri, 2002-06-28 at 11:09, Pierre Delporte wrote:
>> >  Nothing serious ! I am not sure about this. It is always anoying to have
>> > to compile two, three or more times to get a good result. I think, to
>> > improve the quality of the product, that this matter should be
>> > investigated with high priority.
>>
>> Always? I only experience this once every 20 compiles.

Just trying to understand what is happening.  If adding a delay to each
compilation step (prior to invoking gcc/g++) fixes the problem, it sounds
like it is possible for compilation to occur and linking to start before
the clock has advanced enough for 'make' to be able to distinguish that
time has elapsed.

Example:

main.o, timestamp 5:13:47pm

I tell it to make, so it saves my file:

main.cpp, timestamp 5:25:23pm (timestamp of autosave prior to make)

which occurs REALLY FAST, and GCC compiles main.cpp REALLY FAST, so that
the saved .cpp file and the .o file both have the same timestamp (not even
one second has elapsed between save and compilation of this file):

main.o, timestamp 5:25:23pm

Now the linker pass comes along and has some kind of problem, because it
can't tell if main.o is newer than main.cpp or not.  Does this sound like
the problem?  If so, either make needs to be modified to somehow use more
accurate timestamps (difficult, since it relies on file timestamps, which
are OS determined), or GCC needs to be modified so that if it completes
compilation in less than one second, it delays a second to let the
timestamps differ.  If this actually is the problem, it is only going to
get worse as machines get faster.

My Athlon XP 1900+ with Barracuda ATA IV driver does seem to get the clock
skew warning quite frequently, suggesting that it might be CPU and/or
harddrive speed dependent.

Thanks for the delay suggestion Colin!  (And for including the capability).
 Delaying for 1 second _should_ fix the problem, if it is the one just
described, and a one second delay shouldn't be a problem for most builds.
If this really IS the problem, it might be worth modifying Dev-C++ to
always add a one second delay, or to time the runtime of GCC and add a
second if it looks like no time has passed.  Can that even be done, or is
make in complete control?

On a somewhat unrelated note, I do know that if you ever use
QueryPerformanceCounter() and QueryPerformanceFrequency() to calculate
really accurate times, you can get clock rollback.  If you use these
functions and want proof, write a loop that simply stares at the results
from QueryPerformanceCounter() over and over again for several seconds.
Keep track of every time the clock jumps backward -- you'll get one pretty
quickly.  I looked at the bit patterns for the clock, and the problem is
that the clock register is not protected while it is being incremented, or
while it is being read.  So *while* you are copying off the 64bit integer
(which takes at least 2 instructions, probably 3), the value of that
register changes.  Most of the time it isn't a problem, but since you are
reading out portions of the integer, when a carry occurs that crosses the
boundary between the pieces, you can end up with really funky numbers:

Example, shorted into a byte and nybbles for ease of typing:

Clock value   : 0101 1111

Read High Half into variable -> 0101 0000

Clock updates : 0110 0000

Change index in preparation for reading low half

Clock updates : 0110 0001

Read Low Half into variable -> 0101 0001


Notice that the high half changed *after* you had already read it, but
before you managed to read the low half.  This is the problem with the new
processors having a clock that increments once for every instruction, but
which takes multiple cycles (only one instruction, but it internally takes
longer) to read.

The moral?  If you use super high resolution clocks
(QueryPerformanceCounter or directly playing with the RDSTC opcode), check
the clock a few times for each read, and reject silly numbers.  Your timing
code will be slightly slower, but you will not report negative elapsed
times or unnecessarily long times (imagine if your recorded start time was
the bad read of 01010001 above, and then very shortly afterward you took
another reading and got an accurate 01100100.  You would think that almost
00100000 ticks had occurred, when only 00000100 ticks had actually
occurred.  That's not bad with a byte and nybbles, but think about a 64 bit
int with two long int halves -- the reading would claim that over 4 billion
ticks had occurred...)

Sorry for the rambling...
Mac
-
 _____________________________     /"\
 Mac Reiter                        \ /    ASCII Ribbon Campaign
 Nomadics, Inc.                     X     Against HTML Mail
 re...@no...               / \   (To join the campaign, simply use
                                          this in your signature.)