Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

No, because I don't have access to these Windows Server 2016(virtualized on GCP) machines anymore, and the behaviour on Windows 10 isn't the same so I can't check. All I can say is that we have spent weeks investigating this and if it was possible to wait 1ms with the timer resolution set to 16ms we would have done so.


Well I don't know what Windows Server 2016 virtualized on GCP is doing, but if you believe me that I copy-pasted this, you should be wary of making such sweeping claims about Windows...

Re: your troubleshooting: wild guess, but one thing to look into (if you ever encounter it again) might be changing the "Processor scheduling" setting in sysdm.cpl -> Advanced -> Settings #1 -> Advanced to "Programs" instead of "Background services". Not sure if that affects timers, but I can't think of much else (besides the hypervisor or hard-coded kernel differences) that would cause this.


One shouldn't really test Windows timer behavior on virtualized platforms, it's bad enough as it is on bare metal.


Right, but this wasn't some sort of academic exercise - we were deploying a server for a commercial product and ran into this problem because we had to get it running in that scenario. We can of course argue that audio processing shouldn't be done on a virtualized operating system full stop, but that's not a part I had any control over.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: