Monday, April 24, 2017

Supply-Side - Trickle Down - Voodoo - Zombie Economics Article by Paul Krugman


One of my favorite conversations is when one of my conservative friends says, "what we need to do is cut taxes."  To which I respond, "how will you pay for them?"  The answer is always "through growth."

As George H.W. Bush so correctly called out Ronald Reagan for "voodoo economics".

Paul Krugman destroys Supply-Side economics in this great article titled Zombies of Voodoo Economics in the New York Times

Some of my favorite points Dr. Krugman brings out are:

"Back in 1980 George H. W. Bush famously described supply-side economics — the claim that cutting taxes on rich people will conjure up an economic miracle, so much so that revenues will actually rise — as “voodoo economic policy.” Yet it soon became the official doctrine of the Republican Party, and still is. That shows an impressive level of commitment. But what makes this commitment even more impressive is that it’s a doctrine that has been tested again and again — and has failed every time."

Below are key points in Krugman's article:

"So history offers not a shred of support for faith in the pro-growth effects of tax cuts.

Oh, and let’s not forget recent experiences at the state level. Sam Brownback, governor of Kansas, slashed taxes in what he called a “real live experiment” in conservative fiscal policy. But the growth he promised never came, while a fiscal crisis did. At the same time, Jerry Brown’s California raised taxes, leading to proclamations from the right that the state was committing “economic suicide”; in fact, the state has experienced impressive employment and economic growth.

In other words, supply-side economics is a classic example of a zombie doctrine: a view that should have been killed by the evidence long ago, but just keeps shambling along, eating politicians’ brains. Why, then, does it persist? Because it offers a rationale for lower taxes on the wealthy — and as Upton Sinclair noted long ago, it’s difficult to get a man to understand something when his salary depends on his not understanding it."



Sunday, April 23, 2017

Fly Fishing In Harrisonburg, VA For Rainbow Trout



I knocked off an item on my bucket list yesterday - my youngest son Tim and I went out fly fishing in the Harrisonburg, VA area with a great guide named Jacob from Mossy Creek Fly Fishing.

Tim took a course at JMU on fly fishing, but it did not include actually going out on a river or stream to fly fish, so I told him that we would  do it before he graduates.  He graduates a week from this upcoming Friday, so we went yesterday.  While it was raining and 52 degrees, we still had a fantastic day fly fishing since we were learning (mostly me as Tim took a course) and landing rainbow trout.

I had never even cast a fly rod, so it was all new to me except for what I saw in the movies.  Here are some high level bits that I am documenting so when we go again I can remind myself and perhaps others might find it of interest.

  • Get a guide.  Jacob was great and took us through:
    • The basic of casting in a field before we got into the stream.
    • A cast that does not hit the water but is used for positioning where the fly will eventually land is called a false cast.
    • When you lay the fly down in the water you typically only let it float down stream 10 or 15 seconds before you do it again.
    • When you cast, the total range should be between 10 and 2 o'clock -- in other words, not big long motions put more restrained.
    • When you reel in a fly rod, many times you are "stripping" it which means you are reeling in by hand by pulling on the actual line itself and letting it drop to your side.
    • Common mistakes are not waiting long enough on the back swing as the line gets longer and this causes it do bunch up.  In other words, the longer the line, the longer you should wait on the 2 o'clock back swing before you move to 10'o clock.
    • The challenging and fun part of fly fishing is seeing where the fish (rainbow trout in our case) is in the water, having the right fly and casting it right where the trout will attack it and the properly setting the hook.  All easier said than done.
    • Just like with any other fishing, set the hook, put then you will need to PLAY with the fish, by letting it run when needed, but keeping it tight when it is coming toward you or tired so you don't loose the fish.  In other words - balance.

Above is Tim fly fishing and below he is with a great rainbow trout.


Below is a movie of Tim catching and landing the rainbow trout.



Below is the rainbow trout that I caught that I was thrilled about!


Above is me, Tim and Jacob back at Mossy Creek Fly Fishing where we had to pick up some t-shirts as additional memories of a GREAT day!  Thanks Jacob!

Below is the Dirty Dave's Fly Shoppe that Peter E bought me 15 years ago when he was on an Alaska cruise and I HAD to wear my first time fly fishing :-)  Note in the photo above I changed to my standard Corvette t-shirt since I was drenched to the bone being outside for 6 hours in the pouring rain in my "not really rain-proof" jacket I had on.

Thursday, April 20, 2017

Great Night At Wizards Playoff Game and Washington, DC Sports Trifecta

My youngest son Tim called at 2pm yesterday and asked me if I wanted to go to the Wizards playoff game with him. Absolutely!  Below is Tim and me before the game.
 
 

We had a great time and it was a fantastic game. It was a big night for Washington DC sports teams last night with a DC Trifecta - Wizards win 2nd game of playoffs against the Hawks, Caps win playoffs to tie the Leafs and Nats crush the Braves. As the Washington Post reported today, "Wednesday night’s D.C. sports trifecta didn’t prompt the jubilant euphoria we saw from the D.C. sports trifecta 729 days ago, when the Wizards beat the Raptors to take a 2-0 first-round series lead, the Caps beat the Islanders to even their first-round series at two games apiece, and Yunel Escobar and the Nats walked off the Cardinals." 
 
 

Tuesday, April 18, 2017

Most Impressive of 3D Printing -- GE Printed a Helicopter Engine



This is the most impressive example of 3D printing I have seen to date. This article is at Additive Manufacturing. The article is by PETER ZELINSKI, Editor-in-Chief, Additive Manufacturing and is titled:

 
This is a real game-changer on both technical and economic fronts.  Zelinski quotes from a GE article:

"They [Ehteshami and others from GE and Morris] moved a few machines to a drab building away from the main campus across Interstate 75 and started experimenting in secret with printing pieces of an old commercial helicopter engine. “We took six engineers and told them go and see what portion of the total engine they can print,” Ehteshami says. “We hid them from our financial management, because we didn’t want them to cut our budget.”

The clandestine effort paid off. Within 18 months, the team was able to print half of the machine, reducing 900 separate components to just 16, including one segment that previously had 300 different parts. The printed parts were also 40 percent lighter and 60 percent cheaper.To make these parts the ordinary way, you typically need 10 to 15 suppliers, you have tolerances, you have nuts, bolts, welds and braces,” Ehteshami says. “All of that went away.”

The technology of going from 900 parts to 16 is tremendous, but the supplier side affects are even in more interesting.  This goes back to a question that I have often pondered going back to the beginning of MTConnect in 2006 where one of my slides had the bullet, "The Network Is The Machine Tool" and that question is, "when will see the 'Linux_ation' of discrete manufacturing where large CNCs go the way of mainframe with a sea of 3D printers?

What GE has accomplished is certainly a significant milestone.

Sunday, April 16, 2017

One decade since the tragedy at Virginia Tech

It has been one decade since the tragedy at Virginia Tech.

My thoughts and prayers go out to all the families, relatives and friends of those who lost their lives on April 16th, 2007 in this senseless tragedy.

The picture below was on the Collegiate Times in 2007 at VT:
 
There is a permanent memorial at VT. The Collegiate Times has a nice article describing the memorial.

My son, John, was a freshman at VT during this time.  He graduated with a BS and Masters from the School of Engineering in Computer Science.  My middle son, Michael, graduated from VT with degrees in Professional Writing and Creative Writing.  I have countless friends that have gone to that great school in Blacksburg.

John wrote a very touching post on Facebook that I would encourage you to read.

My memories of last April 16th started with a phone call from my wife. Julie called and said, "just wanted to let you know that John is fine." At the time I was on my SunRay reading email while on a con call when she called my cellphone. She never calls me during theday since she is a school teacher. "Why would John not be be fine?" I asked. She asked me if I was watching TV or listening to the news. Of course I was not watching TV or listening to the news. She explained what was going on. I immediately interrupted the Sun folks on the con call and quickly said, "I had to get off the call, there was a shooting at my son's school."

It was then that I turned on the TV and was shocked to see the peaceful and beautiful VT campus on the news. I started getting emails, phone calls from literally around the world checking on John. You sometimes forget in casual conversation that you mentioned something about your kids that your friends and colleagues remember. Every time a call came, I paused the DVR. I was getting the current updates from friend, colleagues and family all around the world via email and non stop phone calls. As the numbers kept rising, it became more and more surreal.

My son John was working for the Collegiate Times during his freshman year of 2006 to 2007.  He put together a very nice week long history of events starting on April 16th through April 23rd that shows what happened each day.
I can not imagine the horror the students and faculty must have felt. There was an article in the post today by Nick Miroff, titled, "A Year Later, Virginia Tech Is Still Healing" is a well written article worth reading. As Miroff points out:
"Virginia Tech students have learned to talk about it in shorthand, if they talk about it at all.   Below are a few stories from that day.

They do not use the words massacre, or shootings, or rampage. They call it "April 16th," and sometimes not even that. To say "four-sixteen" is enough. Everyone knows."
I have been back to VT many times since April 16th, 2007 both as a parent and working for Sun Microsystems where I have given talks and brought down Sun's thought leaders to speak at VT's ACM where my son John is President.  Each time, the first thing I do is visit the memorial
          Governor Kaine has did a good job demanding there was the VT Task Force.  Governor Kaine stated:
"On April 16, 2007, Virginia Tech University suffered a terrible tragedy. Today, my thoughts and prayers are with the victims and their families and the entire Virginia Tech community.
"In the year that has passed since that horrible day, we have grieved for those we lost and prayed for the comfort of their loved ones. We have rejoiced in the recovery of those who were injured. We have been inspired by the unfaltering hope and Hokie spirit of Virginia Tech. And we have renewed our commitment to do even more to learn lessons from that day and to make our campuses and communities safer.
"As I think about the victims' families, I am at a loss for words to express what is in my heart. The courage and strength they have shown in the face of such tremendous, tragic loss is awe-inspiring. We have been inspired by the resilient Hokie spirit of Virginia Tech, both in Blacksburg and around the world. Since that tragic day last April, the unshakeable sense of unity and hope demonstrated by the Hokies has touched the lives of people around the world. Their focus on pulling together to support their school and each other in the days after the shooting, and their commitment to public service through the VT Engage program in the months that followed has moved us all.
"We still have work to do. A continued commitment to improvement is the best tribute we can pay to those who lost so much. And as we move forward, we will continue to be inspired by those in the Hokie Nation."


VT seems to have made the right changes. The VT Task Force seemed to not pull any punches when it came to how the University should have dealt with the events on the morning of April 16th, 2007. As the AP reported and I FULLY AGREE with Governor Kaine about purchasing firearms at gun shows. Virginia needs to get its act together.  This loophole is INSANE!


"Gov. Timothy M. Kaine proposed mandated background checks yesterday for everyone who attempts to purchase firearms at gun shows - legislation that he called critical to helping prevent future tragedies like the shootings at Virginia Tech. Many families of those killed or injured in the April shootings have called on legislators to close Virginia’s so-called gun show loophole, which allows people to purchase firearms from unlicensed sellers at gun shows without having to submit to background checks. Under current Virginia law, only licensed dealers are required to run background checks on customers.

“If by doing this, we can keep one family from having to go through what these families have suffered, it will be the best thing that the legislature will do this year,” Kaine said at Virginia State Police headquarters, surrounded by several of the victims’ families."

VA continues to be a backward state and allows the gun show loophole.   I also called into the Kojo Nnamdi Show when he had an anniversary show on the VT shooting.   If you go to the 11:52 mark, you can hear my statements and question that goes until the 13:14 mark.

"Courage is the first of human qualities because it is the quality which guarantees all others."  Winston Churchill

The tragedy at Virginia Tech is still heart wrenching. As a parent of a VT freshman, it is still hard to comprehend the magnitude of this tragedy. There were many heroes on VT's Campus on April 16th, 2007. Many are well documented in the press.

There are five individuals who were behind the scenes that are absolute heroes in my mind. Those five heroes are the individuals who run online Collegiate Times which is VT's main online paper and kept the world informed on the latest breaking news coming out of VT on this senseless tragedy. These five individuals were literally working around the clock, giving up sleep to keep their fellow students, parents, family, friends, faculty and the rest of the world informed.

These five unsung heroes
all have the "first of human qualities" - courage. It would have been perfectly understandable if these five individuals would have given up when their servers went down. But they did not. They had the courage to literally work around the clock to get the server back up *and* keep the rest of the world informed of the latest updates to one of the most of horrific days in the history of our country. The five
individuals are:

Chris Ritter, Online Director
Tim Tutt, Web Developer
John Edstrom, Associate Web Developer
Gabriel Martinez, Associate Web Designer
Collin Smith, Multimedia Editor


One of the many amazing statistics is that the Collegiate Times received up to 53 million hits by early afternoon on Monday April 16th.
My sister, Dr. Julie Edstrom, (yes, same first name as my wife) was one of the first counselors to arrive at VT from Norther VA to help with the grief counseling.   Volunteers came from all over.

Wikipedia has a nice history of the Collegiate Times with the picture that appeared on the Collegiate Times April 17th, 2007, Edition titled "Heartache."




Below are just some of quotes on the fantastic work that
these five unsung heroes did under
tremendous pressure.


The OnLine Newshour on PBS

"The Internet became a prime place for people to
get the news out of Blacksburg.
The college
newspaper, the Collegiate Times, scooped the major
media, getting the story online, right after the
first shot rang out, and staying on it non-stop
ever since.


The 104-year-old paper received up to 53 million
hits by early Monday afternoon,
forcing the site
down for a time. It also listed some of the dead
early Tuesday morning,
prompting the New York Times
Web site and other news outlets to link to the
Collegiate Times."

The Shield - University of Southern Indiana Student Newspaper
"The information on the Web site is remarkable.
Besides the list of confirmed deceased, the site
provides a graphic map of the shootings, a photo
gallery, personal accounts and interviews and
related stories ranging from emerging donation
details to the impact on the nearest hospital. The
staff has handled the facts correctly, but not
without compassion, which is a difficult task.


The Collegiate Times editorial says, "When
considering the number of deceased victims, 32 is
devastating, but those lives are not just a number,
each one is a member of our community." Journalism
cannot be disregarded due to a personal tragedy,

since citizens rely on journalists for information.
Such journalists must remember, however, that
although horrific tragedies stir media attention as
sensational, there is nothing sensational about
human suffering and coverage must be conducted
tastefully.

Well done Collegiate Times staff.

To those that believe campus newspapers are a waste
of time and funding, let this tragedy serve the
purpose of proving the necessity of campus
newspapers nationwide."
Chronicle of Higher Education

"National Public Radio is among news organizations
that have profiled and praised Virginia Tech
student newspaper, The Collegiate Times, which has
become a crucial source of information for other
reporters covering Monday's events.


The papers online edition, said NPR's Larry
Abramson, has grabbed international attention
indeed, on Tuesday The New York Timess home page
linked to the student publications list
of
confirmed victims of the shooter. Mr. Abramson
also pointed out that Collegiate Times staff
members know how to mine Facebook for information
inaccessible to many older reporters who are
unfamiliar with the social-networking site
." -
WGHP Fox TV VIDEO:


"The team at The Collegiate Times, the campus
newspaper, will remain. So far, they have been
setting the pace for all journalists"
Middlebury Campus


"The face of a crisis, the writers, photographers
and editors of Virginia Tech's student daily,
The
Collegiate Times, transcended their roles as
college journalists to not only inform their
community, but to inform the world. With many local
news sources shut out, only limited comments coming
from Virginia Tech officials and an entire campus
on lock-down, the importance of these students'
work was heightened to an extreme.
The written,
photographic and video posts to The Times website
throughout the day were among the most vivid and
honest portraits of the campus available.
Working
from computers outside of their offices, the
students held nothing back, and produced a raw,
emotional narrative of the tragedy. Their reporting
was effective, critical and in every sense, brave."


Editor and Publisher


"While the editors of the student newspaper went
about their work with inspiring leadership,

internal communications by Virginia Tech
administrators showed the University was less than
fully prepared. As more and more details about the
sequence of events have been released, it has
become clear that administrators did not notify the
entire campus or order a full lockdown until more
than two hours after the first round of shooting
began. Whether or not any of the deaths in the
second round of shooting could have been avoided,
we should realize the need for all institutions to
prepare for the unimaginable. And
in the face of
this shooting, college administrators everywhere
should recognize the need to share information with
their communities quickly and clearly, even as the
full extent of a crisis may remain unknown."



"The college paper at Virginia Polytechnical
Institute kept a running account of the tragedy
that struck the campus today,
with more than 30
students gunned down in at least two areas of the
campus, a dorm and a classroom. The shooter is
allegedly dead as well, but not identified. It is
not known if he was a student ...

Here is how the student-run Collegiate Times
reported it, blog-style, with the most recent
posting first.
A full article is now posted there,
which includes the note that police "are also
investigating if it has any relation to the recent
bomb threats on Tech's campus."
Seattle Post Intelligencer

"For unique reporting on the massacre read the
Collegiate Times, Virginia Tech's student-run
newspaper."
University Daily Kansan

"While news organizations like CNN have done a
thorough job in covering Monday's events, I'd like
to point the readers of kansan.com to Virginia
Tech's student newspaper, the Collegiate Times.
After overcoming early technical difficulty when
the news initially broke, they've done what I feel
is an admirable job as the student voice of the
Virginia Tech community.


In the process of learning about these tragic
events, be sure to not overlook the students
themselves. http://www.collegiatetimes.com"
WRAL

"I found a couple sites with unique angles on this
story. One of the most interesting is The
Collegiate Times, which is VT's student newspaper.

Their staff apparently first reported this shooting
this morning. The server is overwhelmed right now,
but it will be interesting to check their coverage
in the days and weeks ahead."
Forbes

"M
onday's shooting at Virginia Tech provided a
grim, real-time stress test for the effectiveness
of Web 2.0 technologies. And on Monday, all of them
seemed to work: Information flew through text
messages, blog posts, Web sites, online videos and
social networking sites.


The Internet reacted to the event immediately--and
more quickly than Virginia Tech administrators, who
took two hours to warn students, via e-mail, about
a first shooting. The Web site of VT's student
newspaper, the Collegiate Times, crashed when
students flooded it after the first shooting. As a
replacement, students created a low-tech blog,
CollegeMedia.com.

It posted the first entry about the event at 9:47 a.m.,
minutes before the second shooting began."

Yahoo News

"The student newspaper, the Collegiate Times,
regularly updated its website proving to be a
valuable resource for the campus as well as the
national media."
Daily Californian


"And as this happened, students at the Collegiate
Times, the Virginia Tech student newspaper, were
able to live-blog the days events. The Web site
began the day with a post at 9:47 a.m. EST,
reporting Shots were fired on campus and
provided continuing updates throughout the day. The
entries of the papers staff provide an
illuminating window into the fear and questioning
that doubtless gripped the campus in those
uncertain hours."



"The Collegiate Times, Virginia Tech's campus newspaper,
was the first media outlet to break the story Monday with
on-line reports of shots fired on campus."
Manhattan Mercury

"No amount of on-the-job experience or education
could have prepared Kelly Furnas
for what he's
faced this week in his capacity as an editorial
advisor to the campus newspaper at grief-stricken
Virginia Tech University.

.....

To be honest its been pretty much non-stop working
with the student newspaper I have not had time on a
personal level to sit down and digest everything
yet," Furnas said.

The Collegiate Times, Virginia Tech's campus
newspaper, was the first media outlet to break the
story Monday with on-line reports of shots fired on
campus.

"I can't put into words how proud I am of our
students,"
Furnas said. "They have provided
desperately needed information to their readers,
and they have done that with gusto. I think the
campus newspaper's reputation with the students
here has helped a lot."


The Age (Australia)

"'The school's student newspaper, The Collegiate
Times, filed up-to-the-minute online dispatches.
At
4.44pm: "Police have confirmed that the shooter
took his own life." At 4.54pm: "University
Relations has confirmed 31 deaths at Norris Hall,
in addition to two deaths at West Ambler Johnson."
Gulf Times

The Collegiate Times (its server quickly crashed
and a blog written by editors with messages from
students appeared instead on the web site of the
newspapers owning company), as well as to media
outlets around the world, including CNN and the
BBC. Regardless of where the contributions are
aimed, the back and forth on facebook.com and other
social networking sites are equally an instant and
new resource for news producers and reporters



NPR


"As reporters from around the world descend on
Blacksburg, Va., one publication stands out:
Virginia Tech's student newspaper, Collegiate
Times, is doing a truly remarkable job of covering
the story."


About 15 staff members were rushing to update the
site about every 15 minutes with news of the
convocation, shooting investigation and candlelight
vigil plans.


"We're getting like 10 billion phone calls,
everyone from Al Jazeera to tiny radio stations in
Iowa,"
Kendall said.
LA Times


"The paper's scoops included eyewitness accounts of
the shootings, interviews with a classmate of the
shooter and a list of victims' names that was
posted late Tuesday
. A reporter was one of the
first to question administrators about why they
didn't warn students during the two hours between
the two shootings Monday morning."

Poyneronline

"The Web staff for Virginia Tech's student
newspaper, The Collegiate Times, was also
scrambling for solutions after its servers crashed
around 10:30 a.m. the day of the shootings.

Online editor Chris Ritter's main goal was to get
the site back to its original state -- a large,
graphical and Flash-intensive homepage. When that
couldn't happen, Ritter and his staff opted for a
simple text page with blue background -- to ensure
they could communicate information quickly to
users
. After that page continued to overload its
own server, The Collegiate Times tech adviser,
Scott Chandler, suggested that the staff use the
College Media server, the parent company which
hosts the publication's site.

Once the site stabilized on the additional server,
The Collegiate Times began posting photos and
videos to a third server usually reserved for
design research and development. To prevent
crashing again, a Virginia Tech server is now
hosting videos and photos for the site.


Monday night The Collegiate Times staff redesigned
its homepage from scratch to have a Web site
that
was "intuitive and a graphically pleasing display"
of its special content for the shootings. The
Collegiate Times began creating breaking-news
multimedia when escaped convict William Morva shot
two police officers at Virginia Tech on the first
day of school last August.

Since then, Ritter said users are looking at the
Web for information more than ever before, and the
staff has adopted a Web-first attitude change."

Roanoke Times on CT:
Coping Through Journalism Video
 

Hopefully the healing will continue for those directly affected...

Tuesday, April 4, 2017

MTConnect Date and Time Accuracy

 
I had a very interesting discussion last week on MTConnect Dates-Times and thought it deserved a blog post. 
 
This post includes three primary references and I include all of them here (as opposed to just links) to make it easier to read.  I also highlighted the truly important bits on this topic.

  1. Data and Times Info from Part 1 of MTConnect 1.3
  2. W3's Date and Time Formats that MTConnect references
  3. MSFT's QueryPerformanceCounter (QPC) aka OS Tick Interval
    • This document gets in the level of detail that should answer most, if not all, of the questions on accuracy and number of decimal fractional digits.  Nice reading if you have trouble falling asleep tonight as well :-) 
The bottom line is that the MTConnect specification for accuracy in fractions of seconds is limited (as stated in the MTConnect spec below) by the capabilities of the device AND (Dave 
​Edstrom ​
adding this part) the OS that the SW is being run on as well as the communication platform.  For example, Windows 10 "limits" you to 100 nanoseconds provided your HW is capable of this resolution -- as stated 
​in the MSFT documentation ​
below.

While there is an option for “real-time” in MTConnect in a configuration file for an adapter and the sample command, it is more accurate to say "near real-time".  Real-time in the computer industry means a guaranteed response time from event to system response

A guaranteed response time is not part of the MTConnect specification
 
While customers like to talk about absolute maximums, the truth is with MTConnect if you are worrying about nanoseconds or microseconds, you probably need an honest to God realtime OS and are doing some "kids, don't try this at home" type of Caron Engineering work
​ that requires an extremely tight feedback loop.​

MTConnect was not designed to take the place of a closed-loop system where guaranteed response times of nanoseconds or microseconds are a hard requirement

Per the MTConnect Spec:  When the interval parameter is provided (with the MTConnect Sample command), the MTConnect® Agent MUST find all available events, samples, and condition that match the current filter criteria specified by the path delaying  interval milliseconds between data or at its maximum possible rate. The interval indicates the delay between the end of one data transmission and the beginning of the next data transmission.  A interval of zero indicates the Agent deliver data at its highest possible rate.

Below is from Part 1 of the MTConnect 1.3 Specification:​
 
Dates and times will follow the W3C ISO 8601 format with arbitrary decimal fractions of a second allowed. Refer to the following specification for details: http://www.w3.org/TR/NOTE-datetimeThe format will be YYYY-MM- DDThh:mm:ss.ffff, for example 2007-09-13T13:01.213415. The accuracy and number of decimal fractional digits of the timestamp is determined by the capabilities of the device collecting the data. All times will be given in UTC (GMT).

Date and Time Formats

Status of this Document

Submitted to W3C 15 September 1997

This version:
http://www.w3.org/TR/1998/NOTE-datetime-19980827
Newest version:
http://www.w3.org/TR/NOTE-datetime
Authors:
Misha Wolf <misha.wolf@reuters.com>
Charles Wicksteed <charles.wicksteed@reuters.com>
Document Status

Status of this document

This document is a NOTE made available by the W3 Consortium for discussion only. This indicates no endorsement of its content, nor that the Consortium has, is, or will be allocating any resources to the issues addressed by the NOTE.
This document is a submission to W3C from Reuters Limited. Please see Acknowledged Submissions to W3C regarding its disposition.
Comments on this document should be sent to datetime-comments@w3.org.

Abstract

This document defines a profile of ISO 8601, the International Standard for the representation of dates and times. ISO 8601 describes a large number of date/time formats. To reduce the scope for error and the complexity of software, it is useful to restrict the supported formats to a small number. This profile defines a few date/time formats, likely to satisfy most requirements.

Introduction

The International Standard for the representation of dates and times is ISO 8601. Its full reference number is ISO 8601 : 1988 (E), and its title is "Data elements and interchange formats - Information interchange - Representation of dates and times". A discussion of ISO 8601 has been written by Markus Kuhn.
ISO 8601 describes a large number of date/time formats. For example it defines Basic Format, without punctuation, and Extended Format, with punctuation, and it allows elements to be omitted. This profile defines a restricted range of formats, all of which are valid ISO 8601 dates and times. The aim is to simplify the use of ISO 8601 in World Wide Web-related standards, and to avoid the need for the developers and users of these standards to obtain copies of ISO 8601 itself.

A particular problem with ISO 8601 is that it allows the century to be omitted from years, which is likely to cause trouble as we approach the year 2000. This profile avoids the problem by expressing the year as four digits in all cases.
This profile may be adopted by standards which require an unambiguous representation of dates and times. As different standards have their own requirements regarding granularity and flexibility, this profile offers a number of options. An adopting standard must specify which of these options it permits.

Formats

Different standards may need different levels of granularity in the date and time, so this profile defines six levels. Standards that reference this profile should specify one or more of these granularities. If a given standard allows more than one granularity, it should specify the meaning of the dates and times with reduced precision, for example, the result of comparing two dates with different precisions.
The formats are as follows. Exactly the components shown here must be present, with exactly this punctuation. Note that the "T" appears literally in the string, to indicate the beginning of the time element, as specified in ISO 8601.
   Year:
      YYYY (eg 1997)
   Year and month:
      YYYY-MM (eg 1997-07)
   Complete date:
      YYYY-MM-DD (eg 1997-07-16)
   Complete date plus hours and minutes:
      YYYY-MM-DDThh:mmTZD (eg 1997-07-16T19:20+01:00)
   Complete date plus hours, minutes and seconds:
      YYYY-MM-DDThh:mm:ssTZD (eg 1997-07-16T19:20:30+01:00)
   Complete date plus hours, minutes, seconds and a decimal fraction of a
second
      YYYY-MM-DDThh:mm:ss.sTZD (eg 1997-07-16T19:20:30.45+01:00)
where:
     YYYY = four-digit year
     MM   = two-digit month (01=January, etc.)
     DD   = two-digit day of month (01 through 31)
     hh   = two digits of hour (00 through 23) (am/pm NOT allowed)
     mm   = two digits of minute (00 through 59)
     ss   = two digits of second (00 through 59)
     s    = one or more digits representing a decimal fraction of a second
     TZD  = time zone designator (Z or +hh:mm or -hh:mm)
This profile does not specify how many digits may be used to represent the decimal fraction of a second. An adopting standard that permits fractions of a second must specify both the minimum number of digits (a number greater than or equal to one) and the maximum number of digits (the maximum may be stated to be "unlimited").
This profile defines two ways of handling time zone offsets:
  1. Times are expressed in UTC (Coordinated Universal Time), with a special UTC designator ("Z").
  2. Times are expressed in local time, together with a time zone offset in hours and minutes. A time zone offset of "+hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes ahead of UTC. A time zone offset of "-hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes behind UTC.
A standard referencing this profile should permit one or both of these ways of handling time zone offsets.

Examples

1994-11-05T08:15:30-05:00 corresponds to November 5, 1994, 8:15:30 am, US Eastern Standard Time.
1994-11-05T13:15:30Z corresponds to the same instant.

Acknowledgments

This document draws on Chris Newman's Internet Draft "Date and Time on the Internet" (draft-newman-datetime-01.txt).

Acquiring high-resolution time stamp

Windows provides APIs that you can use to acquire high-resolution time stamps or measure time intervals. The primary API for native code isQueryPerformanceCounter (QPC). For device drivers, the kernel-mode API is KeQueryPerformanceCounter. For managed code, the System.Diagnostics.Stopwatch class uses QPC as its precise time basis.
QPC is independent of and isn't synchronized to any external time reference. To retrieve time stamps that can be synchronized to an external time reference, such as, Coordinated Universal Time (UTC) for use in high-resolution time-of-day measurements, useGetSystemTimePreciseAsFileTime.
Time stamps and time-interval measurements are an integral part of computer and network performance measurements. These performance measurement operations include the computation of response time, throughput, and latency as well as profiling code execution. Each of these operations involves a measurement of activities that occur during a time interval that is defined by a start and an end event that can be independent of any external time-of-day reference.
QPC is typically the best method to use to time-stamp events and measure small time intervals that occur on the same system or virtual machine. Consider using GetSystemTimePreciseAsFileTime when you want to time-stamp events across multiple machines, provided that each machine is participating in a time synchronization scheme such as Network Time Protocol (NTP). QPC helps you avoid difficulties that can be encountered with other time measurement approaches, such as reading the processor’s time stamp counter (TSC) directly.

QPC support in Windows versions

QPC was introduced in Windows 2000 and Windows XP and has evolved to take advantage of improvements in the hardware platform and processors. Here we describe the characteristics of QPC on different Windows versions to help you maintain software that runs on those Windows versions.
Windows XP and Windows 2000
QPC is available on Windows XP and Windows 2000 and works well on most systems. However, some hardware systems' BIOS didn't indicate the hardware CPU characteristics correctly (a non-invariant TSC), and some multi-core or multi-processor systems used processors with TSCs that couldn't be synchronized across cores. Systems with flawed firmware that run these versions of Windows might not provide the same QPCreading on different cores if they used the TSC as the basis for QPC.
Windows Vista and Windows Server 2008
All computers that shipped with Windows Vista and Windows Server 2008 used a platform counter (High Precision Event Timer (HPET)) or the ACPI Power Management Timer (PM timer) as the basis for QPC. Such platform timers have higher access latency than the TSC and are shared between multiple processors. This limits scalability of QPC if it is called concurrently from multiple processors.
Windows 7 and Windows Server 2008 R2
The majority of Windows 7 and Windows Server 2008 R2 computers have processors with constant-rate TSCs and use these counters as the basis for QPC. TSCs are high-resolution per-processor hardware counters that can be accessed with very low latency and overhead (in the order of 10s or 100s of machine cycles, depending on the processor type). Windows 7 and Windows Server 2008 R2 use TSCs as the basis of QPC on single-clock domain systems where the operating system (or the hypervisor) is able to tightly synchronize the individual TSCs across all processors during system initialization. On such systems, the cost of reading the performance counter is significantly lower compared to systems that use a platform counter. Furthermore, there is no added overhead for concurrent calls and user-mode queries often bypass system calls, which further reduces overhead. On systems where the TSC is not suitable for timekeeping, Windows automatically selects a platform counter (either the HPET timer or the ACPI PM timer) as the basis for QPC.
Windows 8, Windows 8.1, Windows Server 2012, and Windows Server 2012 R2
Windows 8, Windows 8.1, Windows Server 2012, and Windows Server 2012 R2 use TSCs as the basis for the performance counter. The TSC synchronization algorithm was significantly improved to better accommodate large systems with many processors. In addition, support for the new precise time-of-day API was added, which enables acquiring precise wall clock time stamps from the operating system. For more info, seeGetSystemTimePreciseAsFileTime. On Windows RT PC platforms, the performance counter is based on either a proprietary platform counter or the system counter provided by the Windows RT PC Generic Timer if the platform is so equipped.

Guidance for acquiring time stamps

Windows has and will continue to invest in providing a reliable and efficient performance counter. When you need time stamps with a resolution of 1 microsecond or better and you don't need the time stamps to be synchronized to an external time reference, choose QueryPerformanceCounter,KeQueryPerformanceCounter, or KeQueryInterruptTimePrecise. When you need UTC-synchronized time stamps with a resolution of 1 microsecond or better, choose GetSystemTimePreciseAsFileTime or KeQuerySystemTimePrecise.
On a relatively small number of platforms that can't use the TSC register as the QPC basis, for example, for reasons explained in Hardware timer info, acquiring high resolution time stamps can be significantly more expensive than acquiring time stamps with lower resolution. If resolution of 10 to 16 milliseconds is sufficient, you can use GetTickCount64QueryInterruptTimeQueryUnbiasedInterruptTimeKeQueryInterruptTime, orKeQueryUnbiasedInterruptTime to obtain time stamps that aren't synchronized to an external time reference. For UTC-synchronized time stamps, use GetSystemTimeAsFileTime or KeQuerySystemTime. If higher resolution is needed, you can use QueryInterruptTimePrecise, QueryUnbiasedInterruptTimePrecise, or KeQueryInterruptTimePrecise to obtain time stamps instead.
In general, the performance counter results are consistent across all processors in multi-core and multi-processor systems, even when measured on different threads or processes. Here are some exceptions to this rule:
  • Pre-Windows Vista operating systems that run on certain processors might violate this consistency because of one of these reasons:
    • The hardware processors have a non-invariant TSC and the BIOS doesn't indicate this condition correctly.
    • The TSC synchronization algorithm that was used wasn't suitable for systems with large numbers of processors.
  • When you compare performance counter results that are acquired from different threads, consider values that differ by ± 1 tick to have an ambiguous ordering. If the time stamps are taken from the same thread, this ± 1 tick uncertainty doesn't apply. In this context, the term tick refers to a period of time equal to 1 ÷ (the frequency of the performance counter obtained from QueryPerformanceFrequency).
When you use the performance counter on large server systems with multiple-clock domains that aren't synchronized in hardware, Windows determines that the TSC can't be used for timing purposes and selects a platform counter as the basis for QPC. While this scenario still yields reliable time stamps, the access latency and scalability is adversely affected. Therefore, as previously stated in the preceding usage guidance, only use the APIs that provide 1 microsecond or better resolution when such resolution is necessary. The TSC is used as the basis for QPC on multi-clock domain systems that include hardware synchronization of all processor clock domains, as this effectively makes them function as a single clock domain system.
The frequency of the performance counter is fixed at system boot and is consistent across all processors so you only need to query the frequency from QueryPerformanceFrequency as the application initializes, and then cache the result.

Virtualization

The performance counter is expected to work reliably on all guest virtual machines running on correctly implemented hypervisors. However, hypervisors that comply with the hypervisor version 1.0 interface and surface the reference time enlightenment can offer substantially lower overhead.

Direct TSC usage

We strongly discourage using the RDTSC or RDTSCP processor instruction to directly query the TSC because you won't get reliable results on some versions of Windows, across live migrations of virtual machines, and on hardware systems without invariant or tightly synchronized TSCs. Instead, we encourage you to use QPC to leverage the abstraction, consistency, and portability that it offers.

Examples for acquiring time stamps

The various code examples in these sections show how to acquire time stamps.

Using QPC in native code

This example shows how to use QPC in C and C++ native code.
LARGE_INTEGER StartingTime, EndingTime, ElapsedMicroseconds;
LARGE_INTEGER Frequency;

QueryPerformanceFrequency(&Frequency); 
QueryPerformanceCounter(&StartingTime);

// Activity to be timed

QueryPerformanceCounter(&EndingTime);
ElapsedMicroseconds.QuadPart = EndingTime.QuadPart - StartingTime.QuadPart;


//
// We now have the elapsed number of ticks, along with the
// number of ticks-per-second. We use these values
// to convert to the number of elapsed microseconds.
// To guard against loss-of-precision, we convert
// to microseconds *before* dividing by ticks-per-second.
//

ElapsedMicroseconds.QuadPart *= 1000000;
ElapsedMicroseconds.QuadPart /= Frequency.QuadPart;

Acquiring high resolution time stamps from managed code

This example shows how to use the managed code System.Diagnostics.Stopwatch class.
using System.Diagnostics;

long StartingTime = Stopwatch.GetTimestamp();

// Activity to be timed

long EndingTime  = Stopwatch.GetTimestamp();
long ElapsedTime = EndingTime - StartingTime;

double ElapsedSeconds = ElapsedTime * (1.0 / Stopwatch.Frequency);

The System.Diagnostics.Stopwatch class also provides several convenient methods to perform time-interval measurements.

Using QPC from kernel mode

The Windows kernel provides kernel-mode access to the performance counter through KeQueryPerformanceCounter from which both the performance counter and performance frequency can be obtained. KeQueryPerformanceCounter is available from kernel mode only and is provided for writers of device drivers and other kernel-mode components.
This example shows how to use KeQueryPerformanceCounter in C and C++ kernel mode.
LARGE_INTEGER StartingTime, EndingTime, ElapsedMicroseconds;
LARGE_INTEGER Frequency;

StartingTime = KeQueryPerformanceCounter(&Frequency);

// Activity to be timed

EndingTime = KeQueryPerformanceCounter(NULL);
ElapsedMicroseconds.QuadPart = EndingTime.QuadPart - StartingTime.QuadPart;
ElapsedMicroseconds.QuadPart *= 1000000;
ElapsedMicroseconds.QuadPart /= Frequency.QuadPart;

General FAQ about QPC and TSC

Here are answers to frequently-asked questions about QPC and TSCs in general.
Is QueryPerformanceCounter() the same as the Win32 GetTickCount() or GetTickCount64() function?
No. GetTickCount and GetTickCount64 aren't related to QPCGetTickCount and GetTickCount64 return the number of milliseconds since the system was started.
Should I use QPC or call the RDTSC /RDTSCP instructions directly?
To avoid incorrectness and portability issues, we strongly encourage you to use QPC instead of using the TSC register or the RDTSC or RDTSCP processor instructions.
What is QPC’s relation to an external time epoch? Can it be synchronized to an external epoch such as UTC?
QPC is based on a hardware counter that can't be synchronized to an external time reference, such as UTC. For precise time-of-day time stamps that can be synchronized to an external UTC reference, use GetSystemTimePreciseAsFileTime.
Is QPC affected by daylight savings time, leap seconds, time zones, or system time changes made by the administrator?
No. QPC is completely independent of the system time and UTC.
Is QPC accuracy affected by processor frequency changes caused by power management or Turbo Boost technology?
No. If the processor has an invariant TSC, the QPC is not affected by these sort of changes. If the processor doesn't have an invariant TSC, QPCwill revert to a platform hardware timer that won't be affected by processor frequency changes or Turbo Boost technology.
Does QPC reliably work on multi-processor systems, multi-core system, and systems with hyper-threading?
Yes
How do I determine and validate that QPC works on my machine?
You don't need to perform such checks.
Which processors have non-invariant TSCs? How can I check if my system has a non-invariant TSC?
You don't need to perform this check yourself. Windows operating systems perform several checks at system initialization to determine if the TSC is suitable as a basis for QPC. However, for reference purposes, you can determine whether your processor has an invariant TSC by using one of these:
  • the Coreinfo.exe utility from Windows Sysinternals
  • checking the values returned by the CPUID instruction pertaining to the TSC characteristics
  • the processor manufacturer’s documentation
The following shows the TSC-INVARIANT info that is provided by the Windows Sysinternals Coreinfo.exe utility (www.sysinternals.com). An asterisk means "True".
> Coreinfo.exe 

Coreinfo v3.2 - Dump information on system CPU and memory topology
Copyright (C) 2008-2012 Mark Russinovich
Sysinternals - www.sysinternals.com

 

RDTSCP          * Supports RDTSCP instruction
TSC             * Supports RDTSC instruction
TSC-DEADLINE    - Local APIC supports one-shot deadline timer
TSC-INVARIANT   * TSC runs at constant rate
Does QPC work reliably on Windows RT PC hardware platforms?
Yes
How often does QPC roll over?
Not less than 100 years from the most recent system boot, and potentially longer based on the underlying hardware timer used. For most applications, rollover isn't a concern.
What is the computational cost of calling QPC?
The computational calling cost of QPC is determined primarily by the underlying hardware platform. If the TSC register is used as the basis for QPC, the computational cost is determined primarily by how long the processor takes to process an RDTSC instruction. This time ranges from 10s of CPU cycles to several hundred CPU cycles depending upon the processor used. If the TSC can't be used, the system will select a different hardware time basis. Because these time bases are located on the motherboard (for example, on the PCI South Bridge or PCH), the per-call computational cost is higher than the TSC, and is frequently in the vicinity of 0.8 - 1.0 microseconds depending on processor speed and other hardware factors. This cost is dominated by the time required to access the hardware device on the motherboard.
Does QPC require a kernel transition (system call)?
A kernel transition is not required if the system can use the TSC register as the basis for QPC. If the system must use a different time base, such as the HPET or PM timer, a system call is required.
Is the performance counter monotonic (non-decreasing)?
Yes
Can the performance counter be used to order events in time?
Yes. However, when comparing performance counter results that are acquired from different threads, values that differ by ± 1 tick have an ambiguous ordering as if they had an identical time stamp.
How accurate is the performance counter?
The answer depends on a variety of factors. For more info, see Low-level hardware clock characteristics.

FAQ about programming with QPC and TSC

Here are answers to frequently-asked questions about programming with QPC and TSCs.
I need to convert the QPC output to milliseconds. How can I avoid loss of precision with converting to double or float?
There are several things to keep in mind when performing calculations on integer performance counters:
  • Integer division will lose the remainder. This can cause loss of precision in some cases.
  • Conversion between 64 bit integers and floating point (double) can cause loss of precision because the floating point mantissa can't represent all possible integral values.
  • Multiplication of 64 bit integers can result in integer overflow.
As a general principle, delay these computations and conversions as long as possible to avoid compounding the errors introduced.
How can I convert QPC to 100 nanosecond ticks so I can add it to a FILETIME?
A file time is a 64-bit value that represents the number of 100-nanosecond intervals that have elapsed since 12:00 A.M. January 1, 1601 Coordinated Universal Time (UTC). File times are used by Win32 API calls that return time-of-day, such as GetSystemTimeAsFileTime andGetSystemTimePreciseAsFileTime. By contrast, QueryPerformanceCounter returns values that represent time in units of 1/(the frequency of the performance counter obtained from QueryPerformanceFrequency). Conversion between the two requires calculating the ratio of the QPCinterval and 100-nanoseconds intervals. Be careful to avoid losing precision because the values might be small (0.0000001 / 0.000000340).
Why is the time stamp that is returned from QPC a signed integer?
Calculations that involve QPC time stamps might involve subtraction. By using a signed value, you can handle calculations that might yield negative values.
How can I obtain high resolution time stamps from managed code?
Call the Stopwatch.GetTimeStamp method from the System.Diagnostics.Stopwatch class. For an example about how to useStopwatch.GetTimeStamp, see Acquiring high resolution time stamps from managed code.
Under what circumstances does QueryPerformanceFrequency return FALSE, or QueryPerformanceCounter return zero?
This won't occur on any system that runs Windows XP or later.
Do I need to set the thread affinity to a single core to use QPC?
No. For more info, see Guidance for acquiring time stamps. This scenario is neither necessary nor desirable. Performing this scenario might adversely affect your application's performance by restricting processing to one core or by creating a bottleneck on a single core if multiple threads set their affinity to the same core when calling QueryPerformanceCounter.

Low-level hardware clock characteristics

These sections show low-level hardware clock characteristics.

Absolute Clocks and Difference Clocks

Absolute clocks provide accurate time-of-day readings. They are typically based on Coordinated Universal Time (UTC) and consequently their accuracy depends in part on how well they are synchronized to an external time reference. Difference clocks measure time intervals and aren't typically based on an external time epoch. QPC is a difference clock and isn't synchronized to an external time epoch or reference. When you useQPC for time-interval measurements, you typically get better accuracy than you would get by using time stamps that are derived from an absolute clock. This is because the process of synchronizing the time of an absolute clock can introduce phase and frequency shifts that increase the uncertainty of short term time-interval measurements.

Resolution, Precision, Accuracy, and Stability

QPC uses a hardware counter as its basis. Hardware timers consist of three parts: a tick generator, a counter that counts the ticks, and a means of retrieving the counter value. The characteristics of these three components determine the resolution, precision, accuracy, and stability of QPC.
If a hardware generator provides ticks at a constant rate, time intervals can be measured by simply counting these ticks. The rate at which the ticks are generated is called the frequency and expressed in Hertz (Hz). The reciprocal of the frequency is called the period or tick interval and is expressed in an appropriate International System of Units (SI) time unit (for example, second, millisecond, microsecond, or nanosecond).
Time interval
The resolution of the timer is equal to the period. Resolution determines the ability to distinguish between any two time stamps and places a lower bound on the smallest time intervals that can be measured. This is sometimes called the tick resolution.
Digital measurement of time introduces a measurements uncertainty of ± 1 tick because the digital counter advances in discrete steps, while time is continuously advancing. This uncertainty is called a quantization error. For typical time-interval measurements, this effect can often be ignored because the quantizing error is much smaller than the time interval being measured.
Digital time measurement
However, if the period being measured is small and approaches the resolution of the timer, you will need to consider this quantizing error. The size of the error introduced is that of one clock period.
The following two diagrams illustrate the impact of the ± 1 tick uncertainty by using a timer with a resolution of 1 time unit.
Tick uncertainty
QueryPerformanceFrequency returns the frequency of QPC, and the period and resolution are equal to the reciprocal of this value. The performance counter frequency that QueryPerformanceFrequency returns is determined during system initialization and doesn't change while the system is running.
Note  Cases might exist where QueryPerformanceFrequency doesn't return the actual frequency of the hardware tick generator. For example, in many cases, QueryPerformanceFrequency returns the TSC frequency divided by 1024; and on Hyper-V, the performance counter frequency is always 10 MHz when the guest virtual machine runs under a hypervisor that implements the hypervisor version 1.0 interface. As a result, don't assume that QueryPerformanceFrequency will return the precise TSC frequency.
 
QueryPerformanceCounter reads the performance counter and returns the total number of ticks that have occurred since the Windows operating system was started, including the time when the machine was in a sleep state such as standby, hibernate, or connected standby.
These examples show how to calculate the tick interval and resolution and how to convert the tick count into a time value.
Example 1
QueryPerformanceFrequency returns the value 3,125,000 on a particular machine. What is the tick interval and resolution of QPCmeasurements on this machine? The tick interval, or period, is the reciprocal of 3,125,000, which is 0.000000320 (320 nanoseconds). Therefore, each tick represents the passing of 320 nanoseconds. Time intervals smaller than 320 nanoseconds can't be measured on this machine.
Tick Interval = 1/(Performance Frequency)
Tick Interval = 1/3,125,000 = 320 ns
Example 2
On the same machine as the preceding example, the difference of the values returned from two successive calls to QPC is 5. How much time has elapsed between the two calls? 5 ticks multiplied by 320 nanoseconds yields 1.6 microseconds.
ElapsedTime = Ticks * Tick Interval
ElapsedTime = 5 * 320 ns = 1.6 μs
It takes time to access (read) the tick counter from software, and this access time can reduce the precision of the of the time measurement. This is because the minimum interval time (the smallest time interval that can be measured) is the larger of the resolution and the access time.
Precision = MAX [ Resolution, AccessTime]
For example, consider a hypothetical hardware timer with a 100 nanosecond resolution and an 800 nanosecond access time. This might be the case if the platform timer were used instead of the TSC register as the basis of QPC. Thus, the precision would be 800 nanoseconds not 100 nanoseconds as shown in this calculation.
Precision = MAX [800 ns,100 ns] = 800 ns
These two figures depict this effect.
QPC access time
If the access time is greater than the resolution, don't try to improve the precision by guessing. In other words, it's an error to assume that the time stamp is taken precisely in the middle, or at the beginning or the end of the call.
By contrast, consider the following example in which the QPC access time is only 20 nanoseconds and the hardware clock resolution is 100 nanoseconds. This might be the case if the TSC register was used as the basis for QPC. Here the precision is limited by the clock resolution.
QPC precision
In practice, you can find time sources for which the time required to read the counter is larger or smaller than the resolution. In either case, the precision will be the larger of the two.
This table provides info on the approximate resolution, access time, and precision of a variety of clocks. Note that some of the values will vary with different processors, hardware platforms, and processor speeds.
Clock SourceNominal Clock FrequencyClock ResolutionAccess Time (Typical)Precision
PC RTC64 Hz15.625 millisecondsN/AN/A
Query performance counter using TSC with a 3 GHz processor clock3 MHz333 nanoseconds30 nanoseconds333 nanoseconds
RDTSC machine instruction on a system with a 3 GHz cycle time3 GHz333 picoseconds30 nanoseconds30 nanoseconds

Because QPC uses a hardware counter, when you understand some basic characteristics of hardware counters, you gain understanding about the capabilities and limitations of QPC.
The most commonly used hardware tick generator is a crystal oscillator. The crystal is a small piece of quartz or other ceramic material that exhibits piezoelectric characteristics that provide an inexpensive frequency reference with excellent stability and accuracy. This frequency is used to generate the ticks counted by the clock.
The accuracy of a timer refers to the degree of conformity to a true or standard value. This depends primarily on the crystal oscillator’s ability to provide ticks at the specified frequency. If the frequency of oscillation is too high, the clock will 'run fast', and measured intervals will appear longer than they really are; and if the frequency is too low, the clock will 'run slow', and measured intervals will appear shorter than they really are.
For typical time-interval measurements for short duration (for example, response time measurements, network latency measurements, and so on), the accuracy of the hardware oscillator is usually sufficient. However, for some measurements the oscillator frequency accuracy becomes important, particularly for long time intervals or when you want to compare measurements taken on different machines. The remainder of this section explores the effects of the oscillator accuracy.
The crystals' frequency of oscillation is set during the manufacturing process and is specified by the manufacturer in terms of a specified frequency plus or minus a manufacturing tolerance expressed in 'parts per million' (ppm), called the maximum frequency offset. A crystal with a specified frequency of 1,000,000 Hz and a maximum frequency offset of ± 10 ppm would be within specification limits if its actual frequency were between 999,990 Hz and 1,000,010 Hz.
By substituting the phrase parts per million with microseconds per second, we can apply this frequency offset error to time-interval measurements. An oscillator with a + 10 ppm offset would have an error of 10 microseconds per second. Accordingly, when measuring a 1 second interval, it would run fast and measure a 1 second interval as 0.999990 seconds.
A convenient reference is that a frequency error of 100 ppm causes an error of 8.64 seconds after 24 hours. This table presents the measurement uncertainty due to the accumulated error for longer time intervals.
Time interval durationMeasurement uncertainty due to accumulated error with +/- 10 PPM frequency tolerance
1 microsecond± 10 picoseconds (10-12)
1 millisecond± 10 nanoseconds (10-9)
1 second± 10 microseconds
1 hour± 60 microseconds
1 day± 0.86 seconds
1 week± 6.08 seconds

The preceding table shows that for small time intervals the frequency offset error can often be ignored. However for long time intervals, even a small frequency offset can result in a substantial measurement uncertainty.
Crystal oscillators that are used in personal computers and servers are typically manufactured with a frequency tolerance of ± 30 to 50 parts per million, and rarely, crystals can be off by as much as 500 ppm. Although crystals with much tighter frequency offset tolerances are available, they are more expensive and thus are not used in most computers.
To reduce the adverse effects of this frequency offset error, recent versions of Windows, particularly Windows 8, use multiple hardware timers to detect the frequency offset and compensate for it to the extent possible. This calibration process is performed when Windows is started.
As the following examples show, the frequency offset error of a hardware clock influences the achievable accuracy, and the resolution of the clock can be less important.
Frequency offset error influences achievable accuracy
Example 1
Suppose you perform time-interval measurements by using a 1 MHz oscillator, which has a resolution of 1 microsecond, and a maximum frequency offset error of ±50 ppm. Now, let us suppose the offset is exactly +50 ppm. This means that the actual frequency would be 1,000,050 Hz. If we measured a time interval of 24 hours, our measurement would be 4.3 seconds too short (23:59:55.700000 measured versus 24:00:00.000000 actual).
Seconds in a day = 86400
Frequency offset error = 50 ppm = 0.00005
86,400 seconds * 0.00005 = 4.3 seconds
Example 2
Suppose the processor TSC clock is controlled by a crystal oscillator and has specified frequency of 3 GHz. This means that the resolution would be 1/3,000,000,000 or about 333 picoseconds. Assume the crystal used to control the processor clock has a frequency tolerance of ±50 ppm and is actually +50 ppm. In spite of the impressive resolution, a time-interval measurement of 24 hours will still be 4.3 seconds too short. (23:59:55.7000000000 measured versus 24:00:00.0000000000 actual).
Seconds in a day = 86400
Frequency offset error = 50 ppm = 0.00005
86,400 seconds * 0.00005 = 4.3 seconds
This shows that a high resolution TSC clock doesn't necessarily provide more accurate measurements than a lower resolution clock.
Example 3
Consider using two different computers to measure the same 24 hour time interval. Both computers have an oscillator with a maximum frequency offset of ± 50 ppm. How far apart can the measurement of the same time interval on these two systems be? As in the previous examples, ± 50 ppm yields a maximum error of ± 4.3 seconds after 24 hours. If one system runs 4.3 seconds fast, and the other 4.3 seconds slow, the maximum error after 24 hours could be 8.6 seconds.
Seconds in a day = 86400
Frequency offset error = ±50 ppm = ±0.00005
±(86,400 seconds * 0.00005) = ±4.3 seconds
Maximum offset between the two systems = 8.6 seconds
In summary, the frequency offset error becomes increasingly important when measuring long time intervals and when comparing measurements between different systems.
The stability of a timer describes whether the tick frequency changes over time, for example as the result of temperatures changes. Quartz crystals used as the tick generators on computers will exhibit small changes in frequency as a function of temperature. The error caused by thermal drift is typically small compared to the frequency offset error for common temperature ranges. However, designers of software for portable equipment or equipment subject to large temperature fluctuations might need to consider this effect.

Hardware timer info

TSC Register
Some Intel and AMD processors contain a TSC register that is a 64-bit register that increases at a high rate, typically equal to the processor clock. The value of this counter can be read through the RDTSC or RDTSCP machine instructions, providing very low access time and computational cost in the order of tens or hundreds of machine cycles, depending upon the processor.
Although the TSC register seems like an ideal time stamp mechanism, here are circumstances in which it can't function reliably for timekeeping purposes:
  • Not all processors have TSC registers, so using the TSC register in software directly creates a portability problem. (Windows will select an alternative time source for QPC in this case, which avoids the portability problem.)
  • Some processors can vary the frequency of the TSC clock or stop the advancement of the TSC register, which makes the TSC unsuitable for timing purposes on these processors. These processors are said to have non-invariant TSC registers. (Windows will automatically detect this, and select an alternative time source for QPC).
  • On multi-processor or multi-core systems, some processors and systems are unable to synchronize the clocks on each core to the same value. (Windows will automatically detect this, and select an alternative time source for QPC).
  • On some large multi-processor systems, you might not be able to synchronize the processor clocks to the same value even if the processor has an invariant TSC. (Windows will automatically detect this, and select an alternative time source for QPC).
  • Some processors will execute instructions out of order. This can result in incorrect cycle counts when RDTSC is used to time instruction sequences because the RDTSC instruction might be executed at a different time than specified in your program. The RDTSCP instruction has been introduced on some processors in response to this problem.
Like other timers, the TSC is based on a crystal oscillator whose exact frequency is not known in advance and that has a frequency offset error. Thus before it can be used, it must be calibrated using another timing reference.
During system initialization, Windows checks if the TSC is suitable for timing purposes and performs the necessary frequency calibration and core synchronization.
PM Clock
The ACPI timer, also known as the PM clock, was added to the system architecture to provide reliable time stamps independently of the processors speed. Because this was the single goal of this timer, it provides a time stamp in a single clock cycle, but it doesn't provide any other functionality.
HPET Timer
The High Precision Event Timer (HPET) was developed jointly by Intel and Microsoft to meet the timing requirements of multimedia and other time-sensitive applications. HPET support has been in Windows since Windows Vista, and Windows 7 and Windows 8 Hardware Logo certification requires HPET support in the hardware platform.