(OT) Need to make TCP/IP really slooooow 
Author Message
 (OT) Need to make TCP/IP really slooooow

Hello out there,
the following is completely off topic (except maybe for the - in this
context totally  unimportant - detail that 'my program' mentioned
below is of course a Tcl program :) ), but here in clt are so many
knowledgeable people around, that I thought I'd give it a try.
Ok, here goes:

I have a somewhat strange need: slow down TCP/IP.

Here's the set-up: We configured a Linux box (Suse 9.1) to route all
packets for a different sub-net to a 'tan' interface (some smart
device, turning ethernet <-> serial). My program is listening there,
queues all packets it receives and eventually - when asked by an
external 'master' - sends everything out over a serial port. (This is
the catch: We have to wait until being explicitly asked to send
anything.)

At the other end the opposite happens: my program listens on the
serial port and forwards everything into the tap interface, from where
it is eventually delivered to its destination.
(In case you wonder: It's a research project, trying to do TCP/IP over
10.000 Volt power-line modems - very, very, special.)
_In principle_ everything works fine, but TCP's (or IP's?) built-in
intelligence comes in the way: The originating system repeats its
requests way too soon for this particularly slow set-up.

Here is what happens (at least this is my diagnose from days and days
of logging and analizing):
t0: System 1 sends (e.g.) a HTTP request to system 2 which is
delivered to my program listening at the tan 'device'.
t1 (quite some time later): My program is allowed to deliver this
request (via power-line) to the master (which will forward it via
power-line to another box).
t2: System 1 gets impatient _and repeats its request_ (which is
handled like the first).
t3 (much later): The answer to request 1 arrives via the serial line
and is fed into the tap device to be delivered to the requester - but
it is rejected/ignored, because system 1 is now waiting for an answer
to its request no. 2.
    ...
tx: Request n is sent out.
ty: The answer from system 2 to request n-1 finally arrives - but is
rejected/ignored, because system 1 one is now waiting for an answer to
its request no. n ... and so on and so on.

You see the dilemma: The 2 systems never get in sync, because every
answer arrives too late. (The above scenario is simplified a bit: The
2 systems do arrive at establishing a connection - albeit taking some
time and several repeats - but for the actual data transfer the above
holds.)

I would be happy if someone could provide answers or hints to the
following questions:
1) How do I make the originating system wait longer before
re-attempting to establish a connection?
2) After a connection is established: How do I make the originating
system wait longer for the arrival of the requested data before doing
a re-request?
3) This is a guess: At the other end (the destination of the original
request) I will probably have to wait longer for an acknowledge, too.

Any hints will be greatly appreciated - it's so frustrating, to have
the communication working in principle but not in practice, just
because you can't tell some component: Hey, be patient, data will
arrive eventually.
Best regards
Helmut Giese



Tue, 21 Aug 2007 06:58:36 GMT  
 (OT) Need to make TCP/IP really slooooow

Quote:

> I have a somewhat strange need: slow down TCP/IP.

I can think of two options off the top of my head:

1. Tweak the kernels of the machines to use a longer retransmit time.
The default for eth* on my machines is 99 * USER_HZ = .99 seconds.
Set this with:
  sysctl net.ipv4.neigh.IFNAME.retrans_time=NNNN

(Where IFNAME is the name of your interface, and NNNN is the number of
USER_HZ jiffies -- each jiffy is 0.01 sec on a stock kernel.)

2. Instead of routing the packets, write a userland app to relay them.
This will require that you specify which ports to relay, though.

Good luck.



Tue, 21 Aug 2007 12:22:19 GMT  
 (OT) Need to make TCP/IP really slooooow

Quote:


>> I have a somewhat strange need: slow down TCP/IP.
> I can think of two options off the top of my head:
> 1. Tweak the kernels of the machines to use a longer retransmit time.
> The default for eth* on my machines is 99 * USER_HZ = .99 seconds.
> Set this with:
>   sysctl net.ipv4.neigh.IFNAME.retrans_time=NNNN

> (Where IFNAME is the name of your interface, and NNNN is the number of
> USER_HZ jiffies -- each jiffy is 0.01 sec on a stock kernel.)

> 2. Instead of routing the packets, write a userland app to relay them.
> This will require that you specify which ports to relay, though.

also:
perhaps it would be better all the way to use not relayed
ethernet-protocol (via tan), but something more ppp-like
over the serial line?

I've once read some more or less funny RFC about IP via
aviation (birds!). Now if this is really manageable with
timeouts and such, then powerline should, too :-)



Tue, 21 Aug 2007 21:18:41 GMT  
 (OT) Need to make TCP/IP really slooooow
On 04 Mar 2005 13:18:41 GMT, Andreas Leitgeb

Quote:

>also:
>perhaps it would be better all the way to use not relayed
>ethernet-protocol (via tan), but something more ppp-like
>over the serial line?

>I've once read some more or less funny RFC about IP via
>aviation (birds!). Now if this is really manageable with
>timeouts and such, then powerline should, too :-)

You probably mean RFC 1149, issued on April 1, 1990. It talks about
"Avian carriers" - and it got implemented, too, as pigeonware,
currently at version 0.15 (sorry, lost the URL).
Best regards
Helmut Giese


Tue, 21 Aug 2007 22:11:55 GMT  
 (OT) Need to make TCP/IP really slooooow
On Thu, 03 Mar 2005 23:22:19 -0500, David Cuthbert <"dacut at kanga

Quote:


>> I have a somewhat strange need: slow down TCP/IP.

>I can think of two options off the top of my head:

>1. Tweak the kernels of the machines to use a longer retransmit time.
>The default for eth* on my machines is 99 * USER_HZ = .99 seconds.
>Set this with:
>  sysctl net.ipv4.neigh.IFNAME.retrans_time=NNNN

>(Where IFNAME is the name of your interface, and NNNN is the number of
>USER_HZ jiffies -- each jiffy is 0.01 sec on a stock kernel.)

>2. Instead of routing the packets, write a userland app to relay them.
>This will require that you specify which ports to relay, though.

>Good luck.

I'll need it. According to the local TCP/IP expert it is plainly
impossible to do what we attempted: Passing TCP packets around
_transparently_.
What we should do is write a router. Grrrr, would have been nice to
have had this knowledge some months earlier.
Well then, off to writing a router - I'll start a new thread.
Thanks for your thoughts and best regards
Helmut Giese


Tue, 21 Aug 2007 22:17:33 GMT  
 (OT) Need to make TCP/IP really slooooow

Quote:

> I'll need it. According to the local TCP/IP expert it is plainly
> impossible to do what we attempted: Passing TCP packets around
> _transparently_.

It looks like it's your t3 step that's killing you. You're not
forwarding packets around transparently. You're throwing some away
because you didn't get the answer you wanted.

It sounds like your program either needs to pass through every packet it
gets, or it needs to understand enough TCP to throw away duplicate IP
packets.

In other words, the problem is that TCP stacks don't discard the answer
to the first packet simply because they're waiting for the second
packet. You either need to wait for the answer to the first packet
before sending the second, or you have to deliver the answer to the
first packet even if it arrived after the second packet. Either way,
you're going to have problems unless you get your transmission time up
closer to what the senders expect.

--
   Darren New / San Diego, CA, USA (PST)
     He had a name like someone sneezing with
     a mouth full of alphabet soup...



Wed, 22 Aug 2007 01:14:42 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. OT-Documentation for AWK+TCP/IP in SGML

2. (OT) Configuring TCP/IP related timeouts

3. Help needed for Pathway TCP/IP OCX Control

4. HELP !! Need TCP/IP lib for clipper

5. TCP/IP logon script help needed

6. TCP/IP help needed in Modula II

7. Need TCP/IP Socket Toolkit

8. NEED HELP IN LAT TO TCP/IP CONVERSION

9. Need help with TCP/IP client access from Windows

10. Need TCP/IP extension for TCL

11. US - FL - S.E. ****SMALLTALK/C++ PROGRAMMERS NEEDED NOW (MVS/TSO,COBOL,TCP/IP)****CONTRACT

12. does anyone have an example of a c++ TCP/IP client that works with labview TCP?IP server ??

 

 
Powered by phpBB® Forum Software