Talk:Clock skew

Include a simple definition

This page doesn't give a high-level description of what clock skew is. In particular, it jumps immediately to circuit design. It would be much more useful to start by saying that clock skew is simply that two or more clocks are offset from each other by a constant.

Suggestion: If a clock has a positive drift compared to some reference clock, it simply means that it is ahead of the reference clock by some constant. Similarly, if a clock has a negative drift compared to some reference clock, it simply means that it is behind of the reference clock by some constant. If the drift is not constant, and changes over time, another phenomena is playing in, called clock skew (refer to the clock skew page). —Preceding unsigned comment added by 193.10.65.222 (talk) 10:14, 7 January 2009 (UTC)

How about quoting from here?

How to: Clock Skew Can Save Your Overclock And Memory

Dukeofgaming (talk) 17:16, 16 May 2009 (UTC)

Jitter

I think jitter should probably be included in the equations for beneficial clock skew. Fresheneesz 05:09, 18 May 2007 (UTC)

Zero hold time is preferred?

Yes, I agree that jitter should be included. In addtion to it, why zero hold time is prefered for ICs should be included.

Should the word "cannot" be "can" in the statement?

Positive skew and negative skew cannot negatively impact setup and hold timing constraints respectively (see inequalities below).

Carl Horton 04:10, 18 November 2008

really two articles

This is really two articles: one on circuits and one on networks. This should be split. Asmeurer (talk ♬ contribs) 20:02, 7 December 2008 (UTC)

error?

In the "Beneficial skew" section H is the hold time of the destination register should not this be H is the hold time of the source! register, —Preceding unsigned comment added by 92.205.35.134 (talk) 01:34, 30 May 2009 (UTC)

definition not correct

The article says: "On a network such as the internet, clock skew describes the difference in time shown by the clocks at the different nodes on the network."

IMO this definition is not correct, see e.g. the definition in RFC 1305 where the difference in time is denoted as "offset" and the difference in frequency is denoted as "skew": "Unless indicated otherwise, the offset of two clocks is the time difference between them, while the skew is the frequency difference (first derivative of offset with time) between them. Real clocks exhibit some variation in skew (second derivative of offset with time), which is called drift; however, in this version of the specification the drift is assumed zero."

Gst (talk) 07:36, 11 August 2009 (UTC)

I agree, for me the skew is also the first derivative. 129.132.28.20 (talk) 13:48, 23 November 2009 (UTC)

Suggested clarification to the Clock Skew definition and sign convention

I’d like to suggest a clarification to the Clock Skew section, specifically the formula: T_skew(i, j) = T_C,i − T_C,j In most digital‑timing and static‑timing‑analysis (STA) contexts, skew is defined directionally as: Clock skew = arrival time at destination − arrival time at source This convention is used by industry‑standard STA tools (Synopsys PrimeTime, Cadence Tempus, OpenSTA) because the sign directly determines how skew affects setup and hold timing: Positive skew (destination later) helps setup and hurts hold Negative skew (destination earlier) hurts setup and helps hold Under the current Wikipedia formula, the sign is reversed relative to this widely used convention. This can be confusing because the text description of positive/negative skew matches the STA convention, but the formula uses the opposite sign. Suggested improvement: Either (a) reverse the formula to match the standard STA definition, or (b) explicitly state that the article uses a different sign convention and explain how it relates to the industry‑standard one. For example: “Note: Some timing‑analysis tools define skew as T_dest − T_src. The formula below uses the opposite sign convention.” This small clarification would prevent confusion for readers familiar with digital design and timing analysis. Thank you for considering the update. Shadysal (talk) 00:54, 19 May 2026 (UTC)