求一个可以精确控制时间的方法

devoc 2010-10-17 02:12:48

比如我们需要在1s之类完成多少处理，这个怎么控制，我想了几种方法，但都不理想，程序大概如下



  int y_tps = 500;   /* 每秒发送笔数 */

  int y_times = 8;   /* 持续时间 */

  long y_lslpt;

  int y_total = y_tps * y_times;

  y_lslpt = 1000000 / y_tps; /* 每次操作应该分得的时间 */

  gettimeofday(&tv1, NULL);

  while(y_total -- > 0) {

    gettimeofday(&tv2, NULL);

    dosth();

    gettimeofday(&tv3, NULL);

    ildiff =  (tv3.tv_sec - tv2.tv_sec) * 1000000 + tv3.tv_usec - tv2.tv_usec;

    if (ildiff >= y_lslpt) continue;

    else usleep(ulstime - y_lslpt);

  }

  gettimeofday(&tv4, NULL);

  long y_res =  (tv4.tv_sec - tv1.tv_sec) * 1000000 + tv4.tv_usec - tv1.tv_usec;

  /* 这里得出的值要比上面的时间大得多，我也想到通过usleep(ulstime - y_lslpt);中参数在减去一个固定的值来调整，

   如sleep(ulstime - y_lslpt - 100);

但如果设置的每秒发送笔数增大，又不对了。这里如果需要精确控制，应该怎么来操作呢？有没有其他好的方法。谢谢

*/

...全文

227 22 打赏收藏转发到动态举报

写回复

用AI写文章

22 条回复

切换为时间正序

请发表友善的回复…

发表回复

devoc 2010-10-18

打赏
举报

[Quote=引用 21 楼 yutaooo 的回复:]

引用 19 楼 devoc 的回复:

还有补充下，每秒100次其实不高的。比如工作中用到测试压力的交易发送。

所以要问需求。100次是怎样的概念。是等分的，还是保证100次就OK?
[/Quote]
等分的啊，因为做的都是相同的操作啊

xisiyong 2010-10-17

打赏
举报

GetTickCount来控制

yutaooo 2010-10-17

打赏
举报

准备讨论。

LZ说一下所在的平台。

再完整描述一下需求。

ccltiancai 2010-10-17

打赏
举报

要多精确啊
抢占式的系统还想搞精确的？0 0

try325 2010-10-17

打赏
举报

ls是在linux下吗，可以先google一下

yutaooo 2010-10-17

打赏
举报

[Quote=引用 19 楼 devoc 的回复:]

还有补充下，每秒100次其实不高的。比如工作中用到测试压力的交易发送。
[/Quote]

所以要问需求。100次是怎样的概念。是等分的，还是保证100次就OK?

devoc 2010-10-17

打赏
举报

还有补充一点，这个也是多进程的，暂不考虑多线程之间的。呵呵
我也蛮困了。明天还上班呢。
先睡了哈

devoc 2010-10-17

打赏
举报

还有补充下，每秒100次其实不高的。比如工作中用到测试压力的交易发送。

devoc 2010-10-17

打赏
举报

[Quote=引用 16 楼 yutaooo 的回复:]
1. 每秒100次，这样的要求是比较高的。有资料建议，当sleep()在1秒以下，可以考虑用忙等。

2. 多数资料都会说，现在关于时间和计时触发器，都保证一个最低时延，而不保证最高时延。这也是主要的，认为不精确的要点。

3. 我的理解是，两个关键因素，造成最高时延不能被保证。a)进程(包括线程)调度。b)tick的精度。

4. 进程切换是相对复杂的操作。本身有一定的时延。并且，并……
[/Quote]
晕死，破网速，刚回的全没了。。。

首先谢谢你的回复，你说的很对，但是现在我的考虑是怎么样在考虑到调用usleep之类的函数所用的时间。
nonasleep我也试过了，效果差不多。
调用usleep(1)1毫秒的情况下，一般花的时间需要1000毫秒左右，用gettimeofday测的，不知道是否精准，这里如果tps大于1000的情况下，每次任务需要分的的时间就是1000一下，做完dosth()后，但是如果调用usleep之类的函数来的话，那么本是的时间片就超过了，所以造成实际tps与假设的不符合。

nanosleep也存在函数调用的时间差，这个如果大于本次剩余时间片，那也是不行的啊对吧？

这里是否只有考虑用到tick之类的操作？但是我没找到，只找到sysinfo能取得tick的精确时间，但是用来sleep的没找到。

某某9 2010-10-17

打赏
举报

多精确？
不是有库函数吗？

你的代码看不懂

帮顶吧

sky198306 2010-10-17

打赏
举报

个人意见,开始以后记时,结束记时,然后比较,还有一个就是,开始,然后到1秒结束

yutaooo 2010-10-17

打赏
举报

1. 每秒100次，这样的要求是比较高的。有资料建议，当sleep()在1秒以下，可以考虑用忙等。

2. 多数资料都会说，现在关于时间和计时触发器，都保证一个最低时延，而不保证最高时延。这也是主要的，认为不精确的要点。

3. 我的理解是，两个关键因素，造成最高时延不能被保证。a)进程(包括线程)调度。b)tick的精度。

4. 进程切换是相对复杂的操作。本身有一定的时延。并且，并不能保证当且进程被切换出cpu，立刻就将我们的进程切换上去，也许有其他进程正处于可运行状态与我们争夺。也许，提高我们进程的优先级是个方法。但优先级的调整需要比较熟悉调度算法。

5. tick的精度同样是个问题。现在，linux通常使用3个HZ值，分别是100, 250, 1000，这就是说，tick分别是10毫秒，4毫秒，1毫秒。拿10毫秒来说，比如在第6毫秒，设定一个4毫秒后的触发器，那是完美的。如果，在6毫秒，设定一个1毫秒的触发器，那么有3毫秒的额外时延。

6. 对于tick的第二个例子，幸运的是，结合linux的抢占式调度。如果本进程有较高优先级，是有机会立刻运行的。

7. 关注的函数:
nanosleep()
clock_nanosleep() /* 更高级 */

/* ------------------ */
alarm()
setitimer() getitimer() /* 更高级 */
timer_create() timer_settime() timer_gettime() timer_getoverrun() timer_delete() /* 更更高级 */

8. 关注的标准：
RFC 1305

yutaooo 2010-10-17

打赏
举报

ZeroC的ICE ?呵呵。

devoc 2010-10-17

打赏
举报

[Quote=引用 7 楼 yutaooo 的回复:]
准备讨论。

LZ说一下所在的平台。

再完整描述一下需求。
[/Quote]
uname -a
Linux ice_app1.com.cn 2.6.18-164.15.1.el5 #1 SMP Wed Mar 17 11:37:14 EDT 2010 i686 i686 i386 GNU/Linux

yutaooo 2010-10-17