All of lore.kernel.org
 help / color / mirror / Atom feed
From: tc@forest.one.pl
To: lartc@vger.kernel.org
Subject: [LARTC] Strange pings.
Date: Tue, 19 Apr 2005 22:55:42 +0000	[thread overview]
Message-ID: <200504200055.42395.tc@forest.one.pl> (raw)

Hi.

The configuration script is at the bottom.

My configuration looks similar to this:
    imq0
     |
    1:1  (12mbit)
     |
    1:2  (10mbit)
     |
    3:0  
     |
    3:1  (256kbit)
    / \
 3:2   3:3
icmp   (rest)

both 3:2 and 3:3 have rate 1kbit ceil 256kbit

Icmp bucklet have priority 1 (better), "rest" bucklet have prio 2 (worse)



I tested the script with heavy download from machine 192.168.1.2 in the background.
While the download was going I pinged 192.168.1.1.

All works fine, except pings...
They should be low, and they almost are :)

Pings are fine (0.4ms) for about 120 seconds, then i got pings similar to this:

64 bytes from 192.168.1.1: icmp_seqê ttld time=0.3 ms
64 bytes from 192.168.1.1: icmp_seqë ttld time=0.4 ms
64 bytes from 192.168.1.1: icmp_seqí ttld timeÑ.0 ms
64 bytes from 192.168.1.1: icmp_seqì ttld time#.0 ms
64 bytes from 192.168.1.1: icmp_seqî ttld timeW.0 ms
64 bytes from 192.168.1.1: icmp_seqï ttld timeâ.0 ms
64 bytes from 192.168.1.1: icmp_seqñ ttld time(.0 ms
64 bytes from 192.168.1.1: icmp_seqó ttld timea.0 ms
64 bytes from 192.168.1.1: icmp_seqò ttld timeì.0 ms
64 bytes from 192.168.1.1: icmp_seqô ttld time2.0 ms
64 bytes from 192.168.1.1: icmp_seq\x100 ttld timee.0 ms
64 bytes from 192.168.1.1: icmp_seq\x101 ttld time=4.0 ms
64 bytes from 192.168.1.1: icmp_seq\x102 ttld time6.0 ms
64 bytes from 192.168.1.1: icmp_seq\x103 ttld timei.0 ms
64 bytes from 192.168.1.1: icmp_seq\x104 ttld time=8.0 ms
64 bytes from 192.168.1.1: icmp_seq\x105 ttld time@.0 ms
64 bytes from 192.168.1.1: icmp_seq\x106 ttld times.0 ms
64 bytes from 192.168.1.1: icmp_seq\x107 ttld time\x12.0 ms
64 bytes from 192.168.1.1: icmp_seq\x108 ttld time=0.3 ms
64 bytes from 192.168.1.1: icmp_seq\x109 ttld time=0.3 ms

Then it is stable (0.4ms) for some time.

The same situation repeats in about 60 second delay.

Maybe someone solved this problem?

Thanks for any advice.

Yours sincerly
      Maciek


PS. Please don't ask me why this configuration is so strange, I have
some reasons to use schemes like this one.

PPS. Is it possible to create a filter that will match all packets?



##### script

iptables -t mangle -F PREROUTING
iptables -t mangle -F POSTROUTING
iptables -t mangle -A PREROUTING -i ! lo  -j IMQ --todev 0
iptables -t mangle -A POSTROUTING -o ! lo  -j IMQ --todev 1

tc qdisc del root dev imq0
tc qdisc del root dev imq1

tc qdisc add dev imq0 root handle 1 htb default 2
tc qdisc add dev imq1 root handle 1 htb default 2
tc class add dev imq0 parent 1:0 classid 1:1 htb rate 12mbit burst 2k prio 1 quantum 2048
tc class add dev imq1 parent 1:0 classid 1:1 htb rate 12mbit burst 2k prio 1 quantum 2048
tc class add dev imq0 parent 1:1 classid 1:2 htb rate 10mbit burst 2k prio 1 quantum 2048
tc class add dev imq1 parent 1:1 classid 1:2 htb rate 10mbit burst 2k prio 1 quantum 2048
tc qdisc add dev imq0 parent 1:2 handle 3 htb default 3
tc qdisc add dev imq1 parent 1:2 handle 3 htb default 3

tc class add dev imq0 parent 3:0 classid 3:1 htb rate 256kbit burst 2k prio 1 quantum 2048
tc class add dev imq1 parent 3:0 classid 3:1 htb rate 64kbit  burst 2k prio 1 quantum 2048

tc class add dev imq0 parent 3:1 classid 3:2 htb rate 1kbit ceil 256kbit burst 2k prio 1 quantum 2048
tc class add dev imq1 parent 3:1 classid 3:2 htb rate 1kbit ceil 64kbit  burst 2k prio 1 quantum 2048
tc class add dev imq0 parent 3:1 classid 3:3 htb rate 1kbit ceil 256kbit burst 2k prio 2 quantum 2048
tc class add dev imq1 parent 3:1 classid 3:3 htb rate 1kbit ceil 64kbit  burst 2k prio 2 quantum 2048

tc qdisc add dev imq0 parent 3:2 handle 12:0 pfifo limit 4
tc qdisc add dev imq1 parent 3:2 handle 12:0 pfifo limit 4
tc qdisc add dev imq0 parent 3:3 handle 13:0 pfifo limit 4
tc qdisc add dev imq1 parent 3:3 handle 13:0 pfifo limit 4

tc filter add dev imq0 protocol ip parent 3:0 prio 1 u32 match ip protocol 1 0xFF flowid 3:2
tc filter add dev imq1 protocol ip parent 3:0 prio 1 u32 match ip protocol 1 0xFF flowid 3:2
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

             reply	other threads:[~2005-04-19 22:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-19 22:55 tc [this message]
2005-04-21 23:34 ` [LARTC] Strange pings Andy Furniss
2005-04-22 21:08 ` tc
2005-04-24 11:03 ` tc
2005-04-24 23:59 ` Andy Furniss
2005-05-13 23:36 ` Andy Furniss

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200504200055.42395.tc@forest.one.pl \
    --to=tc@forest.one.pl \
    --cc=lartc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.