项目

一般

简介

性能 #3354

优化cu的启动时间(4s->1s)

由 席 振斌 在 20 天 之前添加. 更新于 2 天 之前.

状态:
进行中
优先级:
普通
指派给:
席 振斌
开始日期:
2025-05-19
计划完成日期:
% 完成:

0%

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

相关的问题

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

Actions

历史记录

#1

由 席 振斌 更新于 20 天 之前

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

由 席 振斌 更新于 10 天 之前

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

由 席 振斌 更新于 10 天 之前

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

由 席 振斌 更新于 6 天 之前

  • 主题 从 优化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左右

导出 Atom PDF