IzIy's Files

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

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

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

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

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

web服务原始架构：

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

登录：

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

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

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

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

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

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

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镜像地址，主要涉及到的文件有

通常，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/

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值变高的影响。

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

本文叙述一个简单的协处理器设计过程，用以加深对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实例: atlNode和tlNode，分别通过Tilelink总线的方式连接到L1缓存，和L2缓存

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

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