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
