From: " Tobias Geiger" <tobias.geiger@web.de>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Shaping and accounting
Date: Fri, 31 May 2002 12:54:26 +0000 [thread overview]
Message-ID: <marc-lartc-102284974330547@msgid-missing> (raw)
In-Reply-To: <marc-lartc-102284596327685@msgid-missing>
Hi. yes afaik you're right: the ipac (for 2.2) and ipac-ng (vor 2.4) "just"
insert iptables-rules in INPUT/OUTPUT/FORWARD, and so they don't see the
"droped/delayed-because-of-shaping" packets..
the only solution i know is ugly and/or unpractiable: read the
interface-stats from /proc/net/dev. but that's only usable, if
1. you have 1. interface/customer
2. you don't need to account certain ports
as i said: it's in most cases no solution...
With Patrick's imq-devices you can at least compute the
"droped/delayed-because-of-shaping" packets: these imq-devices display
in /proc/net/dev the ammount of packets/bytes that SHOULD have deliverd as
RX, and the actual REALLY ammount of packets/bytes delivered to the
interface as TX.
But that's not really useful for your setup :(
Greetings
Tobias
> Hello,
>
> A while ago now I had to set up a traffic shaper for the ISP I work
> for, and I used linux and cbq.init to accomplish this. It worked
> reasonably well, too, but after a while and some double-checking it
> turned out that the ipac accounting on the same machine was
> consistently reporting higher usage than was actually the case by
> roughly the same factor (not amount) for every client.
>
> After a lot of thinking about this, the only conclusion I could reach
> that didn't involve a gross and so far completely undiscovered
> programming flaw in ipac or TCP/IP gremlins was that the difference was
> caused by traffic shaping occuring at the point where packets exit the
> machine while ipac does its accounting of packets at the point where
> they enter.
>
> Am I right, or am I just blowing smoke and moondust, and in either
> case, is there any way to correctly shape and account traffic on one
> machine?
>
> Thanks,
> --
> Rens Houben | opinions are mine
> Resident linux guru and sysadmin | if my employers have one
> Systemec Internet Services. |they'll tell you themselves PGP
> public key at http://suzaku.systemec.nl/shadur.key.asc -- new Dec 12
> 2001
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
prev parent reply other threads:[~2002-05-31 12:54 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-31 11:49 [LARTC] Shaping and accounting Rens Houben
2002-05-31 12:54 ` Tobias Geiger [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-102284974330547@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.