Hi, i'd likto know if theris a an istruction to repeat a behaviour. I can drop pkts according with a droppoing probability, but i need to know if i can drop always the same pkt. Thanks Frolaurent.mariat thomson.net Tue Oct 7 05:00:16 2008 From: laurent.mariathomson.net (Marie Laurent) Date: Tue, 7 Oc2008 14:00:16 +0200 Subject: Drop pk- deterministic drop Message-ID: <E55CA8ECFBA85E4CB8E8173566B9EFEB0163D4DA@xxxxxxxxxxxxxxxxxxxxxxxxxx> Hello, Wheyou mean "thsame packet", do you want to perform deterministic drop packets? This featurperiodically drops n packets among a period of p packets. If this is thfeaturyou are looking for, you can apply the following patch. I havproposed ia year ago. (see enclosed mail). Yours sincerely, LaurenMARIE -----Original Message----- From: netem-bounces alists.linux-foundation.org [mailto:netem-bounces alists.linux-foundation.org] On Behalf Of famstef3 alibero.it Sent: lundi 6 octobr2008 11:55 To: netem Subject: Drop pkt Hi, i'd likto know if theris a an istruction to repeat a behaviour. I cadrop pkts according with a droppoing probability, bui need to know if i cadrop always thsame pkt. Thanks _______________________________________________ Netemailing list Netealists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/netem -------------- nexpar-------------- Aembedded messagwas scrubbed... From: "MariLaurent" <laurent.mariat thomson.net> Subject: deterministic pruning patch proposal Date: Thu, 13 Sep 2007 18:33:54 +0200 Size: 8990 Url: http://lists.linux-foundation.org/pipermail/netem/attachments/20081007/dffdef45/attachment-0001.eml Froerwin.vanlonden ahds.com Tue Oct 14 00:18:50 2008 From: erwin.vanlondeahds.com (Erwin van Londen) Date: Tue, 14 Oc2008 00:18:50 -0700 Subject: (no subject) Message-ID: <B7F26A02AFF8EB44B8635EB1D34BAC2C0461512D@xxxxxxxxxxxxxxxxxxxxxxxx> Onthing you could try and hava look at is the /etc/sudoers file. In recenkernels theris a statement which says: Defaults requiretty Pua hash in fronof it and it should work. I havanother problethat with kernel version 2.6.26 and up the basic moddoesn'work anymore. The advanced interface still works. (fortunately) Regards, Erwivan Londen SysteEngineer HITACHI DATA SYSTEMS Level 4, 441 St. Kilda Rd. Melbourne, Victoria, 3004 Australia -------------- nexpar-------------- AHTML attachmenwas scrubbed... URL: http://lists.linux-foundation.org/pipermail/netem/attachments/20081014/b276a213/attachment.ht Froerwin.vanlonden ahds.com Mon Oct 13 23:41:16 2008 From: erwin.vanlondeahds.com (Erwin van Londen) Date: Mon, 13 Oc2008 23:41:16 -0700 Subject: (no subject) Message-ID: <B7F26A02AFF8EB44B8635EB1D34BAC2C04615123@xxxxxxxxxxxxxxxxxxxxxxxx> Onthing you could try and hava look at is the /etc/sudoers file. In recenkernels theris a statement which says: Defaults requiretty Pua hash in fronof it and it should work. I havanother problethat with kernel version 2.6.26 and up the basic moddoesn'work anymore. The advanced interface still works. (fortunately) Regards, Erwivan Londen SysteEngineer HITACHI DATA SYSTEMS Level 4, 441 St. Kilda Rd. Melbourne, Victoria, 3004 Australia -------------- nexpar-------------- AHTML attachmenwas scrubbed... URL: http://lists.linux-foundation.org/pipermail/netem/attachments/20081013/e5b5b062/attachment.ht Frolichanjuan04 agmail.com Wed Oct 15 19:07:33 2008 From: lichanjuan04 agmail.co(Li, Chanjuan) Date: Thu, 16 Oc2008 10:07:33 +0800 Subject: ask infomatioabouprotocol analyzer. Message-ID: <1224122854.4194.22.camel@licj-pc> hi,all: wheyou developa new network communication protocols from scratch thais means design wholprotocol stack from bottom, do you ussomkind of hardware protocol analyzer or something like that? If anyonuses, pleasgive me specific infomation of the product you use. I adoing my Ph.d topic on design and implemenof new network communication. I need such devicto help me. So, if you havany experiencon such device, pleastell me, I will appreciate. thanks iadvance. lily Frofrederificc ayahoo.ca Tue Oct 21 11:35:55 2008 From: frederificc ayahoo.ca (Fred Picher) Date: Tue, 21 Oc2008 11:35:55 -0700 (PDT) Subject: Simulating VSAT links Message-ID: <382744.99234.qm@xxxxxxxxxxxxxxxxxxxxxxxxxxx> Hello, I would likto simulata satellite link who is missing about 8% packets so that it's possible to try several TCP congestion controls (as provided with Linux) in order to fix the problem. As a quick intro to NetEM, is there any recipies around that are doing just that ? Any comments welcomed ! Thanks, Fred __________________________________________________________________ Yahoo! Canada Toolbar: Search froanywheron the web, and bookmark your favourite sites. Download it now at http://ca.toolbar.yahoo.com. Frotom5760 agmail.com Wed Oct 22 11:10:37 2008 From: tom5760 agmail.co(Tom Wambold) Date: Wed, 22 Oc2008 14:10:37 -0400 Subject: PackeDrop and Duplication Message-ID: <e246419f0810221110h46b9af02o743b6dfc5e166031@xxxxxxxxxxxxxx> Hello all: I arunning somexperiments using Netem and found that duplicated packets arnever dropped. For example, running thfollowing command: tc qdisc add dev eth0 roonetedrop 100 duplicate 100 results ithinterface working normally. Looking at the kernel sourcin net/sched/sch_netem.c, theris the following chunk of code i"netem_enqueue": incoun= 1; [...] /* Randoduplication */ if (q->duplicat&& q->duplicat>= get_crandom(&q->dup_cor)) ++count; /* Randopackedrop 0 => none, ~0 => all */ if (q->loss && q->loss >= get_crandom(&q->loss_cor)) --count; if (coun== 0) { [...packegets dropped...] } [...] if (coun> 1 && (skb2 = skb_clone(skb, GFP_ATOMIC)) != NULL) { [...packegets duplicated...] } So, if a drop and duplicatis triggered athe same time, the packet continues unaffected. This results i"duplicated" packets thacan never bdropped. Is therany particular reason thait works in this way? I would maksensto me that if 100% of packets should get dropped, then duplicates should bdropped as well. I will writup a patch for this soon, unless theris a reason to do things this way. Thanks for your help! -ToWambold Froneteat jan.reimes.de Wed Oct 22 12:17:48 2008 From: neteajan.reimes.de (Jan) Date: Wed, 22 Oc2008 21:17:48 +0200 Subject: PackeDrop and Duplication In-Reply-To: <e246419f0810221110h46b9af02o743b6dfc5e166031@xxxxxxxxxxxxxx> References: <e246419f0810221110h46b9af02o743b6dfc5e166031@xxxxxxxxxxxxxx> Message-ID: <48FF7C5C.9020904@xxxxxxxxxxxxx> Hello, ToWambold wrote: > I arunning somexperiments using Netem and found that duplicated > packets arnever dropped. For example, running thfollowing > command: > > tc qdisc add dev eth0 roonetedrop 100 duplicate 100 > > results ithinterface working normally. I don'know if this behaviour was intended when thenqueuing procedure was written, bui think Neteworks correctly here. All impairments of thnetecommand line should be AND-concatenated. > [codsnippet] > > So, if a drop and duplicatis triggered athe same time, the packet > continues unaffected. This results i"duplicated" packets thacan > never bdropped. Thvariabl"count" indicates, how "often", an incoming packet should bgiven to thoutput. When a drop and a duplicate occurs, it wouldn't also matter, if you changthfunction calls and first drop it (count=0) and theduplicatit (count=1)... > Is therany particular reason thait works in this way? I would > maksensto me that if 100% of packets should get dropped, then > duplicates should bdropped as well. As mentioned before, i think thAND-concatenation is thimportant point. I think iis prefered, thathe impairments you select are applied othcomplete traffic, not only on the one you don't drop. Imaginyou hava stream of 100 packets, a drop rate of 30% and a duplicatioratof 10%. If you capture the stream, you would expect neteto havprocessed 10 duplicated and 30 dropped packets (which you may nodeteccorrectly because of the mentioned erasure). When applying your proposal, you would only get: ->30 packets dropped ->70 remaining packets -->7 packets duplicated (10%) -->63 packets with no impairment HTH & Waiting for other comments, Jan Frotom5760 agmail.com Wed Oct 22 12:49:06 2008 From: tom5760 agmail.co(Tom Wambold) Date: Wed, 22 Oc2008 15:49:06 -0400 Subject: PackeDrop and Duplication In-Reply-To: <48FF7C5C.9020904@xxxxxxxxxxxxx> References: <e246419f0810221110h46b9af02o743b6dfc5e166031@xxxxxxxxxxxxxx> <48FF7C5C.9020904@xxxxxxxxxxxxx> Message-ID: <e246419f0810221249q7a82b93fj32be7c3090793f86@xxxxxxxxxxxxxx> Hi Jan: > As mentioned before, i think thAND-concatenation is thimportant > point. I think iis prefered, thathe impairments you select are > applied othcomplete traffic, not only on the one you don't drop. I think this is whaI was trying to say. I'not trying to suggest thaimpairments should only affecnon-dropped packets. The impairments (likdropping packets) should bapplied to the complete traffic. Duplicates artraffic and thus should bincluded in this _complete_ traffic. > Thvariabl"count" indicates, how "often", an incoming packet should > bgiven to thoutput. When a drop and a duplicate occurs, it wouldn't > also matter, if you changthfunction calls and first drop it > (count=0) and theduplicatit (count=1)... I'noproposing to reverse the order of the function calls. I just think thaduplicated packets should also bconsidered to be dropped (or corrupted, delayed, etc). > Imaginyou hava stream of 100 packets, a drop rate of 30% and a > duplicatioratof 10%. I would expecthathe following would happen: -> 10 packets duplicated (110 total) -> 30 packets dropped -> 80 packets lefto bsent. My understanding is thaevery packethat gets sent should have a chancto bdropped. This seems to more accurately represent a real network. Idoesn'seem to make sense that a duplicated packet should never bdropped. Thanks for your speedy reply! -ToWambold OWed, Oc22, 2008 at 3:17 PM, Jan <netem at jan.reimes.de> wrote: > Hello, > > ToWambold wrote: >> I arunning somexperiments using Netem and found that duplicated >> packets arnever dropped. For example, running thfollowing >> command: >> >> tc qdisc add dev eth0 roonetedrop 100 duplicate 100 >> >> results ithinterface working normally. > > I don'know if this behaviour was intended when thenqueuing procedure > was written, bui think Neteworks correctly here. All impairments of > thnetecommand line should be AND-concatenated. > >> [codsnippet] >> >> So, if a drop and duplicatis triggered athe same time, the packet >> continues unaffected. This results i"duplicated" packets thacan >> never bdropped. > > Thvariabl"count" indicates, how "often", an incoming packet should > bgiven to thoutput. When a drop and a duplicate occurs, it wouldn't > also matter, if you changthfunction calls and first drop it > (count=0) and theduplicatit (count=1)... > >> Is therany particular reason thait works in this way? I would >> maksensto me that if 100% of packets should get dropped, then >> duplicates should bdropped as well. > > As mentioned before, i think thAND-concatenation is thimportant > point. I think iis prefered, thathe impairments you select are > applied othcomplete traffic, not only on the one you don't drop. > > Imaginyou hava stream of 100 packets, a drop rate of 30% and a > duplicatioratof 10%. If you capture the stream, you would expect > neteto havprocessed 10 duplicated and 30 dropped packets (which you > may nodeteccorrectly because of the mentioned erasure). When > applying your proposal, you would only get: > > ->30 packets dropped > ->70 remaining packets > -->7 packets duplicated (10%) > -->63 packets with no impairment > > HTH & Waiting for other comments, > > Jan > _______________________________________________ > Netemailing list > Netealists.linux-foundation.org > https://lists.linux-foundation.org/mailman/listinfo/netem >
