The mach absolute time base is different between ARM and x86/x64 though developers won’t have access to packet capture on iOS devices (internally the packet capture is used on iOS devices). The developers that would be using this software capture are familiar with the Mach Absolute Time format as it is the same values returned by the real software stack so I don’t see any need to change the format to nanoseconds.
—scott > On Jan 5, 2017, at 8:23 PM, Guy Harris <g...@alum.mit.edu> wrote: > > On Dec 13, 2016, at 8:38 AM, Scott Deandrea <sdeand...@apple.com> wrote: > >> The timestamps are in Mach Absolute Time Units >> (https://developer.apple.com/library/content/qa/qa1398/_index.html). > > That says > > This unit is CPU dependent, so you can't just multiply it by a constant > to get a real world value. Rather, you should call a system-provided > conversion function to convert it to a real world value. > > Unfortunately, that would require that the clock rate be provided somewhere > in the capture file. > > However, a quick look at _absolutetime_to_microtime() for x86 (which is > what's used by absolutetime_to_microtime(), which is what's used by > clock_get_calendar_microtime(), which is what's used by microtime(), which is > what's used by the BPF code to time stamp packets) indicates that the units > are "nanoseconds" (and that it's "nanoseconds since the Epoch", for > appropriate values of "since the Epoch" - don't get me started on leap > seconds and POSIX...). > > I don't know whether that's the case on ARM (the Apple TV has an USB port, > after all...), but, if it is, and if Apple's going to continue to maintain > that as the case, then we can just say it's in nanoseconds. > > Otherwise, you might want to convert it to nanoseconds rather than using a > CPU-dependent unit. _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
