为什么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?

谢谢

Danny Llewallyn

Danny Llewallyn

推荐答案

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

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

如果您有一个 tickless内核（ 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屋！