crc32算法原理

Cyclic Redundancy Check循环冗余检验,是基于数据计算一组效验码,用于核对数据传输过程中是否被更改或传输错误。 算法原理 假 设数据传输过程中需要发送15位的二进制信息g=101001110100001,这串二进制码可表示为代数多项式g(x) = x^14 + x^12  + x^9 + x^8 + x^7 + x^5 +  1,其中g中第k位的值,对应g(x)中x^k的系数。将g(x)乘以x^m,既将g后加m个0,然后除以m阶多项式h(x),得到的(m-1)阶余项 r(x)对应的二进制码r就是CRC编码。
h(x)可以自由选择或者使用国际通行标准,一般按照h(x)的阶数m,将CRC算法称为CRC-m,比如CRC-32、CRC-64等。国际通行标准可以参看http://en.wikipedia.org/wiki/Cyclic_redundancy_check
g(x)和h(x)的除运算,可以通过g和h做xor(异或)运算。比如将11001与10101做xor运算:      
明白了xor运算法则后,举一个例子使用CRC-8算法求101001110100001的效验码。CRC-8标准的h(x) = x^8 + x^7 + x^6 + x^4 + x^2 + 1,既h是9位的二进制串111010101。

      
经过迭代运算后,最终得到的r是10001100,这就是CRC效验码。
通过示例,可以发现一些规律,依据这些规律调整算法:

1. 每次迭代,根据gk的首位决定b,b是与gk进行运算的二进制码。若gk的首位是1,则b=h;若gk的首位是0,则b=0,或者跳过此次迭代,上面的例子中就是碰到0后直接跳到后面的非零位。
               

2. 每次迭代,gk的首位将会被移出,所以只需考虑第2位后计算即可。这样就可以舍弃h的首位,将b取h的后m位。比如CRC-8的h是111010101,b只需是11010101。

      

3. 每次迭代,受到影响的是gk的前m位,所以构建一个m位的寄存器S,此寄存器储存gk的前m位。每次迭代计算前先将S的首位抛弃,将寄存器左移一位,同时将g的后一位加入寄存器。若使用此种方法,计算步骤如下:

      
※蓝色表示寄存器S的首位,是需要移出的,b根据S的首位选择0或者h。黄色是需要移入寄存器的位。S’是经过位移后的S。

查表法 同样是上面的那个例子,将数据按每4位组成1个block,这样g就被分成6个block。
      
下面的表展示了4次迭代计算步骤,灰色背景的位是保存在寄存器中的。

      

经4次迭代,B1被移出寄存器。被移出的部分,不我们关心的,我们关心的是这4次迭代对B2和B3产生了什么影响。注意表中红色的部分,先作如下定义:

   B23 = 00111010
   b1 = 00000000
   b2 = 01010100
   b3 = 10101010
   b4 = 11010101
   b’ = b1 xor b2 xor b3 xor b4

4次迭代对B2和B3来说,实际上就是让它们与b1,b2,b3,b4做了xor计算,既:
   B23 xor b1 xor b2 xor b3 xor b4
可以证明xor运算满足交换律和结合律,于是:
   B23 xor b1 xor b2 xor b3 xor b4 = B23 xor (b1 xor b2 xor b3 xor b4) = B23 xor b’
b1是由B1的第1位决定的,b2是由B1迭代1次后的第2位决定(既是由B1的第1和第2位决定),同理,b3和b4都是由B1决定。通过B1就可以计 算出b’。另外,B1由4位组成,其一共2^4有种可能值。于是我们就可以想到一种更快捷的算法,事先将b’所有可能的值,16个值可以看成一个表;这样 就可以不必进行那4次迭代,而是用B1查表得到b’值,将B1移出,B3移入,与b’计算,然后是下一次迭代。

      
可看到每次迭代,寄存器中的数据以4位为单位移入和移出,关键是通过寄存器前4位查表获得
,这样的算法可以大大提高运算速度。
上面的方法是半字节查表法,另外还有单字节和双字节查表法,原理都是一样的——事先计算出2^8或2^16个b’的可能值,迭代中使用寄存器前8位或16位查表获得b’。

反向算法之前讨论的算法可以称为正向CRC算法,意思是将g左边的位看作是高位,右边的位看作低位。G的右边加m个0,然后迭代计算是从高位开始,逐步将低位加入到寄存器中。在实际的数据传送过程中,是一边接收数据,一边计算CRC码,正向算法将新接收的数据看作低位。
逆向算法顾名思义就是将左边的数据看作低位,右边的数据看作高位。这样的话需要在g的左边加m个0,h也要逆向,例如 正向CRC-16算法h=0x4c11db8,逆向CRC-16算法h=0xedb88320。b的选择0还是h,由寄存器中右边第1位决定,而不是左边 第1位。寄存器仍旧是向左位移,就是说迭代变成从低位到高位。

0
0

0 [end

今天重装了virtualbox

今天重装了virtualbox; 原来的ubuntu虚拟机的一些文件还留着呢,自然想能直接使用,于是把一个文件拖到virtualbox上,直接就创建了一个虚拟机; 感觉很方便,但是不爽的是启动到桌面里面的时候就直接报错,然后virtualbox就退出了。
后来重新创建虚拟机,依然使用原来的disk文件,问题解决。

中国车牌号 标识说明

广东省(粤) 

粤A 广州,粤B 深圳,粤C 珠海,粤D 汕头,粤E 佛山,粤F 韶关,粤G 湛江,粤H  肇庆,粤J  江门,粤K 茂名,粤L 惠州,粤M 梅州,粤N 汕尾,粤P 河源,粤Q 阳江,粤R 清远 ,粤S 东莞,粤T 中山,粤U 潮州,粤V 揭阳,粤W  云浮,粤X 顺德,粤Y 南海,粤Z港澳进入内 地车辆 

北京市(京) 

京A、京C、京E、京F、北京市(城区),京G 北京市(远郊区), 京B 出租车,京O警察   

 

天津市(津)   

津A、津B、津C、天津市 ,津E 出租车   

 

上海市(沪)   

沪A、沪B、沪D 上海市区,沪C 远郊区   

 

重庆市(渝)   

渝A 重庆市区(江北),渝B 重庆市区(江南),渝C 永川区,渝F 万州区,渝G 涪陵区,渝H  黔江区   

 

河北省(冀)   

冀A 石家庄,冀B 唐山,冀C 秦皇岛,冀D 邯郸,冀E 邢台,冀F 保定,冀G 张家口,冀H 承德 ,冀J 沧州,冀R 廊坊,冀T 衡水   

 

河南省(豫)   

豫A 郑州,豫B 开封,豫C 洛阳,豫D 平顶山,豫E 安阳,豫F 鹤壁,豫G 新乡,豫H 焦作,豫J  濮阳,豫K 许昌,豫L 漯河,豫M 三门峡,豫N 商丘,豫P 周口,豫Q 驻马店,豫R 南阳,豫S  信阳,豫U 济源   

 

云南省(云)   

云A 昆明,云B 东川,云C 昭通,云D 曲靖, 云E 楚雄彝族,云F 玉溪,云G 红河哈尼族,云H  文山壮族苗,云J 思茅,云L 大理白族,云K 西双版纳,云M 保山,云N 德宏傣族,云P 丽江, 云Q 怒江僳族,云R 迪庆藏族,云S 临沧   

 

辽宁省(辽)   

辽A 沈阳,辽B 大连,辽C 鞍山,辽D 抚顺,辽E 本溪,辽F 丹东,辽G 锦州,辽H 营口,辽J  阜新,辽K 辽阳,辽L 盘锦,辽M 铁岭,辽N 朝阳,辽P 葫芦岛,辽V 省直机关   

 

黑龙江省(黑)   

黑A 哈尔滨 ,黑B 齐齐哈尔,黑C 牡丹江,黑D 佳木斯,黑E 大庆,黑F 伊春,黑G 鸡西,黑H  鹤岗,黑J 双鸭山,黑K 七台河,黑L 松花江行署,黑M 绥化,黑N 黑河,黑P 大兴安岭   

 

湖南省(湘)   

湘A 长沙,湘B 株洲,湘C 湘潭,湘D 衡阳,湘E 邵阳,湘F 岳阳,湘G 大庸,湘H 益阳,湘J  常德,湘K 娄底,湘L 郴州,湘M 零陵,湘N怀化,湘P 湘西州   

 

安徽省(皖)   

皖A 合肥,皖B 芜湖,皖C 蚌埠,皖D 淮南,皖E 马鞍山,皖F 淮北,皖G 铜陵,皖H 安庆,皖J  黄山,皖K 阜阳,皖L 宿州,皖M 滁州,皖N 六安,皖P 宣城,皖Q 巢湖,皖R 池州   

 

山东省(鲁)   

鲁A 济南,鲁B 青岛,鲁C 淄博,鲁D 枣庄,鲁E 东营,鲁F 烟台,鲁G 潍坊,鲁H 济宁,鲁J  泰安,鲁K 威海,鲁L 日照,鲁M 莱芜,鲁N 德州,鲁P 聊城,鲁Q 临沂,鲁R 菏泽,鲁U 青岛 

 

开发区   

 

新疆维吾尔(新)   

新A 乌鲁木齐,新B 昌吉回族,新C 石河子,新D 奎屯,新E 博尔塔拉,新F 伊犁哈萨,新G 塔 城,新H 阿勒泰,新J 克拉玛依,新K 吐鲁番, 新L 哈密,新M 巴音郭,新N 阿克苏,新P 克孜 勒苏柯,新Q 喀什,新R 和田   

 

江苏省(苏)   

苏A 南京,苏B 无锡,苏C 徐州,苏D 常州,苏E 苏州,苏F 南通,苏G 连云港,苏H 淮阴,苏J  盐城,苏K 扬州,苏L 镇江,苏M 泰州,苏N 宿迁   

 

浙江省(浙) 

浙A 杭州,浙B 宁波,浙C 温州,浙D 绍兴,浙E 湖州,浙F 嘉兴,浙G 金华,浙H 衢州,浙J  台州,浙K 丽水,浙L 舟山   

 

江西省(赣)   

赣A 南昌,赣B 赣州,赣C 宜春,赣D 吉安,赣E 上饶,赣F 抚州,赣G 九江,赣H 景德镇,赣J  萍乡,赣K 新余,赣L 鹰潭   

 

湖北省(鄂)   

鄂A 武汉,鄂B 黄石,鄂C 十堰,鄂D 沙市,鄂E 宜昌,鄂F 襄樊,鄂G 鄂州,鄂H 荆门,鄂J  黄岗,鄂K 孝感,鄂L 咸宁,鄂M 荆州,鄂N 郧阳,鄂P 宜昌,鄂Q 鄂西州   

 

广西壮族(桂)   

桂A 南宁,桂B 柳州,桂C 桂林,桂D 梧州,桂E 北海,桂F 南宁,桂G 柳州,桂H 桂林,桂J  贺州(属梧州),桂K 玉林,桂M 河池,桂L 百色,桂N 钦州,桂P 防城   

 

甘肃省(甘)   

甘A 兰州,甘B 嘉峪关,甘C 金昌,甘D 白银,甘E 天水,甘F 酒泉,甘G 张掖,甘H 武威,甘J  定西,甘K 陇南,甘L 平凉,甘M 庆阳 ,甘N 临夏回族,甘P 甘南藏族   

 

山西省(晋)   

晋A 太原,晋B 大同,晋C 阳泉,晋D 长治,晋E 晋城,晋F 朔州,晋H 忻州,晋J 吕梁,晋K  晋中,晋L 临汾,晋M 运城   

 

内蒙古(蒙)   

蒙A 呼和浩特,蒙B 包头,蒙C 乌海,蒙D 赤峰,蒙E 呼伦贝尔盟,蒙F 兴安盟,蒙G 锡林郭勒 盟,蒙H 乌兰察布盟,蒙J 伊克昭盟,蒙K 巴彦淖尔盟,蒙L 阿拉善盟   

 

陕西省(陕)   

陕A 西安,陕B 铜川,陕C 宝鸡,陕D 威阳,陕E 渭南,陕F 汉中,陕G 安康,陕H 商洛,陕J  延安,陕K 榆林,陕U 省直机关   

 

吉林省(吉)   

吉A 长春,吉B 吉林,吉C 四平,吉D 辽源,吉E 通化,吉F 白山,吉G 白城,吉H 延边朝鲜族   

 

福建省(闽)   

闽A 福州,闽B 莆田,闽C 泉州,闽D 厦门,闽E 漳州,闽F 龙岩,闽G 三明,闽H 南平,闽J  宁德,闽K 省直机关   

 

贵州省(贵)   

贵A 贵阳,贵B 六盘水,贵C 遵义,贵D 铜仁,贵E 黔西南州,贵F 毕节,贵G 安顺,贵H 黔东 南州,贵J 黔南州   

 

青海省(青)   

青A 西宁,青B 海东,青C 海北,青D 黄南,青E 海南州,青F 果洛州,青G 玉树州,青H 海西州,   

 

西藏(藏)   

藏A 拉萨,藏B 昌都,藏C 山南,藏D 日喀则,藏E 那曲,藏F 阿里,藏G 林芝   

 

四川省(川)   

川A 成都,川B 绵阳,川C 自贡,川D 攀枝花,川E 泸州,川F 德阳,川H 广元,川J 遂宁,川K  内江,川L 乐山,川Q 宜宾,川R 南充,川S 达县,川T 雅安,川U 阿坝藏族,川V 甘孜藏族,川W 凉山彝族,川Z 眉山。   

 

宁夏回族(宁)   

宁A 银川,宁B 石嘴山,宁C 银南,宁D 固原   

 

海南省(琼)   

琼A 海口,琼B 三亚,琼C 琼北

TokyoTyrant调谐参数之 xmsiz

不同的情景适合不同的参数,我们的场景是读写比例2:1, 写操作高峰时间为 6000/s ;资源为 2台8核16G内存机器。每台机器 6 * 149G的磁盘做了raid10。

每台机器2个端口,每个端口数据文件为5G; 存储方式为 .tch ; 没有任何调谐参数时, 每个端口处理写操作量为:
200~400/s ; 添加调谐参数 #xmsiz=5242880000 后, 每个端口处理写操作量为:
1000~2000/s ;  速度整整提高了原来的4倍。

关于负载的比较(只取了部分时间点来比较):
调整参数前:
sar  -f /var/log/sa/sa05

调整参数后:
sar  -f /var/log/sa/sa06

关于磁盘的读写数据的变化,因为没有sar没有收集,这里就不能给出了

关于页面的换入换出的比较:
调整参数前:
sar -B -f /var/log/sa/sa05

调整参数后:
sar -B -f /var/log/sa/sa06

可以看到,页面的换入换出明显减少了大约一半, 或许你发现了fault变多了,这也是使用了mmap的缘故,具体需要了解一下mmap了。

关于mmap
因为tc是从文件的开始固定地map文件的一段区域的,所以,如果map的那段区域如果慢慢变冷的话,这样的map也就变的没有意义了;或者文件太大,能map到内存的也不过1/10或者更少,则map的意义也是很小的,故要根据实际情况来选择之。
如果tc能聪明地选择map热数据的话,自然是件好事,但是目前确实还没有这么做,而且其升级版kc也没有这么做,至少到1.2.70版本是没有这么做的。

TokyoTyrant的全内存存储不支持压缩

最近由于使用TokyoTyrant的全内存存储方式导致内存吃紧,于是突然想到TokyoTyrant支持压缩存储,抱着试一试的态度,看看内存存储是不是也能压缩;测试了一下发现似乎没有压缩,看了一下代码,如下图:

不解释了,意思就是说内存型的不支持压缩,其实也可以理解