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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <18b669d80804250059m793f3f56xc4fdb8bad949fa3@mail.gmail.com>
Date:	Fri, 25 Apr 2008 16:59:45 +0900
From:	"Shigeo N" <shigeonx@...il.com>
To:	"Andi Kleen" <andi@...stfloor.org>
Cc:	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: XTP for 2.6.25

I emulated WAN delay by netem and compared the performance again.

case1) fixed delay

    <------------- 100Mbps -------------->
Host1 --------- Linux Router ---------- Host2

 In this case, just adds a fixed amount of delay to all packets going
out on Linux Router by command, "tc qdisc add dev eth0 root netem
delay 100ms".

 Here is the result.

    fixed delay    UDP/TCP/XTP throghput
  ---------------------------------------
      10ms         88/85/92 Mbps
      30ms         88/70/91 Mbps
      50ms         88/63/89 Mbps
      70ms         88/52/84 Mbps
     100ms         88/36/70 Mbps


case2) random delay

 In this case, add a fixed amount of delay + 10% random delay by
command, "tc change dev eth0 root netem delay 100ms 10ms 25%".

 Here is the result.

    fixed delay    UDP/TCP/XTP throghput
  ---------------------------------------
      10ms         88/80/92 Mbps
      30ms         88/51/91 Mbps
      50ms         88/41/89 Mbps
      70ms         88/28/80 Mbps
     100ms         88/19/66 Mbps

 TCP's perfomance looks very poor when delay is long and variable.

Thanks
Shigeo


On Thu, Apr 24, 2008 at 10:06 PM, Shigeo N <shigeonx@...il.com> wrote:
> Now I have connected 2 hosts directly, and evaluate the each throughput.
>  Then all the results of UDP, TCP and XTP are the same and 94Mbps. (My
>  netwrok is 100Base/TX).
>
>  In this case round-trip time between 2 hosts is less than 0.1ms
>  because they are directly connected. But my previouse case, round-trip
>  time between 2 hosts are 4ms. (I use IPSEC between the security
>  gateways to increase delay).
>  I think that's the reason TCP throughput is slow. If ACK packets are
>  delayed, sending window cannot slide and sending packets cannot be
>  fully bursted.
>
>  If I changes wmem size through /proc/sys/net/ipv4/tcp_wmem, TCP's
>  throughput may improve, but congestion control becomes more difficult
>  for TCP.
>
>  That is TCP's disadvantage to XTP.
>
>  Best
>  Shigeo
>
>
>
>  On 4/24/08, Andi Kleen <andi@...stfloor.org> wrote:
>  > "Shigeo N" <shigeonx@...il.com> writes:
>  > >
>  > > I tested in the network where UDP throughput is 29Mbps, then TCP
>  > > throughput was 13Mbps, but XTP's reached to 25Mbps.
>  >
>  > One interesting question is why TCP was so much slower than UDP
>  > on your test. It shouldn't be on a fair test setup.
>  >
>  > Please post details. Was the network losing packets?
>  >
>  > New protocols might be interesting, but even more interesting is to
>  > fix any (real) problems in existing protocols.
>  >
>  > -Andi
>  >
>
--
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