Thank you for the reply, Ben.
Yes im using policing, but even when i set policing_rate and burst to 0,there
is still packet lost.
I will try to use the Queue tables anyway.
But also i have question for this Queue tables QoS,will bandwidth of one queue
be
reserved all the time? By that i mean,say i reserve 20Mbps for queue1,and there
is another queue2 i reserved
90Mbps for, however,the total bandwidth of this link is only 100Mbps. So when i
push 20Mbps and 90Mbps
data to two queues,respectively, will they compromise to each other?
regards,
Shan
----- Original Message -----
From: "Ben Pfaff" <b...@nicira.com>
To: "Shan Hu" <shan...@utdallas.edu>
Cc: discuss@openvswitch.org
Sent: Wednesday, October 26, 2011 10:24:13 PM
Subject: Re: [ovs-discuss] Sending UDP traffic in openflow network
On Wed, Oct 26, 2011 at 10:22:18PM -0500, Shan Hu wrote:
> Im trying to test the QoS Rate-Limiting of Kernel vSwitch, i use iperf
> as my measurement tool. Everything is working fine with TCP part,that
> is, after i limit rate of one port to, say 50Mbps, the rate is limited
> to 50Mbps correctly and packets are tranferred 100%. But when i turn
> to UDP part,i ran into problems.I have to limit bandwidth to at most
> 4Mbps in order to tranfer 100% packets.And if i use bandwidth more
> than 4Mbps, the lost packets increase, the worst packet lost
> percentage is almost 99%.
Are you using policing? The documentation says a lot about problems
with policing:
Ingress Policing:
These settings control ingress policing for packets received on this
interface. On a physical interface, this limits the rate at which
traffic is allowed into the system from the outside; on a virtual
interface (one connected to a virtual machine), this limits the rate at
which the VM is able to transmit.
Policing is a simple form of quality-of-service that simply drops pack-
ets received in excess of the configured rate. Due to its simplicity,
policing is usually less accurate and less effective than egress QoS
(which is configured using the QoS and Queue tables).
Policing is currently implemented only on Linux. The Linux implementa-
tion uses a simple ``token bucket'' approach:
o The size of the bucket corresponds to ingress_polic-
ing_burst. Initially the bucket is full.
o Whenever a packet is received, its size (converted to
tokens) is compared to the number of tokens currently in
the bucket. If the required number of tokens are avail-
able, they are removed and the packet is forwarded. Oth-
erwise, the packet is dropped.
o Whenever it is not full, the bucket is refilled with
tokens at the rate specified by ingress_policing_rate.
Policing interacts badly with some network protocols, and especially
with fragmented IP packets. Suppose that there is enough network
activity to keep the bucket nearly empty all the time. Then this token
bucket algorithm will forward a single packet every so often, with the
period depending on packet size and on the configured rate. All of the
fragments of an IP packets are normally transmitted back-to-back, as a
group. In such a situation, therefore, only one of these fragments
will be forwarded and the rest will be dropped. IP does not provide
any way for the intended recipient to ask for only the remaining frag-
ments. In such a case there are two likely possibilities for what will
happen next: either all of the fragments will eventually be retransmit-
ted (as TCP will do), in which case the same problem will recur, or the
sender will not realize that its packet has been dropped and data will
simply be lost (as some UDP-based protocols will do). Either way, it
is possible that no forward progress will ever occur.
ingress_policing_rate: integer, at least 0
Maximum rate for data received on this interface, in kbps. Data
received faster than this rate is dropped. Set to 0 (the
default) to disable policing.
ingress_policing_burst: integer, at least 0
Maximum burst size for data received on this interface, in kb.
The default burst size if set to 0 is 1000 kb. This value has
no effect if ingress_policing_rate is 0.
Specifying a larger burst size lets the algorithm be more for-
giving, which is important for protocols like TCP that react se-
verely to dropped packets. The burst size should be at least
the size of the interface's MTU. Specifying a value that is
numerically at least as large as 10% of ingress_policing_rate
helps TCP come closer to achieving the full rate.
If you're not using policing, please tell us about your configuration.
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
