Sending UDP packets at a specified rate

(Originally posted to comp.unix.programmer)

Hello,

I am trying to understand how to write a simple network program that
sends UDP packets at a specified rate.

For example, let's say I want to send 500-byte packets at 40 Mbit/s

This means I want to send one packet every 0.1 ms

In my mind, the naive way to do that would be to write:

(pseudo code...)

while (1)
{
send(500-byte UDP packet);
sleep(0.1 ms);
}

But I don't think any of the sleep functions (nanosleep?) will let me
sleep for such a short period, will they?

Maybe I could send 10 packets, then sleep 1 ms? That might solve the
sleep problem, but my traffic would be very bursty.

I suppose I could waste time in a busy loop, but I don't like that solution.

Is there a (simple?) way to send 500-byte packets every 0.1 ms without
pegging the CPU to 100%?

> I am trying to understand how to write a simple network program that
> sends UDP packets at a specified rate.
> For example, let's say I want to send 500-byte packets at 40 Mbit/s
> This means I want to send one packet every 0.1 ms
> In my mind, the naive way to do that would be to write:
> (pseudo code...)
> while (1)
> {
> send(500-byte UDP packet);
> sleep(0.1 ms);
> }
>
> But I don't think any of the sleep functions (nanosleep?) will let me
> sleep for such a short period, will they?
>
> Maybe I could send 10 packets, then sleep 1 ms? That might solve the
> sleep problem, but my traffic would be very bursty.
>
> I suppose I could waste time in a busy loop, but I don't like that
> solution.
>
> Is there a (simple?) way to send 500-byte packets every 0.1 ms without
> pegging the CPU to 100%?

Short answer: no.

Long answer:

In the 2.4 series kernels, the pktgen module used to be able to do this,
sort of. I have no idea what happened to it in the 2.6 series kernels,
but it's worth looking at.

You could also try the fine-grained timer stuff. (It may have found its
way into the 2.6 kernels, again I'm not up-to-date.) I tried an early
version and couldn't get it to work, but there appear to have been
significant improvements since that time.


--
My real e-mail address is *aamci* *at* *optonline* *dot* *net*

On Wed, 19 Apr 2006, in the Usenet newsgroup comp.os.linux.networking, in
article <e25amp$vo2$(E-Mail Removed)>, Spoon wrote:

>I am trying to understand how to write a simple network program that
>sends UDP packets at a specified rate.

That would normally be easy - given certain limitations.

>For example, let's say I want to send 500-byte packets at 40 Mbit/s

And you just ran into one of them. Even though a full duplex link will
let you send packets "whenever" you want, you are not the only application
on the system - what happens if you have some other application that wants
to send a packet AND IS DOING SO when you decree it's time to send NOW.

>In my mind, the naive way to do that would be to write:

And you're also forgetting that this is not a single user system - the
kernel has tons of other stuff to do - like keep track of clock interrupts
or monitor key presses.

>But I don't think any of the sleep functions (nanosleep?) will let me
>sleep for such a short period, will they?

Likely not - and unless you disable all interrupts (a REALLY BAD idea),
something else will happen at the end of your timeslice in the sun, and
the kernel will be doing "something" else.

>Maybe I could send 10 packets, then sleep 1 ms? That might solve the
>sleep problem, but my traffic would be very bursty.

What are you trying to accomplish?

>I suppose I could waste time in a busy loop, but I don't like that solution.

I don't think it would work anyway.

>Is there a (simple?) way to send 500-byte packets every 0.1 ms without
>pegging the CPU to 100%?

I don't think so.

Old guy

Moe Trin wrote:

> On Wed, 19 Apr 2006, in the Usenet newsgroup comp.os.linux.networking, in
> article <e25amp$vo2$(E-Mail Removed)>, Spoon wrote:
>
>>I am trying to understand how to write a simple network program that
>>sends UDP packets at a specified rate.
>
> That would normally be easy - given certain limitations.
>
>>For example, let's say I want to send 500-byte packets at 40 Mbit/s
>
> And you just ran into one of them. Even though a full duplex link will
> let you send packets "whenever" you want, you are not the only application
> on the system - what happens if you have some other application that wants
> to send a packet AND IS DOING SO when you decree it's time to send NOW.

I run my tests on a retired 1.2 GHz Pentium III. This system is idle
99.9% of the time. When my application requests the CPU and the NIC, it
doesn't have to wait much.

> And you're also forgetting that this is not a single user system - the
> kernel has tons of other stuff to do - like keep track of clock interrupts
> or monitor key presses.

I didn't forget ;-)

I'm aware that the kernel is always busy, but AFAIU, it can carry out
each individual task in a few tens (hundreds) of µs.

>> But I don't think any of the sleep functions (nanosleep?) will let me
>> sleep for such a short period, will they?
>
> Likely not - and unless you disable all interrupts (a REALLY BAD idea),
> something else will happen at the end of your timeslice in the sun, and
> the kernel will be doing "something" else.

I'm trying to write a user-space application. I don't think user-space
apps can disable interrupts, can they?

>>Maybe I could send 10 packets, then sleep 1 ms? That might solve the
>>sleep problem, but my traffic would be very bursty.
>
> What are you trying to accomplish?

I want a CBR UDP packet stream.

I don't need any real-time guarantee. All I want is to send packets at a
constant bitrate. For example, 40 Mbit/s means 10,000 500-byte packets
every second *ON AVERAGE*. It doesn't matter if I send only 9000 one
second, and 11000 the next.

>>I suppose I could waste time in a busy loop, but I don't like that solution.
>
> I don't think it would work anyway.

Since the system is idle, a busy loop would guarantee that I can send
when I want to.

Allen McIntosh wrote:

> Spoon wrote:
>
>> I am trying to understand how to write a simple network program that
>> sends UDP packets at a specified rate.
>> For example, let's say I want to send 500-byte packets at 40 Mbit/s
>> This means I want to send one packet every 0.1 ms
>> In my mind, the naive way to do that would be to write: (pseudo code...)
>> while (1)
>> {
>> send(500-byte UDP packet);
>> sleep(0.1 ms);
>> }
>>
>> But I don't think any of the sleep functions (nanosleep?) will let me
>> sleep for such a short period, will they?
>>
>> Maybe I could send 10 packets, then sleep 1 ms? That might solve the
>> sleep problem, but my traffic would be very bursty.
>>
>> I suppose I could waste time in a busy loop, but I don't like that
>> solution.
>>
>> Is there a (simple?) way to send 500-byte packets every 0.1 ms without
>> pegging the CPU to 100%?
>
>
> Short answer: no.
>
> Long answer:
>
> In the 2.4 series kernels, the pktgen module used to be able to do this,
> sort of. I have no idea what happened to it in the 2.6 series kernels,
> but it's worth looking at.
>
> You could also try the fine-grained timer stuff. (It may have found its
> way into the 2.6 kernels, again I'm not up-to-date.) I tried an early
> version and couldn't get it to work, but there appear to have been
> significant improvements since that time.

I use kernel 2.6.14.x

I'll look at pktgen. Thanks for the pointer.

The fine-grained timer stuff you mention, is it available to user-space
apps, or is it a kernel facility?

> I use kernel 2.6.14.x
>
> I'll look at pktgen. Thanks for the pointer.
>
> The fine-grained timer stuff you mention, is it available to user-space
> apps, or is it a kernel facility?


I had the wrong acronym. It's high-resolution timers, or hrtimers.
Apparently in the 2.6.16 kernel. Google should tell you more.

Spoon <(E-Mail Removed)> wrote:
> Since the system is idle, a busy loop would guarantee that I can
> send when I want to.

Basically, that is what netperf2 does for ./configure
--enable-intervals --enable-spin - it will sit and spin until it sees
the right quantity of time passed and then does its next set of sends.

Having lurked in this thread, I'll have to go check-out the 2.6.16
hrtimer stuff myself. Might call for some further enhancements to
netperf

rick jones
--
portable adj, code that compiles under more than one compiler
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...