artificial latency for a network interface

artificial latency for a network interface

[Andreas Schuldei]

to simulate a sattelite link, I need to add a latency to a
network connection. 

What is the easiest and best way to do that?

I wanted to do that using two tun devices. 
I had hoped to have a routing like this:

 <-> eth0 <-> tun0 <-> userspace, waiting queue <-> tun1 <-> eth1

I need to do it this way and not with iptables help, because it
needs to work also on 2.2.x kernels.

Now I started experimenting with the tun0 interfaces and got
problems: till now I have not succeeded to get a tun0 interface
up. the example code (br_select.c) in the package (as found for
example on sourceforge) looks fishy and does not work too well. 
is it correct that only one /dev/tun file is necessary, but
/dev/tun0 and tun1 are opend for reading and writing?

I also did not manage to point any routes at tun0 or tun1. thoes
interfaces do not show up in the /proc/net/dev either.

only the module is loaded.

I seem to miss something. who has used those devices before and
got them working and could help me debug this?

artificial latency for a network interface

[David McWherter]

I once solved this problem using the QoS qdisc facilites:

 http://edge.mcs.drexel.edu/GICL/people/udmcwher/dnt/DNT.html

It works on 2.2 kernels as well.

-david

Andreas Schuldei writes:
 > to simulate a sattelite link, I need to add a latency to a
 > network connection. 
 > 
 > What is the easiest and best way to do that?
 > 
 > I wanted to do that using two tun devices. 
 > I had hoped to have a routing like this:
 > 
 >  <-> eth0 <-> tun0 <-> userspace, waiting queue <-> tun1 <-> eth1
 > 
 > I need to do it this way and not with iptables help, because it
 > needs to work also on 2.2.x kernels.
 > 
 > Now I started experimenting with the tun0 interfaces and got
 > problems: till now I have not succeeded to get a tun0 interface
 > up. the example code (br_select.c) in the package (as found for
 > example on sourceforge) looks fishy and does not work too well. 
 > is it correct that only one /dev/tun file is necessary, but
 > /dev/tun0 and tun1 are opend for reading and writing?

----------------------[=========]------------------------
David T. McWherter                udmcwher@mcs.drexel.edu

My religion consists of a humble admiration of the illimitable superior
spirit who reveals himself in the slight details we are able to perceive
with our frail and feeble mind.
		-- Albert Einstein

Re: artificial latency for a network interface

[Andrew Morton]

Andreas Schuldei wrote:
> 
> to simulate a sattelite link, I need to add a latency to a
> network connection.
> 
> What is the easiest and best way to do that?
> 
> I wanted to do that using two tun devices.
> I had hoped to have a routing like this:
> 
>  <-> eth0 <-> tun0 <-> userspace, waiting queue <-> tun1 <-> eth1

yes, that works very well.  A userspace app sits on top of the
tun/tap device and pulls out packets, delays them and reinjects
them.

The problem is routing: when you send the packet back to the
kernel, it sends it straight back to you.  You need to rewrite
the headers, which is a pain.

A simpler approach is to use policy routing - use the source
and destination devices to override the IP addresses.  Works
well.  The code is at

	http://www.uow.edu.au/~andrewm/packet-delay.tar.gz

It has its own variable bandwidth management as well
as variable latency.  It's for simulating narrowband, high
latency connections.

Re: artificial latency for a network interface

[Burkhard Daniel]

I had a similiar problem once, and wrote a module that overwrote the
loopback net device. Since it's loopback, the kernel won't care about
headers.

Yeah, I know: Quick & Dirty.

I made the new loopback put its packets in a queue and then deliver them
after a (adjustable) delay.

If I can still find the source for this, I'll post it here.

Burk.

On Fri, 29 Jun 2001, Andrew Morton wrote:

> Andreas Schuldei wrote:
> > 
> > to simulate a sattelite link, I need to add a latency to a
> > network connection.
> > 
> > What is the easiest and best way to do that?
> > 
> > I wanted to do that using two tun devices.
> > I had hoped to have a routing like this:
> > 
> >  <-> eth0 <-> tun0 <-> userspace, waiting queue <-> tun1 <-> eth1
> 
> yes, that works very well.  A userspace app sits on top of the
> tun/tap device and pulls out packets, delays them and reinjects
> them.
> 
> The problem is routing: when you send the packet back to the
> kernel, it sends it straight back to you.  You need to rewrite
> the headers, which is a pain.
> 
> A simpler approach is to use policy routing - use the source
> and destination devices to override the IP addresses.  Works
> well.  The code is at
> 
> 	http://www.uow.edu.au/~andrewm/packet-delay.tar.gz
> 
> It has its own variable bandwidth management as well
> as variable latency.  It's for simulating narrowband, high
> latency connections.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: artificial latency for a network interface

[Pekka Pietikainen]

On Thu, Jun 28, 2001 at 11:29:38PM -0500, Burkhard Daniel wrote:
> I had a similiar problem once, and wrote a module that overwrote the
> loopback net device. Since it's loopback, the kernel won't care about
> headers.
> 
> Yeah, I know: Quick & Dirty.
> 
> I made the new loopback put its packets in a queue and then deliver them
> after a (adjustable) delay.
> 
> If I can still find the source for this, I'll post it here.
> 
And for something with a lot more options, try
http://www.antd.nist.gov/nistnet.

Works great, lets you drop packets, have variable latency, simulate
congestion, almost everything you need to simulate networks.
Even has a nice GUI to tune it all ;)

Re: artificial latency for a network interface

[Maksim Krasnyanskiy]

> > I wanted to do that using two tun devices.
> > I had hoped to have a routing like this:
> > 
> >  <-> eth0 <-> tun0 <-> userspace, waiting queue <-> tun1 <-> eth1
>
>yes, that works very well.  A userspace app sits on top of the
>tun/tap device and pulls out packets, delays them and reinjects
>them.
Right. And you don't even need tun1. Just write them back to tun0.

>The problem is routing: when you send the packet back to the
>kernel, it sends it straight back to you.  You need to rewrite
>the headers, which is a pain.
True.

Max

Maksim Krasnyanskiy	
Senior Kernel Engineer
Qualcomm Incorporated

maxk@qualcomm.com
http://bluez.sf.net
http://vtun.sf.net