一个人的角落,也许并没人会看到这里~~ 祝福你,工作顺心,学习快乐~

记一例简单web业务性能瓶颈的改造过程

web项目通常由于需求紧,任务重,在上线初期,通常不会考虑太多架构性以及可靠性的问题。因此在业务稳定增长的过程中,大多都存在一个持续优化的过程。

这里记录一下前段时间,因某业务需要,对其持续优化的过程。

业务包括两个数据部分,一个负责实时数据上报的client,一个是负责数据接收以及实时数据展示的web系统。

优化目标有两个,一个是保证实时数据从收集到展示的延迟尽可能短,另一个是提高业务的可扩展性,保证业务的吞吐量不被一台服务器瓶颈所限制。

主要的操作包括静态资源加速,数据上报通道优化,服务器分布差异导致的延迟问题等。

web服务原始架构:

Client为安装在客户终端设备中的一个程序,浏览器为客户的其它带屏终端。Web Server为部署的服务器。

登录:

Client ==(认证信息)==> Web Server ==(返回服务URL)==> Client显示

授权通过后,Client开始收集数据并上传,客户通过Client显示的URL,在浏览器中加载完素材后,便有如下数据流。

XCode11下兼容arm64e的代码混淆编译器llvm11

对于ios程序,即使对binnary进行了加密,但启动之后加载到了memory中,还是存在一个解密的过程。 所以从源码以及编译器级别,对binary代码进行混淆是对抗安全攻击的最有效方法。

最新的apple处理器 a12 a13增加了arm64e架构,同时兼容arm64指令。

然而目前的最新的llvm-obfuscation 最高支持到llvm9,支持arm64e的llvm版本最低到llvm11。

去github上从apple的仓库中拉了llvm11的代码下来,给编译了一下,参考了现有的代码。重新实现了一个以支持arm64e。

在国内环境下安装Discourse

Discourse的版本升级与维护都是基于github来完成的,而Discourse本身又是基于ruby编写。

使用包括腾讯云的CVM、轻量服务器以及阿里云的ECS都存在国外网站访问慢的问题,主要是为了扶持国内git仓库做的限流操作。

在clone托管在github上的discourse时,可以通过将clone链接替换github.com为github.com.cnpmjs.org来加速对github的访问,比如:

git clone https://github.com/discourse/discourse_docker.git 替换为 git clone https://github.com.cnpmjs.org/discourse/discourse_docker.git

除此之外,在运行./discourse-setup时,安装程序同样会在docker中安装一些额外的的项目,

比如:gem update,同样需要添加ruby的镜像。

可以通过修改配置文件来添加ruby镜像地址,主要涉及到的文件有

黑苹果实现iPhone/iPad快充功能

通常,iphon或iPad连接苹果电脑的USB口时,会使用快充功能,充电功率可以达到2.1A,在[关于本机->系统报告->USB-iPad]中可以看到可用电流为500mA,加上额外的操作电流1600mA,总共2.1A。

然而在MacOS 10.13中USB的电源管理部分,由之前的AppleBusPowerControllerUSB变成了AppleBusPowerController,对应的电源描述属性也有所变化,在tonymacx86.com上RehabMan大佬已经详细阐述了这个问题:

[Guide] USB power property injection for Sierra (and later)

也就是EC的问题。

然而,在我的k610d笔记本上,显示EC被正常识别,AppleBusPowerController也正常加载,USB接上iPad后,额外的所需电流只有900mA,起初没太在意,直到后来把网卡换成BCM943后,额外的所需电流变成了850mA,再到后来接上鼠标后, 额外的操作电流 (mA)变成了650mA,于是不能再忍了。

今天,查看主板USB供电部分,三个接口,左侧USB有一块1.5A限流芯片,右边一个USB3.0和一个USB2.0供电部分直接接到了S5态的19v转5v的DC-DC上,芯片型号为nb671,查看数据手册发现,该芯片持续电流可达6A,峰值电流可达9A,分出2A来充电也是绰绰有余了,不会造成沁硬件损伤。

由于重新修改SSDT-UIACaml中电源电流供应参数,将USB总电流供应由3200ma提升为4100ma,这样在有耗电设备增加时,也不会由于总供电量不足而减少iPad的快充供电。

参考https://www.tonymacx86.com/threads/cant-charge-ipad-using-usb-ports-el-capitan.230465/

阿里YunOS电视盒子中多遥控器兼容实现

Allwinner h3处理器,作为入门级4k解决方案,经过了四五年时间的打磨,使用定制化的系统,目前还是可以运行一些简单的直播类点播类应用,这两天闲着把家里两款H3的积灰了的盒子刷下固件,一个是迪优美特X16,一个是忆典S1,两者均使用的512MB内存,8GB存储的公版设计,使用了阿里的YunOS系统的机器,刷机时只能刷YunOS系统,否则刷机工具会提示 “烧写BOOT1分区失败” ,具体实现机制应该是有芯片设计配合实现。网上有大虾破解这限制,并制作了可以刷入的安卓固件。

h3的机器固件大多可以通刷,只是小部分gpio,包括遥控器等无法正常使用,这里分析其支持多遥控器的实现机制。

涉及到一个内核模块和一个交互程序以及一个按键映射表文件夹。分别是sunxi-ir-rx.ko和/system/bin/multi_ir以及/system/usr/keylayout/custom_ir_xxxx.kl,其源代码分别可在github上找到。

sunxi-ir-rx.ko负责接收红外数据并进行解析。具体外红数据格式为NEC协议,参考:https://www.cnblogs.com/zhugeanran/p/9334289.html

根据遥控器发出的设备地址码和命令码,结合/dev/下注册设备用于与multi_ir交互提供的按键映射,向系统input发送按键消息。通常,设备地址码与遥控器厂商相关,而命令码对应具体物理按键。

而multi_ir用于解析/system/usr/keylayout/中的custom_ir_xxxx.kl。并向sunxi-ir-rx.ko提供不同设备地址的命令码对应的系统按键。其中xxxx为设备地址码。

通过cat /proc/kmsg 可以实时查看sunxi-ir-rx.ko接收到的数据。

sunxi-ir-rx.ko中默认编译可以最大存储16个不同设备地址的映射,因此,文件夹中最多可能存在16个不同的设备地址映射文件。

一例多系统共存下的无陨迁移

四年前买的固态如今不知道什么原因,开机会有一定概率主板检测不到固态,需要多次重启才检测到。

然而最近这种情况概率越来越大了,于是决定换一块三星的,毕竟数据重要。现在的固态价格比起四年前大约降低了一倍多,可能是TLC技术的普及吧。

系统环境

原系统使用了128G固态msata接口+500G机械,都使用的是GPT分区。原来加固态的时候就把机械上的Windows迁移到到固态,顺便把MBR分区转成了GPT,以兼容UEFI启动。

其中固态上为了三个分区,分别为(EFI分区,windows系统区,Ubuntu分区),机械硬盘5个分区,分别为(EFI分区,MacOS分区(原windows所在)以及D,E,F分区)

迁移环境

现在新换的固态为120G,原机械硬盘内容不动。需要将旧固态内容迁移到新固态。

歌华链路由器刷机历程

一入恩山深似海,从此节操是路人。。。

本文纯属闲扯,用到的方法恩山都有,但没有一个路径完全整合的方法,这里记录一下。

实验室的路由器一直用的还是大一买的,当时为便宜走奶茶家一次性买了俩,想着学校小水管D-Link内置天线就够用了,79包邮到一食堂门口。签收完,发现系统着实垃圾,但能用稳定还凑合,接有线一用就是四五年,直到现在9102年了都。

一直用的都是2.4Ghz频段的无线,因为宿舍区墙多隔离效果也好,实际对上网络要求不高,延迟要求不高的应用来讲,2.4Ghz频段的干扰也不大,不像商场比较开旷的地区,对普通应用体验来讲也是感觉不到干扰的。实际上干扰是存在的,主要表现为,当附近有2.4Ghz的大数据量传输时,其它设备会有严重丢包和Ping值变高的影响。

设计一个简单的RiscV协处理器RoCC(数组求和)一

 从系统效率和功能可复性方面来讲,当要使得协处理器能够处理更多的应用情景时,应当将目标事物,拆分成一系列更小的重复通用的事物处理过程,在上层软件中再进行事物处理的组装。而当要使得协处理器以系统效率为主,比如低功耗,则需将系统功能整体设计为一个功能单一的模块,做为专用处理器。

本文叙述一个简单的协处理器设计过程,用以加深对RoCC接口的理解。

RoCC加速器模块是由LazyRoCC类继承而来,该模块包含一个由LazyRoCCModuleImp继承而来的实例。

依葫芦画瓢,我们先设计一个加速器模块的外壳,用以可以被Rocket核调用。


class ArraySumCoP(opcodes: OpcodeSet)(implicit p: Parameters) extends LazyRoCC(opcodes) {
  override lazy val module = new ArraySumCoPImp(this)
}

class ArraySumCoPImp(outer: ArraySumCoP)(implicit p: Parameters) extends LazyRoCCModuleImp(outer)
    with HasCoreParameters {
    val cmd = Queue(io.cmd)
        ...
        ...
        ...
        
}

由于LazyRoCCModuleImp中已经包含了一个RoCCIO的接口,我们可以在实现中直接使用此接口。

RoCCIO接口由多组不同的Wire和bundle组成,具体信息参考上一篇文章:RoCC接口介绍

其中,cmd包含了Custom指令调用时,加速器接收到的内容,参数如下:

  • cmd.inst,为32位指令内容,由以下组成:cmd.inst.[opcode, rd, rs1, rs2, funct, xd, xs1, xs2
  • cmd.rs1,为源寄存器1内容
  • cmd.rs2, 为源寄存器2内容

此外,LazyRoCC类包含了两个TLOutputNode实例: atlNodetlNode,分别通过Tilelink总线的方式连接到L1缓存,和L2缓存

mem实例用于直接访问L1 Cache缓存,ptw直接访问页表,busy信号指明加速器是否正在处理指令以及一个中断信号。

本次,我们使用mem接口来实现对内存数据的访问和存储。