Skip to content
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

runtime: go causes Windows 2003 server clocks to run fast #25268

Closed
ncw opened this issue May 6, 2018 · 7 comments

Comments

Projects
None yet
5 participants
@ncw
Copy link
Contributor

commented May 6, 2018

What version of Go are you using (go version)?

This affects go10.1 but does not affect go1.8

Does this issue reproduce with the latest release?

It reproduces with go10.1 - haven't tried tip, however the relevant code in src/runtime/os_windows.go looks unchanged.

What operating system and processor architecture are you using (go env)?

I compiled the binary with go10.1 but it was run by an rclone user on a Windows 2003 server machine.

What did you do?

The user ran a sync with rclone and reported:

When Rclone is running, the system clock runs faster than normal in my Windows 2003 server. ‘Faster’ meaning like 1,3 seconds per second. Upon closing the program, the clock goes back to the normal speed.

I’ve already tried exchanging the CMOS battery - no difference.

I sent the user a binary compiled with go1.8 and they reported that the problem was gone.

What did you expect to see?

Time running normally

What did you see instead?

Time running at 1.3x!

The cause

I found this Microsoft advisory The system clock may run fast when you use the ACPI power management timer as a high-resolution counter on Windows 2000-based, Windows XP-based, and Windows Server 2003-based computers which seemed to match the symptoms, and from that tracked down the code here: https://tip.golang.org/src/runtime/os_windows.go#L326

It appears in go1.9 we switched away from using QueryPerformanceCounter. Unfortunately the current method of reading the time has that strange effect of speeding up the system clock in Windows 2003 server.

It seems possible that we could make sure useQPCTime is set for the affected OSes.

The minium required Windows is "Microsoft Windows Windows XP SP3 or later, Intel 64-bit processor" from the download page. So I'm not sure whether Windows 2003 server is supported or not. I don't know whether this affects Windows XP SP3.

This was originally reported in the rclone forum.

@ALTree ALTree added this to the Go1.11 milestone May 6, 2018

@ALTree

This comment has been minimized.

Copy link
Member

commented May 6, 2018

@alexbrainman

This comment has been minimized.

Copy link
Member

commented May 7, 2018

@ncw is your issue dup of #24489 ?

Anyway, I don't think we could help you, because Windows XP is not supported anymore (search for Windows XP in https://golang.org/doc/go1.10 ).

The only suggestion I have is to try and change release-branch.go1.10 branch as suggested #24489 (comment) to see if it helps. Let us know, if you need more details.

Alex

@FiloSottile

This comment has been minimized.

Copy link
Member

commented May 8, 2018

This issue refers to Go 1.10, which supports Windows XP ("Go 1.10 is the last release that will run on Windows XP or Windows Vista.") and which will be supported for 9 more months, so even if we don't fix it in 1.11 we should look into a fix for a minor release.

/cc @aclements

@ncw

This comment has been minimized.

Copy link
Contributor Author

commented May 8, 2018

@alexbrainman wrote:

is your issue dup of #24489 ?

Not sure... They seem similar but the advisory I linked was just for Windows XP/ Windows server 2003 and the effect is much bigger here than in that issue.

Anyway, I don't think we could help you, because Windows XP is not supported anymore (search for Windows XP in https://golang.org/doc/go1.10 ).

Note that this issue was reported on Windows Server 2003. Reading that I'm unsure whether go supports Windows 2003 server or not, since Windows Server 2003 is on a different timeline to XP. Looking at the windows version numbers, XP is 5.1, 2003 Server is 5.2 and Vista is 6.0 so it seems reasonable to assume that Windows 2003 server won't be supported by go1.11

( Aside: Will windows server 2008 be supported? That isn't end of life until Jan 2020? I think it would be helpful if that page said explicitly which Windows server versions are supported.)

@FiloSottile wrote:

This issue refers to Go 1.10, which supports Windows XP ("Go 1.10 is the last release that will run on Windows XP or Windows Vista.") and which will be supported for 9 more months, so even if we don't fix it in 1.11 we should look into a fix for a minor release.

I'd say if it is easy then OK but I don't think it is worth putting a huge amount of effort in since there is a reasonable workaround "compile with go1.8" and this has been an issue since go1.9 and no-one has reported it up until now.

@alexbrainman

This comment has been minimized.

Copy link
Member

commented May 8, 2018

Looking at the windows version numbers, XP is 5.1, 2003 Server is 5.2 and Vista is 6.0 so it seems reasonable to assume that Windows 2003 server won't be supported by go1.11

I pretty sure Windows server 2003 won't be supported by go1.11. But go1.10 release notes do not mention Windows server 2003. I doubt go1.10 release notes can be changed to add mention of Windows server 2003.

Will windows server 2008 be supported? That isn't end of life until Jan 2020?

I am pretty sure Windows server 2008 will be supported by go1.11. For example one of our windows builders on https://build.golang.org/ runs Windows server 2008 (you can hover your mouse over 386 and x64 under windows title).

I think it would be helpful if that page said explicitly which Windows server versions are supported.)

https://golang.org/dl says Windows XP SP3 and above. That pretty much includes every Windows that runs today.

there is a reasonable workaround "compile with go1.8"

If that works for the user, then sure.

Alex

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Jul 10, 2018

Is there anything to do for this issue? I can't tell.

@alexbrainman

This comment has been minimized.

Copy link
Member

commented Jul 10, 2018

Is there anything to do for this issue?

I don't think so. Please reopen if you disagree.

Alex

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.