linux下1ms分辨率定时器推荐方式 [英] 1ms resolution timer under linux recommended way

查看:14
本文介绍了linux下1ms分辨率定时器推荐方式的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我需要一个 linux 下分辨率为 1ms 的计时器滴答声.它用于增加一个计时器值,该值又用于查看是否应触发各种事件.由于 glibc 要求,POSIX timerfd_create 不是一个选项.我尝试了 timer_create 和 timer_settimer,但我从它们那里得到的最好的是 10 毫秒的分辨率,较小的值似乎默认为 10 毫秒的分辨率.根据联机帮助页,Getittimer 和 setitimer 的分辨率为 10 毫秒.

I need a timer tick with 1ms resolution under linux. It is used to increment a timer value that in turn is used to see if various Events should be triggered. The POSIX timerfd_create is not an option because of the glibc requirement. I tried timer_create and timer_settimer, but the best I get from them is a 10ms resolution, smaller values seem to default to 10ms resolution. Getittimer and setitimer have a 10 ms resolution according to the manpage.

我目前能想到的做这个计时器的唯一方法是在我的主循环中使用带有 CLOCK_MONOTONIC 的clock_gettime 测试是否已经过了毫秒,如果是,则增加计数器(然后检查是否应该触发各种事件).

The only way to do this timer I can currently think of is to use clock_gettime with CLOCK_MONOTONIC in my main loop an test if a ms has passed, and if so to increase the counter (and then check if the various Events should fire).

有没有比在主循环中不断查询更好的方法呢?对此的推荐解决方案是什么?

Is there a better way to do this than to constantly query in the main loop? What is the recommended solution to this?

我使用的语言是普通的旧 c

The language I am using is plain old c

更新
我使用的是 2.6.26 内核.我知道你可以让它以 1kHz 的频率中断,然后 POSIX timer_* 函数可以被编程为最多 1ms 但这似乎不可靠,我不想使用它,因为它可能需要一个新内核系统.一些库存内核似乎仍然配置了 100Hz.我需要检测到这一点.该应用程序可能会在我的系统之外的其他设备上运行:)

Update
I am using a 2.6.26 Kernel. I know you can have it interrupt at 1kHz, and the POSIX timer_* functions then can be programmed to up to 1ms but that seems not to be reliable and I don't want to use that, because it may need a new kernel on some Systems. Some stock Kernel seem to still have the 100Hz configured. And I would need to detect that. The application may be run on something else than my System :)

我睡不着 1 毫秒,因为可能有网络事件我必须做出反应.

I can not sleep for 1ms because there may be network events I have to react to.

我是如何解决的由于它不是那么重要,我只是声明全局计时器具有 100 毫秒的分辨率.所有使用自己计时器的事件都必须设置至少 100 毫秒的计时器到期时间.我或多或少想知道是否有更好的方法,因此问题.

How I resolved it Since it is not that important I simply declared that the global timer has a 100ms resolution. All events using their own timer have to set at least 100ms for timer expiration. I was more or less wondering if there would be a better way, hence the question.

为什么我接受了答案我认为来自 freespace 的回答最好地描述了为什么没有实时 Linux 系统就不可能实现.

Why I accepted the answer I think the answer from freespace best described why it is not really possible without a realtime Linux System.

推荐答案

在主循环中轮询也不是解决方案 - 您的进程可能没有太多的 CPU 时间,因此在您的代码开始运行之前将过去 10 毫秒以上,使其毫无意义.

Polling in the main loop isn't an answer either - your process might not get much CPU time, so more than 10ms will elapse before your code gets to run, rendering it moot.

10 毫秒是大多数非实时操作系统 (RTOS).但它在非 RTOS 中没有实际意义 - 调度程序和调度程序的行为将极大地影响您对计时器到期的响应速度.例如,即使假设您有一个低于 10 毫秒的分辨率计时器,如果您的代码没有运行,您也无法响应计时器到期.由于您无法预测代码何时运行,因此您无法准确响应计时器到期.

10ms is about the standard timer resolution for most non-realtime operating systems (RTOS). But it is moot in a non-RTOS - the behaviour of the scheduler and dispatcher is going to greatly influence how quickly you can respond to a timer expiring. For example even suppose you had a sub 10ms resolution timer, you can't respond to the timer expiring if your code isn't running. Since you can't predict when your code is going to run, you can't respond to timer expiration accurately.

当然有实时 linux 内核,请参阅 http://www.linuxdevices.com/articles/AT8073314981.html 获取列表.RTOS 提供了一些工具,您可以通过这些工具获得有关代码何时运行的软性或硬性保证.这是可靠且准确地响应计时器到期等的唯一方法.

There is of course realtime linux kernels, see http://www.linuxdevices.com/articles/AT8073314981.html for a list. A RTOS offers facilities whereby you can get soft or hard guarantees about when your code is going to run. This is about the only way to reliably and accurately respond to timers expiring etc.

这篇关于linux下1ms分辨率定时器推荐方式的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆