相关疑难解决方法(0)

我正在将一个最初为Win32 API编写的游戏移植到Linux上(好吧,将Win32端口的OS X端口移植到Linux).

我已经QueryPerformanceCounter通过在进程启动后给出uSeconds来实现:

BOOL QueryPerformanceCounter(LARGE_INTEGER* performanceCount)
{
    gettimeofday(&currentTimeVal, NULL);
    performanceCount->QuadPart = (currentTimeVal.tv_sec - startTimeVal.tv_sec);
    performanceCount->QuadPart *= (1000 * 1000);
    performanceCount->QuadPart += (currentTimeVal.tv_usec - startTimeVal.tv_usec);

    return true;
}

这一点,加上QueryPerformanceFrequency()给出一个恒定的1000000作为频率,在我的机器上工作得很好,给我一个包含uSeconds自程序启动以来的64位变量.

所以,这是便携式？如果内核是以某种方式或类似的方式编译的,我不想发现它的工作方式不同.不过,我很好,因为它不适用于Linux之外的其他东西.

挂钟时间通常由系统RTC提供.这主要仅提供低至毫秒范围的时间,并且通常具有10-20毫秒的粒度.但是,gettimeofday()的分辨率/粒度通常报告在几微秒范围内.我假设微秒粒度必须来自不同的来源.

gettimeofday()的微秒分辨率/粒度是如何完成的？

当从RTC获取毫微秒的部分并且从不同的硬件获取微秒时,出现了两个源的定相问题.这两个来源必须以synchronized某种方式.

这两个来源之间的同步/阶段是如何完成的？

编辑:从我在amdn提供的链接中看到的,特别是以下的英特尔链接,我在这里添加一个问题:

是否gettimeofday()在微秒制度中提供分辨率/粒度？

编辑2:总结amdns 答案以及更多阅读结果:

Linux仅在启动时使用实时时钟(RTC)与更高分辨率的计数器同步,即Timestampcounter(TSC).引导后gettimeofday()返回一个完全基于TSC值和该计数器频率的时间.frequency通过将系统时间与外部时间源进行比较来校正/校准TSC的初始值.调整由adjtimex()函数完成/配置.内核运行锁相环以确保时间结果是单调且一致的.

这样可以说gettimeofday()具有微秒分辨率.考虑到更现代的Timestampcounter在GHz体系中运行,可获得的分辨率可能在纳秒范围内.因此这个有意义的评论

/**
407  * do_gettimeofday - Returns the time of day in a timeval
408  * @tv:         pointer to the timeval to be set
409  *
410  * NOTE: Users should be converted to using getnstimeofday()
411  */

可以在Linux/kernel/time/timekeeping.c中找到.这表明在稍后的时间点可能存在更高分辨率的功能.现在getnstimeofday()只在内核空间中可用.

但是,查看所有涉及的代码以获得正确的信息,显示了很多关于不确定性的评论.有可能获得微秒分辨率.该功能gettimeofday()甚至可以在微秒方案中显示粒度.但是:由于driftTSC频率无法准确校正,因此对其准确性有严重的考虑.此外,在Linux中处理这个问题的代码的复杂性暗示着相信它实际上很难做到正确.这是特别的,但不仅仅是由Linux应该运行的大量硬件平台引起的.

结果: …