Re: XTP for 2.6.25

[Shigeo N]

I tested again on Linux 2.6.25 with TCP reordering patch.
Of course, TCP performance was improved.

Here is the result.

 case2-2) random delay (with TCP reordering patch)

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

    fixed delay    UDP/TCP/XTP throghput
  ---------------------------------------
      10ms         88/85/92 Mbps
      30ms         88/67/91 Mbps
      50ms         88/58/89 Mbps
      70ms         88/43/80 Mbps
     100ms         88/26/66 Mbps

 case2) random delay (without TCP reordering patch)

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

    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

  case1) fixed delay

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

    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

Thanks,

On Fri, Apr 25, 2008 at 5:23 PM, Ilpo JÃrvinen
<ilpo.jarvinen@xxxxxxxxxxx> wrote:
> On Fri, 25 Apr 2008, Shigeo N wrote:
>
>> 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.
>
> Where these results with 2.6.25 as well? ...John Heffner just couple of
> days ago fixed reordering related problem in TCP (in case that netem
> parametrization causes reordering), the fix is not even in 2.6.24.y, I
> think...
>
> --
>  i.
>
N‹§²æìr¸›yúèšØb²X¬¶ÇvØ^–)Þ{.nÇ+‰·¥Š{±‘êçzX§¶›¡Ü}©ž²ÆzÚ&j:+v‰¨¾«‘êçzZ+€Ê+zf£¢·hšˆ§~†­†Ûiÿûàz¹®w¥¢¸?™¨è­Ú&¢)ßf”ù^jÇy§m…á@A«a¶Úÿ0¶ìh®å’i