【问题标题】:Loopback tcp connection accelerationLoopback tcp 连接加速
【发布时间】:2014-10-20 21:31:14
【问题描述】:

我正在尝试使用以下代码使用 tcp 环回连接向第三方应用程序(在同一台服务器上运行)发送一些字节。

struct sockaddr_in serv_addr;
struct hostent *server;
int sockfd = socket(PF_INET, SOCK_STREAM, 0);
server = gethostbyname(host_address);

bzero((char *) &serv_addr, sizeof (serv_addr));
serv_addr.sin_family = AF_INET;

bcopy((char *) server->h_addr, (char *) &serv_addr.sin_addr.s_addr, server->h_length);

/**** Port No. Set   ****/
serv_addr.sin_port = htons(portno);
int sockKeepAliveOption = 1;
int al = setsockopt(sockfd, SOL_SOCKET, SO_KEEPALIVE, (void*) &sockKeepAliveOption, sizeof (sockKeepAliveOption));
if (al == -1) {
    std::cout << "Setsocket option err: SO_KEEPALIVE --unable to set keep alive tcp connection." << std::endl;
} 
else {
    std::cout << "S0_KEEPALIVE set, with SOL_SOCKET.. . ..\n" << std::endl;
}

我一次发送 400 个字节,每秒发送 100 次。我正在使用以下代码发送

int n = send(sockfd,sendB,400, ONLOAD_MSG_WARM); 

我的问题是,我越来越抖动。我得到最小延迟 3 us,平均 7 us 和最大 19 us。如何优化?

谢谢

于 2014 年 8 月 28 日编辑。

让我添加更多信息。我也在不同线程中从同一端口接收数据,但在我发送之后。我还通过以下代码为每个线程分配一个核心,并且除了核心 0 之外的所有 cpu 都与调度程序隔离。

        thread1= new std::thread(myfunction, input1, input2);
        pthread_t thread_hnd = thread1->native_handle();
        CPU_SET(5, &cpuset);
        s = pthread_setaffinity_np(thread_hnd, sizeof (cpu_set_t), &cpuset);

当我以每 1 毫秒连续发送时,我得到了很好的数字(3 或 4 我们),但如果频率较低(比如每秒 1-5 次),那么有时我会得到大约 20 我们,但平均大约是 7我们。

不同线程在同一个端口上监听和发送是否会产生抖动?

2014 年 8 月 28 日第二次编辑。

这是我的 CPU 状态。它不会进入 C3。 Core 2 [7] 是我通过环回发送数据的线程。

 Cpu speed from cpuinfo 3499.00Mhz
 True Frequency (without accounting Turbo) 3499 MHz

 Socket [0] - [physical cores=6, logical cores=6, max online cores ever=6]
 CPU Multiplier 35x || Bus clock frequency (BCLK) 99.97 MHz
 TURBO ENABLED on 6 Cores, Hyper Threading OFF
 Max Frequency without considering Turbo 3598.97 MHz (99.97 x [36])
 Max TURBO Multiplier (if Enabled) with 1/2/3/4/5/6 cores is  38x/37x/36x/36x/36x/36x
 Real Current Frequency 3600.17 MHz (Max of below)
    Core [core-id]  :Actual Freq (Mult.)      C0%   Halt(C1)%  C3 %   C6 %  Temp
    Core 1 [0]:       3600.17 (36.01x)      1.08    98.9       0       0    41
    Core 2 [1]:       3595.44 (35.96x)      1.07    98.9       0       0    46
    Core 3 [2]:       3595.28 (35.96x)         1    99.1       0       0    40
    Core 4 [3]:       3599.01 (36.00x)         1    99.9       0       0    46
    Core 5 [4]:       3599.51 (36.01x)         0     100       0       0    50
    Core 6 [5]:       3598.97 (36.00x)       100       0       0       0    56

  Socket [1] - [physical cores=6, logical cores=6, max online cores ever=6]
  CPU Multiplier 35x || Bus clock frequency (BCLK) 99.97 MHz
  TURBO ENABLED on 6 Cores, Hyper Threading OFF
  Max Frequency without considering Turbo 3598.97 MHz (99.97 x [36])
  Max TURBO Multiplier (if Enabled) with 1/2/3/4/5/6 cores is  38x/37x/36x/36x/36x/36x
  Real Current Frequency 3600.12 MHz (Max of below)
    Core [core-id]  :Actual Freq (Mult.)      C0%   Halt(C1)%  C3 %   C6 %  Temp
    Core 1 [6]:       3598.97 (36.00x)       100       0       0       0    56
    Core 2 [7]:       3598.51 (36.00x)      1.12    98.8       0       0    49
    Core 3 [8]:       3599.98 (36.01x)      1.94      98       0       0    45
    Core 4 [9]:       3598.97 (36.00x)       100       0       0       0    56
    Core 5 [10]:      3599.48 (36.01x)         1    99.9       0       0    48
    Core 6 [11]:      3600.12 (36.01x)      3.44    96.5       0       0    45

 C0 = Processor running without halting
 C1 = Processor running with halts (States >C0 are power saver)
 C3 = Cores running with PLL turned off and core cache turned off
 C6 = Everything in C3 + core state saved to last level cache
 Above values in table are in percentage over the last 1 sec
 [core-id] refers to core-id number in /proc/cpuinfo

【问题讨论】:

  • 什么平台以及如何计算延迟时间?在 us 范围内,计时器本身可能不够精确。
  • 我正在使用 RHEL6.4 并使用 CLOCK_MONOTONIC_RAW 来测量时差。

标签: c tcp onload loopback


【解决方案1】:

首先,有一些技术可以加快速度,但这不一定能解决抖动问题。大多数速度优化也依赖于异步套接字处理,主要是在接收数据时提供帮助,在发送数据时帮助较少。

可能的帮助是设置TCP_NODELAY 选项。这将通过禁用Nagle algorithm 确保尽快发送数据包。本质上,Nagle 算法尝试在单个数据包中附加多个 TCP 缓冲区,以以延迟/抖动为代价最大化吞吐量。

另外,请记住,在如此低的分辨率上的时间安排充其量是棘手的。仔细检查您的计时器分辨率 (clock_getres) 并记住,任何系统中断和进程调度都会影响计时。您的实际抖动可能比您的时间更好。

【讨论】:

  • 是的,我通过以下代码禁用了 NAG。抱歉之前忘记添加了。 setsockopt(sockfd, IPPROTO_TCP, TCP_NODELAY,(char *) &flag,sizeof(int));
  • 如何异步处理我的套接字连接?我认为,这可能会更好。
【解决方案2】:

您可以在您的网络线程上尝试sched_setaffinity(2) 吗?如果您的代码是单线程的,那么使用它的包装器taskset(1) 会更容易。

此外,最好使用isolcpus 参数启动Linux,这样其他不相关的进程就不会打扰您的实验。

C 状态更新

您的 CPU 是否可能睡眠过深 (>= C3)?

此工具可能有助于监控 C 状态:

您可能需要调整 intel_idle.max_cstate 内核参数或类似参数,具体取决于您的 CPU 和内核版本。

【讨论】:

  • 是的,我正在使用 isolcpus 启动我的 cpu。 Core 0 正在运行所有系统进程。我为每个线程分配了一个核心。
  • @prashantsingh 我阅读了您关于长间隔情况下高延迟的更新,并添加了一些有关英特尔 CPU 睡眠状态的信息。
  • 这是非常好的信息。非常感谢。我会通过它并回复你。我认为,CPU睡得太深的可能性很小。我在同一个线程中逐个逐个解析刻度数据,数据每 10-20 次发送一次。
  • 我已经发布了 i7z 结果。它看起来大多处于 C1 状态(当它等待数据时)。没问题还是我应该禁用 c-states ?
  • i7z 报告为“C1”的内容实际上可以是 C1(狭义)或 C1E,如果是 C1E,它可能对您造成伤害。此文件包含每个 C 状态 github.com/torvalds/linux/blob/master/drivers/idle/intel_idle.c典型延迟表您不妨尝试在谷歌上搜索“bios disable c1e”或其他内容...如果您仍然观察到高延迟和抖动,那就是值得尝试使用非阻塞套接字忙循环。
猜你喜欢
  • 2013-04-28
  • 1970-01-01
  • 2021-11-24
  • 1970-01-01
  • 2018-02-03
  • 2011-01-19
  • 1970-01-01
  • 2012-11-11
  • 1970-01-01
相关资源
最近更新 更多