UDP packets scheduling

UDP packets scheduling

[Lukas Hejtmanek]

Hello,

can anyone suggest me a proper way how to schedule UDP packets to transmit at
some given rate?

E.g., I have two boxes both having 10 GE interfaces. One box is able to
transmit at 9.9Gbps, the other one is able to receive only at about 5.5Gbps.
Flow control must be turned off for some other reason.

How can I put delay between subsequent msg sends to achieve desired
packet rate without loses, e.g., 3.5Gbps without bursts? Even nanosleep()
with the lowest possible delay seems to be too much delay. Busy loop with
clock_gettime(3) works OK on SMP boxes, but on UP it causes problems.

-- 
Lukáš Hejtmánek

RE: UDP packets scheduling

[David Schwartz]

> can anyone suggest me a proper way how to schedule UDP packets to
> transmit at
> some given rate?
>
> E.g., I have two boxes both having 10 GE interfaces. One box is able to
> transmit at 9.9Gbps, the other one is able to receive only at
> about 5.5Gbps.
> Flow control must be turned off for some other reason.

UDP is not a very good choice of protocol for this purpose. UDP pushes the
transmit timing job into user-space, where it cannot be done particularly
well.

> How can I put delay between subsequent msg sends to achieve desired
> packet rate without loses, e.g., 3.5Gbps without bursts? Even nanosleep()
> with the lowest possible delay seems to be too much delay. Busy loop with
> clock_gettime(3) works OK on SMP boxes, but on UP it causes problems.

Why do you want to avoid bursts? You're going to be bursting between 10Gb/s
and 0 anyway.

It sounds like you're deliberately putting impossible requirements on
yourself choosing the worst possible protocol and demanding the pacing be
perfect. I don't think the technology to do that is here yet, but why would
you possibly need it?

10GE cards tend to have large buffers precisely because it's not possible to
get the timing even. Why is burstiness a problem?

DS

Re: Re: ex-upload

[Lukas Hejtmanek]

Hello,

>> How can I put delay between subsequent msg sends to achieve desired
>> packet rate without loses, e.g., 3.5Gbps without bursts? Even nanosleep()
>> with the lowest possible delay seems to be too much delay. Busy loop with
>> clock_gettime(3) works OK on SMP boxes, but on UP it causes problems.
>
> Why do you want to avoid bursts? You're going to be bursting between 10Gb/s
> and 0 anyway.

It is because bursts above 5.5Gbps cannot be received by the peer. The peer is
only able to receive bursts up to 5.5Gbps whereas the sender is able to burst
up to 9.9Gbps.

> It sounds like you're deliberately putting impossible requirements on
> yourself choosing the worst possible protocol and demanding the pacing be
> perfect. I don't think the technology to do that is here yet, but why would
> you possibly need it?

it is video transmission encapsulated in RTP over UDP. I do not know whether
there are any other possibilities that would work also on Mac OS or FreeBSD.

(Please Cc me)

-- 
Lukáš Hejtmánek

Re: UDP packets scheduling

[Stephen Hemminger]

On Mon, 19 Mar 2007 19:37:58 -0700
"David Schwartz" <davids@webmaster.com> wrote:

> 
> > can anyone suggest me a proper way how to schedule UDP packets to
> > transmit at
> > some given rate?
> >
> > E.g., I have two boxes both having 10 GE interfaces. One box is able to
> > transmit at 9.9Gbps, the other one is able to receive only at
> > about 5.5Gbps.
> > Flow control must be turned off for some other reason.

  "Those who do not understand TCP are condemned to reinvent it, poorly."


-- 
Stephen Hemminger <shemminger@linux-foundation.org>

Re: UDP packets scheduling

[Jan Engelhardt]

On Mar 20 2007 09:31, Stephen Hemminger wrote:
>> > can anyone suggest me a proper way how to schedule UDP packets to
>> > transmit at
>> > some given rate?
>> >
>> > E.g., I have two boxes both having 10 GE interfaces. One box is able to
>> > transmit at 9.9Gbps, the other one is able to receive only at
>> > about 5.5Gbps.
>> > Flow control must be turned off for some other reason.
>
>  "Those who do not understand TCP are condemned to reinvent it, poorly."

So perhaps, might want to use SCTP?



Jan
-- 

Re: UDP packets scheduling

[Andi Kleen]

Lukas Hejtmanek <xhejtman@mail.muni.cz> writes:

> Flow control must be turned off for some other reason.

That's your fundamental problem. Fix that. 

Even if you get the rate right there can be many reasons why timing 
gets disrupted temporarily and to recover from any of this you need
working flow control.

-Andi

Re: UDP packets scheduling

[Lukas Hejtmanek]

On Tue, Mar 20, 2007 at 06:52:51PM +0100, Andi Kleen wrote:
> > Flow control must be turned off for some other reason.
> 
> That's your fundamental problem. Fix that. 
> 
> Even if you get the rate right there can be many reasons why timing 
> gets disrupted temporarily and to recover from any of this you need
> working flow control.

How do you want to enable wire/fibre flow control, e.g., from Europe to USA?
You are not guaranteed any hardware based flow control.

And as of software flow control, you need precise timing of UDP packets to
keep desired packet rate. How to do it at speeds about 5.5Gbps, that is my
question.

-- 
Lukáš Hejtmánek

Re: UDP packets scheduling

[Robert Hancock]

Lukas Hejtmanek wrote:
> On Tue, Mar 20, 2007 at 06:52:51PM +0100, Andi Kleen wrote:
>>> Flow control must be turned off for some other reason.
>> That's your fundamental problem. Fix that. 
>>
>> Even if you get the rate right there can be many reasons why timing 
>> gets disrupted temporarily and to recover from any of this you need
>> working flow control.
> 
> How do you want to enable wire/fibre flow control, e.g., from Europe to USA?
> You are not guaranteed any hardware based flow control.
> 
> And as of software flow control, you need precise timing of UDP packets to
> keep desired packet rate. How to do it at speeds about 5.5Gbps, that is my
> question.

Why is it necessary to avoid bursting? There should be enough buffering 
along the chain to avoid packet loss with reasonable burst sizes.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/