Achieving the required transmit bandiwdth
Inf
I have written a simple C program to control the
transmission rate of a UDP sender. The way it works is as follows:
Lets say I want to achieve half the line rate, then I would transmit
say a burst of 100 packets, measure the time taken to send the burst,
and then sleep for the same time. This is done in a loop till the
required number of packets are transmitted.
I have two PCs with 1Gig NICs connected back to back, and the OS is
Ubuntu.
The problem that I am facing is that when the burst size is small
(e.g. 10) and the number of packets to be sent is huge (to offset the
buffering effects), using the above mechanism I am getting a
throughput which is close to the line rate, instead of half the line
rate. In fact, I was expecting that with a burst size of 10 packets,
the throughput would be even less than half, as the amount of time
spent sleeping would be more as compared to burst size of 100 or 1000.
Can any one please point out what could be happening here.
Thanks..
Piet de Arcilla
I'm not sure why you would expect the data to be completely processed
by the receiver when your program measures the elapsed time and goes
to sleep.
I assume the elapsed time that you are using for your sleep cycle is
just the time it takes to put the packets in a queue somewhere, and
not nearly enough time for them to get all the way to the destination.
Pascal J. Bourguignon
You cannot _measure_ the thing, unless you go to the wire. There are
buffers, in the library you may be using to send the data, in the
kernel, and in the NIC. This what allows the system to accept a burst
of packets. So you will have completed sending your burst to the
kernel long before it has even tried to start sending them to the NIC,
or if your burst is big, long before the NIC will have started to send
the first byte of the first packet.
You must know in advance at what average speed you want to send your
data.
And take into account that most 1 Gb/s NIC just cannot send data at 1
Gb/s, but more like 500 Mb/s or 675 Gb/s (at least that was the case
last time I bought 1 Gb/s NICs, a few years ago).
So instead, you could implement an algorithm similar to Bresenham's
line drawing algorithm:
http://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm where you
take x as the wall time, and y as the number of bytes you send. Since
you're sending your bytes packet by packets, you may consider your
packets size to be the size of the pixel. plot(x,y) means send packet
number y at time x (don't do anything if you have already sent the
packet y), and if x is greater than current time, then sleep a little.
Ah, of course, the slope is your transmission speed.
--
__Pascal Bourguignon__