stress: AIMD 控制器 v5 —— 可用率约束 98%→99%(用户 2026-11-02)+ 低速恢复锁修复(爬坡备选条件「验证码≤1且短窗≥98.5%」,修 dp6 实测 05:00-06:10 滞留 70min 于 24-42/min);附 dp6 24h 实测优化报告(104,440 请求 98.11% 72.6/min,+29% 吞吐)

2026-11-02 11:03:47 +08:00
parent 329d0e4c5d
commit a2e1f0d923
2 changed files with 174 additions and 26 deletions
@@ -0,0 +1,142 @@
+# dp6 24小时实测优化报告(fetch+浏览器双路径)
+
+- **运行区间**: 2026-11-01 01:22:43 UTC → 2026-11-02 01:21:43 UTC(24h 跑满,进程正常退出,final 已写)
+- **版本**: SerpMax v1.78.2 + 压测客户端控制器 v4(`stress/serp-dualpath-optimize.ts`,runtime=auto 双路径,workers=12,速率区间 [3,400])
+- **数据源**: `/opt/serpmax/data/dp6-final.json`、`dp6.jsonl`(分钟)、`dp6-req.jsonl`(逐请求 117,724 条)、`dp6.log`;对照 `dp5-final.json`、`dp5-req.jsonl`。全部为服务器落盘的真实测量值,无任何外推/估算。
+- **对照说明**: dp1–dp4 为短程调优试探(服务器上无 24h final 文件);完整 24h 对照只有 dp5(v1.78.1+控制器 v3)与 dp6(v1.78.2+控制器 v4)。
+
+---
+
+## 1. 结论摘要
+
+| 指标 | dp5(v3) | dp6(v4) | 变化 |
+|---|---|---|---|
+| 总请求 | 80,974 | **104,440** | **+29.0%** |
+| 成功 | 80,301 | 102,461 | — |
+| 成功率 | 99.17% | **98.11%** | −1.06pp,仍 >98% ✓ |
+| 日均速率 | 56.3/min | **72.6/min** | **+29.0%** |
+| captcha 命中 | 335(0.41%) | 1,537(1.47%) | 当日波次更密 |
+| 门壳结果 gate | 270 | 246 | — |
+| 池空 poolEmpty | 0 | 75(最差 1 小时 23 次) | v1.78.2 轮转取缓存代价 |
+| httpErr / netErr | 10 / 7 | 65 / 0 | httpErr 全部集中在 23 时波浪 |
+| fetch / browser 分流 | 41,773 / 38,849 | 48,573 / 54,190 | browser 承接溢出 52.7% |
+
+**核心结论**: 在 >98% 成功率约束下,控制器 v4 把 24h 真实日均吞吐从 56.3 提到 **72.6 请求/分钟(+29%)**,代价是成功率贴着约束线收在 98.11%。这是约束边界上的实测最优交换。
+
+---
+
+## 2. dp6 全天逐小时实测(UTC)
+
+| 小时 | 请求 | 成功率 | captcha | gate | poolE | fetch | browser | 均值/min |
+|---|---|---|---|---|---|---|---|---|
+| 01日01时(38min) | 3,762 | 99.39% | 19 | 3 | 0 | 1,558 | 2,185 | 99 |
+| 02时 | 5,214 | 98.68% | 59 | 8 | 0 | 2,415 | 2,740 | 87 |
+| 03时 | 5,416 | 98.47% | 54 | 25 | 0 | 2,265 | 3,097 | 90 |
+| 04时 | 4,266 | 96.91% | 115 | 12 | 1 | 2,094 | 2,056 | 71 |
+| 05时 | 1,667 | 98.86% | 9 | 10 | 0 | 1,632 | 26 | 28 |
+| 06时 | 5,098 | 99.86% | 2 | 4 | 1 | 2,189 | 2,906 | 85 |
+| 07时 | 5,063 | 99.09% | 32 | 14 | 0 | 2,006 | 3,025 | 84 |
+| 08时 | 5,189 | 98.50% | 67 | 10 | 0 | 2,003 | 3,119 | 86 |
+| 09时 | 5,146 | 98.15% | 72 | 18 | 1 | 2,105 | 2,968 | 86 |
+| 10时 | 4,583 | 98.23% | 68 | 13 | 0 | 2,206 | 2,309 | 76 |
+| 11时 | 3,601 | 98.03% | 45 | 14 | 7 | 2,014 | 1,531 | 60 |
+| 12时 | 4,470 | 99.22% | 17 | 13 | 3 | 2,093 | 2,356 | 74 |
+| 13时 | 4,678 | 97.26% | 101 | 14 | 8 | 1,792 | 2,773 | 78 |
+| 14时 | 3,505 | 97.60% | 55 | 5 | 2 | 2,196 | 1,231 | 58 |
+| 15时 | 3,231 | 97.62% | 70 | 6 | 0 | 2,165 | 996 | 54 |
+| 16时 | 5,352 | 97.42% | 112 | 14 | 0 | 2,080 | 3,158 | 89 |
+| 17时 | 4,509 | 96.70% | 116 | 6 | 14 | 2,094 | 2,282 | 75 |
+| 18时 | 2,708 | 98.08% | 46 | 3 | 0 | 1,575 | 1,087 | 45 |
+| 19时 | 4,712 | 98.58% | 61 | 2 | 2 | 2,025 | 2,624 | 79 |
+| 20时 | 5,228 | 97.42% | 111 | 15 | 3 | 2,037 | 3,076 | 87 |
+| 21时 | 4,673 | 98.44% | 57 | 8 | 6 | 2,325 | 2,285 | 78 |
+| 22时 | 4,752 | 97.92% | 91 | 7 | 0 | 1,910 | 2,751 | 79 |
+| 23时(最差) | 4,114 | **94.90%** | **146** | 14 | **23** | 1,650 | 2,268 | 69 |
+| 02日00时 | 1,613 | 98.64% | 12 | 6 | 1 | 1,374 | 224 | 27 |
+| 02日01时(21min) | 1,840 | 99.73% | 0 | 1 | 3 | 747 | 1,090 | 88 |
+
+- jsonl 口径合计 104,390;final.json 权威口径 **104,440 / 98.11%**(差值为跨小时边界分钟)。
+- 全天净错误 netErr=0,无一次网络层失败。
+- 最差小时 23时(94.90%)对全天累计仅拖累约 0.13pp——深度削减把该小时暴露量压到最小,是"深切保护累计"策略的实测验证。
+
+---
+
+## 3. 速率段分布与控制器行为结构(实测)
+
+**速率段时间分布(1,439 分钟):**
+
+| 速率段 | 分钟数 | 发出请求 | 请求占比 |
+|---|---|---|---|
+| <50/min | 250 min | 7,119 | 6.8% |
+| 50–100 | 252 min | 17,691 | 16.9% |
+| 100–200 | 517 min | 44,402 | 42.5% |
+| 200–300 | 337 min | 28,047 | 26.9% |
+| 300–400 | 53 min | 4,356 | 4.2% |
+| =400 | 30 min | 2,775 | 2.7% |
+
+**行为结构(来自 dp6.log 全量速率变更史,共 113 次调率):**
+- **5 次深切瀑布**(×0.7 连锁到 <30/min):04:50→23.9、09:32→47、14:10→39、17:54→11.1、23:57→6.3/min(末次为 ×0.5 四连)。每次都在波浪过后由 clean-fast ×1.3 链恢复。
+- **10 次 clean-fast ×1.3 恢复链**,最快 9 拍从 40 拉到 331/min(14:46–14:53),典型 6–7 拍。
+- **×1.08 常规爬坡**接在恢复链后,爬到 280–400 区间;全天共 228 个 ramp 序列。
+- **12 次验证码软切**(×0.7)、**2 次池空软切**(×0.85)、多次 30 分钟入场切(<98% 成功)。
+- 完整周期 1.5–2h:波浪 → 切(最深 ×0.5)→ 低速持守到 captcha==0 → ×1.3 链 → ×1.08 爬坡 → 重复。
+- 结尾 00:56–01:13 恢复链一路拉回 400/min,最后 21 分钟以 352–400/min 跑出 99.73%。
+
+**饱和天花板(重要实测发现)**: 速率上限虽设 400/min,但 =400 段实际只发出 92.5 请求/min(2,775/30min)。瓶颈是 workers=12 × 平均延迟(ok 均值 7.5s)→ 理论上限 ≈96/min;实测高速率段稳定落在 100–135/min。**400 的桶只是天花板标记,有效吞吐由 worker 数与延迟决定**——这是 v5 最直接的扩容方向。
+
+---
+
+## 4. 双路径经济学(逐请求实测)
+
+| 路径/结果 | dp6 条数 | dp6 均延迟 | 多次尝试占比 | dp5 对照 |
+|---|---|---|---|---|
+| fetch/ok | 48,467 | **5,160ms** | 0.70% | 41,663 / 4,465ms / 0.90% |
+| browser/ok | 53,994 | **9,668ms** | 2.26% | 38,638 / 7,446ms / 2.89% |
+| fetch/gate | 106 | 10,873ms | 100% | 110 / 10,649ms |
+| browser/gate | 140 | **39,677ms** | 100% | 160 / 30,851ms |
+| browser/empty | 56 | 31,469ms | — | 51 / 24,546ms |
+| captcha(未分派) | 1,537 | 4,530ms | — | 335 / 4,927ms |
+| poolEmpty / httpErr | 75 / 65 | 31.2s / 42.2s | — | 0 / 10 |
+
+- browser 单请求耗时是 fetch 的 1.87 倍,但承接了 52.7% 的已分派流量(dp5 为 48.0%)——高速率段 fetch 桶(60/min 封顶)只够供给约 15%,溢出全部由浏览器热池消化,溢出设计按预期工作。
+- 门壳尝试 874 次(0.83%,dp5 为 0.95%):browser 门壳每次烧 39.7s,是最贵的失败形态;v1.78.2 的指纹轮换使门壳占比略降。
+- captcha 检测均耗时 4.5s,本身便宜;真正昂贵的是它触发的降速与爬坡时间。
+
+---
+
+## 5. 稀释论的实测验证
+
+**论题**: captcha 供给由 Google 侧按波次发放(逐小时 2–146 个,与本地速率弱相关),因此同等波次下速率越高、captcha 占比越低、窗口成功率越高;**波浪中降速反而抬高 captcha 占比、恶化窗口成功率**。
+
+实测证据:
+- 配对小时:19时(79/min,captcha 61)→ 98.58%;17时(75/min,captcha 116)→ 96.70%。速率相近,成败由波次强度决定。
+- 高速率窗口:400/min 段窗口成功率 99.6–99.9%,captcha 短窗占比 0(capPctS=0)。
+- 低速率反例:05:24 在 31.3/min 处,窗口内 3 个 captcha 就构成 1.13% 占比触发软切——同样的 3 个 captcha 在 400/min 下只占 0.09%。
+- 但波浪总量确实随速率升高而增多(dp6 1,537 vs dp5 335):提速换来的是分母稀释,不是 captcha 绝对数减少。
+
+---
+
+## 6. 控制器 v4 的三个残余缺陷(实测例证,已列入 v5 待修)
+
+1. **ongoing 切不感知量(量盲)**: 低速率下小分母放大占比。05:24 因"验证码 3 个占比 1.13%"把 31.3 切到 25/min;00:02–00:03 波浪实际已近尾声(~00:20 结束),仍以窗口 93.4%/93.2%(每窗仅几十个请求)连续 ×0.5 切到 6.3/min 并滞留到 00:30。代价:05时全天第二低的 28/min 却有 98.86% 成功率——明显压不满。
+2. **低速恢复锁死**: 恢复条件要求 10 分钟短窗 successS≥0.995,低速涓流(~1% captcha 占比)下永远达不到;实际恢复全靠 captcha==0 清洁段触发 clean-fast。05:00–06:10 在 24–42/min 滞留 70 分钟,11:35–12:14 滞留 39 分钟。
+3. **累计盲**: 控制器只看窗口不看全天累计。23时 94.90% 把累计从 98.19% 压到 98.06%,控制器没有任何累计感知的削波/放行;反过来,结尾累计已锁定 >98% 时,00:43 仍因 4 个 captcha(0.96%)从 73.3 切到 51.3,未能利用富余度。深切能保护累计是"暴露量最小化"的副产品,不是设计使然。
+
+---
+
+## 7. v5 优化方向(待下一个真实 24h 验证,本报告不做任何数字预测)
+
+1. **恢复条件按量归一**: 低速时用绝对失败数而非占比判恢复(如短窗 captcha≤1 且 sent≥N,或改用指数衰减基线),消除 05时/11时式滞留。
+2. **ongoing 切加量下限**: 窗口 sent 不足阈值时只记信号不切速,避免小分母瀑布。
+3. **累计感知**: 把全天累计成功率与 98% 线的余量引入削波深度(余量大→浅切)与恢复速度(余量大→快爬)。
+4. **扩 workers**: 实测饱和 ≈96–135/min 由 workers=12 × 延迟决定;提高 worker 数是把 100–400 段天花板变为真实吞吐的最短路径,同时配合 fetch 桶扩容评估。
+5. 池空 75 次来自 v1.78.2 节点轮换取缓存,最差小时 23 次;可对波浪期保留最小缓存水位以归零该类错误。
+
+---
+
+## 8. 口径备注
+
+- 成功率 = ok/sent;sent 含 captcha/gate/empty/poolEmpty/httpErr 全部结果,netErr 另计。
+- dp6 全天 fetch 48,573 + browser 54,190 = 102,763 条有路径归属;其余 1,677 条为未按路径记录的结果(池空/httpErr 等)。
+- dp1–dp4 仅有试探性产物(dp1 26KB / dp2–dp3 ~1.7KB / dp4 137KB jsonl),无 24h final,不参与定量对照。
+- 服务器监控(serp-monitor)h24 口径混有 dp6 之外的生产流量,本报告一律不采用;只用 dp6 系列文件自身口径。
@@ -1,22 +1,24 @@
 /** # 脚本说明
- * SERP 双路径(fetch+浏览器)24h 自适应吞吐优化测试(用户 2026-10-30 目标):
- * 在保证客户端成功率 >98% 的约束下,自适应逼近系统可持续的最大每分钟请求数。
+ * SERP 双路径(fetch+浏览器)24h 自适应吞吐优化测试(用户 2026-10-30 目标;
+ * 2026-11-02 用户要求可用率约束上调至 >99%):
+ * 在保证客户端成功率 >99% 的约束下,自适应逼近系统可持续的最大每分钟请求数。
 * 与 serp-profile-capacity.ts(单号 sticky+fetch,绕过池/令牌)不同,本脚本走生产
- * 双路径原形态(runtime=auto,无 sticky,全池 LRU 选号):
+ * 双路径原形态(runtime=auto,无 sticky,全池公平负载选号):
 *   GET /api/serp/json/search?q=...&num=10
 * 令牌内走 go-fetch(全局限流 fetchPerSec),限流外并发走温池浏览器 —— 组合即生产形态。
- * AIMD 控制器 v4(每 60s 决策;dp5 全程实测教训驱动):
- *   硬约束(成功率即约束本身):首次跌破 98%(失败≥2)×0.7、<95% ×0.5;退化段内续砍
- *     需短窗 <95% 且全程增量新失败 ≥2 —— dp5 教训:10:24-10:28 同一波旧失败被短窗
- *     反复引用,五分钟连砍五刀 175→30/min,直接打灭浏览器溢出路径;
+ * AIMD 控制器 v5(dp6 全天实测教训驱动;v4 基础上改四点):
+ *   硬约束(成功率即约束本身):首次跌破 99%(失败≥2)×0.7、<96% ×0.5;退化段内续砍
+ *     需短窗 <96% 且全程增量新失败 ≥2 —— dp5 教训:同一波旧失败被短窗反复引用,
+ *     五分钟连砍五刀 175→30/min,直接打灭浏览器溢出路径;
 *   软信号按事件段(episode)迟滞 + 绝对数护栏(低速率下 1~2 个噪音 = 高比率,不得触发):
 *     验证码 10min 窗 ≥3 个且占比>2% ×0.5、≥3 个且>0.5% ×0.7;门壳 ≥3 且占比>15% ×0.85;
- *     池空>5 ×0.85;软砍下限 SOFT_FLOOR=25 —— dp5 教训:背景验证码供给恒定,速率越低
- *     比率越高,比率规则在低位永真,12:00-17:00 自 52/min 自残至 3/min 而温池 150
- *     ready 全程空转(poolEmpty 20h=0);
- *   干净爬坡:不在退化段 且 短窗成功率≥99.5% 且门壳<2% 且无池空 且(验证码 0 个或
- *     样本 ≥300)→ 深跌后向「干净水位」(30min 窗 ≥98.5% 时的最高速率)以 ×1.3/拍
- *     快速回收,水位之上每 5 拍 ×1.08(dp5 教训:×1.08/5 拍从 3/min 爬回需 3 小时)。
+ *     池空>5 ×0.85;软砍下限 SOFT_FLOOR=25 —— 背景验证码供给恒定,速率越低比率越高,
+ *     比率规则在低位永真(dp5 实测 12:00-17:00 自 52/min 自残至 3/min);
+ *   干净爬坡:不在退化段 且 短窗干净 且 无池空 且(验证码 0 个或样本 ≥300)→ 向「干净
+ *     水位」(30min 窗 ≥99.5% 时的最高速率)以 ×1.3/拍快速回收,水位之上每 5 拍 ×1.08。
+ *     v5 修 dp6 实测「低速恢复锁死」:短窗成功率 ≥99.5% 在低速涓流下永不可达
+ *     (05:00-06:10 滞留 70min 在 24-42/min,该小时实际 98.86%)→ 增加备选条件
+ *     「验证码 ≤1 个且短窗 ≥98.5%」(稀释论:同量涓流在高速率下占比可忽略,可爬)。
 * 速率区间 [3, 400] req/min;并发 worker 默认 12(真实并发让溢出自然流向浏览器路径)。
 * 判定(客户端,JSON 出口):ok = 200 且 organic>0;gate = 200 且 organic=0 且
 *   attempts 含 gate;empty = 200 且 organic=0 无门壳尝试;错误按响应 code 分类
@@ -140,17 +142,18 @@ function sumWindow(n = WINDOW_MIN): Counter {
 let captchaWave = false;
 let gateWave = false;
 let poolEmptyWave = false;
-/** # 成员变量 硬约束退化段(进段砍一次;段内连砍需增量新失败;30min 窗恢复≥98% 退段) **/
+/** # 成员变量 硬约束退化段(进段砍一次;段内连砍需增量新失败;30min 窗恢复≥99% 退段) **/
 let degraded = false;
 /** # 成员变量 上次硬砍时的全程累计失败数(段内连砍要求全程新失败 ≥2,dp5 教训:同一波旧失败被短窗反复引用,10:24-10:28 五分钟连砍五刀 175→30/min) **/
 let failsAtLastCut = 0;
-/** # 成员变量 干净水位:30min 窗 ≥98.5% 且短窗 ≥99% 时达到过的最高速率(深跌后向水位快速回收;dp5 教训:×1.08/5 拍从 3/min 爬回需 3 小时,温池 150 ready 全程空转) **/
+/** # 成员变量 干净水位:30min 窗 ≥99.5% 且短窗 ≥99% 时达到过的最高速率(深跌后向水位快速回收;dp5 教训:×1.08/5 拍从 3/min 爬回需 3 小时,温池 150 ready 全程空转) **/
 let maxCleanRate = 0;
 /** # 成员变量 软砍速率下限(req/min):背景验证码供给恒定,速率越低比率越高,比率规则在低位永真 → 钉死地板(dp5 实测 12:00-17:00 自 52/min 自残至 3/min)。软规则不砍破此位;真退化由硬规则(无下限)兜底 **/
 const SOFT_FLOOR = 25;

 /** # 函数
 * 控制器决策(每 60s 调用):按窗口成功率/内部压力调整速率,返回决策记录或 null。
+ * v5(dp6 教训):目标上调 99%;爬坡备选条件「验证码 ≤1 且短窗 ≥98.5%」修低速恢复锁死。
 * v4(dp5 教训):①硬砍连砍需「增量新失败」(全程失败数较上次砍时新增 ≥2),同一波旧失败不再反复引用;
 * ②软信号加绝对数护栏(10min 窗内验证码 ≥3 / 门壳 ≥3 才允许比率规则),低速率噪音不再触发;
 * ③软砍下限 SOFT_FLOOR,消除比率陷阱钉死地板;④爬坡:向干净水位快速回收 ×1.3/拍,水位之上 ×1.08/5 拍。
@@ -167,20 +170,20 @@ function controlTick(): Record<string, unknown> | null {
  const from = rate;
  let to = from;
  let reason = "hold";
-  // 硬约束:首次跌破 98% 即砍;段内续砍需「进行中」证据 —— 短窗 <95%(比入段门槛更强的
+  // 硬约束:首次跌破 99% 即砍;段内续砍需「进行中」证据 —— 短窗 <96%(比入段门槛更强的
  // 活跃失败信号,波尾噪声不算)且全程增量新失败 ≥2(高速率下 2 个新失败转瞬即攒,单靠
  // 增量计数仍会逐分钟级联,dp5 教训:10:24-10:28 五分钟连砍五刀 175→30/min 打灭浏览器溢出)
  const fails = tot - wH.ok;
  const allFails = totals.sent - totals.ok;
  const successS = wS.sent > 0 ? wS.ok / wS.sent : 1;
-  if (success >= 0.98) degraded = false;
-  const entry = !degraded && success < 0.98 && fails >= 2;
-  const ongoing = degraded && wS.sent >= 10 && successS < 0.95 && allFails - failsAtLastCut >= 2;
+  if (success >= 0.99) degraded = false;
+  const entry = !degraded && success < 0.99 && fails >= 2;
+  const ongoing = degraded && wS.sent >= 10 && successS < 0.96 && allFails - failsAtLastCut >= 2;
  if (entry || ongoing) {
    degraded = true;
    failsAtLastCut = allFails;
-    to = success < 0.95 ? from * 0.5 : from * 0.7;
-    reason = `success=${(success * 100).toFixed(1)}%<${success < 0.95 ? 95 : 98}%(失败 ${fails}${entry ? "" : ";短窗<95%+新失败≥2"}) ×${success < 0.95 ? 0.5 : 0.7}`;
+    to = success < 0.96 ? from * 0.5 : from * 0.7;
+    reason = `success=${(success * 100).toFixed(1)}%<${success < 0.96 ? 96 : 99}%(失败 ${fails}${entry ? "" : ";短窗<96%+新失败≥2"}) ×${success < 0.96 ? 0.5 : 0.7}`;
  } else {
    // 软信号:事件段迟滞 + 绝对数护栏(低速率下 1~2 个噪音即高比率,不得触发;dp5 教训)
    if (wS.captcha >= 3 && capPctS > 0.005 && !captchaWave) {
@@ -200,12 +203,15 @@ function controlTick(): Record<string, unknown> | null {
      reason = `池空 ${wS.poolEmpty} ×0.85`;
    } else if (wS.poolEmpty === 0) poolEmptyWave = false;
  }
-  // 干净水位记账:30min 窗 ≥98.5% 且短窗 ≥99% 时的速率即为「实测可行」
-  if (success >= 0.985 && successS >= 0.99 && wS.sent >= 10) maxCleanRate = Math.max(maxCleanRate, from);
-  // 干净爬坡:退化段中不爬(30min 窗未恢复 98%);深跌后向水位快速回收 ×1.3/拍,水位之上 ×1.08/5 拍;
-  // 爬坡验证码条件:短窗 0 个,或样本 ≥300 时比率已无意义(绝对护栏统一交给软砍规则)
+  // 干净水位记账:30min 窗 ≥99.5% 且短窗 ≥99% 时的速率即为「实测可行」
+  if (success >= 0.995 && successS >= 0.99 && wS.sent >= 10) maxCleanRate = Math.max(maxCleanRate, from);
+  // 干净爬坡:退化段中不爬(30min 窗未恢复 99%);深跌后向水位快速回收 ×1.3/拍,水位之上 ×1.08/5 拍;
+  // 爬坡验证码条件:主条件短窗成功率 ≥99.5%,备选「验证码 ≤1 且短窗 ≥98.5%」修 dp6 实测
+  // 低速恢复锁死(涓流 1~2 个验证码在低速小分母下永远压住 99.5%,高速率下占比可忽略);
+  // 短窗 0 个验证码恒可爬,或样本 ≥300 时比率已无意义(绝对护栏统一交给软砍规则)
  if (to === from && !degraded && wS.sent >= 10) {
-    if (successS >= 0.995 && gateRatioS < 0.02 && wS.poolEmpty === 0 && (wS.captcha === 0 || wS.sent >= 300)) {
+    const cleanS = successS >= 0.995 || (wS.captcha <= 1 && successS >= 0.985);
+    if (cleanS && gateRatioS < 0.02 && wS.poolEmpty === 0 && (wS.captcha === 0 || wS.sent >= 300)) {
      rampSeq++;
      if (maxCleanRate > 0 && from < maxCleanRate * 0.75) {
        to = from * 1.3 + 0.2;