博文

Asgard 4T SATA SSD 狗东上车记录&测评

## 引言 最近因为网课消息闭塞的我于4月13号凌晨突然看到群友说要开车。 ![img](https://vip1.loli.net/2020/04/15/nYsMAQlJjmyb32i.jpg) 然后打开才知道是JD的阿斯加特4T ssd,不是深夜开的那种车,虽然2000r/4t的确是很香吧……一看就知道是灵车,作为资深灵车受害者我必须得上一上 于是整了一个 ![image-20200415213830950](https://vip1.loli.net/2020/04/15/ChDobU6e8WNTxV5.png) 不要在意三块,另外两块是别人的( 到货之后拍了两张序列号当保修留底,盒子没什么特别的,没有拍的欲望。 测试环境记录: > OS:Windows 10 2004 > Motherboard:ROG Z370i > CPU:Shitel 8086k > Ram:[email protected] > 系统盘:760p 512G ## 跑分 先进行一下例行的跑分: 没啥区别,忘截图了,过。 ## 测试 因为这次的车非常的大,又非常的灵,让我有一种小孩开大车的感觉,所以干脆测试地彻底一点,按评(虐)测(待)的标准来。 然后打开我心爱的HDTune Pro……不对,HDTune不支持200G+的文件,我还是用 dd for Windows 自己写个脚本来测试吧。 然后让我们先用大文件读写个半盘并记录数据: ![image-20200415215151913](https://vip1.loli.net/2020/04/15/iYwJvSCQUKu7kO3.png) 这个……明显是全盘slc擦(ca)车(che),平时体验不错,能用能用(五毛一条,发时删除)。 ![image-20200415215355290](https://vip1.loli.net/2020/04/15/aKdWlx96P5wnDiO.png) 暂且不谈缓外60M直接吓得我停了测试,读的那四个在底部的点是怎么回事呢?是坏块,当读到的时候系统报错数据错误无法读取,然后四个文件就这样阵亡了…… 有SMART为证(图中框出来的A1项是出厂坏块数,A6项是目前坏块数,差值即为当前坏块) ![image-202004152258013…

wsl2, docker desktop, etc踩坑小记

markdown 在 [VMware 技术预览版](http://bit.ly/getworkstation-tp)的诱惑下,我果断地投入了Windows insider的怀抱,开始我曾经梦想的wsl2+docker windows+VMware的生活。 然后炸了我一脸,幸好因为疫情暂时没啥锅要背。 ## wsl2 ### 错误 0xffffffff 刚装上之后总是转不过去wsl2,看到[一篇issue](https://github.com/microsoft/WSL/issues/4364#issuecomment-520742839)中说到53端口的问题,看了一下发现确实有个(以前搞的没啥卵用的)服务在占用53端口,关闭并重启就ok了 ## docker desktop ### 神秘端口占用 常用的端口全被他给日了,一旦启动docker desktop就会被占用。 看到[这篇博文](https://blog.miniasp.com/post/2019/03/31/Ports-blocked-by-Windows-10-for-unknown-reason)意识到又是`excludedportrange`的锅(如果你有在win10 1803更新后打不开ss,提示1080被占用,怎么找都找不到端口占用的话,那就是这个了) #### before 忘截图了,总之就是只有几个条目的样子 #### after ![](https://vip1.loli.net/2020/02/15/PKM6Vkb7DyfQt9j.jpg) #### solution 因为忘了截图,所以上面的after其实是我解决之后的截图。 docker desktop会占下一批的端口留待动态分配,看到上面那个博文中「每次占用的端口都有变化」之后,如果你还没有意识到他是在从系统整动态端口的话就说不过去了。 通过`netsh int ipv4 show dynamicport tcp`检查自己的动态端口分配规则发现:tmd竟然是从1000开始的? 使用`netsh int ipv4 set dynamicport tcp startport=40000 numberofports=20000`将tcp动态端口的范围设置为「40000-60000」,当然你愿意严格按照IANA那…

杀软影响测试数据记录 Day5

看到网友想要咖啡,看了一下似乎咖啡的查杀率还行?正好水一水 ## McAfee version: LiveSafe™ 16.0 R22 ViruScan: 22.7.150 ``` mcafee,1,51438493,true mcafee,2,43255635,true mcafee,3,43356768,true mcafee,1,52562688,true mcafee,2,43689556,true mcafee,3,43780748,true ``` 嗯…… ## Dr.Web version: 12.0 ``` drweb,1,58892710,true drweb,2,46069981,true drweb,3,44657713,true drweb,1,51462600,true drweb,2,46164587,true drweb,3,44953941,true ``` 卡的不出预料,反而……还比预想的好一点?(

杀软影响测试数据记录 Day4

图片
明明是day3怎么就变成day4了呢( 被卡饭的 [B100D1E55](https://bbs.kafan.cn/space-uid-1089589.html) 老哥提醒之后意识到了,有一部分排除后运行的杀软成绩也被包括了,所以这里先改用PS脚本确定不会报毒之后,再重做一下这几个杀软的测试吧。 ## Avira version: 不变 ``` avira-re,1,39048895,true avira-re,2,37008196,true avira-re,3,36394711,true avira-re,1,36326695,true avira-re,2,34122910,true avira-re,3,34279854,true ``` 数据稍有上涨,在误差或是其他玄妙原因可概括范围之内。 ## Norton version: 不变 ``` norton-re,1,514410715,true norton-re,2,466684875,true norton-re,3,444878396,true norton-re,1,453577892,true norton-re,2,456043242,true norton-re,3,435251122,true ``` 这至少体现出诺顿排除是有用的( ## 360 version: 不变 ``` 360-re,1,485718803,5 360-re,2,414207104,5 360-re,3,466016728,5 360-re,1,419395764,5 360-re,2,385525534,5 360-re,3,393290280,5 ``` 数据差别不大,头部神秘上扬,还是一如既往的骚就是了 ## 360 TS version: 不变 ``` 360ts-re,1,355801192,4.5 360ts-re,2,408716625,4.5 360ts-re,3,417581926,4.5 360ts-re,1,366732217,4.5 360ts-re,2,437999527,4.5 360ts-re,3,391668938,4.5 ``` 同上 ## Avast version: 19.8.2393 - 19.8.4793.544 鉴于有网友深切渴望小…

杀软影响测试数据记录 Day3

markdown 本来打算明天再摸的东西今天就摸了,摸了就摸了吧 本段包含: - MalwareBytes - Norton - 360 - PcMgr - 火绒 ## Norton version: 22.19.9.63 诺顿安装更弱智,我在国区买的国区only key在中国的ip的vm里竟然不能激活……幸好他大发慈悲给我一天的测试时间……谢谢啊.jpg ``` norton,1,46405926,5 norton,2,44072534,5 norton,3,43486169,5 norton,1,43328095,5 norton,2,43932741,5 norton,3,42333949,5 ``` 说实在的,ux还行( 这个明显的下降看起来也挺像云影响造成的,不知道是不是。现在我对3s内的都感觉像误差。 ## 360 version: 12 ``` 360,1,43211434,5 360,2,40877322,5 360,3,38490096,5 360,1,41856146,5 360,2,45256039,5 360,3,44284756,5 ``` 有一说一,不吹不黑,纯路人,360的用户体验的确是不错……如果你愿意先花个一分钟去设置里面把广告都关掉的话。 360这个时间波动有点大,同时还能看到联网日志,所以据推测应该是有不少云数据在搞,波动主要来自于网络,除此之外也没啥好解释的。 一键加白好评,速度很快,基本没有动画过渡还没有一点点卡顿感。 ## 360 TS version: 10.6.0.1259 无BD/红伞引擎 ``` 360ts,1,45764871,4.5 360ts,2,41463470,4.5 360ts,3,44874638,4.5 360ts,1,42143256,4.5 360ts,2,40082983,4.5 360ts,3,43187944,4.5 ``` 360这个的时间我实在是说不出什么话了,误差以内,可以接受( 不过有一说一,ts的ux也还行 ## 火绒 version: 5.0.32.15 ``` huorong,1,39322002,5 huorong,2,33283295,5 huorong,3,33196784,5 huorong,1,36969941,5 …

杀软影响测试数据记录 Day2

图片
markdown 今天预计是摸鱼功力见长的一天……本应是的( 本段包含: - BitDefender IS - Avira Pro - F-Secure Protect - ESET IS ## Bitdenfender version: Internet Security 2020 ``` bd,1,74410068,4 bd,2,62610618,4 bd,3,48293547,4 bd,1,61211506,4 bd,2,48497856,4 bd,3,41159297,4 ``` bd在测试过程中非常神秘地误报了我的自解压包,我等了半分钟才在列表里看到它并且放出来,其实还好。 这玩意大概是我今天耗时最久的一个,因为装上之后连个手动更新都找不到,只能搁那放着等他自动更新……于是我双重摸鱼去打了一个小时屁股( bd的耗时也可以看到非常明显的下降趋势,不出预料的话主防有记忆白名单影响,在回滚快照后独立进行了一次测试之后就降低了主防的监测量。 ## Avira version: 不知道,忘了记版本号,今天是20191202自己脑补吧( ``` avira,1,33914045,4 avira,2,34130823,4 avira,3,33140247,4 ``` 红伞的体验极差+性能差距不大的缘故让我只测试了一组。先是把我的自解压传到云上报了个壳杀了,恢复之后双击又把我的go程序传到云上报了个APC…… 最终不得不全部加白,这样一来性能肯定是相当可以的,毕竟红伞除了扫描啥都没有(乳伞)。 ## F-Secure version: 不知道,忘了记版本号,今天是20191202自己脑补吧( ``` fs,1,65873652,4 fs,2,47410988,4 fs,3,47538219,4 fs,1,64186865,4 fs,2,49041397,4 fs,3,47576290,4 ``` 性能不出意料的菜,顺便一提因为先测的红伞,所以fs这边给我误报了APC……不知道要是先测fs的话会不会来个dg不常见呢(恶意)。 看起来应当是一个模块存在学习白名单,但是其他模块木大,因此最终耗时还是高于红伞。 ## ESET version: 13鬼知道哪个小版本 ``` eset,1,37290031,0 eset,2,32623…

杀软影响测试数据记录 Day1

markdown 虽然说是Day1,但是摸鱼的我明显不会一天搞完,暂且算作第一段吧( 本段包含: - Base Line - Windows Defender - Kaspersky Free Antivirus - GDATA Antivirus 数据结构定义: ``` name,round,time(10^-6s),usability ``` 其中「可用性」定义为`5 - ((排除所需的额外不自然操作 - 1) / 2)`。 ## Base Line ``` none,1,32238426,5 none,2,32719690,5 none,3,32866807,5 ``` 这是没有任何杀软情况下的基准线。 ## Windows Defender version: 20191201 ``` wd,1,41449415,5 wd,2,35426191,5 wd,3,35548786,5 wd,1,40973951,5 wd,2,36079794,5 wd,3,35698385,5 ``` WD的测试数据可以看出明显的,在第一次测试后的下降趋势 ## KFA version:2020(e) ``` kaspersky,1,44065458,4 kaspersky,2,44829224,5 kaspersky,3,35838571,5 kaspersky,1,38798133,5 kaspersky,2,34887663,5 kaspersky,3,35615266,5 ``` 卡巴的测试数据同样展现出了下降的趋势,不出意料的话是KSN发挥了作用,在恢复快照后的第二次测试中消耗了额外的3s用于请求网络数据。 ## GDATA version:25.5.5.40 ``` gd,1,47323123,4 gd,2,41108207,4 gd,3,41361050,4 gd,1,44900977,4 gd,2,47476211,4 gd,3,41713014,4 ``` gd的自有A引擎在测试时将我的自制自解压「可疑程序」误报了,第一次时加白后测试得到的成绩,第二次为直接使用测试脚本跑的。 ## Day1 Summary 为了便于阅读,这里的y轴单位是ms(10^-3 s)。 ![pic](data:image/png;bas…