Controlling rate of tcp/ip data transmission

Controlling rate of tcp/ip data transmission

Post by Jack Snodgras » Fri, 13 Jul 2007 04:48:49



Not sure if this is a 'networking' question or what exactly....

I need to be able to control the 'rate' at which I send data on a slow
speed link. It's an ethernet port... but the device that is connected
is a slow speed device. I don't know of an 'offical' way to control the
rate... i'm just using socket sendto and adding a delay between packets
of data. I know that I send 'x' bytes in 'y' secods so I can come up with
my kbs transfer rate. The engineers looking at the line say that the data
is 'bursty' which it is... I've changed my code to send 1/4 the size of
the data packet with 1/4 the wait between packets. The data is less
'bursty' now.... and I'm getting about the same trasnfer rate but I've got
4x as much overhead on the control packets I'm sending...

Is there a better way to control how fast data goes over an
ethernet port than the send/wait/send/wait/send/wait approach
I've come up with?

--
D.A.M. - Mothers Against Dyslexia

see http://www.jacksnodgrass.com for my contact info.

jack - Grapevine/Richardson

 
 
 

Controlling rate of tcp/ip data transmission

Post by David Schwart » Fri, 13 Jul 2007 07:33:03




Quote:> I need to be able to control the 'rate' at which I send data on a slow
> speed link. It's an ethernet port... but the device that is connected
> is a slow speed device. I don't know of an 'offical' way to control the
> rate... i'm just using socket sendto and adding a delay between packets
> of data. I know that I send 'x' bytes in 'y' secods so I can come up with
> my kbs transfer rate. The engineers looking at the line say that the data
> is 'bursty' which it is... I've changed my code to send 1/4 the size of
> the data packet with 1/4 the wait between packets. The data is less
> 'bursty' now.... and I'm getting about the same trasnfer rate but I've got
> 4x as much overhead on the control packets I'm sending...

> Is there a better way to control how fast data goes over an
> ethernet port than the send/wait/send/wait/send/wait approach
> I've come up with?

Are you using TCP or UDP? You say "packets", so I'm guessing you mean
UDP.

DS

 
 
 

Controlling rate of tcp/ip data transmission

Post by Jack Snodgras » Fri, 13 Jul 2007 08:03:25





>> I need to be able to control the 'rate' at which I send data on a slow
>> speed link. It's an ethernet port... but the device that is connected
>> is a slow speed device. I don't know of an 'offical' way to control the
>> rate... i'm just using socket sendto and adding a delay between packets
>> of data. I know that I send 'x' bytes in 'y' secods so I can come up
>> with my kbs transfer rate. The engineers looking at the line say that
>> the data is 'bursty' which it is... I've changed my code to send 1/4
>> the size of the data packet with 1/4 the wait between packets. The data
>> is less 'bursty' now.... and I'm getting about the same trasnfer rate
>> but I've got 4x as much overhead on the control packets I'm sending...

>> Is there a better way to control how fast data goes over an ethernet
>> port than the send/wait/send/wait/send/wait approach I've come up with?

> Are you using TCP or UDP? You say "packets", so I'm guessing you mean
> UDP.

> DS

... yes... UDP... does it matter? It's also a one-way connection.. the
receiver has 0 TX and the sender has 0 RX on the connection.

--
D.A.M. - Mothers Against Dyslexia

see http://www.jacksnodgrass.com for my contact info.

jack - Grapevine/Richardson

 
 
 

Controlling rate of tcp/ip data transmission

Post by David Schwart » Fri, 13 Jul 2007 15:26:36


On Jul 11, 4:03 pm, Jack Snodgrass

Quote:> ... yes... UDP... does it matter? It's also a one-way connection..
> the receiver has 0 TX and the sender has 0 RX on the connection.

It matters tremendously. The answer to your question is, use TCP. TCP
was developed precisely to solve problems just like this. UDP was
designed for applications that want to do this themselves.

Each datagram will be sent more or less when you call 'sendmsg'. If
you are sending a large datagram over a fast link, the fragments will
probably be sent back-to-back.

UDP makes the application responsible for transmit pacing, duplicate
detection, lost datagram detection, proper datagram selection, and
quite a few more things that TCP does automatically.

Transferring large amounts of data over UDP is very tricky to get
right, especially with a slow link somewhere in the middle.

DS

 
 
 

Controlling rate of tcp/ip data transmission

Post by Rick Jone » Sat, 14 Jul 2007 02:47:37



> On Jul 11, 4:03 pm, Jack Snodgrass
> > ... yes... UDP... does it matter? It's also a one-way connection..
> > the receiver has 0 TX and the sender has 0 RX on the connection.

Do you mean to imply that it is not physically possible for the
receiver to send anything to the sender?

Quote:> It matters tremendously. The answer to your question is, use
> TCP. TCP was developed precisely to solve problems just like
> this. UDP was designed for applications that want to do this
> themselves.

And just in case it wasn't obvious, where "this" is "flow-control."
In the case of TCP, it is a window-based flow control, where the
receiver advertises a certain window to the sender, the sender send's
up to a window's-worth of data before he must stop and wait for a
window update from the receiver.

If indeed you cannot have anything transmitted back from the receiver
to the sender you cannot use TCP, and some sort of rate-based pacing
along the lines of what you are using is what you can use.  What sort
of link-rates are we talking about on either end here?  What sort of
rate can the receiver tolerate?  A few more details about the setup
might help us postulate some other possibilities.

The comment about the size of the sends you make via UDP possibly
leading to short bursts of IP datagram fragments is a good one to
heed.

rick jones
--
The computing industry isn't as much a game of "Follow The Leader" as
it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
                                                    - Rick Jones
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...

 
 
 

1. !!DDE->TCP/IP, REAL TIME DATA PUMP, Trans.DDE App.DATA via TCP/IP

        DDE to TCP/IP Real Time Data Pump

DDE2TCP, is a Real Time Data Pump used as a data bridge
between DDE applications and ANY host system using
TCP/IP (SUN,HP,IBM,Apple, etc).  DDE2TCP runs in the
background, totally transparent between server and target
system.

DDE2TCP is perfect for use with any MMI system such as FIX,
WONDERWARE,GENESIS,LabTech for real time update of SQL
databases residing on other hosts.  DDE2TCP comes with it's
own configurator for fast and effective setup.  DDE2TCP runs
on WINDOWS 3.1,3.11,95 and NT.  Site licenses,volume discounts
and modifications are available.  For more information on this
product or our other porducts and custom services contact:

                Marshall Rowe
                Custom Technology
                640 N. LaSalle Ste 284
                (312) 384-4104

        VISIT our WEB
        site    WWW.CUSTOM-TECH.COM                      

2. USENIX Summer 1993 Technical Conference - REGISTRATION INFORMATION

3. Installing Freebsd

4. 2.5.63 snd_printd

5. Keeping modem away from voice calls?

6. binary data transmission in TCP/IP