为什么 nanosleep() 和 usleep() 太慢了? [英] Why are nanosleep() and usleep() too slow?

问题描述

我有一个程序可以生成要发送到接收器的数据包.我需要一种有效的方法来在每个数据包的发送之间引入一个小的延迟，以免超出接收器.我试过 usleep() 和 nanosleep() 但它们似乎太慢了.我已经实现了一个繁忙的等待循环并取得了更大的成功，但我知道这不是最有效的方法.我对任何人尝试做我正在做的事情的经历感兴趣.其他人是否认为 usleep() 和 nanosleep() 适合此类应用程序?

I have a program that generates packets to send to a receiver. I need an efficient method of introducing a small delay between the sending of each packet so as not to overrun the receiver. I've tried usleep() and nanosleep() but they seem to be too slow. I've implemented a busy wait loop and had more success, but it's not the most efficient method, I know. I'm interested in anyone's experiences in trying to do what I'm doing. Do others find usleep() and nanosleep() to function well for this type of application?

谢谢，

丹尼·勒沃林

推荐答案

睡眠函数在非常短的时间间隔内的行为很大程度上取决于内核版本和配置.

The behaviour of the sleep functions for very small intervals is heavily dependent on the kernel version and configuration.

如果您有一个无滴答"内核 (CONFIG_NO_HZ) 和高分辨率计时器，那么您可以预期睡眠非常接近您的要求.

If you have a "tickless" kernel (CONFIG_NO_HZ) and high resolution timers, then you can expect the sleeps to be quite close to what you ask for.

否则，您通常会以定时器中断的粒度进​​入睡眠状态.定时器中断间隔是可配置的(CONFIG_HZ) - 10ms、4ms、3.3ms和1ms是常见的选择.

Otherwise, you'll generally end up sleeping at the granularity of the timer interrupt. The timer interrupt interval is configurable (CONFIG_HZ) - 10ms, 4ms, 3.3ms and 1ms are the common choices.

这篇关于为什么 nanosleep() 和 usleep() 太慢了?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！