All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tobias Geiger <tobias.geiger@web.de>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Sharing incoming traffic
Date: Thu, 21 Mar 2002 13:28:02 +0000	[thread overview]
Message-ID: <marc-lartc-101672401200768@msgid-missing> (raw)
In-Reply-To: <marc-lartc-101671390020588@msgid-missing>

For me ingress works great.
ok, i more or less copy/pasted from the "wondershaper" :)

I guess it's not good to have a rate of 8000bps AND a burst of 10k 

I'm also not shure, if the iptables-marks get noticed, but it seems so,
as you said there is a shaping effect. but as your iptable-rule is so
generally i'd say there's no reason not to use the appropriate u32
filter instead of fw.

VMWare shouldn't be the problem, at least i never had ones.

Tell me, if tuning rate/burst helped

Greetings 

	Tobias




On Thu, Mar 21, 2002 at 12:29:09PM +0000, Julián Muñoz wrote:
> 
> I've done my first test with ingress,
> 
> 2 ftps, and I've seen that the bandwidth is not shared "very well".
> 
> From the point of view of a user, his transfer stops suddenly, and
> restarts 20 seconds (or more!) later. Then the other has to wait !! I
> observ a kind of feedback process, beeing the interval of stopped traffic
> bigger each time, during the transference.
> 
> The bandwidth is limited to 64.000 bit per second, killing packets.
> 
> In fact it is not a real ethernet link, and the filter is on a vmware
> machine computer, so maybe this test is not valid.
> 
> Anyone knows more about this behaviour ??
> 
> Could I optimize it playing with burst and mpu ?
> 
> Or am I doing something really bad ?
> 
> Thank you,
> 
> Here's my filter:
> 
> iptables -A PREROUTING -i eth0 -t mangle --protocol all -j MARK --set-mark
> 1
> 
> tc qdisc add dev eth0 handle ffff: ingress
> 
> tc filter add dev eth0 parent ffff: protocol ip prio 5 handle 1 fw  \
>    police rate 8000bps burst 10k mpu 64b drop flowid :1
> 
> 
> -- 
> 
>       __o
>     _ \<_
>    (_)/(_)
> 
> Saludos de Julián
> EA4ACL
> -.-
> 
> Foro Wireless Madrid
> http://opennetworks.rg3.net
> 
> 
> 
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

  reply	other threads:[~2002-03-21 13:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-21 12:29 [LARTC] Sharing incoming traffic Julián Muñoz
2002-03-21 13:28 ` Tobias Geiger [this message]
2002-03-21 14:18 ` Tobias Geiger
2002-03-21 14:23 ` Tobias Geiger
2002-03-21 14:43 ` Julián Muñoz
2002-03-21 15:11 ` Martin Devera
2002-03-21 15:31 ` Jason Tackaberry
2002-03-21 15:36 ` Martin Devera
2002-03-21 16:25 ` Julián Muñoz

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-101672401200768@msgid-missing \
    --to=tobias.geiger@web.de \
    --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.