From: Eric Dumazet <dada1@cosmosbay•com>
To: Stephen Hemminger <shemminger@vyatta•com>
Cc: Patrick McHardy <kaber@trash•net>,
Denys Fedoryschenko <denys@visp•net.lb>,
Jesper Dangaard Brouer <hawk@diku•dk>,
netdev <netdev@vger•kernel.org>,
bugme-daemon@bugzilla•kernel.org
Subject: Re: [BUG #12364] Re: HTB - very bad precision? HFSC works fine! 2.6.28
Date: Tue, 13 Jan 2009 08:52:45 +0100 [thread overview]
Message-ID: <496C484D.6060502@cosmosbay.com> (raw)
In-Reply-To: <20090112232811.46100689@extreme>
Stephen Hemminger a écrit :
> On Tue, 13 Jan 2009 05:33:14 +0100
> Patrick McHardy <kaber@trash•net> wrote:
>
>> Denys Fedoryschenko wrote:
>>> They are enabled
>>>
>>> Router-Dora /config # zcat /proc/config.gz |grep HIGH_RES
>>> CONFIG_HIGH_RES_TIMERS=y
>>> Router-Dora /config # zcat /proc/config.gz |grep HZ
>>> CONFIG_NO_HZ=y
>> Its odd that HZ=1000 solved the problem despite HR timers being active.
>> Are you sure they're actually enabled? You should see something like
>> this in the ringbuffer:
>>
>> [ 0.241972] Switched to high resolution mode on CPU 0
>> [ 0.242708] Switched to high resolution mode on CPU 1
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger•kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> Even with NO_HZ the regular kernel won't schedule timers sooner
> than HZ. I believe it caused regressions so it was disabled.
Are you sure of this Stephen ?
This is not what I see with a CBQ setup, shaping a Gigabit interface with 60 Mb constraint
tc qdisc del dev eth2 root
tc qdisc add dev eth2 root handle 1: cbq avpkt 1000 rate 1000Mbit bandwidth 1000Mbit
tc class add dev eth2 parent 1: classid 1:1 cbq allot 1500 rate 1000Mbit prio 1 avpkt 1500 bounded
# VOIP : essayons d'espacer un peu les paquets plutot que de les envoyer en burst
tc class add dev eth2 parent 1:1 classid 1:11 cbq allot 1500 rate 60Mbit avpkt 200 bounded
tc filter add dev eth2 protocol ip parent 1: u32 \
match ip dst 10.170.72.0/24 \
flowid 1:11
All following RTP frames are sent at once by the producer, yet we can see them leaving machine at the right rate
08:47:59.492059 IP 10.170.74.20.40026 > 10.170.72.109.8270: UDP, length 172
08:47:59.492066 IP 10.170.74.20.40002 > 10.170.72.109.12540: UDP, length 172
08:47:59.492104 IP 10.170.74.20.40016 > 10.170.72.110.8230: UDP, length 172
08:47:59.492109 IP 10.170.74.20.40044 > 10.170.72.109.4040: UDP, length 172
08:47:59.492136 IP 10.170.74.20.40038 > 10.170.72.109.13780: UDP, length 172
08:47:59.492163 IP 10.170.74.20.40060 > 10.170.72.110.7670: UDP, length 172
08:47:59.492191 IP 10.170.74.20.40066 > 10.170.72.109.8860: UDP, length 172
08:47:59.492219 IP 10.170.74.20.40020 > 10.170.72.110.12160: UDP, length 172
08:47:59.492246 IP 10.170.74.20.40078 > 10.170.72.110.12010: UDP, length 172
08:47:59.492273 IP 10.170.74.20.40010 > 10.170.72.109.12670: UDP, length 172
08:47:59.492306 IP 10.170.74.20.40018 > 10.170.72.109.4340: UDP, length 172
08:47:59.492333 IP 10.170.74.20.40008 > 10.170.72.109.7450: UDP, length 172
08:47:59.492361 IP 10.170.74.20.40024 > 10.170.72.110.10300: UDP, length 172
08:47:59.492388 IP 10.170.74.20.40006 > 10.170.72.109.13390: UDP, length 172
08:47:59.492389 IP 10.170.74.20.40036 > 10.170.72.109.9040: UDP, length 172
08:47:59.492416 IP 10.170.74.20.40042 > 10.170.72.110.5420: UDP, length 172
08:47:59.492444 IP 10.170.74.20.40040 > 10.170.72.109.8080: UDP, length 172
08:47:59.492470 IP 10.170.74.20.40048 > 10.170.72.110.17010: UDP, length 172
08:47:59.492502 IP 10.170.74.20.40032 > 10.170.72.109.8340: UDP, length 172
08:47:59.492529 IP 10.170.74.20.40004 > 10.170.72.109.8420: UDP, length 172
2.6.27.10 kernel, HZ=1000, HighRES timers on
Switched to high resolution mode on CPU 0
Switched to high resolution mode on CPU 5
Switched to high resolution mode on CPU 4
Switched to high resolution mode on CPU 7
Switched to high resolution mode on CPU 1
Switched to high resolution mode on CPU 3
Switched to high resolution mode on CPU 6
Switched to high resolution mode on CPU 2
next prev parent reply other threads:[~2009-01-13 7:52 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-07 22:02 HTB - very bad precision? HFSC works fine! 2.6.28 Denys Fedoryschenko
[not found] ` <008201c97115$091b5d50$1b5217f0$@jorge@decimal.pt>
2009-01-07 22:36 ` Denys Fedoryschenko
[not found] ` <00a101c97118$e25a6ae0$a70f40a0$@jorge@decimal.pt>
2009-01-07 22:44 ` Denys Fedoryschenko
2009-01-07 23:42 ` mysql.jorge
2009-01-08 9:42 ` [BUG 12364] " Jarek Poplawski
2009-01-08 9:54 ` [BUG #12364] " Jarek Poplawski
2009-01-08 10:06 ` Jarek Poplawski
2009-01-08 10:35 ` mysql.jorge
2009-01-08 11:04 ` Jarek Poplawski
2009-01-08 11:22 ` mysql.jorge
2009-01-08 13:59 ` Jarek Poplawski
2009-01-08 14:09 ` mysql.jorge
2009-01-08 17:27 ` mysql.jorge
2009-01-08 18:32 ` Denys Fedoryschenko
2009-01-08 18:37 ` Jorge Bastos
2009-01-08 18:46 ` Denys Fedoryschenko
2009-01-08 18:41 ` Denys Fedoryschenko
2009-01-08 21:46 ` Jorge Bastos
2009-01-08 21:57 ` Denys Fedoryschenko
2009-01-08 22:04 ` Jorge Bastos
2009-01-09 10:30 ` Jarek Poplawski
2009-01-09 10:32 ` Denys Fedoryschenko
2009-01-09 10:44 ` Jarek Poplawski
2009-01-09 10:47 ` Jorge Bastos
2009-01-09 10:58 ` Jarek Poplawski
2009-01-12 7:27 ` Patrick McHardy
2009-01-12 8:13 ` Jarek Poplawski
2009-01-12 9:49 ` Jorge Bastos
2009-01-12 11:14 ` Jarek Poplawski
2009-01-12 8:30 ` Denys Fedoryschenko
2009-01-12 18:38 ` Denys Fedoryschenko
2009-01-12 19:58 ` Jesper Dangaard Brouer
2009-01-12 20:01 ` Denys Fedoryschenko
2009-01-13 4:33 ` Patrick McHardy
2009-01-13 7:28 ` Stephen Hemminger
2009-01-13 7:52 ` Eric Dumazet [this message]
2009-01-13 8:43 ` Michal Soltys
2009-01-13 9:53 ` Jarek Poplawski
2009-01-13 10:08 ` Denys Fedoryschenko
2009-01-12 9:48 ` Jorge Bastos
2009-01-14 1:53 ` Denys Fedoryschenko
2009-01-14 19:37 ` Jorge Bastos
2009-01-15 10:38 ` Jarek Poplawski
2009-01-09 9:48 ` Jarek Poplawski
2009-01-09 9:51 ` Jorge Bastos
2009-01-09 10:06 ` Jarek Poplawski
2009-01-09 10:10 ` Jorge Bastos
2009-01-09 7:24 ` Jarek Poplawski
2009-01-09 9:39 ` Jorge Bastos
2009-01-09 10:02 ` Jarek Poplawski
2009-01-09 7:54 ` Jarek Poplawski
2009-01-09 9:42 ` Jorge Bastos
2009-01-09 10:12 ` Jarek Poplawski
2009-01-09 10:15 ` Jorge Bastos
2009-01-09 10:22 ` Jarek Poplawski
2009-01-09 10:26 ` Jorge Bastos
2009-01-09 10:32 ` Jorge Bastos
2009-01-08 10:37 ` mysql.jorge
2009-01-08 10:34 ` [BUG 12364] " mysql.jorge
2009-01-08 9:27 ` Jarek Poplawski
2009-01-08 9:34 ` Denys Fedoryschenko
2009-01-08 10:40 ` Jarek Poplawski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=496C484D.6060502@cosmosbay.com \
--to=dada1@cosmosbay$(echo .)com \
--cc=bugme-daemon@bugzilla$(echo .)kernel.org \
--cc=denys@visp$(echo .)net.lb \
--cc=hawk@diku$(echo .)dk \
--cc=kaber@trash$(echo .)net \
--cc=netdev@vger$(echo .)kernel.org \
--cc=shemminger@vyatta$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox