-
Notifications
You must be signed in to change notification settings - Fork 18k
runtime/trace: v2 traces contain an incorrect timestamp scaling factor on Windows #65997
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
cc @mknyszek |
I wonder if this could be a Windows-specific bug, given that tracing handles clocks on Windows differently from other systems. Is there a chance you can test this on Linux to see if the problem reproduces there? Additionally, if you could attach a v1 and v2 trace for comparison, that would help. |
Thanks for the detailed reporting! FTR, the clock used by both the old tracer and the new one on Windows is nearly identical, so I suspect the timestamps in the wire format should be OK. I think this is a bug in the time conversion code, either with the "EvFrequency" event getting emitted incorrectly, or somewhere in the parser. |
'Doh. Yep. We emit a very wrong |
I sent out a fix. It's so small and simple that I think it may be worth backporting this (even though there is a workaround). |
Change https://go.dev/cl/567937 mentions this issue: |
@gopherbot Please open a backport issue for Go 1.22. |
Backport issue(s) opened: #66201 (for 1.22). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases. |
Change https://go.dev/cl/570195 mentions this issue: |
…ws in the new tracer The value produced for the EvFrequency event on Windows is missing the fact that the cputicks clock gets divided. This results in durations that are consistently wrong by the same factor (about 256). For #65997. Fixes #66201. Change-Id: I930cbfce3499d435c20699f41c11e3227d84f911 Reviewed-on: https://go-review.googlesource.com/c/go/+/567937 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> (cherry picked from commit 707eba9) Reviewed-on: https://go-review.googlesource.com/c/go/+/570195 Reviewed-by: Than McIntosh <thanm@google.com>
Go version
go version go1.22.0 windows/amd64
Output of
go env
in your module/workspace:What did you do?
I'm trying to record a trace of a program that utilizes glfw/opengl and other c/c++ libraries to check why in rare occasions 1ms sleep or runtime.Gosched can take up to 2-20 seconds. I wanted to check the new tracing introduced in go 1.22, but noticed that timestamps are completely wrong.
Minified example that also has this issue: glfwtest.zip
What did you see happen?
Main thread is set to pace at ~144Hz (pacing is done using time.Sleep(time.Millisecond)+runtime.Gosched), so it means rendering function should run every ~7ms. But looking at trace tool page it shows that it is running every 28us:
I see the same delta between other frames.
That's how it looks for the minified example (VSync is on, I'm measuring time between glfw.PollEvents()):

Again, 27us where 6.9-7ms is expected
What did you expect to see?
Both screenshots are from traces recorded by programs compiled with
GOEXPERIMENT=noexectracer2
.Main program:

Minified example (VSync on 144hz monitor):

As we can see, delta in both examples is ~6.9ms, so it is correct.
The text was updated successfully, but these errors were encountered: