Clocker For Windows
Boleslao Drinker
Therefor I used clock() in front and after an fgets()call. When running on my Windows computer it worked perfectly. However when running on my friends Mac-Book and Linux-PC it gave extremely small results (a few micro seconds of time only).
Now my question is why there is such a difference in implementation of clock() on these OS. For windows it seems like the clock keeps ticking while the thread is sleeping/waiting but for Linux and Mac isn't?
However, we have opted to avoid reimplementing clock() in such a way that it might return time values advancing faster than one second per physical second, as this change would silently break programs depending on the previous behavior (and we expect there are many such programs).
If we look at the source code for clock() on Mac OS X, we see that it is implemented using getrusage, and reads ru_utime + ru_stime. These two fields measure CPU time used by the process (or by the system, on behalf of the process). This means that if usleep (or fgets) causes the OS to swap in a different program for execution until something happens, then any amount of real time (also called "wall time", as in "wall clock") elapsed does not count against the value that clock() returns on Mac OS X. You could probably dig in and find something similar in Linux.
In pure C, I am not aware of a function available on OS X, Linux and Windows that will return wall time with a sub-second precision (time.h being fairly limited). You have GetSystemTimeAsFileTime on Windows that will return you time in slices of 100ns, and gettimeofday from BSD that will return time to a microsecond precision.
On Linux, you should read time(7). It suggests to use the POSIX 2001 clock_gettime which should exist on recent MacOSX (and on Linux). On Linux, running on not too old hardware (e.g. less than 6 years old laptop or desktop), clock_gettime gives good accuracy, typically dozens of microseconds or better. It gives measures with seconds and nanoseconds (in a struct timespec), but I don't expect the nanosecond figure to be very accurate.
Note: Remember two things about this function, 1) You can change the type of the variables. 2) You can use errno global variable to describe details about why a particular operation failed.
I upgraded windows 11 to it's beta build 22000.160 in which the focus session update has to come in the clock app. But, i didn't got it even after one month of the update had been delivered to the beta users. What to do now ?
I am in Windows 11 Insider Preview Beta Channel 22000.194 but still I have the old clock itself. In the Microsoft Store page, I am not recieving any update for the New Clock App. If you want the new Calculator, Photos, Snip and Sketch, you can ask me for the the link to download. I downloaded and I have got the new Calculator, Photos, Snip and Sketch apps. But I have not got the new clock app. As other users may have the new clock app, can you make the new clock app into a zip file and upload it to OneDrive, and then send the link, so we can extract the app and download it. I am need of the new Focus Sessions. Please help me. I hope it is best to give the link, as the step will be faster and convinient too.
I've been having this strange issue with my system clock. Sometimes when I start up Windows 10, my clock displays a time that is 5 hours ahead of the current time. So if it's noon where I live (Eastern time zone), the clock says 5pm. It adjusts for Daylight Savings Time as well staying 5 hours ahead.
I've checked my time zone settings and it's set to the correct time zone. I have internet time set to sync with time.nist.gov, and when manually synchronizing the time, it correctly sets the clock, although the following error message appears when doing so:
This issue started immediately after erasing my hard drive and reinstalling Windows 10 from scratch, so it's not caused by anything I've installed since then. It only happens on Windows startup, but not every time. I currently have Ubuntu 16.04 installed in a dual boot configuration (the problem started before I installed Ubuntu), and I haven't seen any similar issues with the Ubuntu clock.
I've looked through similar time-related issues on the internet, but none seemed to match mine. This question is very similar to my own, but the issue there was caused by the hardware clock being off, and the clock shown in BIOS on my computer is set to the correct time.
What strikes me as strange is that the time is exactly five hours off, not a minute more, even adjusting for DST. It would seem to me that Windows is occasionally syncing with the wrong time zone, but I have no idea how to verify or correct that.
UPDATE: It turns out that switching from Ubuntu to Windows triggers the 5 hour offset every time, so it was indeed an issue with the hardware clock being set to Universal/Local by Ubuntu/Windows, respectively.
I would highly suspect Ubuntu and Windows disagreeing on whether the hwclock is localtime or UTC. The conflict usually comes about because Linux uses the the hwclock set in UTC, while Windows uses the hwclock set to the localtime zone.
If you want your hwclock to show the time in your timezone, then you will need to change linux to not be UTC, which means make linux use localtime. If you are OK with your hwclock (BIOS) to be in UTC, then change windows to be UTC.
Note: Windows Time service will still write local time to the RTC regardless of the registry setting above on shutdown, so it is handy to disable Windows Time service with this command (if time sync is still required while in Windows use any third-party time sync solution):
This is not a big problem, just update the system clock and the command will work. However, if the Linux system in question is running inside WSL2 on Windows, then it's not quite as straightforward to fix as it ought to be and you're likely to encounter this error more often than you might expect, especially if you're using nested virtualisation.
However, if you're running Windows Terminal, then you can use a simple menu item I've created to fix it for you. You can also run the fix manually, but I find it significantly easier to use Windows Terminal.
Since running any command doesn't take zero time, rather than making it run by magic every time you try to use your WSL2 environment, I've deliberately made it be something that you have to instigate manually (albeit with a single menu command which can be run with a keyboard shortcut). I considered doing something clever, but this fix feels better and it's very lightweight and also more portable as it should work on any machine running WSL2.
Hyper-V is a great virtualisation environment and I've got it running on an old Dell PowerEdge R720xd in my home lab. One of the nice things about Hyper-V is that I can shut down the physical host server (e.g. through the web interface of Windows Admin Center) and it will save the state of any virtual machines which are running. When I start the server again, those same virtual machines will automatically start running again (this is all configurable, of course, but this is how my system is configured). And their system clocks are synchronised with the host machine, which is something that most hypervisors do.
Cutting a long story (slightly) short, I have a Windows 10 virtual machine running inside Hyper-V server. Then I'm running WSL2 inside Docker inside that virtual machine, so we're talking nested virtualisation (I can't be the only one who's thinking, "It's turtles all the way down"). If I turn off my Hyper-V server for any reason then, when I switch it back on and the virtual machines start running again, my Windows 10 VM has the correct system time, but my WSL2 environment (in my case Ubuntu 20.04) doesn't. The clock restarts from whenever I shut it down. To illustrate this point, I powered off my server just over a day ago. When I switched it back on and logged in to my dev machine, I opened Windows Terminal and ran the following command:
This is a simple way of displaying the system date for Windows (by using the PowerShell Get-Date command) and also for WSL2 (by using wsl.exe date to run the date command inside the default WSL environment, which in my case is Ubuntu running inside WSL2).
In order to fix this without having to enter the correct date and time manually, you need to install the ntpdate command in your WSL2 environment (e.g. via sudo apt install ntpdate). I tried various ways of setting the system clock automatically and this was the only one that I found worked reliably (I was unable to synchronise it to the host machine). As you might realise, the ntp in the command refers to Network Time Protocol and it means we're going to set the system time from a network time server. I'm using time.windows.com, but you can use any ntp server you like.
In order to preserve the look and feel, I copied my existing Ubuntu WSL2 profile and changed the command it runs, but you don't necessarily need to do that; the only important bit is the commandline value, which needs to look like this (although you can use a different time server if you like, of course):
Hypervisors are great, but nested virtualisation can have some unexpected challenges. If you're running WSL2 inside a virtual machine then, if you hibernate that parent virtual machine, your WSL2 system clock will not update automatically when you restart your system. This will cause all sorts of problems and can be painful to fix. By creating a simple menu command for Windows Terminal you can correct your WSL2 system clock with almost no effort and also see how far it had drifted (in my case, this shows me how long I'd had my system switched off).
I really really do not want to re-install windows at this time. It has been 3+ years since my last clean install and it will take me a week to get things backed up, and re-installed, and tweaked back the way I like it.
Anyways, i REALLY like EOS so far. Boot time is like 2 sec, while 12 sec to windows 10.
And im using JBL Quantum Duo speakers via USB connection and EOS detected them properly. For some reason (or is it just me), MP3/FLAC sounds a lot better, clearer with EOS than Windows(used foobar, resonic, aimp). Maybe JBL drivers for Windows are not so good?