RE: Using Unix TC to shape high bandwidth traffic

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,


Thanks for the post. We also played with mtu 1514 (and even greater) but did not change anything. I really think it comes from the jiffy limit but can't find another way..

Yannick

-----Original Message-----
From: Andy Furniss [mailto:adf.lists@xxxxxxxxx] 
Sent: Thursday 6 August 2015 14:10
To: LAMBRUSCHI Yannick (EXT) ResgGtsMktMdm; lartc
Subject: Re: Using Unix TC to shape high bandwidth traffic

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=100,
> 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�ʇڙ�,j
��f���h���z��w���
���j:+v���w�j�m����
����zZ+�����ݢj"��!tml=
>
��.n��������+%������w��{.n����j�\�)��jg��������ݢj����G�������j:+v���w�m������w�������h�����٥




[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux