今天加班有点累。掐着点坐末班地铁回到家。喝水休息。又好一点了。上来随便敲点，放松一下。
wyj美女正在跑超大规模的实验，我要帮她完成一部分。但最近时间紧张。今天索性抓她一起完成，交叉检查避免疏漏。到晚上22点，384组实验的参数总算全设置完了，我们都接近崩溃。然而，跑起来，集群速度不正常。瓶子帮忙检查了好久。有些灯枯油尽，又要赶地铁，明天再继续。
感觉是硬件问题。最近某个节点似乎一直在“带病坚持工作”：也不彻底死机，就是超级慢。遇到这种问题Google系统的常规做法是把长时间“不归队”的节点放弃掉，将其任务重新平分给其他各节点。pFind目前对此还没啥特别措施，Mascot、SEQUEST和X!tandem等竞争对手的集群版也没考虑。
可用性应该是云计算设施的基本要求，也许比速度甚至精度还重要。算算概率，Intel
CPU理论上连续运行10年出现一次浮点计算错误，这就意味着上千核的集群每2小时就错一次（还没考虑其他更容易出问题的部件）。也就是说，在大规模的廉价商业集群上长期运行的软件，必须把硬件错误当作常规事件，考虑对应的鲁棒性设计。Google就强调GFS、MapReduce和BigTable的最牛之处并不是峰值速度或数据吞吐量，而是其在廉价集群硬件上的稳定性和容错能力。
跑题，列点最近几天新买的书：《Search Engines — Information Retrieval in Practice》、《Out of Mao’s Shadow》、《一九八四》、《伊斯坦布尔——一座城市的记忆》和《一个人的电影》。发现前两本英文书居然看得最快。第二本书，是hchi去美国参加RECOMB Satellite Conference on Computational Proteomics 2010给带回来的。走之前他问我要带什么。我随口说：“带本书吧”。结果他就千里迢迢从美国带回来一本华人写中国的英文书。我该早预计到这个结果的。当然，书是好书，还是要感谢。
顺便自豪一下：这次rxsun老大参加iPRG 2010磷酸化数据鉴定评测，pFind引擎在全世界人民面前一鸣惊人了一把。而hchi哥的pNovo更是让de novo算法的主流人物服气了。（伟大的hchi哥进入de novo领域才半年，真快。)
