Trap)本质上是流动性伴生的泡沫在破裂边缘的震荡。几年前写过一篇讲流动性的文章可以读读>>谈谈流动性从风控视角看网络NetDAM拥塞控制在不确定性中寻找概率确定性技术、玄学、艺术

也难怪每次背锅的都是网工，真是哀其不幸，又怒其不争，BGP协议估计要改名叫不敢碰协议了...至于故障的原因么，老外的故障报告一般都会说，我们做这个变更有ticket，有dry-run，并且有roll-out的流程，同时还进行了大量的peer

serdes上，有了error还能duplicate发，似乎感觉是在25G上为了延迟连FEC都可以不要那种，然后Slingshot[1]也是值得参考的，毕竟是Cray为米国搞的三套Exascale

首先对于损失和丢包的英文都是Loss，然后对于金融机构流动性管理和网络buffer管理也是类似的，例如在巴塞尔协议三中，规定了一级核心资本充足率高于4.5%，加上其它一级资本充足率要求高于6%,

昨天公众号看到华为举办的一个“通算一体化网络理论研讨会"的邀请，6G将迎来通信、计算、数据、Al融合的全面智能化时代,通信产业呼唤基础数学、通信理论和计算科学的交叉碰撞。深深的感受到了任总的智慧和华为人的远见,

这是一篇原本给某金融大佬准备的DPU科普资料，起因是该大佬作为投资人问过很多计算方和应用方，大家都觉得DPU可有可无，而去问一些网络和基础架构的团队却是截然相反的答案。表面上DPU厂商都会说省了数据中心税，但是省了多少，增加了多少成本没有人算过于是投资人辗转找到我这种在计算和通信的边缘反复试探的数学系法外狂徒张三...一个最本质的问题揭开了...计算(CS)和通信(EE)两个专业的差异决定了DPU的价值，追根溯源，这种差异居然在上溯到两个行业的祖师爷图灵和香农时找到了答案.

即便是疫情的影响也没给这些巨头带来爆发性的增长，那就是市场对了，而技术本身错了？第一象限里的每一家我都可以给你吐槽一整天它们的各种技术缺陷。其实最本质的问题就是原来的惯性思维，而忘记了通信的本质。

拥塞控制是一个研究了数十年的大问题，例如花了整整三章。但是有些奇怪的事情似乎把整个节奏带偏了，那就是RoCE的无损网络。本文先介绍(吐槽)一下无损网络，然后介绍一下HPCC和NDP的工作，紧接着大概说下Google

今天美国东部标准时间上午11点51分开始，Facebook出现故障，最终六个小时以后才恢复。很多平台(CloudFlare[1],ThousandEye[2])都做了故障归因.

从前有一个大老板,聘请了一个首席经济学家,然后正在发生一些大家吃瓜的事情....然后这个首席还在写某地房价为啥涨不起来，洋洋洒洒近万字，其实就是流动性管理没学好.因此，今天要讲的话题就是流动性，您可以很有钱，但是都是不动产

从成本上而言，正如几个月前在阿里云讲过的一张ppt讲述的因此基于这个模式来看，阿里云营收增长但份额下降势必会继续发生，因为技术门槛敌不过价格竞争，特别是在准备上市的过程中要维持相应的利润率和营收,

好基友的第四范式IPO了，比起曾经的四小龙，我只是想说踏踏实实做技术的公司都会被这个世界善待。因此多写几篇文让各位做DPU的踏实一些,脚踏实地在这场计算机体系结构的变革中帮助国家弯道超车什么叫踏踏实实做事业，可以参考前几周的一篇文夏寒：闲谈算法、云计算公司估值[1]计算的流动性随手翻开一个公有云，都会发现有不同的计算实例，搭配不同的CPU、内存、网络和存储来应对不同业务的需求.当云原生和大量的新技术出现后，作为公有云考虑的最重要的一件事情就是提供这些丰富服务的成本:青云、Ucloud也都在A股上市了，市场给出的估值参考并不高，而且还在持续亏损。而阿里云即便是盈利，份额也在下滑。如果大家想想这么多年来对三大运营商动刀，搞增速降费，同样也是鲸落万物生。所以公有云市场作为基础设施的提供方是不会允许它有高额利润的.

pkt}发送PM_Req时采用一个Goroutine的函数,其中Describe库是用于做统计描述的一个库，稍后讲.另外Prob的Internval参数是艺术，不告诉你们

❝技术只是谋生的手段,玄学是不知所以的取舍,艺术才是人生的价值。而穷,才是保持良好品德和高尚人格的经济基础.❞人生在世,活得明白的不多.有人靠技术或者玄学赚了些钱,却总想以艺术和修养的形式分享给别人."看清世界荒谬，是一个智者的基本水准。看清了，不是感到恶心，而是会心一笑。"--木心技术

这样的好处就是可以降低功耗，并且提升核的数量。所以你会看到处理器的设计上处处都是取舍。报文的处理采用Run-To-Compile（RTC)的结构，即即便功能再多，一个处理器处理完一个包的所有功能，

除此之外，在主机侧的优化则集中在CacheLine对齐，BIOS调整禁用CPU省电降频，使用高频率CPU和绑定CPU核等技术。未来几年还有基于CXL等技术来进一步降低网卡到CPU的通信延迟。

所以这也是某种程度上我并不看好SRv6做复杂的编程Policy的原因，更多的是您需要将策略和路径和虚拟化租户三者解耦，把策略和转发混合在一起本质上就是一个灾难，策略是自顶而下的，转发是自底而上的。

Ruta架构简介对于整个Ruta系统，主要的节点类型分为：节点类型用途STUN需要有公网地址或者1：1NAT静态映射的地址。主要用于帮助其它节点发现公网地址Fabric用于SRoU的中继转发节点.

INET|1000|1000|192.168.99.74:5555|192.168.99.74:5555]启动后，STUN服务会按照如下方式注册节点和通告业务能力1.

例如阿里云需要SRv6和HPCC落地，这个场景就是一个不错的选择，既实施了SRv6又把HPCC的能力加入，而且不光是在两端的智能网卡上实施，中间的交换机也做了很好的协同。

所以这也是某种程度上我并不看好SRv6做复杂的编程Policy的原因，更多的是您需要将策略和路径和虚拟化租户三者解耦，把策略和转发混合在一起本质上就是一个灾难，策略是自顶而下的，转发是自底而上的。

据说前段时间给各个云技术扶贫反馈还不错，那么今天来给各个金服技术扶贫一下~知道你们上不了市的苦~先从一道小学生应用题说起：还呗黑条当铺发行一期ABS，

互联网经济给了每个人一个说话的舞台，当然也造就了一大堆并不那么职业也没完全受过训练的主播人。昨日看到一篇达里奥的澄清文，只是为了怼《马云变成达里奥的梦魇》。通常自媒体和一些快速扩张的传统媒体都喜欢用非常荒诞的手法来搞事情。最后Ray的回复蚂蚁正在做一些可能会对货币以及中国的信贷风险和机遇产生重大影响的革命性的新尝试，因此监管机构正试图找出最好的监管方法，并且选择谨慎对待。据我理解，中国监管机构的反应主要由于事件的进展快于其预期所致。以我与中国监管机构打交道的亲身经历来说，我认为他们公道合理，始终兼顾处理诸多事宜，并且非常倾向于在学习和监管新的投资工具时谨慎行事。所有国家和地区的监管机构都面临监管过于严格，或不够严格的风险。例如，我们的监管机构对金融过度方面不够严格，导致了2008年全球金融危机。我也奇怪，自己正经写的技术文档没人读，随口吐槽倒是有人看的津津有味。然后还有那种今天xx捧上天，明天就把它揣到地。我只想从几个方面解释，随意的猜测都会引来法律风险，所以接下来的只针对金融科技行业，也故意抹去了原来初稿中的数据。如果一个公司对于信贷的AI算法牛逼，那么应该来说Expected

从思科Webex出走的袁征带来的Zoom的故事不必多说，但Zoom的答案简单的出奇：“做市场上最好的产品，一个真正好用的产品”，这一句简单的话却掏出了整个2B市场2B的本质：面向标书的编程。每个做2B市场的产品经理都会经历很多痛苦的事情，真正用产品的人没有决定权，而做决定的领导往往也不知道自己在干嘛。常年来大家都干着一系列荒唐的事情，用BDM(for

srlist:=[]string{1.1.1.1:2345,2.2.2.2:4567，255.vnid:end.DT4}

Pinhole完成确定性的转发路径，Ruta只是把这种随路SIP信令构建的有状态转发流表变成了使用SR的无状态源路由，所以你会看到Ruta在这个场景的应用：下一代数据中心架构-3：从视频会议应用谈起

随便记录点有趣的东西

sytle染色了，当然matplotlib有些时候也会用一点，主要是比较懒的时候。通常我也喜欢把Jupyter的屏幕宽度调到100%屏幕宽度，这样干活舒服点。

前路有太多的未知，我们也有太多的差距，无论是芯片技术上，还是数学算法上，我只是比一般人多读了几本书，多看了一点世界，仅做一点微小的贡献，希望能够帮助到一些人，也算是完成我技术扶贫的一点小心愿吧。

End.DT2U(16bits)定义上End.X正好16bit，VNID也刚好24bit，而255.0.0.0/8的地址段正好又没人用，就这样我们在IPv4网络上也可以实现类似的可编程能力。5.

policy，也都是类似的东西，其实从策略来看，本源是什么？“我(Who)在什么时候(When),访问什么应用(Which)需要怎么干(Action)”

End.DT2U(16bits)定义上End.X正好16bit，VNID也刚好24bit，而255.0.0.0/8的地址段正好又没人用，就这样我们在IPv4网络上也可以实现类似的可编程能力。5.

sytle染色了，当然matplotlib有些时候也会用一点，主要是比较懒的时候。通常我也喜欢把Jupyter的屏幕宽度调到100%屏幕宽度，这样干活舒服点。

最近很长一段时间都被zartbot.Net占用了，因为随着AI带来计算范式的变化和去中心化应用的大规模产生使得整个网络已经无法适应新型的应用了，于是zartbot.Net花了几个月时间搞了一下SRoU的研究。最近稍微空闲一点点，把zartbot.Fin放出来，毕竟还手贱给zartbot.Fin报了FRM的考试...1.LPR转不转？那么先来谈一个最简单的话题，LPR转还是不转，最近很多人也来问我，其实这个问题不要从自己的角度出发，有些人说这是难得国家照顾大家，宁愿自己损失一些都要帮助大家降息降低负担。但凡事要从根本出发，银行靠什么赚钱的？Commercial

但是这样是不是太蠢了点，每个报文都要查询一次路由表，随着网络规模的扩大，路由表多了就发现性能有问题了，所以后面出现了所谓的快速交换，也就是增加了一个Cache用于路由查询,也就是我们常说的Fast

End.DT2U(16bits)定义上End.X正好16bit，VNID也刚好24bit，而255.0.0.0/8的地址段正好又没人用，就这样我们在IPv4网络上也可以实现类似的可编程能力。5.

policy，也都是类似的东西，其实从策略来看，本源是什么？“我(Who)在什么时候(When),访问什么应用(Which)需要怎么干(Action)”

但是这样是不是太蠢了点，每个报文都要查询一次路由表，随着网络规模的扩大，路由表多了就发现性能有问题了，所以后面出现了所谓的快速交换，也就是增加了一个Cache用于路由查询,也就是我们常说的Fast

106.52.60.176:443,49.51.243.80:443其实这样就很容易的实现了上海-->广州--->美国--->法兰克福，

不同的业务颗粒度不同，甚至有些业务需要用到per-user的policy（例如：让领导先走？嘻嘻~），单一的ID编码或许不符合需求，那么干脆通过某种方式对它进行编址，然后类似于IP地址那样做LPM

=bokeh_multi_line_chart(data,['residual'],['残差'],title='残差')show_column([chart2,chart3,chart4])

这是一篇部署网络同时又如何分析遥测数据，并涉及一些简单的python分析统计数据的操作，供大家学习参考。起因是昨天想测试一下分布式SDWAN部署的可靠性以及验证国内几个公有云的互联带宽情况如何，于是就做了一些测试，大概就按照如下的拓扑组了一张网，构建了一个基于公有云的覆盖全国的网络，共计13个VPC，一个私有云，还有一个电信宽带接入路由器。如果使用传统的VPN组网或者物理设备组网，这么大的一个工程可能要耗时几个月，而基于公有云VPC和SDWAN构建，我一个人用了2小时不到就全网连通了，这在以前是难以想象的。1.测试环境概述前一篇文章提到了TLOC的编址方式,也就是说根据不同的区域配置Site-ID，根据不同的接入设备配置SystemIP，根据不同的运营商配置Color我们这次测试也根据这样的规则来进行编址，由于阿里云的UI橙色偏红，腾讯云UI偏蓝色，我们就按照Red/Blue区分这两个云，而私有云标记为了MPLS，中国电信标记成土豪金？Site-ID编码上，阿里云统一使用5000号段，腾讯云6000号段，自己家里和公司私有云为101和201，System-IP作用和Router-ID类似，不做路由。云上虚拟主机的区域私网和公网地址以及主机类型如下图所示：某司SDWAN路由器开局非常简单，指定Site-ID/System-IP和ZTP的Vbond地址就好，然后公网地址由于各个VPC都有NAT，直接DHCP动态获取，VPC内部的网络可以选择具有双网卡的虚机，但是这次测试并不做应用流量的测试，仅配置了Loopback口做路由通告和连通性测试。system

昨天接到一朋友的消息，问我某个快消企业想把自己的数据中心完全云化，问我该如何解决？特别是这次疫情之中，大量完成“数字化转型”的企业似乎都还活着，而很多传统的企业由于IT架构的陈旧却迟迟不能复工。这类的问题问的越来越多，人毕竟精力有限，就像前段时间写低延迟交易系统

很多人在说我到底是干啥的，以后我就自我分裂成两个吧，一个叫zartbot.Net：主业搞网络的，另一个叫zartbot.Fin，兼职没事玩玩量化的，估计没过多久还会分裂成一个zartbot.Cook，zartbot.AI...当然，下文是zartbot.Net发的...记得有一个教授说过：软件定义的世界（SDx）就像盲人摸象，谁都有自己见解却无法一窥全貌。而这一段软件定义的历史已经走过了一大半历程，就差一本史记一样的来回顾来复盘了。作为国内最早一批上互联网的网虫，亲身经历从28.8k

随着中国证券市场对海外的开放，担忧国内一些机构还在使用陈旧的技术被人家割韭菜，然后有些机构风气也很不好，其实很简单的东西，总是神叨叨的以为自己都懂还是绝顶的商业机密，所以来写一个短文吧，让不知道的学一点，知道的就一笑而过吧。本文主要分几个部分，第一部分是交易所低延迟系统架构给交易所的朋友们看的，当然有些券商也有自己的场外期权交易部门也可以看看。第二部分是券商和私募机构用的低延迟交易系统。第三部分是针对最近股票期权的做市商系统，当然你也可以理解为程序化交易，程序化套利，高频/低延迟交易，我只是选了一个合规的词，同时相对于股票和期货，选择了较复杂的期权系统给读者做交流。1.交易所交易系统1.1