All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Furniss <adf.lists@gmail.com>
To: lartc@vger.kernel.org
Subject: Re: Using Unix TC to shape high bandwidth traffic
Date: Thu, 06 Aug 2015 12:09:50 +0000	[thread overview]
Message-ID: <55C34E8E.5060908@gmail.com> (raw)
In-Reply-To: <E9450EA5C62BD943A17ACD921A227DD2054A3EA2@MMXDC2642.hermes.si.socgen>

LAMBRUSCHI Yannick (EXT) wrote:
> Hello,
>
>
> We actually have a 10Gb/s servers and 1Gb/s servers that coexist
> together (temporary migrating solution) [UDP traffic]. We would like
> to shape the traffic coming from the 10Gb/s servers in order to avoid
> big bursts that the 1G servers could not handle.
>
> It seems that "tc" cannot do the job with a tbf (or maybe we use it
> the wrong way). For instance on our 10G servers we tried the
> following:

I don't know about shaping high bandwidth.

> sudo tc qdisc add dev eth5 root tbf rate 950mbit latency 1s burst
> 50mbit peakrate 1000mbit mtu 1500

I can test this though and it's actually broken for me = no full size 
traffic.

You should read man tc-tbf - the mtu setting + peakrate is an issue.

mtu on eth when playing with tc is 1514 to allow for 1500 ip level as
that's the size tc sees the packets as. Of course it may be more or less
eg. on vlan (1518) or ip level on ppp.

The mtu using your command actually prevents 1500 ip level traffic 
totally (for me).

>
> Here we normally set the peakrate at 1mb (which normally can't
> generate burst > 1mb/s). Unfortunately, that does not work, in fact
> after using this tc config, we lower our main bandwidth to at max
> 2Mb/s..
>
> Our only clue for this strange behavior is that sentence in the tc
> manual:
>
> "To achieve perfection, the second bucket may contain only a single
> packet, which leads to the earlier mentioned 1mbit/s limit.
>
> This limit is caused by the fact that the kernel can only throttle
> for at minimum 1 'jiffy', which depends on HZ as 1/HZ. For perfect
> shaping, only a single packet can get sent per jiffy - for HZ\x100,
> this means 100 packets of on average 1000 bytes each, which roughly
> corresponds to 1mbit/s. "
>
> So, it's sure we can't have a peakrate > 1Mbit/s ?
>
> Maybe, there is another completely different way to achieve our goal,
> if anyone has a suggestion that would help me achieve our goal.. =)
> ?
>
> Kind regards
> N�����r��y���b�X��ǧv�^�)޺{.n�+���j�\�{ay�\x1dʇڙ�,j\a��f���h���z�\x1e�w���\f���j:+v���w�j�m����\a����zZ+�����ݢj"��!tml>

  reply	other threads:[~2015-08-06 12:09 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-03 13:38 Using Unix TC to shape high bandwidth traffic LAMBRUSCHI Yannick (EXT)
2015-08-06 12:09 ` Andy Furniss [this message]
2015-08-06 14:08 ` LAMBRUSCHI Yannick (EXT)
2015-08-06 17:01 ` Andy Furniss
2015-08-07  8:30 ` LAMBRUSCHI Yannick (EXT)
2015-08-07  8:44 ` Dave Taht
2015-08-17  8:51 ` LAMBRUSCHI Yannick (EXT)
2015-09-01 15:19 ` Marco Gaiarin

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=55C34E8E.5060908@gmail.com \
    --to=adf.lists@gmail.com \
    --cc=lartc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.