From: Phil Brutsche <phil@optimumdata.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] prio fighting
Date: Wed, 27 Jun 2001 19:50:16 +0000 [thread overview]
Message-ID: <marc-lartc-99367174308275@msgid-missing> (raw)
In-Reply-To: <marc-lartc-99351566704106@msgid-missing>
On Mon, 25 Jun 2001, Nikolai Vladychevski wrote:
> Hi,
>
> I have done this setup to give the machine 192.168.1.4 (masqueraded over
> dialup) the highest priority:
>
> #! /bin/bash
> WHAT="add"
> iptables -A PREROUTING -i eth0 -s 192.168.1.1 -t mangle -j MARK
> --set-mark 1
> iptables -A PREROUTING -i eth0 -s 192.168.1.4 -t mangle -j MARK
> --set-mark 4
> tc qdisc $WHAT dev ppp0 root handle 1: prio bands 3 priomap 0 1 2
> tc qdisc $WHAT dev ppp0 parent 1:1 handle 2: pfifo limit 1024
> tc qdisc $WHAT dev ppp0 parent 1:2 handle 3: pfifo limit 1024
> tc qdisc $WHAT dev ppp0 parent 1:3 handle 4: pfifo limit 1024
> tc filter add dev ppp0 protocol ip parent 1:0 prio 0 handle 4 fw classid
> 1:2
> tc filter add dev ppp0 protocol ip parent 1:0 prio 2 handle 1 fw classid
> 1:3
Have you tried "classid 2:" and "classid 3:" instead of "classid 1:2" and
"classid 1:3"? It would seem to me to work better that way.
> and it is working because form the stats I can see the packets are
> flowing:
>
> [root@qis /root]# tc -s -r qdisc show dev ppp0
> qdisc pfifo 4: limit 1024p
> Sent 42374 bytes 804 pkts (dropped 0, overlimits 0)
>
> qdisc pfifo 3: limit 1024p
> Sent 16535 bytes 381 pkts (dropped 0, overlimits 0)
>
> qdisc pfifo 2: limit 1024p
> Sent 589 bytes 10 pkts (dropped 0, overlimits 0)
>
> qdisc prio 1: bands 3 priomap 0 1 2 2 1 2 0 0 1 1 1 1 1 1 1 1
> Sent 59498 bytes 1195 pkts (dropped 0, overlimits 0)
>
>
> There is just 1 problem, the prioritization is not working. When I
> start downloading FTP on on the machine 192.168.1.1 , wait 20-30 secs
> and start another FTP session on 192.168.1.4 it does not gets the full
> bandwidth as it should get. What could be wrong? One workstation is
> linux (.1) , other is Win98 (.4), I don't know if this could be the
> issue.
I could be the subqueue discipline that you're using. I would think that
the tbf queue discipline would be more fair in this situation.
--
-----------------------------------------------------------------------
Phil Brutsche phil@optimumdata.com
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/
prev parent reply other threads:[~2001-06-27 19:50 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-06-26 0:36 [LARTC] prio fighting Nikolai Vladychevski
2001-06-27 19:50 ` Phil Brutsche [this message]
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=marc-lartc-99367174308275@msgid-missing \
--to=phil@optimumdata.com \
--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.