网站弹屏广告怎么做,WordPress谷歌字体会慢,买过域名之前就可以做网站了吗?,自媒体软文发布平台RTT
往返时间#xff0c;从tcp协议栈决定发包#xff0c;到收到回包的时间。
包含本地驱动#xff0c;网卡硬件#xff0c;网线#xff0c;交换机#xff0c;收包方处理的耗时。需注意如果开了delayed ack#xff0c;协议栈未做特殊处理#xff08;默认没做#xff…RTT
往返时间从tcp协议栈决定发包到收到回包的时间。
包含本地驱动网卡硬件网线交换机收包方处理的耗时。需注意如果开了delayed ack协议栈未做特殊处理默认没做则RTT可能包含delayed ack时间。
delay ack
理论上来说有可能会延迟40ms发ack实际对我们来说概率非常小详见delayed ack代码和实车环境影响分析
cwnd 40
拥塞窗口。in flights数据包的数量不能大于cwnd。linux是按照包数而不是数据字节来管理的。
当开启gso后会根据skb→size / mss来计算发出的包量4.9的内核收到ack时也会按照确认的包数量扩大拥塞窗口老内核不是。
所以gso不影响拥塞窗口计算。
initcwnd 30
初始拥塞窗口。当连接刚建立或者重置拥塞窗口时使用这个值。
RTO 4ms
如果发出的数据包未得到回复会在rto时间之后进行重传。
在丢包场景下rto就是丢包带来的额外延迟。
linux内核代码写死了全局rto_min200ms可以通过路由表ip route change ..... rto_min 10ms覆盖全局的rto_min
rto需要跟quickack联动默认delayed ack可能40ms才回ack包rto_min ack时间可能导致大量无效重传。
快速重传
当收到3个“错误”的ack时对未确认数据包进行重传。
涉及的扩展算法较多对我们影响不大不展开。
TLP 4ms
当发包端最后一个数据包丢包时响应ack达不到三个无法触发快速重传。
此时会把最后一个包重传一下触发对端响应。
但在linux内核实现时TLP和RTO共用了一个定时器
判断1: tlp时间 max(..., 200ms这200ms是写死的除了改内核代码外无法修改
接着判断2: tlp时间 min( tlp时间, rto时间
因为rto_min可以被路由表覆盖实际上在我们修改rto_min后tlp时间等于rto时间 从结果上来看非常的蛋疼。因为在局域网情况下TLP时间总是小于RTO时间导致未能起到尽快触发重传的效果反而还抢了RTO的定时器
TODO 实验记录单独记录文档引用到这里 下图中 8253 就是一个 TLP 包因为 50362853 12567 - 983 50374437。12ms 后重传了尾包 cubic
linux默认使用的拥塞控制算法。windows多个版本也是使用此算法。
启动时使用initcwnd每个rtt窗口倍增达到ssthresh后线性增长。
发生丢包时cwnd1同时调整ssthresh。丢包的cwnd1是在tcp协议栈写死的不受拥塞控制算法影响见tcp_enter_lost函数。 bbr
google做的拥塞控制算法bbr比传统拥塞策略要先进很多主要体现在
1 摒弃了用丢包触发限速的策略会通过延迟的变动来调整对网络情况的探测
2 除了in flights包数量控制外还会控制发包的频率间隔。 但是bbr的很多设计细节不适合自动驾驶领域。
例如对rtt1ms场景的适配传输的DAG优先级定频流量场景等都可以做针对性优化能取得非常大的提升。
长期来看我们会针对自动驾驶场景自己写拥塞算法故不把使用bbr算法纳入计划中。
备注平行驾驶推流通常会内置拥塞算法这里建议尝试bbr。 gso/gro
gso允许tcp协议栈直接发送大报文且无需计算checksum由网卡负责拆包计算checksum。
gro是在napi类型的网卡中断处理时将一次循环中收到的数据包合并后再交给上层协议栈处理。napi是硬中断触发后一直轮询直到数据为空
在我们用的4.9版本内核里拥塞窗口的变动考虑了gso/gro的情况。
gso/gro会导致tcp协议栈收发的数据包尺寸大于mss和mtu并减少收发的包数量。会带来一定的附加影响。 从实车抓包来看收包方抓到的包基本都经过gro处理发包方收到的ack也是明显收到gro影响的。
但是结合内核gro相关代码 火焰图分析来看感觉gro触发几率很小。gro收包的CPU占用0.08普通收包的CPU占用2.74。
不确定是分析过程有问题还是xavier在网卡硬件层面实现了gro。
时间有限不展开分析后续相信实际抓包情况认为gro大量生效。
TODO-低优先级分析gro生效路径 二 自动驾驶的网络模型分析
网络丢包的理论模型 上图是一个简化的从发包到收包的环节描述。 各个环节都可能因为故障导致丢包如md5错误网卡硬件错误等。
因故障导致的丢包在正常环境中是非常非常少见的。一般出现在网口接触不良网线损坏等情况下。 除了故障之外各环节的缓冲区满也会导致丢包这是实际场景中最常见的情况。
例如xavier的内置switch是SJA1105型号根据其手册buffer128KB根据我们的实验测试也能得到相应的结论。 xavier上linux内核的发包缓冲区满时会阻止socket发包socket不可写收包缓冲区满时tcp的滑动窗口会降为0。
故重点考察的是网卡和switch缓冲区满导致的丢包。 无论是对网卡还是switch当入流量 出流量时缓冲区开始积压积压超过buffer size时就会丢包。 根据我们的实验可以证明这一点
TODO 这里单抽一个文档贴代码测试环境详细记录引用到这里
udp发包实验测网卡缓冲区大小
1400字节10us一个包延迟增加1800us左右开始丢包。即180个包250KB积压开始丢包。
700字节设10us一个包实际7.7ms左右一个包延迟增加3000us左右开始丢包不稳定可能是发包速率就不稳定。即390个包273KB积压开始丢包。
14000字节100us一个包延迟增加1800us左右开始丢包。即18个包250KB积压开始丢包。 根据实车观察一旦触发丢包会在几毫秒内有很大的丢包率。
现象1dup ack很少远少于rto/tlp超时触发的次数。
现象2: rto/tlp触发时一般都是连续一段数据都需要重传。
这个现象符合理论分析。当入流量出流量时缓冲区增加当缓冲区满时丢包。
一旦触发丢包入流量无改善的情况下会有相当高的丢包率。 带宽 RTT窗口
带宽/ms 窗口 * 每ms包数量 窗口 ÷ RTT 以xavier的1Gb/s网络计算
每个数据包的发送速度 1.5KB ÷ 1Gb/s 0.012ms
打满1Gb/s带宽需要每秒传输83个1.5KB的数据包 打满1Gb/s带宽窗口 83 * rtt 以switch 128KB buffer计算
积压85个包会打满缓冲区85 * 0.012ms 1ms即当入流量大于出流量时缓存积压的包会增加由此会导致rtt上升。
这也是bbr基于rtt变化调整发送速率的理论基础。 使用ss -i -t实车观察rtt
在网络良好且空闲时一般在0.25ms左右
在流量上升时一般在0.5-1ms缓存积压收包端CPU0繁忙导致耗时增加
如果持续超过1.6ms一般丢包就比较严重了。
因为是手动采集了100多次数据做的观察具体数值不够准确但大致趋势应该是没错的。 实验rtt带宽随cwnd变化
不锁的情况speed [829.35 Mb/s]rtt:1.467/0.181cwnd:149
锁40的情况见抓包no_dropspeed [781.53 Mb/s]rtt:0.408/0.08cwnd:40
锁30的情况speed [707.76 Mb/s]rtt:0.314/0.057cwnd:30
锁20的情况speed [590.34 Mb/s]rtt:0.293/0.059cwnd:20 自动驾驶的场景特征
1 自动驾驶中大多数流量是定频发生的。
2 不同流量topic有不同的优先级DAG优先级。
3 硬件环境是已知的如6*xavier的网络拓扑2*orin的网络拓扑。当实际探测到的硬件环境与设计不符时应报故障并做降级处理。 丢包场景分两种
场景1 MAP在中间件中的多个topic流量同时触发。此场景的特点是持续时间短一般10ms。
场景2 MAP之外的持续大流量。此场景具有不确定性如果有人手动拷数据包则可能是持续十几分钟的高丢包环境。
场景3 MAP之外的短暂大流量。如filebeat突然上传数据激光雷达的udp点云。 目前根据在多个车型上tcpdump抓包总计3小时观察丢包在80%的情况下持续10ms20%的情况下持续10-20ms尚未看到前后两帧数据间隔100ms都出现丢包的情况。
TODO-重点通过毫秒级流量监控做更全面的流量模型分析 三 参数调整方案
可以调整的方案重点集中在几组
修改重传间隔 rto_min quickackTLP开关
修改窗口上限tcp_rmem控制滑动窗口路由表cwnd_limit控制拥塞窗口上限
修改窗口初始值initcwnd ssthresh tcp_slow_start_after_idle
修改快速重传门限tcp_reordering
参数含义和修改方法参考ip route下的tcp参数设置 /proc/sys/net/ipv4/tcp相关参数说明 1 重传间隔修改
因无法完全规避丢包通过修改重传间隔可以减少丢包带来的影响。
根据前面的理论分析switch缓冲区打满最多使得rtt上升1ms。
实车观察到的rtt最高到1.87ms同一时刻的tcpdump已能观察到较多丢包。
即使再计算收包方CPU0打满的情况最多也是增加2ms延迟网卡硬件缓冲区满丢包。
理论上在有TLP时无效重传应该不会很多。改到8ms可能都是可行的但是不确定各种极端场景下是否会触发大量无效重传需要大量测试观察验证。 稳妥起见将rto_min设置为10ms实车观察到的rto都是16ms。这是因为rto_min设置有坑具体看ip route下的tcp参数设置内关于rto_min的描述
TODO-重点实车调参尝试把rto_min降低到7ms看是否会触发大量无效重传。 TLP开关默认开启不需要关闭
关闭的收益是在丢包发生时直接开始重传减少一次rtt耗时。在已经发送丢包的情况下这一次rtt的耗时不算什么。
打开的收益是在ack丢包时不按丢包的流程走会把cwnd降低为1更友好。
理论上即使关闭了TLP影响也不大因为还有“拥塞撤销机制”
当触发重传ack回包发现不需要重传时cwnd会回复。但是具体效果得详细看内核代码测试时间有限未深入确认。
保险起见可以不关闭TLP。 2 窗口上限修改
拥塞窗口管理的是in flight数据包总数。这些数据包可能在各个环节上跑着也可能丢了。
考虑到各环节都是需要耗时的cwnd通常不会全都集中在switch buffer上。
但是在空闲时突然发包的情况下cwnd更容易集中卡在一个点上比较危险。
这里给出两个典型值
1 cwnd_limit80
即使运气不好单个tcp连接的in flight数据包都积压在switch buffer上也不会丢包。
当rtt1ms时单tcp连接可以把流量打到800Mb/s以上完全够用了。
即使网络环境差rtt1.5ms单tcp连接可以把流量打到650Mb/s以上也是够用的。 2 cwnd_limit40
即使运气很不好两个tcp连接的in flight数据包都积压在switch buffer上也不会丢包。
在rtt0.8ms时单tcp连接可以把流量打到500Mb/s以上不是特别好基本也够用。
在rtt0.5ms时单tcp连接可以把流量打到700Mb/s以上够用了。
从另一个角度来看cwnd40 60KB/rtt60KB以下数据一次rtt时间120KB两次rtt时间180KB三次rtt时间可以完成传输
cwnd_limit40等于是牺牲一定的平均延迟来降低丢包率 TODO-重点-优先实车观察丢包时流量超标原因调参。
如果丢包原因不受我们控制例如一个topic给三端发或者udp流量或者102-106之外的大流量则cwnd_limit倾向于调到80
另外cwnd_limit对丢包的影响可能需要较长时间观察。可以调整一个cwnd值观察几天/一周确保统计数据稳定后换cwnd值继续观察。作为偏长期的技术优化项
目前cwnd提测给的40观察了四辆车*三天统计数据没有观察到p50p90p99p999传输延迟上升。
但是也未能观察到丢包率下降。需通过毫秒级监控分析引发丢包的主要原因。
备注通过抓包能看到cwnd设置是生效的。 3 窗口初始值修改
tcp_slow_start_after_idle默认打开不修改。
打开的理由
1 在我们的环境下丢包几乎不会持续到100ms以上所以10HZ定频的topic不需要在发下一帧时继承上一帧的窗口设置。
2 这是全局参数影响所有连接需要考虑对平行驾驶鹰眼大屏数据上云等业务等影响修改有风险。
3 如果一个连接“在使用中增长cwnd”其cwnd对应的in flight数据包通常分布在各个环节上而从空闲开始突然按cwnd发包的连接有更大的概率将in flight数据包集中在一个环节上从而引起丢包。 通过重置可以避免空闲状态下直接使用之前的大cwnd连续发出大流量。 102-107之间的流量设置了cwnd上限此问题不突出对未受我们管理的其他业务有很大的价值。遗憾的是其他业务的rto_min也未做调整需要200ms空闲才会重置cwnd。
TODO-重点如实车观察到大屏/鹰眼业务的突发流量导致大量丢包出相应解决方案例如telemtics通过setsockopt设置tcp参数。 initcwnd暂定30 ssthresh暂定40
设置逻辑
传统拥塞控制中不丢包就增加cwnd丢包就降为1这个策略太傻了。
增加策略会顶着rtt上升奔着丢包而去。
丢包之后又自己把自己按在地上摩擦。 通过将initcwnd设置到接近cwnd_limitssthresh设置为cwnd_limit直接初始化时就按我们的理想速率发送。
之所以initcwnd略小于cwnd_limit是为了避免在空闲时直接while循环发出cwnd大小数据导致数据包集中在一个环节上。
修改cwnd_limit后需要记得同步修改initcwnd和cwnd_limit 4 快速重传门限
不修改 理论上来说在开启gro后由于收包方收到的是合并后的数据包回复的ack会显著变少。而且当连续10ms丢包率都较高时ack会进一步减少。
在我们的场景下快速重传未能发挥原本tcp协议设计中的作用。 从实车抓包来看
现象1dup ack很少连续三个dup ack非常少远少于rto/tlp超时触发的次数。很少看到有触发快速重传的场景。
现象2: rto/tlp触发时一般都是连续一段数据都需要重传。丢包经常有连续性。 tcp_reordering参数可以把默认的三个dup ack包触发快速重传改成一个或两个dup ack即触发快速重传。改更大也行
考虑到以下几个因素本次不做改动
1 这是全局参数影响所有连接需要考虑对平行驾驶鹰眼大屏数据上云等业务等影响修改有风险。
2 从实车抓包来看即使快速重传门限改成1也只是减少5-10%的超时重传。收益不是非常大。 5 优化指标
从结果来看我们要优化的是两个指标
1 降低因丢包-超时重传引起高延迟的概率
观察pub_recv./local_planning.p99的各分位数值
此延迟一般会存在跳变从未触发超时重传的个位数毫秒跳变到丢包的16ms。
找出现跳变的百分位数值大致上可以判断超时重传出现的概率。
目前尚未观察到明显优化需依赖340的毫秒级流量监控分析丢包瞬间流量打满的原因。 2 降低发生丢包-超时重传后带来的延迟
直接看pub_recv./local_planning的p99.p99数值即可。
目前已可以从100ms降低到20ms左右调整rto_min可进一步降低。
