lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTilSrX5PifVHlxMjTK-wo_viD8IS_1m1k-vPOlE3@mail.gmail.com>
Date:	Fri, 28 May 2010 13:38:53 -0700
From:	Ivan Novick <novickivan@...il.com>
To:	netdev@...r.kernel.org
Cc:	Tim Heath <theath@...enplum.com>
Subject: Choppy TCP send performance

Hello,

I am using RHEL5 and have 1 Gigabit NIC cards.

When doing a loop sending 128 KB blocks of data using TCP.  I am using
system tap to debug the performance and finding that:

90% of the send calls take about 100 micro seconds and 10% of the send
calls take about 10 miliseconds.  The average send time is about 1
milisecond

The 10% of the calls taking about 10 milliseconds seem to be
correlated with "sk_stream_wait_memory" calls in the kernel.

sk_stream_wait_memory seems to be called when the send buffer is full
and the next send call does not complete until the send buffer
utilization goes down from 4,194,304 bytes to 2,814,968 bytes.

This implies that the send that blocks on a full send buffer will not
complete until there is 1 meg of free space in the send buffer even
though the send could be accepted into the OS with only 128KB of free
space.

Do you think I am misinterpreting this data or is there a way to even
out the send calls so that they they are more even in duration: approx
1 milisecond per call.  Is there a parameter to reduce how much space
needs to be free in the send buffer before a blocking send call can
complete from user space?

Cheers,
Ivan
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ