不知道seti官方是怎么想的

WiZarD811

ap大量普及后,半途而废的情况大幅增加…往往是七八个用户算同一个包,结果没几个能及时上报…这样对官方而言岂不是很没效率么?

BiscuiT

查看了一下...

普平是4种情况
1. Error while downloading
2. Error while computing
3. Timed out - no response
4. Aborted by user (这个相对少..

ap包文件大, 网络便秘用户容易出现下载超时...(可以理解
毕竟使用优化的用户相对比较少, 长时间计算肯定会增加任务出错率...(可以理解
同样的计算需时长但限期却相对MB包少, 也会导致用户完成能力下降...(可以理解
看到恐慌性的需时又没了解ap包的特性, 存有害怕心理的用户主动中止ap包...(可以理解

随便浏览了四十多个已给分的ap包... 超过5用户算不算多.. 碰到两个7用户
而且发觉 Error while computing 的包基本都是接收后很近期内出现...(任务管理器终结进程?
不过有些已经评分了但还有用户在 In progress ...



(网络便秘者其实比较多...囧

[ 本帖最后由 BiscuiT 于 2009-4-26 17:02 编辑 ]

ycb

项目组有什么好想的呢.

机制决定需要2人计算出同一结果才算该WU完成,现在因为中途放弃的人多,所以只好再把该WU分给另外的人,甚至有7-8之多,

项目组本来可以做2件事情:
    1 划小AP包的WU,这样中途放弃的人就少一些,但好象这个不适合AP,以前有帖子说过这样就会增加很多额外的计算,不合适.
    2 把优化程序作为标准程序提供给新人,减少恐惧,增强继续计算的信心, 但也有帖子分析过 也有难处,比如要考虑成熟度,通用性等等.

所以现在也许只能先这样了,其实中途放弃的人大多赶开始计算就放弃了,前面BiscuiT 分析过了,这样浪费并不严重的,所以没有多大关系的.

Youth

引入第三方的优化手段是王道，就像之前在mb包上所做的一样。

BG4ACE

不是七八人同时算的吧 应该是每次同时两个人在算 发生中止的情况以后再会分配给其他人  最后要两个人提交出相同的结果才算结束 如果两个人计算的结果不同的话  还会发配给第三个人进行验证