项目

一般

简介

性能 #3354

优化cu的启动时间到f1ap建立成功的时间(4s->1s)

席 振斌3 个月 之前添加. 更新于 大约一个月 之前.

状态:
已关闭
优先级:
普通
指派给:
开始日期:
2025-05-19
计划完成日期:
% 完成:

0%

预期时间:
问题归属:
CU
发现问题版本:
Rel_3.0.1
目标解决问题版本:
Rel_3.0.1

文件

f1ap建立时长统计打印截图.png (47.3 KB) f1ap建立时长统计打印截图.png 孙 浩, 2025-06-16 11:56
f1ap建立时长测试1.txt (18.8 KB) f1ap建立时长测试1.txt 孙 浩, 2025-06-16 11:56
f1ap建立时长测试2.txt (18.8 KB) f1ap建立时长测试2.txt 孙 浩, 2025-06-16 11:56
241-1118.pcap (72.6 KB) 241-1118.pcap 孙 浩, 2025-06-16 11:56
f1ap建立时长测试3.txt (38.5 KB) f1ap建立时长测试3.txt 孙 浩, 2025-06-16 11:56
f1ap建立时长测试4.txt (18.8 KB) f1ap建立时长测试4.txt 孙 浩, 2025-06-16 11:56
F1建立抓包截图.png (102 KB) F1建立抓包截图.png 孙 浩, 2025-06-23 16:38
242-1620.pcap (24 KB) 242-1620.pcap 孙 浩, 2025-06-23 16:38
242-1610.pcap (48 KB) 242-1610.pcap 孙 浩, 2025-06-23 16:38

相关的问题

关联到 3.0基站产品测试 - 性能 #3266: 600ue时,定时器处理能力是否为性能瓶颈已关闭2025-04-29

Actions
关联到 3.0基站产品测试 - 性能 #3492: 优化du支持f1ap建立成功的时间(4s->1s)已关闭2025-06-11

Actions

历史记录

#1

席 振斌 更新于 3 个月 之前

  • 关联到 性能 #3266: 600ue时,定时器处理能力是否为性能瓶颈 已添加
#2

席 振斌 更新于 2 个月 之前

  • 主题600ue,释放ue流程, 内部消息的构建用内存池代替new 变更为 优化cu的启动时间
#3

席 振斌 更新于 2 个月 之前

  • 状态新建 变更为 进行中
#4

席 振斌 更新于 2 个月 之前

  • 主题优化cu的启动时间 变更为 优化cu的启动时间(4s->1s)
#5

席 振斌 更新于 2 个月 之前

cu侧通过同步机制优化了之前每起一个线程的sleep100ms的问题,优化了1.4s,在这个基础上日志打印发现,从cu程序启动->给du回f1 setup response信令,花费900ms-3s不等,通过报文分析定位是,du发起周期性INIT进行sctp建立连接的时间有3s的时间间隔,通过代码发现是每次建链失败,都有代码std::this_thread::sleep_for (std::chrono::milliseconds(3000));会等待3s,修改此处为50ms,时间都能稳定在900ms左右

#6

席 振斌 更新于 大约 2 个月 之前

多次测试发现会偶现du 重传 cookie,这个的重传时间间隔是3s,会导致整个流程时间到3200ms左右,得定位为什么会重传

#7

席 振斌 更新于 大约 2 个月 之前

  • 主题优化cu的启动时间(4s->1s) 变更为 优化cu的启动时间到f1ap建立成功的时间(4s->1s)
#8

周 立伟 更新于 大约 2 个月 之前

  • 关联到 性能 #3492: 优化du支持f1ap建立成功的时间(4s->1s) 已添加
#9

席 振斌 更新于 大约 2 个月 之前

测试多测试几次,多起几次站,可以通过抓包和每一次起站的日志xzb f1_end_ms来查看f1ap建立所需要的的时间

#10

席 振斌 更新于 大约 2 个月 之前

  • 指派给席 振斌 变更为 孙 浩
#11

席 振斌 更新于 大约 2 个月 之前

  • 状态进行中 变更为 转测试
#12

孙 浩 更新于 大约 2 个月 之前

基于Rel_3.1.2_Pre1T1版本,替换du与cu版本,三层启动多次,cu界面统计的f1ap建立时长均为超过1秒,达到预期;

#13

孙 浩 更新于 大约一个月 之前

在Rel_3.1.2_Pre1T2版本,三层启动多次,从基站抓包看f1ap建立时长均未超过1秒,问题关闭;

导出 Atom PDF