Clock skew detected - Warning

In hardware, clock skew usually means the clock signal arrives at different components at different times.

But in the case you found, it sounds like the tool chain or the OS messed up the time-stamps. What tool chain and under what OS are you using?

Both warnings apply to the same thing.

Normally, the compiler (on systems using makefiles, the make tool) does not always recompile everything. It just detectes whether a source file has a newer date than the previously compiled object file. If so, it has been changed and therefore needs to be recompiled.

If the compiler detects that a file is newer than 'now', this indicates an inconsistency in the timeline. If this happens, you are warned that the nomal compile mechanism might be messed up and maybe not all files that would require recompiling have been recompiled.

In your case, it is possible that the background NTP client has updated and corrected your system time by a few seconds back ,between saving the source file and starting the compile process. It is not critical if just a source file is newer than 'now'. it is critical, if an object file has been compiled, then the time has been set back and then the source file was changed. In this case the object file is still considered 'newer' than the soure and therefore not recompiled.

If your IDE allows it, select 'build all' or use 'make clean' and all compiler-generated files will be renewed regardless whether there are outdated or not. It takes some additional time but after then all is well again.

Thanks a lot for your help!

I am using CCS4, and will try to make a clean, if such warnings appear again. It was important to me, to find out, that it has nothing to do with my clocks in the controller.

Thanks guys!

Hans.

Dear Jens-Michael,

Jean-Michael said:

In your case, it is possible that the background NTP client has updated and corrected your system time by a few seconds back ,between saving the source file and starting the compile process.

I got the same "clock skew deteced" message so I googled and found this post.

Is "NTP" acronym for "network protocol"?

 

Another question is that the original questioner didn't mention anything relateing to network condition, how did you infer that he has network related time reset problem? I am asking this also partly because nor did I use any network-based time updating/correction but I also got the same "clock skew detected" message.

 

Zheng

Zheng Zhao said:

Is "NTP" acronym for "network protocol"?

Network Time Protocol. It is the way Windows (and others) synchronizes its RTC with an internet server. This happens at startup as well as in regular intervals, since PC realtiem clocks are notoriously inprecise (to say the least). NTP keeps the PC to the standard time by requesting the time from a (freely available) time server (which is intended to have the correct time). Th eprotocol reduces skew cause by transmission length and latency by doing some smart calculations and round-trip measurements.

It won't adjust your time if the skew is larger than a certain amount (you'll see a warning message in the systems message log), but a jump of a few seconds back or forth is always possible.

Zheng Zhao said:

how did you infer that he has network related time reset problem

It was the only thing that comes in mind when there seems to be a sudden time change (unles she played with the calendar while compiling). There might be other reasons, but I have no cle which ones. Also, msot people have a constant internet connection these days, and the TNP client is one of the background services everyone has running on his system and almost nobody knows about. As it is a default part of Windows and (I think) Linux and is normally just working.

 

Dear Jens-Michael,

I have an old 32-bit Windows XP PC which runs CCS only and has no internet connection, but the "clock skew detected" message still appears. So how can it still be attributed to Network Time Protocol?

 

Zheng

Zheng Zhao said:

I have an old 32-bit Windows XP PC which runs CCS only

If there is a network layer, then there is most certainly the NTP client also running. It is a system background process, not an application you actively start. It is installed and activated by default.

Zheng Zhao said:

and has no internet connection

That's rather uncommon these days. I too have an old 32bit Xp machine (at home and at work). But both have internet access as soon as they start up. Always since I did set them up 6 years ago.

Zheng Zhao said:

the "clock skew detected" message still appears

Do you have external storage (NAS)? The make process compares the file date/time with the system date/time. If you are workign with a file storage that has its own timebase (e.g. a NAS device - network attached storage, whcih can be an external RAID HD, even if connected using USB or ESATA)), then the file date is based on the NAS time while the compiler compares it against the PC time. Which will trigger the skew warning if the NAS has a time that is in the future compared to the PC.

Zheng Zhao said:

how can it still be attributed to Network Time Protocol

Not if you really have no internet connection (LAN connection to any local computer that might serve as NTP server), then of course not. This is so uncommon these days that without explicitely knowing it I didn't even think of this possibility.
Since you're posting here and the forum is in teh internet, I didn't think that you could do the work on a different computer that is not connected. :)
Now that I know, well, see the other possibility above.

 

Dear Jens-Michael,

I forgot to mention that fact (without Internet connection) earlier. Nor do I have any external storage.

I shall try to diagnose this sometime later, it doesn't appears to affect anything beyond this "clock skew detected" message.

 

Zheng

Well, compilers are almost the only applications which care for a file date. Especially if the 'detected' skew is in the second range.
There's almost no other application where the creation date of a file is compared against current time within a few seconds of creation.

Even versioning systems won't 1) do an update operation only seconds after the last file change and 2) usually compare teh content, not the date.

The windows explorer doesn't show the seconds at all (so nobody would notice, even if he could look that fast).

No, I think nothing but a compiler suite (which saves the source file immediately before starting the compiler process and therefore the tiem comparison) would detect or care for a file that is written 'in the future'.

There are some other setups aside form external influence possible. Besides a bug in the file system driver whcih causes files to be written with wrogn fiel date in som ecases, there might be special file systems (such as an encrypted partition with e.g. TrueCrypt) or a program inside a VM that accesses a drive from the host system. Here the clocks may differ too. (well, i guess that could be counted as a very special case of external storage)

Thinkable other causes might (but shuldn't) be problems due to lags (the application is shortly stopped after it has read the system time but before checking the file date) in combination with a delayed write due to write caching. Maybe the flushing of the write cache was triggered by the IDE asking for the file info, which in turn caused the delay. Weird combination but not completely impossible.