New TIMESTAMPMODE for QPC without system start time #773
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…s are based of the performance counter but do not have a system start time offset applied. Thus, applications can directly convert from QPC (after accounting for frequency) to another time format or source.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This mode functions the same as
TIMESTAMPMODE_SINGLE_SYNCHRONIZATIONexcept the start time is set to zero. Thus the timestamp appears as "1970-01-01..." in Wireshark for example.This is useful if an application wishes to synchronise packets with an external time source and is able to convert from QPC ticks to that time source. In the regular mode
TIMESTAMPMODE_SINGLE_SYNCHRONIZATION, the driver start time must first be subtracted, which can only be approximated, substantially reducing accuracy. With this modification, high accuracy can be maintained.I've named the new mode
TIMESTAMPMODE_SINGLE_SYNCHRONIZATION_RELATIVEsince the returned timestamps are relative to system boot time, but there may be better names. Similarly, it may be better to pass the timestamp mode into the call toTIME_SYNCHRONIZEand set the timeval to 0 there.