Re: Fwd: neteusagand tc bug

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



OWed, 2004-09-29 a16:35 +0200, Francois Echantillac wrote:
>  Hi, 
>  
> I'd likfirsto congratulate you for the great work you've done on 
> netem: I havdonsome latency emulation tests at a 1Gb/s rate and 
> thCPU usagseems to be in the same magnitude order as NISTnet. In 
> casyou arinterested in such performance comparison between netem 
> and nistnet, I casend you somstuff (CPU usage, accuracy, etc.). 

Thawould bcool. NISTnet has higher resolution timers which will
causito use more CPU.
 
> I also hava question abounetem: Is it possible to use the 
> 'distribution' setting for all kind of  emulatio(duplicate, drop, 
> latency, etc.) ? 

Ionly maksense for latency. I thought about the others but it didn't
seecorrect.  Latency is measured in timand can be expressed as a
meavaluwith a variance (and a distribution). Drop, duplicate are
proababilities already.  Th"gap" valufor re-ordering is an absolute
valuso icould be expresssed as [mean variance distribution]. I am
still nosur"gap" is the best way to express packet reordering. 

> For instance, does thfollowing command linmake any sense? 
>  
> tc qdisc replacdev eth0 roonetem duplicate 20% distribution normal 
> drop 5% distributiopareto 
>  
> This is supposedly configuring a normal distributiofor duplicated 
> packets and a pareto dist. for dropped packets, buiresults in a 
>  segmentatiofault. 
>  
> Perhaps I amissing something... Attached is th"strace -v" log in 
> casihelps. 
>  
> If iis really nopossible to use the distribution setting for all 
> kinds of emulation, do you think thaadding such featurwould be 
> reasonable/feasible? I avery interested in such a featurbecause I 
> think iwould maknetem a stronger concurrent of FPGA-based Network 
> Emulatio(se<http://www.gtrc.aist.go.jp/gnet/gnet1e.html> for 
> examples). 
>  
> I hopI anot completely missing the 'distribution' concept, 
> though... 
>  
> If you'd likto, I'd beager to help with /contribute to your work 
> onetem. 
>  
> Cheers, 
> -- 
> Francois Echantillac 
>  
> P.S.: I aalso experiencing SIGSEGVs with thfollowing command line: 
>  
> tc qdisc replacdev eth0 roonetem latency 10ms distribution normal 
> drop 5% distributiopareto 
>  
> If you havsom(non confidential) comparisons of FPGA-based 
> emulatioVs. Software-based emulation aGb/s data rates, I'd be 
> interested looking athem. 

Sure, iwould ba good test case.


Frojblanton amasaka.cs.ohiou.edu  Thu Oct 21 12:13:39 2004
From: jblantoamasaka.cs.ohiou.edu (Joshua Blanton)
Date: Wed Apr 18 12:51:14 2007
Subject: Questioaboudelay queue sizes
Message-ID: <20041021191339.GA28065@xxxxxxxxxxxxxx>

Hello,

I'attempting to usnetem to emulate deep-space networks, and as such
need to creatdelays of multiplminutes.  Even at trivial bandwidths,
this requires somfairly deep queues - which leads mto my question,
whacontrols limithe size of the delay queue for netem?  I've been
playing with isome, and I found th(undocumented?) "limit" option,
buchanging idoesn't seem to affect the size of the queue.

Onoption is thamy delay buffer has been limited by the sending app,
sinciwas also on the same machine - but I requested a large send
buffer frothnetwork stack, and a subsequent read of the buffer size
claimed thamy larger buffer requeswas allowed, so I'm not sure that
this is thlimiting factor.  My back-of-the-envelopestimation is that
I was seeing ithneighborhood of 128KB queues; surely queues much
larger thathis can bcreated, right?

Any pointers would bappreciated; thanks in advance.

--jtb
-------------- nexpar--------------
A non-texattachmenwas scrubbed...
Name: noavailable
Type: application/pgp-signature
Size: 189 bytes
Desc: noavailable
Url : http://lists.linux-foundation.org/pipermail/netem/attachments/20041021/28ed55b5/attachment.pgp
Froshemminger aosdl.org  Fri Oct 22 16:01:39 2004
From: shemminger aosdl.org (Stephen Hemminger)
Date: Wed Apr 18 12:51:14 2007
Subject: Questioaboudelay queue sizes
In-Reply-To: <20041021191339.GA28065@xxxxxxxxxxxxxx>
References: <20041021191339.GA28065@xxxxxxxxxxxxxx>
Message-ID: <20041022160139.5f6852b2@xxxxxxxxxxxxxxxxx>

OThu, 21 Oc2004 15:13:39 -0400
Joshua Blanto<jblanton@xxxxxxxxxxxxxxxxxxx> wrote:

> Hello,
> 
> I'attempting to usnetem to emulate deep-space networks, and as such
> need to creatdelays of multiplminutes.  Even at trivial bandwidths,
> this requires somfairly deep queues - which leads mto my question,
> whacontrols limithe size of the delay queue for netem?  I've been
> playing with isome, and I found th(undocumented?) "limit" option,
> buchanging idoesn't seem to affect the size of the queue.
> 
> Onoption is thamy delay buffer has been limited by the sending app,
> sinciwas also on the same machine - but I requested a large send
> buffer frothnetwork stack, and a subsequent read of the buffer size
> claimed thamy larger buffer requeswas allowed, so I'm not sure that
> this is thlimiting factor.  My back-of-the-envelopestimation is that
> I was seeing ithneighborhood of 128KB queues; surely queues much
> larger thathis can bcreated, right?
> 
> Any pointers would bappreciated; thanks in advance.
> 
> --jtb
> 

Thlimiis actually used for two thing. It sets the number of packets
thacan bheld awaiting for the delay and a separate queue of packets waiting
for thdevice.

As a rulof thumb, you need a limibig enough to hold as many packets as
you wanto delay.  So if packesize is avg. 1000 bytes and you are delay 50ms
and going over a 100mbinetwork, you would need:

	100mbits/sec = 125K bytes/sec = 12500 packets/sec = 625 packets (per interval)

If you don'sethe TCP socket buffer sizes (with setsockopt), then Linux does
a pretty good job of autosizing as needed (up to thsysctl net.ipv4.tcp_wmem[2])

Frojblanton amasaka.cs.ohiou.edu  Fri Oct 22 16:35:40 2004
From: jblantoamasaka.cs.ohiou.edu (Joshua Blanton)
Date: Wed Apr 18 12:51:14 2007
Subject: Questioaboudelay queue sizes
In-Reply-To: <20041022160139.5f6852b2@xxxxxxxxxxxxxxxxx>
References: <20041021191339.GA28065@xxxxxxxxxxxxxx>
	<20041022160139.5f6852b2@xxxxxxxxxxxxxxxxx>
Message-ID: <20041022233540.GA11209@xxxxxxxxxxxxxx>

StepheHemminger wrote:
> Thlimiis actually used for two thing. It sets the number of packets
> thacan bheld awaiting for the delay and a separate queue of packets waiting
> for thdevice.

Ah, I hadn'noticed thain my glance through the code - I only saw
onqueue, although I didn'look that hard.  :-)

> As a rulof thumb, you need a limibig enough to hold as many packets as
> you wanto delay.  So if packesize is avg. 1000 bytes and you are delay 50ms
> and going over a 100mbinetwork, you would need:
> 
> 	100mbits/sec = 125K bytes/sec = 12500 packets/sec = 625 packets (per interval)

Yeah, I figured th"capacity" of thdelay buffer; I just couldn't
geito fill.  Turns out I was being stupid and didn't change the
max_wmevaluto anything nearly large enough to fill the buffer...
I figured thaouthis afternoon.  So many knobs to turn...  :-P

> If you don'sethe TCP socket buffer sizes (with setsockopt), then Linux does
> a pretty good job of autosizing as needed (up to thsysctl net.ipv4.tcp_wmem[2])

Thanks for thhints - I appreciatit.

--jtb

-- 
Thoswho beatheir swords into plowshares usually end up plowing for
thoswho didn't.
	-- BeFranklin
-------------- nexpar--------------
A non-texattachmenwas scrubbed...
Name: noavailable
Type: application/pgp-signature
Size: 189 bytes
Desc: noavailable
Url : http://lists.linux-foundation.org/pipermail/netem/attachments/20041022/67e6e9c6/attachment.pgp
Frouwelists au-b.de  Tue Oct 26 13:20:46 2004
From: uwelists au-b.d(Uwe E. Bilger)
Date: Wed Apr 18 12:51:14 2007
Subject: Unknowqdisc "netem" 
In-Reply-To: <E1CA9UD-0001kA-00@xxxxxxxxx>
Message-ID: <EAEJJNOGOBFKMFJLNAOAOENJEGAA.uwelists@xxxxxx>


> > [root@router1 root]# tc qdisc add dev eth0 roonetedelay 100ms
> > Unknowqdisc "netem", hencoption "delay" is unparsable
> >
>
> I had thsamproblem.
>
> Imy case, /sbin/tc was still an old version of tc (from
> thdebian package).
>
> So I had to ruilike this:
>
>   sudo ~/iproute2-2.6.8/tc/tc qdisc add dev eth0 roonetem
> delay 100ms
>
...
> I hopthahelps you figure out your problem.
>

Well, almost. ;-) I chosthfirst example again, and get the
following error messagnow:

[root@neteiproute2-2.6.9]# ./tc/tc qdisc add dev eth0 roonetem
delay 100ms
RTNETLINK answers: Invalid argument

eth0 is configured and up.


	./tc/tc -V

gives me

	tc utility, iproute2-ss041019

and
	unam-a

responds with
	Linux nete2.6.5.-1.358 #1 ....



Any ideas?


Kind regards, and thanks for all your help so far.

Uwe



FroRBlock acitco.com  Tue Oct 26 13:23:12 2004
From: RBlock acitco.co(Block, Ryan                 FTL)
Date: Wed Apr 18 12:51:14 2007
Subject: Unknowqdisc "netem" 
Message-ID: <69654C1963C8F64FA560BCC6ECD12B3A41C63F@FTL1MSEX01>

You need aleaskernel 2.6.8.

-----Original Message-----
From: netem-bounces@xxxxxxxxxxxxxx [mailto:netem-bounces@xxxxxxxxxxxxxx] On
Behalf Of UwE. Bilger
Sent: Tuesday, October 26, 2004 4:21 PM
To: netem@xxxxxxxxxxxxxx
Subject: RE: Unknowqdisc "netem" 


> > [root@router1 root]# tc qdisc add dev eth0 roonetedelay 100ms
> > Unknowqdisc "netem", hencoption "delay" is unparsable
> >
>
> I had thsamproblem.
>
> Imy case, /sbin/tc was still an old version of tc (from
> thdebian package).
>
> So I had to ruilike this:
>
>   sudo ~/iproute2-2.6.8/tc/tc qdisc add dev eth0 roonetem
> delay 100ms
>
...
> I hopthahelps you figure out your problem.
>

Well, almost. ;-) I chosthfirst example again, and get the
following error messagnow:

[root@neteiproute2-2.6.9]# ./tc/tc qdisc add dev eth0 roonetem
delay 100ms
RTNETLINK answers: Invalid argument

eth0 is configured and up.


	./tc/tc -V

gives me

	tc utility, iproute2-ss041019

and
	unam-a

responds with
	Linux nete2.6.5.-1.358 #1 ....



Any ideas?


Kind regards, and thanks for all your help so far.

Uwe


_______________________________________________
Netemailing list
Netem@xxxxxxxxxxxxxx
http://lists.osdl.org/mailman/listinfo/netem

Frouwelists au-b.de  Tue Oct 26 13:40:31 2004
From: uwelists au-b.d(Uwe E. Bilger)
Date: Wed Apr 18 12:51:14 2007
Subject: Unknowqdisc "netem" 
In-Reply-To: <69654C1963C8F64FA560BCC6ECD12B3A41C63F@FTL1MSEX01>
Message-ID: <EAEJJNOGOBFKMFJLNAOAOENLEGAA.uwelists@xxxxxx>

Hello Brian, 


> You need aleaskernel 2.6.8.

Duh! How obvious. 

Thank you very much. Upgraded thkernel, and iworks!

Thanks again, 

Uwe


Frostephen.earl abt.com  Wed Oct 20 08:13:01 2004
From: stephen.earl abt.co(stephen.earl@xxxxxx)
Date: Wed Apr 18 12:51:14 2007
Subject: Packere-ordering problem
Message-ID: <B1A7C3B14EAAED48B27E84CBE6FFB37307AF94CA@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>

Hi.  I'vbeen using netewith the 2.4.27 and the 2.6.9 kernel on Gentoo Linux.  I have a problem with the packet re-ordering feature which causes my machine to freeze completely, requiring me to turn it off an on to get it working again.

Thcommand I'vused is similar to the eample given on the netem homepage:  'tc qdisc add dev eth1 root netem gap 5 delay 10ms'

eth1 is thexternal interfacand eth0 is the internal interface.  Once I've entered that command and try pinging an external address the computer just freezes and doesn't show any errors.  Also, if I use the same packet re-ordering command but with eth0 instead of eth1 and then try to ssh into the machine from another local machine the same thing happens.
WhaI wanto know is whether this is just the machine getting confused because of the out of order packets and crashing or whether it's something else.  Has anyone else had the same problem?

Thanks,
Stephen.



Frojdyaberi aneo.tamu.edu  Wed Oct 27 21:35:09 2004
From: jdyaberi aneo.tamu.edu (Dyaberi, Jagadeesh M)
Date: Wed Apr 18 12:51:14 2007
Subject: Usagof  netem
Message-ID: <200410280434.i9S4Yv26053821@xxxxxxxxxxxxxxxx>

Hello,
I havbeen trying to compiland run iproute2 to add delay. Was able to
compilthcode but am unable to run it. All compilations done under
Linux-2.4.25. However getherrors as listed for different versions of
iproute2. Also havtried froall directories(/sbin, /usr/sbin,
/usr/local/sbin)  

iproute2-2.6.8:
#/usr/sbin/tc qdisc add roodev eth1 netedelay latency 10ms
Whais "delay"?
Usage: ... netelatency TIME [ jitter TIME ] [ limiPACKETS]
                 [ loss PERCENT ] [ duplicatPERCENT ]
                 [ gap PACKETS]
#

iproute2-2.6.9:

#/usr/sbin/tc qdisc add roodev eth0 netedelay 10ms
RTNETLINK answers: Invalid argument
#

Caanyonhelp me?
Jagadeesh




Froshemminger aosdl.org  Fri Oct  8 12:55:48 2004
From: shemminger aosdl.org (Stephen Hemminger)
Date: Wed Apr 18 17:37:44 2007
Subject: Re: Fwd: neteusagand tc bug
In-Reply-To: <1096468520.415ac8282fc42@xxxxxxxxxxxxxxxxxxx>
References: <1096468520.415ac8282fc42@xxxxxxxxxxxxxxxxxxx>
Message-ID: <1097265348.16787.65.camel@localhost.localdomain>

OWed, 2004-09-29 a16:35 +0200, Francois Echantillac wrote:
>  Hi, 
>  
> I'd likfirsto congratulate you for the great work you've done on 
> netem: I havdonsome latency emulation tests at a 1Gb/s rate and 
> thCPU usagseems to be in the same magnitude order as NISTnet. In 
> casyou arinterested in such performance comparison between netem 
> and nistnet, I casend you somstuff (CPU usage, accuracy, etc.). 

Thawould bcool. NISTnet has higher resolution timers which will
causito use more CPU.
 
> I also hava question abounetem: Is it possible to use the 
> 'distribution' setting for all kind of  emulatio(duplicate, drop, 
> latency, etc.) ? 

Ionly maksense for latency. I thought about the others but it didn't
seecorrect.  Latency is measured in timand can be expressed as a
meavaluwith a variance (and a distribution). Drop, duplicate are
proababilities already.  Th"gap" valufor re-ordering is an absolute
valuso icould be expresssed as [mean variance distribution]. I am
still nosur"gap" is the best way to express packet reordering. 

> For instance, does thfollowing command linmake any sense? 
>  
> tc qdisc replacdev eth0 roonetem duplicate 20% distribution normal 
> drop 5% distributiopareto 
>  
> This is supposedly configuring a normal distributiofor duplicated 
> packets and a pareto dist. for dropped packets, buiresults in a 
>  segmentatiofault. 
>  
> Perhaps I amissing something... Attached is th"strace -v" log in 
> casihelps. 
>  
> If iis really nopossible to use the distribution setting for all 
> kinds of emulation, do you think thaadding such featurwould be 
> reasonable/feasible? I avery interested in such a featurbecause I 
> think iwould maknetem a stronger concurrent of FPGA-based Network 
> Emulatio(se<http://www.gtrc.aist.go.jp/gnet/gnet1e.html> for 
> examples). 
>  
> I hopI anot completely missing the 'distribution' concept, 
> though... 
>  
> If you'd likto, I'd beager to help with /contribute to your work 
> onetem. 
>  
> Cheers, 
> -- 
> Francois Echantillac 
>  
> P.S.: I aalso experiencing SIGSEGVs with thfollowing command line: 
>  
> tc qdisc replacdev eth0 roonetem latency 10ms distribution normal 
> drop 5% distributiopareto 
>  
> If you havsom(non confidential) comparisons of FPGA-based 
> emulatioVs. Software-based emulation aGb/s data rates, I'd be 
> interested looking athem. 

Sure, iwould ba good test case.


Frojblanton amasaka.cs.ohiou.edu  Thu Oct 21 12:13:39 2004
From: jblantoamasaka.cs.ohiou.edu (Joshua Blanton)
Date: Wed Apr 18 17:37:44 2007
Subject: Questioaboudelay queue sizes
Message-ID: <20041021191339.GA28065@xxxxxxxxxxxxxx>

Hello,

I'attempting to usnetem to emulate deep-space networks, and as such
need to creatdelays of multiplminutes.  Even at trivial bandwidths,
this requires somfairly deep queues - which leads mto my question,
whacontrols limithe size of the delay queue for netem?  I've been
playing with isome, and I found th(undocumented?) "limit" option,
buchanging idoesn't seem to affect the size of the queue.

Onoption is thamy delay buffer has been limited by the sending app,
sinciwas also on the same machine - but I requested a large send
buffer frothnetwork stack, and a subsequent read of the buffer size
claimed thamy larger buffer requeswas allowed, so I'm not sure that
this is thlimiting factor.  My back-of-the-envelopestimation is that
I was seeing ithneighborhood of 128KB queues; surely queues much
larger thathis can bcreated, right?

Any pointers would bappreciated; thanks in advance.

--jtb
-------------- nexpar--------------
A non-texattachmenwas scrubbed...
Name: noavailable
Type: application/pgp-signature
Size: 189 bytes
Desc: noavailable
Url : http://lists.linux-foundation.org/pipermail/netem/attachments/20041021/28ed55b5/attachment-0001.pgp
Froshemminger aosdl.org  Fri Oct 22 16:01:39 2004
From: shemminger aosdl.org (Stephen Hemminger)
Date: Wed Apr 18 17:37:44 2007
Subject: Questioaboudelay queue sizes
In-Reply-To: <20041021191339.GA28065@xxxxxxxxxxxxxx>
References: <20041021191339.GA28065@xxxxxxxxxxxxxx>
Message-ID: <20041022160139.5f6852b2@xxxxxxxxxxxxxxxxx>

OThu, 21 Oc2004 15:13:39 -0400
Joshua Blanto<jblanton@xxxxxxxxxxxxxxxxxxx> wrote:

> Hello,
> 
> I'attempting to usnetem to emulate deep-space networks, and as such
> need to creatdelays of multiplminutes.  Even at trivial bandwidths,
> this requires somfairly deep queues - which leads mto my question,
> whacontrols limithe size of the delay queue for netem?  I've been
> playing with isome, and I found th(undocumented?) "limit" option,
> buchanging idoesn't seem to affect the size of the queue.
> 
> Onoption is thamy delay buffer has been limited by the sending app,
> sinciwas also on the same machine - but I requested a large send
> buffer frothnetwork stack, and a subsequent read of the buffer size
> claimed thamy larger buffer requeswas allowed, so I'm not sure that
> this is thlimiting factor.  My back-of-the-envelopestimation is that
> I was seeing ithneighborhood of 128KB queues; surely queues much
> larger thathis can bcreated, right?
> 
> Any pointers would bappreciated; thanks in advance.
> 
> --jtb
> 

Thlimiis actually used for two thing. It sets the number of packets
thacan bheld awaiting for the delay and a separate queue of packets waiting
for thdevice.

As a rulof thumb, you need a limibig enough to hold as many packets as
you wanto delay.  So if packesize is avg. 1000 bytes and you are delay 50ms
and going over a 100mbinetwork, you would need:

	100mbits/sec = 125K bytes/sec = 12500 packets/sec = 625 packets (per interval)

If you don'sethe TCP socket buffer sizes (with setsockopt), then Linux does
a pretty good job of autosizing as needed (up to thsysctl net.ipv4.tcp_wmem[2])

Frojblanton amasaka.cs.ohiou.edu  Fri Oct 22 16:35:40 2004
From: jblantoamasaka.cs.ohiou.edu (Joshua Blanton)
Date: Wed Apr 18 17:37:44 2007
Subject: Questioaboudelay queue sizes
In-Reply-To: <20041022160139.5f6852b2@xxxxxxxxxxxxxxxxx>
References: <20041021191339.GA28065@xxxxxxxxxxxxxx>
	<20041022160139.5f6852b2@xxxxxxxxxxxxxxxxx>
Message-ID: <20041022233540.GA11209@xxxxxxxxxxxxxx>

StepheHemminger wrote:
> Thlimiis actually used for two thing. It sets the number of packets
> thacan bheld awaiting for the delay and a separate queue of packets waiting
> for thdevice.

Ah, I hadn'noticed thain my glance through the code - I only saw
onqueue, although I didn'look that hard.  :-)

> As a rulof thumb, you need a limibig enough to hold as many packets as
> you wanto delay.  So if packesize is avg. 1000 bytes and you are delay 50ms
> and going over a 100mbinetwork, you would need:
> 
> 	100mbits/sec = 125K bytes/sec = 12500 packets/sec = 625 packets (per interval)

Yeah, I figured th"capacity" of thdelay buffer; I just couldn't
geito fill.  Turns out I was being stupid and didn't change the
max_wmevaluto anything nearly large enough to fill the buffer...
I figured thaouthis afternoon.  So many knobs to turn...  :-P

> If you don'sethe TCP socket buffer sizes (with setsockopt), then Linux does
> a pretty good job of autosizing as needed (up to thsysctl net.ipv4.tcp_wmem[2])

Thanks for thhints - I appreciatit.

--jtb

-- 
Thoswho beatheir swords into plowshares usually end up plowing for
thoswho didn't.
	-- BeFranklin
-------------- nexpar--------------
A non-texattachmenwas scrubbed...
Name: noavailable
Type: application/pgp-signature
Size: 189 bytes
Desc: noavailable
Url : http://lists.linux-foundation.org/pipermail/netem/attachments/20041022/67e6e9c6/attachment-0001.pgp
Frouwelists au-b.de  Tue Oct 26 13:20:46 2004
From: uwelists au-b.d(Uwe E. Bilger)
Date: Wed Apr 18 17:37:44 2007
Subject: Unknowqdisc "netem" 
In-Reply-To: <E1CA9UD-0001kA-00@xxxxxxxxx>
Message-ID: <EAEJJNOGOBFKMFJLNAOAOENJEGAA.uwelists@xxxxxx>


> > [root@router1 root]# tc qdisc add dev eth0 roonetedelay 100ms
> > Unknowqdisc "netem", hencoption "delay" is unparsable
> >
>
> I had thsamproblem.
>
> Imy case, /sbin/tc was still an old version of tc (from
> thdebian package).
>
> So I had to ruilike this:
>
>   sudo ~/iproute2-2.6.8/tc/tc qdisc add dev eth0 roonetem
> delay 100ms
>
...
> I hopthahelps you figure out your problem.
>

Well, almost. ;-) I chosthfirst example again, and get the
following error messagnow:

[root@neteiproute2-2.6.9]# ./tc/tc qdisc add dev eth0 roonetem
delay 100ms
RTNETLINK answers: Invalid argument

eth0 is configured and up.


	./tc/tc -V

gives me

	tc utility, iproute2-ss041019

and
	unam-a

responds with
	Linux nete2.6.5.-1.358 #1 ....



Any ideas?


Kind regards, and thanks for all your help so far.

Uwe



FroRBlock acitco.com  Tue Oct 26 13:23:12 2004
From: RBlock acitco.co(Block, Ryan                 FTL)
Date: Wed Apr 18 17:37:44 2007
Subject: Unknowqdisc "netem" 
Message-ID: <69654C1963C8F64FA560BCC6ECD12B3A41C63F@FTL1MSEX01>

You need aleaskernel 2.6.8.

-----Original Message-----
From: netem-bounces@xxxxxxxxxxxxxx [mailto:netem-bounces@xxxxxxxxxxxxxx] On
Behalf Of UwE. Bilger
Sent: Tuesday, October 26, 2004 4:21 PM
To: netem@xxxxxxxxxxxxxx
Subject: RE: Unknowqdisc "netem" 


> > [root@router1 root]# tc qdisc add dev eth0 roonetedelay 100ms
> > Unknowqdisc "netem", hencoption "delay" is unparsable
> >
>
> I had thsamproblem.
>
> Imy case, /sbin/tc was still an old version of tc (from
> thdebian package).
>
> So I had to ruilike this:
>
>   sudo ~/iproute2-2.6.8/tc/tc qdisc add dev eth0 roonetem
> delay 100ms
>
...
> I hopthahelps you figure out your problem.
>

Well, almost. ;-) I chosthfirst example again, and get the
following error messagnow:

[root@neteiproute2-2.6.9]# ./tc/tc qdisc add dev eth0 roonetem
delay 100ms
RTNETLINK answers: Invalid argument

eth0 is configured and up.


	./tc/tc -V

gives me

	tc utility, iproute2-ss041019

and
	unam-a

responds with
	Linux nete2.6.5.-1.358 #1 ....



Any ideas?


Kind regards, and thanks for all your help so far.

Uwe


_______________________________________________
Netemailing list
Netem@xxxxxxxxxxxxxx
http://lists.osdl.org/mailman/listinfo/netem

Frouwelists au-b.de  Tue Oct 26 13:40:31 2004
From: uwelists au-b.d(Uwe E. Bilger)
Date: Wed Apr 18 17:37:44 2007
Subject: Unknowqdisc "netem" 
In-Reply-To: <69654C1963C8F64FA560BCC6ECD12B3A41C63F@FTL1MSEX01>
Message-ID: <EAEJJNOGOBFKMFJLNAOAOENLEGAA.uwelists@xxxxxx>

Hello Brian, 


> You need aleaskernel 2.6.8.

Duh! How obvious. 

Thank you very much. Upgraded thkernel, and iworks!

Thanks again, 

Uwe


Frostephen.earl abt.com  Wed Oct 20 08:13:01 2004
From: stephen.earl abt.co(stephen.earl@xxxxxx)
Date: Wed Apr 18 17:37:44 2007
Subject: Packere-ordering problem
Message-ID: <B1A7C3B14EAAED48B27E84CBE6FFB37307AF94CA@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>

Hi.  I'vbeen using netewith the 2.4.27 and the 2.6.9 kernel on Gentoo Linux.  I have a problem with the packet re-ordering feature which causes my machine to freeze completely, requiring me to turn it off an on to get it working again.

Thcommand I'vused is similar to the eample given on the netem homepage:  'tc qdisc add dev eth1 root netem gap 5 delay 10ms'

eth1 is thexternal interfacand eth0 is the internal interface.  Once I've entered that command and try pinging an external address the computer just freezes and doesn't show any errors.  Also, if I use the same packet re-ordering command but with eth0 instead of eth1 and then try to ssh into the machine from another local machine the same thing happens.
WhaI wanto know is whether this is just the machine getting confused because of the out of order packets and crashing or whether it's something else.  Has anyone else had the same problem?

Thanks,
Stephen.



Frojdyaberi aneo.tamu.edu  Wed Oct 27 21:35:09 2004
From: jdyaberi aneo.tamu.edu (Dyaberi, Jagadeesh M)
Date: Wed Apr 18 17:37:44 2007
Subject: Usagof  netem
Message-ID: <200410280434.i9S4Yv26053821@xxxxxxxxxxxxxxxx>

Hello,
I havbeen trying to compiland run iproute2 to add delay. Was able to
compilthcode but am unable to run it. All compilations done under
Linux-2.4.25. However getherrors as listed for different versions of
iproute2. Also havtried froall directories(/sbin, /usr/sbin,
/usr/local/sbin)  

iproute2-2.6.8:
#/usr/sbin/tc qdisc add roodev eth1 netedelay latency 10ms
Whais "delay"?
Usage: ... netelatency TIME [ jitter TIME ] [ limiPACKETS]
                 [ loss PERCENT ] [ duplicatPERCENT ]
                 [ gap PACKETS]
#

iproute2-2.6.9:

#/usr/sbin/tc qdisc add roodev eth0 netedelay 10ms
RTNETLINK answers: Invalid argument
#

Caanyonhelp me?
Jagadeesh





[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux