All of lore.kernel.org
 help / color / mirror / Atom feed
* [LARTC] Shaping and accounting
@ 2002-05-31 11:49 Rens Houben
  2002-05-31 12:54 `  Tobias Geiger
  0 siblings, 1 reply; 2+ messages in thread
From: Rens Houben @ 2002-05-31 11:49 UTC (permalink / raw)
  To: lartc

[-- Attachment #1: Type: text/plain, Size: 1209 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [LARTC] Shaping and accounting
  2002-05-31 11:49 [LARTC] Shaping and accounting Rens Houben
@ 2002-05-31 12:54 `  Tobias Geiger
  0 siblings, 0 replies; 2+ messages in thread
From:  Tobias Geiger @ 2002-05-31 12:54 UTC (permalink / raw)
  To: lartc

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/

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2002-05-31 12:54 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-05-31 11:49 [LARTC] Shaping and accounting Rens Houben
2002-05-31 12:54 `  Tobias Geiger

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.