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=
--
To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
