netdev - Re: [PATCH v2 2/2] net: netem: always adjust now/delay when not reordering

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: <5214668E.504@hupie.com>
Date:	Wed, 21 Aug 2013 09:04:46 +0200
From:	Ferry Huberts <mailings@...ie.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	netdev@...r.kernel.org
Subject: Re: [PATCH v2 2/2] net: netem: always adjust now/delay when not reordering

On 21/08/13 08:14, Eric Dumazet wrote:
> On Wed, 2013-08-21 at 07:59 +0200, Ferry Huberts wrote:
>> From: Ferry Huberts <ferry.huberts@...agic.nl>
>>
>> Not doing this (current behaviour) introduces reordering.
>>
>> The packet_len_2_sched_time call is the only thing that logically
>> depends on q->rate, so move the now/delay adjustment out of the if.
>>
>> How to test:
>> -----------
> 
> I ask again :
> 
> Did you test a config with both rate limiting and delay.

(sorry for missing that question)

Just did so and with rate limiting I get no reordering, which is logical
looking at the code.

The thing is, the evaluation q->rate is within the 'no-reordering' block
and in the current situation you can get reordering (with that 'strange'
command). My patch makes sure that no reordering will occur, and
effectively 'clamps' the realised delay, which currently isn't done.

> 
> Netem primary use is to emulate say a 1Mbits link with a rtt of 50ms
> 
> netem rate 1Mbit delay 50ms
> 
> 
> Because the "delay 10ms 500ms" is very strange : effective delay is in
> the following range : -490 ms ... 510 ms
> 
> Its probably clamped to 0ms ... 510ms

Currently it isn't. With my patch it's 'clamped' in the sense that if
the calculated delay would make the packet be scheduled before the
previous one, that the delay of the current packet is adjusted so that
it's scheduled right after the previous one.

> 
> I really doubt this is what you wanted.

It's the command Teco showed me to test/reproduce it.

-- 
Ferry Huberts
--
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