Timing issue with Dummynet on high kernel timer interrupt

Hans Petter Selasky hps at selasky.org
Fri Nov 6 08:42:40 UTC 2015


On 11/06/15 01:08, Rasool Al-Saadi wrote:
>
> On Thursday, 5 November 2015 8:53 PM, Hans Petter Selasky wrote:
>>
>> On 11/05/15 00:44, Rasool Al-Saadi wrote:
>>>
>>> On Wednesday, 4 November 2015 12:34 AM, Hans Petter Selasky wrote:
>>>> On 11/03/15 14:14, Rasool Al-Saadi wrote:
>>>>> Does anyone have thoughts on what we can test next to narrow down
>>>>> the
>>>> root-cause of these unusual timing jumps?
>>>>
>>>> You might also want to test the "projects/hps_head" branch, which
>>>> uses a bit different callout implementation.
>>>
>>> Thanks Hans for your suggestion.
>>> I have tried "projects/hps_head" branch and the result is better (number
>> of spikes is less than in the master branch). However, the problem still exists
>> on the same timer interrupt frequencies (>3000 in my case). You can see in
>> this graph https://goo.gl/photos/C2Mqx4xhMQuzxWnz6 the RTT spikes still
>> there.
>>>
>>> Do you have any further suggestions?
>>>
>>
>> Hi,
>>
>> If the jitter is in the xx milliseconds range, like your graph shows, my guess is
>> that td_owepreemt is not set when we return from the dummynet()
>> callback. See attached patch.
>
> The patch doesn't solve the problem. I tried it on the master and hps branches.
>
>> Else you might want to try to remove the C_HARDCLOCK flag from
>> callout_reset_sbt() in ip_dummynet.c.
>
> Removing C_HARDCLOCK reduces the problem but doesn't  solve it completely. However, removing  C_DIRECT_EXEC  instead solves the problem (but occasionally  very small spike(s) appears in high hz values).
> I mentioned in my first email that removing these flags makes the issue to disappear. But what the effects of removing these flags? If it cause timing issue to Dummynet, why we should use them?
>

Hi,

The C_DIRECT_EXEC flag reduces task switching overhead, that you don't 
have to wakeup a thread to wakeup the dummynet worker thread. It affects 
timing.

Here is one more patch you can try. See attachment. It restarts the 
timeout from within the timer callback, instead of when the worker 
thread is executing.

--HPS

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipfw_reschedule.diff
Type: text/x-patch
Size: 682 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20151106/281ebfc6/attachment.bin>


More information about the freebsd-net mailing list