From: "Roy" <roy@xxx.lt>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Weird quirk with ingress policing
Date: Sun, 14 Mar 2004 18:33:06 +0000 [thread overview]
Message-ID: <002601c409f2$cc2f8b20$030aa8c0@t> (raw)
In-Reply-To: <40543DD1.5020702@rebirthing.co.nz>
That is normal, policers do not share bandwich, they simply drop packets on
match randomly.
Probably you are already using index feature.
I checked policer source code, and cant understand anything at all,
probabaly everyhing is in other modules.
From that little what I could understand, seems that index means sharing
some parts of data.
probably rate counters, this is quite logical, but than I dont undestand its
behavior,
each policer should see sum of rates, but match on its own rate.
In practice it seems to ignore its own rate and match on sum of rates all at
once
so that one which packet exceed sum of trates will drop its packet.
Maybe you could check if it is corerct?
Since it is hard to believe that policer is intended to work in such way so.
I dont think policers are capable to divide trafic in fair way, they work as
simple one fifo.
(all policers as single fifo at once)
----- Original Message -----
From: "David McNab" <david@rebirthing.co.nz>
To: <lartc@mailman.ds9a.nl>
Sent: Sunday, March 14, 2004 1:11 PM
Subject: [LARTC] Weird quirk with ingress policing
> Hi,
>
> I notice that if two or more existing connections match an ingress
> policing filter, the input bandwidth does not get evenly divided up
> between the n connections.
>
> Kinda like litters of baby animals, where the stronger babies get more
> access to the mothers teats and grow up bigger and faster than their
> siblings.
>
> The only workaround that's working for me is to set explicit ingress
> policing filters, which match src and dest host and port, so for each
> filter there can only be exactly one connection which matches. Then,
> it's just a matter of evenly dividing up the allocated total input bw
> amongst these n processes. This works, but it's not exactly optimal.
>
> --
>
> Kind regards
> David
>
> --
>
> leave this line intact so your email gets through my junk mail filter
> _______________________________________________
> 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/
next prev parent reply other threads:[~2004-03-14 18:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-14 11:11 [LARTC] Weird quirk with ingress policing David McNab
2004-03-14 18:33 ` Roy [this message]
2004-03-14 22:51 ` David McNab
2004-03-16 0:34 ` 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='002601c409f2$cc2f8b20$030aa8c0@t' \
--to=roy@xxx.lt \
--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.