从大家的回复，你就会发现此 ac+ap 不是彼 ac+ap 甚至都涉及到隧道转发了。同样此 mesh 也不一定就是彼 mesh 。。。
无线这种高深莫测的东西远不是光选择 ac+ap 或者 mesh 就可以了。它太复杂了，包括 ap 对终端的兼容性至少我的环境，市面上 intel>高通>realtek

如果在使用 openwrt 环境，我会告诉你用同样的 uap ac 硬件刷 ap 或者变成 mesh point 它的 iperf 呑吐测试不相上下。而此时 mp 设备是有网状特性的，我还真观察到几次有线 poe 在供电但有线端口不通，mp 通过 mesh point 无线接口借邻近 mp 通迅的过程。这方面我认为 mesh 的网状还是比 ap 的星形先进的。

Tplink 去年我应该咨询过 600 价位左右的同时有易展或者 ac+ap 的两种型号。但官方的客服人员就很难回答我的提问，比如告诉我可以 6 个组有线 mesh 又告诉我最好 1 对 3 组 mesh 之类的。在 openwrt 组 mesh 的一些必要条件，那个 mesh point 接口是得通过无线建立，而且还得同信道。然后有人就会告诉你同频干扰了。此时才能在 batctl 工具下看到 batman adv mesh 是如何工作的。
Mesh point 接口我认为是组有线 mesh 的一个可大可小的缺点，在公司一万平方 3 层 12 个 mp 每层 4 个的情况。为了避免性能损失，通过 mesh id 将每层 4 个 mesh point 连接在 5g 接口，稍远的第三个都已经-83dbm 以下了。不让它连接其它楼层的 mp 。网上有些搞笑的评测还说三频才是真 mesh 。。。也就是在组有线 mesh 时，那个必须建立的 mesh point 无线接口，最好两 mp 之间是可视无阻碍的。虽然在有线状态时经过 mesh point 交互的信息非常小，但无线弱信号导致的性能下降必须得考虑。

我最后没选择 tplink,因为对方支支吾吾，我怕买到的是 mtk 芯片。。。我看上的是 huawei 的 airengine,还没采购回来。个人建议少量采购，在 7 天退货期深入测试，不然这些成品路由远不是用 openwrt 可以用自定义方法解决的。



这是当时 tplink 易展的一个评论

2021 年 11 月购机三台，感觉 bug 很多，挑几个大的说：1 ，mesh 组合方式，尤其是一台主 ap ？ 2 台子 ap 方式，三台机子都是 poe 供电联网，装两台没问题，第三台非要用无线方式组 mesh ，导致为了避免 wifi 组网信号差架设的网线无用，也没看到按钮去调节；才用这种模式后，几个 wifi 信道没法调节，只能用一个。换了高发模式他不行，际非变 mesh 结构。另，主 ap 和子 ap 不知何原因会自己变动； 2 ，商业云很多按钮虚了，也不告知该怎么调整； 3 ，刚开通商业云时，机子会隐藏 sid ，客服也没法解决，自己花了很大功夫才找到，4 ，安装的螺丝设计变态，很长，不太好安装。总体感觉很差，服务不好，可能是设计理念是工程师的，实操方面不适合非专业人士，易联版仅仅是说易插个网线而已，组 mesh 不那么易…

厉害的快速双击
不厉害的用批处理 start 微信.exe
这种方法应该还是有效的，至少 windows 7 一直正常

纯 socks5 不好过墙,没特别要求可以试试 stunnel 。官方有的只有加密性能测试。

这么多年也没在 windows 下成功建立起需要的文件共享方式。之前尝试用 windows 共享，SyncBack 进行同步，不适合手机端使用。还是需要一个有多用户管理的基于 web 浏览的实现。
nextcloud ，当时似乎解决了中文编辑问题，似乎也是因为通过 windows 共享新建文件，在 web 端不能及时看到。这个 filebrowser 挺好的。支持多用户权限管理，新建的文件也可以 F5 快速出现。不错不错。

看得晕乎乎的，至少多年前就有说 qq 转 gmail 有问题，所以为什么不 gmail 直接收。
如果涉及到本地收 gmail 可以通过 stunnel 加密到本地，使用 emailrealey 完美解决 25 端口发信问题。

你不卷人家都在卷，你如何独善其身。
其实之前就有一个非常好的解释叫，会包装的，精致的利己主义者。
除非你的人生精打细算，已经在考虑孩子的未来，已经在考虑买房，留钱给他们。那朋友对孩子的期望就只剩下快乐的成长，但她依然给孩子补 5 千块的学校老师补习还参加校外培训，每个父母多少还是望子成龙的。

我记得在相亲节目里那些忙于事业的女神男神说是忙得连看手机的时间都没。。。

哎，也许闲人才阅读即回。对喜欢的人我都是必回的，对于那些不回的自己心里有数，忙什么忙，要不要吃饭要不要睡觉，搞起来连手机都没时间看，谁信。

我们公司是以有线为主，无线为辅的。当然那些对无线网络如何运行不清楚的员工，只会一脸怒气的说，我到那个地方网络就要断一下，软件还要重新连一下都浪费时间，都浪费工作效率，老板本来可以赚 2 亿的就因为这个破网络变成只有 5 千万了，哈哈。。。

无线平时遇到比较多的
1 。漫游，通常 intel 无线网卡要好过高通好过 realtek
2 。硬件兼容性，realtek 的无线网卡得通过每天重启 AP 来保证它不至于掉到几 KB/S ，而其它的 intel 无线网卡不存在这个长时间运行掉速的问题
3 。其它的就是布点不合理造成的漫游，乱漫游，没有就近漫游导致的网络问题。

通常也就简单到通过 ping 网关是否出现掉包延迟来确定是否就近连接到附近的 AP 。windows 可以使用 WifiInfoView 通过对 AP 备注，方便员工在统一 SSID 环境，识别当前连接的到底是哪一台 AP 。也就是终端的选择 AP 盲很容易造成网络连接故障。
至于硬件兼容问题，这就不好排除了。

当然 QOS 也是相当重要的，纯无线网络办公，更多的还是是得通过测试单 1 终端接入 2.4G/5G 的极限速度再除终端数量。一般我的 866mbps 的 AP uap ac lr 刷 openwrt 19.07.1 ，2.4 最好成绩 162mbps 左右，5G 最好的固件大概在 367mbps 左右，终端用的 Intel® Dual Band Wireless-AC 7260 802.11ac/149 频道。普通用用还行，大流量那就不好说了，而且此时的有线 QOS ，是不适用无线的 ebtables 。实际这么多年一直没在无线使用 ebtables QOS,到了中午休息时间大量终端在 AP 上，2.4G 至少有了 80+终端，还是撑不住的，有时候 AP 都直接死机重启。。。

配合温湿度传感器，完美实现机房自动开关空调省了不少电。

用了几下 win11 竟然不知道任务管理器在哪。。 。只能运行 taskmgr 。累，没有延续性，别人让教怎么找出设定，最后无奈回不知道在哪，敲命令就是了。

今天刚到手两台 hp zhan99 g9 i5-12500,
3500 块，给财务用
16g+256g+2t

以后对儿子说，咱也是见过世面的。。。

财务不用 wps 。用 wps 的也可能因为和 office2016 的兼容问题被迫统一使用 office 。

我虽然也用过 wps ，觉得 excel 插入行比 office 方便多了。最后却因为 wps 的后台占用了大量 cpu 资源选择不用。。。另外用了各种文件替换，z 府专版，仍然搞不定广告。。。功能用得少，至少像宏之类的也是特有版本才支持的。至于财务不用 wps 肯定有她们的原因。

汉王 ocr

这个小包不适合我来讨论。我也不知道小包是啥玩意。。。说说我认识中的小包

对于 tomato 的 QOS 就是这样的，不是 routeros 里的 iptables length 匹配。说到包转发的硬件能力，曾经接触过 iptables 每包匹配(非 CONNMARK 这种包到连接的转换过程)。在一些低端设备，像 mtk7620 跑 openwrt 的 SQM （ 2016 年版本）每包匹配非常耗 CPU 资源，包括更早的 ddwrt imq 那是直接导致路由死机。。。
从 QOS 的优先级来说显然已经对 tcp 的这些握手的真正小包实现了高优先级出列。
#$TC filter add dev $UDEV parent 1:0 prio 12 protocol arp handle 1 fw classid 1:20 # Arp traffic
$TC filter add dev $UDEV parent 1: prio 13 protocol ip u32 match ip protocol 1 0xff flowid 1:20 #ICMP
#$TC filter add dev $UDEV parent 1: prio 14 protocol ip u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x10 0xff at 33 flowid 1:20 #ACK
$TC filter add dev $UDEV parent 1: prio 15 protocol ip u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x02 0x02 at 33 flowid 1:20 #SYN
$TC filter add dev $UDEV parent 1: prio 17 protocol ip u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x01 0x01 at 33 flowid 1:20 #FIN
$TC filter add dev $UDEV parent 1: prio 19 protocol ip u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x04 0x04 at 33 flowid 1:20 #RST

以上就涉及到小包转换像 iptables 这种需要靠 cpu 运算的，以及其它的所谓的硬件转发。但硬件转发往往又没有 iptables 那么好玩。像 mtk7620 使用 openwrt 固件，没有 mtk 官方的驱动，在使用 pppoe 拔号时大概 88mbps,但在专线模式 eth0 接口下它也能在 QOS 状态跑接近 600mbps 的能力。

至于游戏和延迟，应该有公式计算的。最早接触的是，这些公式似乎和 SQM 作者经常提到的公式不一样。。。
http://linux-ip.net/articles/hfsc.en/

Assume that all packets to be sent conform to a fixed size of 1500 bytes and all classes are sending at maximum rate. Based on the 1000 kbit link capacity, it takes 12ms (8*1500 byte / 1000000 bit/s = 12ms) to send a packet. The Voice over IP application sends at 100kbit which corresponds to 8 packets per second. In order to meet the guaranteed 100kbit rate for this class, the qdisc must send a packet from this class every 120ms, which would mean a maximum [queuing] delay of 132ms per packet. This example illustrates the relationship between bandwidth and delay.

实际上在 adsl(电话线线路)的测试结果，上行表现为使用当前带宽 60%时拥有极低的延迟，在当前带宽 80%时下行速度还不错延迟也不是很高。超过 80%时就出现下行还不如 80%时，下行流量更差延迟更高。
有了这样的经验认知就可以用 tc class 概念对 1 根带宽切成针对游戏的小水管+针对 P2P 的大水管。只要记得 CS 游戏交互基本不超过 5KB ，那只要给这根小水管 5/0.6=8.33KB 就足以保证游戏延迟。。。
对我来说我只要记得延迟和带宽的关系就可以了，根本不通过公式去计算。当然这种针对有线线路的延迟，似乎到了无线又成了另外一回事。在无线更多的是因为弱信号导致的 AP 呑吐性能的变化，所以对玩游戏的朋友有条件就自己独占一个 AP ，也用不着被人忽攸买什么几千块的游戏路由。。。
通过一个 1:2 分组限制了 P2P 最多只能使用 90%带宽，又能极大的保障高优先级分组游戏的延迟。根据早些年在 135KB 的光纤线路的测试结果。游戏小于 19ms,而其它 P2P 流量接近 600ms 。

##$TC class add dev $UDEV parent 1:1 classid 1:100 htb quantum 1514 rate $((UPLINK*10/100))kbps ceil 1Gbit prio 5
#$TC class add dev $UDEV parent 1:1 classid 1:2 htb rate $((UPLINK*8/10))kbps ceil $((UPLINK*9/10))kbps

#$TC class add dev $UDEV parent 1:1 classid 1:10 htb quantum 1514 rate $((UPLINK*1/10))kbps ceil $((UPLINK))kbps prio 0
#$TC class add dev $UDEV parent 1:1 classid 1:20 htb quantum 1514 rate $((UPLINK*1/10))kbps ceil $((UPLINK))kbps prio 2
#$TC class add dev $UDEV parent 1:2 classid 1:30 htb quantum 1514 rate $((UPLINK*3/100))kbps ceil $((UPLINK*90/100))kbps prio 3
#$TC class add dev $UDEV parent 1:2 classid 1:40 htb quantum 1514 rate $((UPLINK*5/100))kbps ceil $((UPLINK*85/100))kbps prio 4

最后用 QOS 的概念回答了延迟问题，而不是小包。

android 版 moneywiz 3.从 2 月份开始记的，除了联网有广告，好像没看到功能限制，而且还可以备份在本地，无需要在线登录，符合我的眼光。。。