Snooda

智器的CPU从拆机图上看是TCC8902，主频600MHZ，ARM架构。由于内置的ubuntu里的perl有问题，apt的时候报一堆错，所以需要重新安装一个perl，activeperl提供的下载只有x86和x86_64，故需要自己编译。搞了一下发现太蛋疼了，比之前买的cpu限制为300mhz的vps还慢一个数量级。。通过分析cpu使用情况，发现虽然存储用的是flash芯片，但io速度并不是瓶颈。在解压缩的过程中主要是nand_flash_q服务占用了一半的cpu，也就是读写闪存芯片耗费了过多的cpu。在config和make的过程中io耗费的cpu大概占用了百分之三十。用户态cpu占用率为百分之七十。关于为什么智器速度要慢于弱vps的问题，我分析可能是如下原因：
1，对于不同架构cpu，主频并不决定性能的绝对高低。性能还跟一二三级缓存大小、流水线等有关，故智器的cpu频率虽高，未必性能要强于300mhz的至强。
2，那个弱vps是openvz技术，openvz技术里操作io耗费的cpu不知道是不是计入小鸡的份额里，很大可能是不计入。这样的话由于智器有将近一半的cpu被用来做io操作了。故跟vps比的时候只相当于300对300.
3，智器的iowait占用cpu量极小，故推测io速度不是瓶颈，这个推断是否正确？感觉总是和直觉上不符。


以上只是个人推测观点，有错误之处还请高手指教。

最近比较忙，很久没写日志，现在又有时间了。

先搞一下智器，本来想搞个小主机用来搭建个家庭多媒体中心，后来查了一下新的成本较高，旧的扩展性太差。突然想起来有个限制的智器，很不错，arm架构，功耗不大。256内存，有ubuntu 9.10.可以拿来用。于是翻出来接上电源。

首先启动ssh服务，自己带了，编辑/etc/rc.local让它开机自启。连上无线路由器，现在可以同局域网ssh上去操作了。

下面是公网访问，本来想搞个端口映射出来，电信给的路由器很烂，配了没啥效果，所以决定先用ssh做个端口转发，使用博客服务器做跳板，优点是路由器公网ip变了也没事，缺点是每个命令都要中美之间走两个来回，延迟巨大。用upnp应该能解决端口映射的问题，这个后续研究。

下一步想搞个远程音乐播放出来，智器是由esound提供音频服务，windows下有个WinESD客户端，不过已经十多年没有更新了，感觉不靠谱，自己研究一下写一个出来。

最近用到opencv库，该库只能从文件中载入图像，而我的数据是在内存中的。需要将数据映射到文件再供opencv使用，于是想到mmap。
mmap主要是用来将文件的内容映射到内存地址，而将内存中的内容映射到文件不知行不行，于是决定尝试一下。

于是将mmap的第一个参数设置为存放数据的存储区指针，大小设置为数据大小，文件描述符为打开的一个空文件。发现映射前后内存区数值未变化，但是文件内容并未变化，调用msync无效，后来发现映射后的地址和传入的地址不同，原来已被使用的内存地址不能用来mmap，函数自动调整了映射位置，后来又做了些测试，总结如下特性：
1，mmap不能改变对应文件的大小，比如文件之前10k，即使映射100k，文件还是10k。
2，mmap映射大小和文件大小无关，10k的文件可以映射100k出来，当然后90k其实是无意义的。
3，mmap映射后的内存大小以映射时指定大小为准，比如10k文件映射100k，那么对于映射地址可操作的地址空间是100k。
4，mmap只向文件同步修改过的内容，而不是同步不一致的内容，比如映射了10k，目标内存地址原内容和文件内容完全不同，后修改了指定内存地址1k的内容，同步后文件只有1k的内容修改。

以上只是通过测试得出的特性，具体mmap的实现原理还有待读代码体会。

最近想搞个fastcgi模块跟nginx交互，弄了个测试程序结果怎么也跑不起来，直接显示502，nginx日志显示“upstream closed prematurely FastCGI stdout while reading response header from upstream”。调了很长时间调不出来，gdb显示程序运行没什么问题。后来请教高人，终于发现了问题，原来cgi回复里面http头一定要自己构造的，其中的“Content-type: text/html”必不可少，且由“
”结尾，也可自己根据需要添加cookie等头信息，然后需要有一个“
”组成的空行（http头规定），然后是http内容，http内容就可以自己随便写了。

今天在看一些资料时突然看到有人讨论thinkpad里电源管理器的省电模式是伪降频还是别的什么，于是决定探究一下我的电脑。

打开cpu-z，在电源管理器选择“最高性能”，频率马上跑到2.26G，电压也提高到了1.138v，切换到“最长电池寿命”，cpu频率降到800mhz，核心电压0.9v。可见电源管理器里的电源方案对cpu频率是有调节作用的。

然后打开一个高清视频，在自动电源方案下，先使用带硬件加速的播放器播放，显示cpu占用百分之三十，频率800mhz。关闭硬件加速，显示cpu占用百分之八十，频率在800-1500左右浮动。
在最高性能方案下，开启硬件加速时cpu占用百分之八到九，关闭硬件加速cpu占用百分之三十多。
在最长电池寿命方案下，开启硬件加速时cpu占用百分之三十，关闭硬件加速时cpu满载，视频卡。

由此可见在笔记本电脑上由于频率自动调节技术的存在，单靠任务管理器里cpu占用率并不能判断出计算量的规模大小。还需要同时结合cpu的工作频率来计算。举个例子，在自动方案下，开启硬件加速和关闭硬件加速时cpu占用率相差一倍半，此时并不能简单判定计算量也增大了一倍半，根据最高性能方案数据，计算量相差两倍多。之所以cpu占用率只差一倍半，是因为cpu工作频率提高了。所以在笔记本上做评测对比计算量时，需要启用最高性能方案，然后比较cpu占用率，才能得到比较准确的结果。

通过十几分钟的观察，发现cpu大部分时间都是工作在800的频率下，在观看网页视频的时候平均也只工作在1Ghz左右，虽然在任务管理器里看到cpu占用率达到了百分之六十多，但实际上cpu还是处在休息状态。因此可以判定在现阶段的日常应用中，cpu资源是大大富余的。

这时又想到一点，就是core i系列cpu鼓吹的睿频技术，通过上面的评测可以看出移动cpu本来就是频率自动调整的，睿频并没有太大的亮点。只是一个宣传的技巧，比如把我现在用的cpu不再说“额定频率2.26g“而是改成说：“该cpu额定频率2ghz，在cpu占用率高时可以自动超频到2.26g”。那我的cpu也就成了“睿频”技术了。不过貌似睿频是只能单个核超。不过总体上来讲对于移动平台来说这不算个技术。

今天发现拿一个磁铁在电脑屏幕左侧边缘中间处上下滑动后电脑就会待机。。。这是为啥。留待考证

今天在用无线网共享有线网连接的时候遇到问题，提示无法启动，错误信息居然是null，从事件查看器里面查看了下日志，发现报“ICS_IPV6 未能继续配置 IPv6 堆栈”错误和“ICS_IPV6 无法分配  字节的内存。这可能表示系统的虚拟内存不足或者内存管理程序遇到一个内部错误。”警告，禁用了ipv6后仍无效，后来发现需要开启windows firewall服务后可解决此问题。令人无语的是错误信息居然报null，估计是微软的工程师开发的时候这里的异常处理没有做好。

晚上的火车，明天早晨到。

今天不小心把VPS上一个重要的脚本给覆盖了，郁闷了2秒思考恢复之法的时候突然想起我每天都备份了。哈，爽，从备份里把文件提取出来恢复了。

最近想了解一下p2p的东西，于是决定装个rtorrent，rtorrent依赖于libtorrent库。yum源里带的版本太旧，于是决定自己编译一个。

选了rtorrent官网推荐的stable版的libtorrent-0.12.6.tar.gz和rtorrent-0.8.6.tar.gz，编译过程总体比较顺利。期间遇到一个问题，就是我把libtorrent安装到了自己定义的一个路径下，在编译rtorrent的时候用pkg-config搜索libtorrent的时候无法找到。

搜了一下有两个方案，一种是export PKG_CONFIG_PATH="libtorrent的路径"，把路径加入pkg-config的搜索路径，是个比较简单的方法。还有一种是定义libtorrent_LIBS环境变量，用来替代pkg-config的输出，比较复杂，不推荐。

编译好后下个bt测试一下，结果发现不能连接tracker服务器，老是timed out。查了下需要libcurl-7.19以上且编译时需要编译时加入c-ares支持，而yum源里最新的是7.15，需要重新编译libcurl，评估了一下代价太大。查了下说0.8.2版以后才有此问题，于是下了个0.8.1版的rtorrent编译了。

在编译rtorrent的时候加了--enable-ipv6，但是实际使用中无法启用ipv6，又查了下发现在编译libtorrent的时候也要加--enable-ipv6.加上后还是不行。后来发现需要给libtorrent打个补丁：

cd libtorrent-0.12.6
wget http://home.samfundet.no/~sesse/libtorrent-0.12.6-ipv6-07.patch
patch -p1 < libtorrent-0.12.6-ipv6-07.patch

然后再configure --enable-ipv6，make，make install。

一切ok。