AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |
Back to Blog
Mach clock fre2/1/2024 ![]() Tags APFS Apple AppleScript Apple silicon backup Big Sur Blake bug Catalina Consolation Console diagnosis Disk Utility Doré El Capitan extended attributes Finder firmware Gatekeeper Gérôme HFS+ High Sierra history of painting iCloud Impressionism iOS landscape LockRattler log logs M1 Mac Mac history macOS macOS 10.12 macOS 10.13 macOS 10.14 macOS 10.Rainmeter is a free desktop customization program that lets you completely transform the way your desktop looks. I have a feeling that a few apps running on Apple Silicon will get this spectacularly wrong. If you find an app that is affected by this, there’s nothing the user can do other than report it to its developer as a bug. This is least likely in apps which were developed when PowerPC systems were still around, and in those which share code with an iOS version. So don’t be surprised if running older apps on Apple Silicon systems sometimes results in strangeness in time, and time intervals. I’ll be releasing a new version of RouteMap tomorrow to address this. I know that this affects timing values in my own RouteMap, which calculates time intervals between Signpost entries in the unified log. Unlike processor instructions which are automatically translated from Intel to ARM code by Rosetta 2, if you run an Intel app which uses Mach ticks and fails to correct the values (or derived values, such as time intervals), then all those times will be incorrect on Apple Silicon Macs. If you calculate time intervals from them, you’ll need to correct those using the mach_timebase_info as above. If you store or process log records, the machTimestamp from Apple Silicon Macs will be very different from that of Intel Macs. The other is a direct reading of the Mach absolute time and termed the machTimestamp, which is given in system ticks as a large positive integer like Which resolves down to one microsecond (0.000001 of a second). One is in the recognisable format of a timestamp, such as ![]() Every entry in the macOS unified log, including Signposts, features two separate records of the time. This also affects entries written to the log. Some ideas which may work for languages other than Swift and Objective-C are given in this handy cross-platform compilation. If you use any code which assumes that Mach ticks are at nanosecond intervals, now is the time to incorporate this correction. Big Sur running on Apple Silicon Macs won’t be the same, though, the correction may well be large, and could vary from model to model. Returns the time interval in nanoseconds.įor macOS running on Intel processors, the numerator and denominator of mach_timebase_info are the same, and have often been omitted. ((secondTicks - firstTicks) * UInt64(info.numer)) / UInt64(nom) What we should have been doing was applying a conversion factor to the difference in clock ticks, to convert from ticks to nanoseconds. Maybe with this change, Apple might like to restore them? Sadly the CoreServices conversion functions it refers to have long since been removed from macOS. Get the tick number (an unsigned 64-bit integer) at the first moment, get it at the second, take the first from the second and your answer is already in nanoseconds.Īpple’s only documentation that I can find is Technical Q&A QA1398, which dates from fifteen years ago and has now been archived. On Intel processors, that tick has been one nanosecond long, so working out a time interval has been all too easy. It’s hardware clock ticks, Mach precision time, which changes. Local reference clocks and timers which already work in proper time units such as seconds aren’t affected by this change. If any of your code uses mach_absolute_time, or anything derived from it, including the machTimestamp field in unified log extracts, now is the time to put your clock right.Īs I have explained previously, Macs contain several different clocks and views of the time. When it’s written to an entry in the unified log, because the machTimestamp has always been in nanoseconds, it’s easy to assume that it is and calculate time intervals accordingly.Īpple has warned us that its new Apple Silicon Macs won’t be the same, and continuing to make the assumption that Mach clock ticks occur once every nanosecond will prove seriously wrong. For many years, the precision Mach clock in Macs has ticked away in nanoseconds, and we’ve come to assume that it always will. When something doesn’t change for a long time we tend to get complacent and cut corners.
0 Comments
Read More
Leave a Reply. |