RamseyX客户端完善建议 #1

wpf999

@ZizhengTai 4.2.1已经将上传班车改为2min一趟，遭遇小任务包之后，还是存在利用率偏低的问题。

见下方数据，一个包只要30秒左右，而2分钟一趟上传班车，意味着有3/4的时间在等待，只有1/4的时间在计算，总体资源利用率仅为25%，这也是很大的浪费啊。希望RamseyX程序继续完善。

1. 最后保存: 09/08/13 11:12:14
   
2. 状态：暂停中
   
3. 运算时长：36秒
   
4. -------------------------------------
   
5. 进行中任务：0
   
6. -------------------------------------
   
7. 等待中任务：0
   
8. -------------------------------------
   
9. 已完成任务：1
   
10. Task #20784：100.00%
    
11. 
    
12. 最后保存: 09/08/13 11:14:14
    
13. 状态：暂停中
    
14. 运算时长：37秒
    
15. -------------------------------------
    
16. 进行中任务：0
    
17. -------------------------------------
    
18. 等待中任务：0
    
19. -------------------------------------
    
20. 已完成任务：1
    
21. 
    
22. Task #20888：100.00%
    
23. 最后保存: 09/08/13 11:16:14
    
24. 状态：暂停中
    
25. 运算时长：37秒
    
26. -------------------------------------
    
27. 进行中任务：0
    
28. -------------------------------------
    
29. 等待中任务：0
    
30. -------------------------------------
    
31. 已完成任务：1
    
32. Task #20996：100.00%

复制代码

wpf999

如果是强大的cpu，执行时间更短，那么总体资源利用率还会更低。有用户报告执行时间只有20秒，那么总体资源利用率只有1/6， 而且这个问题与并发任务数设置没有关系。

@ZizhengTai

wpf999

如果采用完成包就上传然后下载新包，可使总体资源利用率接近100%，由于硬件性能不同，以平均25%的总体资源利用率计，速度提升4倍

arthur200000

但是存在一个问题，即服务器负担过重。
个人倾向于类似于BOINC的基准测试方式，一次屯25分钟的包，20分钟一传。

wpf999

arthur200000 发表于 2013-9-8 13:14
但是存在一个问题，即服务器负担过重。
个人倾向于类似于BOINC的基准测试方式，一次屯25分钟的包，20分钟一 ...

这一批21万个包已经划分了，应该不可能再修改了。单包时间突然变短，得益于v4.2.1 采用了fwjmath博士的改进意见，速度大大加快

ZizhengTai

wpf999 发表于 2013-9-8 13:29
这一批21万个包已经划分了，应该不可能再修改了。单包时间突然变短，得益于v4.2.1 采用了fwjmath博士的改 ...

这个问题我觉得只是优化得速度太快导致的，正常情况下一个包（按设计）不应该这么短（至少一包一小时吧），所以也不会出现利用率很低的情况。
另外，速度非常快的应该只是某些中间区段，我遇到的一些包还是要算半个小时什么的...按进度这个目标不久之后就会完成了，由于现有任务已经无法更改了，不如下个版本中再做更合理的调整~

wpf999

ZizhengTai 发表于 2013-9-8 14:02
这个问题我觉得只是优化得速度太快导致的，正常情况下一个包（按设计）不应该这么短（至少一包一小时吧） ...

可以