跳到主要内容
自适应运行时物理设计 · MorphoSys → AURA

第9章：端到端实战 v27 复现 —— CloudLab 5-node 一条龙 + 日志到 paper 表格的 cookbook

从 0 到 KOPS 跑通 AURA v27 §6 所有正向数据的端到端实战：CloudLab 5-node 集群 setup（OFED 4.9 + IOMMU passthrough + mlx5_2 校验）、3 条 smoke 脚本（5-cell / a1b / drift）的运行方式、日志到 paper §6 表格的 cookbook、故障速查表

End-to-End Reproduction CloudLab OFED TPC-C Bench Harness AURA v27 Cookbook

前 8 章把 v27 的 thesis、设计、负结果、方法论都讲透了。最后一章是实战——从拿到 CloudLab 5-node 集群、跑通 OFED + IOMMU 配置、build CREST、启动 MN + 4 CN + client，到 3 条 smoke 脚本（5-cell / a1b / drift）的产出日志怎么变成 paper §6 表格中的数字，全流程都给出可复制粘贴的命令。本章不讲设计哲学，只讲怎么把 v27 的 §6 数据一字不漏地复现出来——读完你拿到任意 CloudLab c6525-25g 5-node experiment，理论上 1.5 小时内可以跑出 RQ1 + RQ2 + RQ3 三份正向数据。

📑 目录

1. CloudLab 5-node 集群 setup 速通

1.1 Profile + 节点角色

申请 small-lan profile, 5 × c6525-25g (Utah cluster)。

5 节点角色固定（这套配置已在 v27 全套实验上验证稳定）：

角色节点Hostname控制 IPRDMA IP (ens1f0, mlx5_2 gid 3)状态
MNnode2amd103.utah.cloudlab.us128.110.219.1410.10.1.3✅ 稳定
CN0node3amd118.utah.cloudlab.us128.110.219.2910.10.1.4✅ 稳定
CN1node1amd107.utah.cloudlab.us128.110.219.1810.10.1.2OK
CN2node4amd112.utah.cloudlab.us128.110.219.2310.10.1.5OK (不做 MN)
备用node0amd119.utah.cloudlab.us128.110.219.3010.10.1.1不稳定

警告：amd119 / amd112 历史上多次因 MR 溢出导致 kernel panic 而死机——尽量避免做 MN。当前稳定配置：MN=amd103, CN0=amd118。

1.2 SSH 配置

CL_KEY=/Users/yanchaomei/Desktop/Working/id_ed25519

# 直连测试（Clash TUN 关闭时）
ssh -i $CL_KEY chaomei@128.110.219.14 'hostname'   # 应输出 amd103
ssh -i $CL_KEY chaomei@128.110.219.29 'hostname'   # 应输出 amd118

如果直连失败：Clash TUN 模式劫持所有 TCP 包括 SSH——解法：

  • 关闭 Clash TUN 模式；或
  • Clash 规则最前面加 IP-CIDR,128.110.219.0/24,DIRECT

🍎 直觉比喻：Clash TUN 像在所有出口装关卡——ping (ICMP) 不查，但所有 TCP（包括 SSH）都被截。CloudLab 的 IP 不在 Clash 白名单 → SSH 被吞。

1.3 SSH 长连接保护

实验跑 60 s+，必须开 keepalive：

SSH_OPTS="-i $CL_KEY \
  -o ServerAliveInterval=20 \
  -o ServerAliveCountMax=15 \
  -o TCPKeepAlive=yes \
  -o LogLevel=QUIET \
  -o StrictHostKeyChecking=no"

ssh $SSH_OPTS chaomei@128.110.219.14 ...

详见第 8 章 §7.3。

2. OFED 4.9 + IOMMU passthrough + mlx5_2 校验

CloudLab profile 默认装 Ubuntu 但没装 OFED——需要手动装。

2.1 OFED 4.9 安装

CREST 依赖 ibv_exp_* verbs（experimental verbs），必须 OFED 4.9 而不是 OFED 5.x（5.x 把 exp verbs 去掉了）。

# 下载 MLNX_OFED 4.9-7.1.0.0
wget https://content.mellanox.com/ofed/MLNX_OFED-4.9-7.1.0.0/MLNX_OFED_LINUX-4.9-7.1.0.0-ubuntu20.04-x86_64.tgz
tar -xzf MLNX_OFED_LINUX-4.9-7.1.0.0-ubuntu20.04-x86_64.tgz
cd MLNX_OFED_LINUX-4.9-7.1.0.0-ubuntu20.04-x86_64

# Ubuntu 20.04 (kernel 5.4) 需要 add-kernel-support
sudo ./mlnxofedinstall --add-kernel-support --without-fw-update
sudo /etc/init.d/openibd restart

⚠️ CloudLab 旧 5-node experiment 用的是 Ubuntu 18.04，OFED 直接装就行。 ⚠️ CloudLab 新 7-node experiment（new.intelisys-pg0）是 Ubuntu 20.04，必须 --add-kernel-support。

2.2 IOMMU passthrough

这步漏掉 = RDMA read 全 0：

sudo vi /etc/default/grub
# 在 GRUB_CMDLINE_LINUX_DEFAULT 加 iommu=pt
# 例如：GRUB_CMDLINE_LINUX_DEFAULT="quiet splash iommu=pt"
sudo update-grub
sudo reboot

reboot 后验证：

dmesg | grep -i "iommu.*pass" 
# 应输出: AMD-Vi: ... pass-through (or similar)

🧠 关键洞察：如果 IOMMU 不是 passthrough，RDMA WRITE 会返回 SUCCESS 但数据是全 0——这是 CloudLab 上 CREST 的最大隐性陷阱。WC 状态 IBV_WC_SUCCESS 误导调试方向。

2.3 mlx5_2 校验

CloudLab c6525-25g 有 两张 RDMA 网卡：

  • mlx5_0 → bonded to eno33 (control network) ← 禁用
  • mlx5_2 → bonded to ens1f0 (experiment network, 10.10.1.x) ← 正确数据通路

走错网卡的代价：

  • 用 mlx5_0 跑大流量 → CloudLab 检测到 control network 流量过载 → 强制停实验

验证 mlx5_2 配置：

ibstatus mlx5_2
# 应见：
# Infiniband device 'mlx5_2' port 1 status:
#         state: PORT_ACTIVE
#         phys_state: LINK_UP

ibv_devinfo -d mlx5_2 -v | grep -E "active_mtu|gid|state"
# active_mtu: 1024 (注意：默认 4096，但 CREST 代码改成 1024)
# GID[3]: RoCEv2 IPv4 = 10.10.1.x

2.4 Atomic IOPS 上限验证

跑 ib_atomic_bw 测当前硬件 atomic 上限：

# Server (MN)
ssh -i $CL_KEY chaomei@128.110.219.14 'ib_atomic_bw -d mlx5_2 -F'

# Client (CN0)
ssh -i $CL_KEY chaomei@128.110.219.29 'ib_atomic_bw -d mlx5_2 -F 10.10.1.3'

输出应在 5-10 Mpps 量级（ConnectX-6 Dx 物理上限，第 2 章 §1）。

3. CREST 部署与 build

3.1 仓库 + 部署目录

  • 本地仓库：/Users/yanchaomei/Desktop/Working/2026科研/DisaggTxn/CREST-aura-impl/CREST-Opensource-0007/
  • 远程部署：/users/chaomei/CREST-Opensource-0007/（每个节点都要）

3.2 同步代码

CL_KEY=/Users/yanchaomei/Desktop/Working/id_ed25519
CREST_LOCAL=/Users/yanchaomei/Desktop/Working/2026科研/DisaggTxn/CREST-aura-impl/CREST-Opensource-0007

# 同步到所有 5 节点
for IP in 128.110.219.14 128.110.219.29 128.110.219.18 128.110.219.23 128.110.219.30; do
  rsync -avz --exclude='.git' --exclude='build' --exclude='core' --exclude='*.o' \
    -e "ssh -i $CL_KEY -o StrictHostKeyChecking=no" \
    $CREST_LOCAL/ chaomei@$IP:/users/chaomei/CREST-Opensource-0007/
done

⚠️ rsync 静默 SIGSEGV：在 CloudLab CN 节点上 rsync 偶尔会静默 SIGSEGV（参考 memory feedback）。如发现部分文件没同步，改用 scp + grep 校验：

ssh -i $CL_KEY chaomei@$IP 'grep -c "v27" /users/chaomei/CREST-Opensource-0007/PROGRESS.md'
# 应输出 > 0

3.3 Build

每个节点都要 build（client 在 MN 节点跑，但所有 binary 必须一致）：

for IP in 128.110.219.14 128.110.219.29 128.110.219.18 128.110.219.23 128.110.219.30; do
  ssh -i $CL_KEY chaomei@$IP \
    "cd /users/chaomei/CREST-Opensource-0007 && \
     rm -rf build && mkdir build && cd build && \
     cmake -DCMAKE_BUILD_TYPE=Release .. && \
     make -j40"
done

5 节点 × 5 min 编译 ≈ 25 min，可以并行用 &。

3.4 Memcached（只在 MN）

ssh -i $CL_KEY chaomei@128.110.219.14 \
  "sudo systemctl stop memcached; \
   memcached -d -p 11211 -u chaomei -m 256 -c 1024 -l 0.0.0.0; \
   sleep 1; \
   ss -tlnp | grep 11211"
# 应输出 0.0.0.0:11211 LISTEN

⚠️ 系统自启的 memcached 绑 127.0.0.1——CN 远程连不上。必须手动 stop + 用 -l 0.0.0.0 重启。

4. 三条 smoke 脚本：5-cell / a1b / drift

4.1 RQ1 静态 5-cell ablation

cd /Users/yanchaomei/Desktop/Working/2026科研/DisaggTxn/CREST-aura-impl/CREST-Opensource-0007
bash bench/aura/run_v27_step6.sh 3 200000   # 3 reps × 5 cells × 200K txn

参数：

  • $1 = REPS：每 cell 跑几次
  • $2 = TXN_NUM：每次跑多少 txn（cap，时间到也停）

输出：

/tmp/aura_v27_step6_<timestamp>/
├── baseline_rep0/      m_client.log, m_cn{0..3}.log, m_mn.log, *.details.txt
├── baseline_rep1/
├── baseline_rep2/
├── +a1_rep0/  ...  +a3_rep2/
├── full_v27_rep0/  ...  full_v27_rep2/
└── summary.csv        # 5 cells × 3 reps × {tried_kops, commit_kops, atomic_per_txn, cn balance}

完整跑约 15 cells × 80 sec ≈ 20 min。

4.2 RQ3 A1 tuner ablation

bash bench/aura/run_v27_a1b_smoke.sh 3 200000

3 cells × 3 reps：fixed / rule / sgd。

输出：

/tmp/aura_v27_a1b_<timestamp>/
├── fixed_rep{0,1,2}/
├── rule_rep{0,1,2}/
└── sgd_rep{0,1,2}/    # log 含 "self-tuned.*sgd" 行（权重演化）

完整跑约 9 cells × 80 sec ≈ 12 min。

4.3 RQ2 drift workload

bash bench/aura/run_v27_drift_smoke.sh 3 200000   # 60s duration in script

3 cells × 3 reps：no_drift / drift_5sec / drift_2sec。

输出：

/tmp/aura_v27_drift_<timestamp>/
├── no_drift_rep{0,1,2}/
├── drift_5sec_rep{0,1,2}/
└── drift_2sec_rep{0,1,2}/
summary.csv 额外列：n_sgd_logs（self-tuned 计数）

完整跑约 9 cells × 90 sec ≈ 14 min（60 s 实验 + 30 s setup）。

4.4 完整 §6 数据采集

三条脚本串起来：

bash bench/aura/run_v27_step6.sh 3 200000   # ~20 min
bash bench/aura/run_v27_a1b_smoke.sh 3 200000   # ~12 min
bash bench/aura/run_v27_drift_smoke.sh 3 200000   # ~14 min
# 总计 ~46 min

加上数据回收 + 清理 ≈ 1 小时。

5. 日志到 paper §6 表格的 cookbook

5.1 提取 KOPS / commit rate

cd /tmp/aura_v27_step6_*/full_v27_rep0/
grep -oE 'Tried Throughput: [0-9.]+' m_client.log | head -1
# Tried Throughput: 14.32

grep -oE 'Commit Troughput: [0-9.]+' m_client.log | head -1
# Commit Troughput: 13.70

grep -oE 'Tried: [0-9]+' m_client.log | head -1
# Tried: 859200

grep -oE 'Committed: [0-9]+' m_client.log | head -1
# Committed: 822000

注意：CREST 日志里 “Troughput” 是拼写错（throughput 少 h）——grep 时要按它的拼写来。

5.2 提取 atomic/txn

TOTAL_ATOMIC=0
for i in 0 1 2 3; do
  CN_ATOMIC=$(grep -E 'tpcc\.(NEWORDER|PAYMENT|DELIVER|ORDER_STATUS)\.rdma\.atomic\.total' \
              m_cn${i}.details.txt \
              | awk '{sum+=$NF} END{print sum+0}')
  TOTAL_ATOMIC=$((TOTAL_ATOMIC + CN_ATOMIC))
done

COMM_NUM=$(grep -oE 'Committed: [0-9]+' m_client.log | head -1 | awk '{print $2}')
echo "scale=2; $TOTAL_ATOMIC / $COMM_NUM" | bc
# 12.10

5.3 提取 SGD 权重演化

cd /tmp/aura_v27_drift_*/drift_5sec_rep0/

# 提取每行 SGD 权重 self-tune
grep "self-tuned.*sgd" m_client.log | awk '{print $1, $5, $7, $9, $11}'
# 输出：timestamp atomic_w rpc_w move_w load_w

输出格式（示例）：

[t=0.10s] atomic=0.500 rpc=1.000 move=2.500 load=0.180
[t=0.20s] atomic=0.498 rpc=1.020 move=2.500 load=0.180
[t=5.10s] atomic=0.480 rpc=1.100 move=2.520 load=0.200   ← phase 切换
[t=5.20s] atomic=0.485 rpc=0.985 move=2.667 load=0.179
...

5.4 跨 rep median + bootstrap CI

把上面提取的数字（每 cell 3 reps）算中位数 + bootstrap CI：

#!/usr/bin/env python3
import numpy as np
from numpy.random import choice

def median_with_ci(reps, n_bootstrap=1000):
    reps = np.array(reps)
    bootstrap = np.array([
        np.median(choice(reps, size=len(reps), replace=True))
        for _ in range(n_bootstrap)
    ])
    median = np.median(reps)
    ci_lo, ci_hi = np.percentile(bootstrap, [2.5, 97.5])
    return median, ci_lo, ci_hi

# Full v27 3 reps
reps_full = [13.64, 13.71, 13.58]
m, lo, hi = median_with_ci(reps_full)
print(f"full_v27: {m:.2f} [{lo:.2f}, {hi:.2f}]")
# full_v27: 13.64 [13.58, 13.71]

5.5 一键 summary.csv → paper table

bench harness 已经写了 summary.csv，直接读：

import pandas as pd
df = pd.read_csv('/tmp/aura_v27_step6_*/summary.csv')
print(df.groupby('cell')['commit_kops'].agg(['median', 'std']))

paper §6.2 那张表的数字直接从 summary.csv 拼出来。

5.6 SGD 权重时间序列图

import matplotlib.pyplot as plt
import re

times, atomic_w, rpc_w, move_w, load_w = [], [], [], [], []
with open('m_client.log') as f:
    for line in f:
        m = re.search(r't=([\d.]+).*atomic=([\d.]+).*rpc=([\d.]+).*move=([\d.]+).*load=([\d.]+)', line)
        if m:
            times.append(float(m.group(1)))
            atomic_w.append(float(m.group(2)))
            rpc_w.append(float(m.group(3)))
            move_w.append(float(m.group(4)))
            load_w.append(float(m.group(5)))

plt.figure(figsize=(10, 4))
plt.plot(times, atomic_w, label='atomic_cost')
plt.plot(times, rpc_w, label='rpc_cost')
plt.plot(times, move_w, label='move_cost')
plt.plot(times, load_w, label='load_cost')

# Phase 切换垂直虚线（每 5 s）
for t in range(5, 65, 5):
    plt.axvline(t, color='gray', linestyle='--', alpha=0.5)

plt.xlabel('Time (s)')
plt.ylabel('Weight value')
plt.legend()
plt.savefig('sgd_weight_evolution_drift_5sec.pdf')

这是 §6.4 headline 图。

6. 故障速查表

完整 9 条故障 + 解法（合并第 8 章 §7 + 实际运行经验）：

#症状根因解法
1RDMA read / atomic 全 0IOMMU 没设 passthroughgrub 加 iommu=pt + reboot
2CN 无限 wait SyncComputeNodesconfig 中 CN 数 ≠ 实际 CN 数修 config 文件 (config/sanity_*.json)
3Memcached connection refused系统 memcached 绑 127.0.0.1sudo systemctl stop + 手动 -l 0.0.0.0
4MR 溢出 / kernel panic数据量超过 mr_size降 MAX_PAYMENT_CNT + 升 mr_size to 32
5节点 kernel panic 频发amd119 / amd112 历史问题避免做 MN，仅做 CN
6SSH 60s 中途断TCP keepalive 不够-o ServerAliveInterval=20 -o ServerAliveCountMax=15
7client crash “terminate called”Drift::Stop 没 hitBenchRunner.cc 早 return 路径补 Drift::Stop
811GB core dump 撑满rm core/* glob 不展开（单 file）sudo rm -f /users/chaomei/CREST-Opensource-0007/core /tmp/core.*
9Clash 劫持 SSHTUN 模式劫持所有 TCP关 TUN 或加 IP-CIDR,128.110.219.0/24,DIRECT

⭐ 教学重点：这张表的每一行都对应一次”我们踩过坑、修好了”的真实经历，是 v27 paper §6.1 setup 章节的”细节增量”。

6.1 实验前 sanity 一条龙

跑实验前过这 5 条 sanity，能避开 70% 的”实验跑完发现数据不对”：

# (1) IOMMU passthrough?
ssh -i $CL_KEY chaomei@128.110.219.14 'dmesg | grep -i "iommu.*pass"'

# (2) mlx5_2 active?
ssh -i $CL_KEY chaomei@128.110.219.14 'ibstatus mlx5_2 | grep PORT_ACTIVE'

# (3) memcached 0.0.0.0?
ssh -i $CL_KEY chaomei@128.110.219.14 'ss -tlnp | grep 11211'

# (4) Binary 一致？
for IP in 128.110.219.14 128.110.219.29 128.110.219.18 128.110.219.23; do
  ssh -i $CL_KEY chaomei@$IP 'md5sum /users/chaomei/CREST-Opensource-0007/build/benchmark/bench_runner'
done   # 5 个 md5 应该一致

# (5) core dump 清掉
for IP in 128.110.219.14 128.110.219.29 128.110.219.18 128.110.219.23; do
  ssh -i $CL_KEY chaomei@$IP 'sudo rm -f /users/chaomei/CREST-Opensource-0007/core /tmp/core.*'
done

7. 5/12 节点 punt 决定为什么是对的

7.1 决定背景

第 8 章 §6 已分析——5-node 集群只能 1 MN + 4 CN。如果想做 RQ5 (CN scale-out 1/4/8/12 CN sweep)，需要 12-node cluster。

CloudLab 已申请新 7-node experiment (new.intelisys-pg0)，但需要：

  1. OFED 4.9 + --add-kernel-support（Ubuntu 20.04）
  2. IOMMU passthrough + reboot
  3. 验证 mlx5_X = ens1f0
  4. 配置文件重新生成

总估时 ~10 天。

7.2 4 条 punt 标准的验证

(对照第 7 章 §6 的 4 条标准)

标准触发情况决定
1. 连续修不动 + 根因没动不适用（不是修问题）—
2. 工具/环境超出可调范围不适用（新 cluster 有，只是要时间）—
3. caveat 写法论证更强RQ5 缺失不反证 thesis（只是 future）△
4. 机会成本超过完成成本10 天 setup 占 critical path✓

→ 主要触发的是标准 4（机会成本）。

7.3 决定的合理性

  • v27 主体 contribution（5 维度 framing、A1-A4 levers、I1-I3 protocol）已经被 §6.1-§6.4 充分支持
  • §6.6 RQ5 是”完整性”加分项，不是”必要条件”
  • 投稿可以先不带 RQ5，rebuttal 阶段再补
  • 10 天 setup 跟 paper writing 抢 critical path

→ 决定：暂留在 5-node + 4 CN，新 7-node experiment 作为 follow-up。

7.4 §6.1 setup 章节的免责声明模版

### §6.1 Experimental Setup

We evaluate AURA v27 on a CloudLab small-lan profile with 5 ×
c6525-25g (Utah cluster): 1 MN (amd103) + 4 CN (amd118 / amd107 /
amd112 / amd119). All nodes have ConnectX-6 Dx 100 GbE QSFP56
network and run MLNX_OFED 4.9-7.1.0.0 with IOMMU passthrough.
CN scale-out trends (RQ5) on larger clusters are deferred to
future work in a 12-node configuration.

⭐ 教学要点：scale-out RQ 留 future work 不影响 paper 主线——只要 §6.1 setup 明确写”1 MN + 4 CN”就行。reviewer 不会因为缺 12-CN 直接拒。

🌟 结论：v27 团队 5/12 punt 的决定是 punt 标准 4（机会成本）触发的合理判断。这种 punt 留痕在 PROGRESS.md，给未来回看者一个清晰的 “为什么当时这样选” 解释。

✅ 自我检验清单

  • 集群 setup：能不查资料默写 5 节点角色 + IP 映射 + 哪 2 个节点历史不稳
  • OFED + IOMMU：能默写 IOMMU passthrough 配置步骤 + mlx5_2 校验命令 + 走错 mlx5_0 的代价
  • build 一条龙：能给出从 rsync 到 cmake + make -j40 的完整命令 + memcached 启动命令
  • 三 smoke 脚本：能默写三脚本名称 + 每个的输出目录结构 + 总耗时估计
  • 日志→表格：能用 grep + awk 提取出 KOPS / atomic/txn / SGD 权重
  • bootstrap CI：能写出 numpy bootstrap 计算 95% CI 的代码片段
  • 故障速查：能对至少 5 个症状给出根因 + 解法（atomic 全 0 / SSH 断 / core dump 撑满 / Clash 劫持 / memcached 绑错）
  • 实验前 sanity：能默写 5 条 sanity check 命令
  • punt 判断：能解释 5/12 节点 punt 决定由哪条标准触发 + 为什么是合理决定

📚 参考资料

概念入门

  • v27 paper outline §6.1 + cumulative commit map —— 复现的 source of truth
  • CLAUDE.md “CloudLab 集群配置 (CREST 实验用)” —— 集群配置细节

关键论文

  • CREST original paper —— upstream 系统的复现说明
  • CloudLab paper (Ricci et al., USENIX Login’14) —— CloudLab experiment 平台使用指南

行业讨论

框架文档（代码 anchor）

  • bench/aura/run_v27_step6.sh —— RQ1 5-cell ablation
  • bench/aura/run_v27_a1b_smoke.sh —— RQ3 tuner ablation
  • bench/aura/run_v27_drift_smoke.sh —— RQ2 drift adaptation
  • bench/aura/run_v27_rdma_dispatch_smoke.sh —— RDMA dispatch smoke（第 7 章已分析）
  • config/sanity_old_w4_4cn.json —— 5-node 4-CN 配置
  • PROGRESS.md —— 全程实验 / 修复 / 决策记录

📎 v25 对照视角：模块二十三-AURA 论文精讲 第9章-评测方法论与端到端复现 —— v25 时期复现脚本是 run_v25_*.sh；v27 升级为 run_v27_*.sh 系列 + 加入 5/12 节点 punt 决定的工程留痕