All of lore.kernel.org
 help / color / mirror / Atom feed
From: "LE ROY Philippe" <philippe@liddell-prod.com>
To: lartc@vger.kernel.org
Subject: [LARTC] HTB + PPPOE : inaccurate rates ?
Date: Tue, 27 May 2003 12:02:57 +0000	[thread overview]
Message-ID: <marc-lartc-105403734230802@msgid-missing> (raw)

Hi all !

(English is not my native langage but I will try to be as simple as
possible.)

The question is at the end !

-----

I am using Debian Woody (stable). Kernel 2.4.18 is patched with
patch-o-matic, HTB, IMQ, ESFQ and some other things.

At home, an old 486dx4-100mhz acts as a firewall/gateway.
This PC is connected to Internet with an Ethernet ADSL Modem
(Speed Touch Home). The protocol used is PPPOE.

I am playing with Qos and HTB since two months and it works
great !

All should be perfect in a perfect world except one thing : rates used
by htb do not include (I think so) PPPOE overhead...

From
http://tldp.org/HOWTO/ADSL-Bandwidth-Management-HOWTO/implementation.html :

> This means that if you are sending a typical TCP ACK packet
> which consists of 0 bytes data + 20 bytes TCP header + 20 bytes
> IP header + 18 bytes Ethernet header. In actuality, even though the
> ethernet packet you are sending has only 40 bytes of payload (TCP
> and IP header), the minimum payload for an Ethernet packet is 46
> bytes of data, so the remaining 6 bytes are padded with nulls.
> This means that the actual length of the Ethernet packet plus header
> is 18 + 46 = 64 bytes.

This is for standard ethernet but with PPPOE, you must add 8 bytes.
So, when sending "a typical TCP ACK packet", payload is 48 bytes
(0 data +20 tcp + 20 ip + 8 pppoe) plus 18 bytes Ethernet header
(14 header + 4 crc).

Total transmited : 66 bytes. The problem is that HTB do not see these
extra bytes (26). This is not a big problem with large packets but when
you send many little packets (ssh keystokes) the overhead is quite big.

------

An example :

Supose I want to limit total upload bandwidth to 10ko/s.
(rate = ceil = 10000 bytes/s)

When I send a (big) email, packets are truncated to 1420bytes (from
ppp and htb point of view). so 10000bytes/s / 1420 = 7 packets/s

If we add pppoe overhead (1420+26*7), 10122 bytes are *realy*
transmitted per second.

Now, imagine that while I am sending that big mail, I use ssh "intensively"
(like holding "down" key to go further in a long man page...)

When pressing a key, ssh send two packets : each one is 92 bytes long
so if you keyboard rate is set to 30 keys/s, 60 packets are sent.
60 packets/s * 92 bytes = 5520 bytes/s.

Because my ssh htb class has a lower prio than smtp htb class, ssh
packets are sent first.

As a result 9780 bytes/s are allowed to be sent by HTB
(60 * 92 bytes (ssh) + 3 * 1420 (mail) )

But with pppoe overhead, 11418 bytes/s are transmited
( 60 * (92+26) + 3 * (1420+26) )

-------

Now, if I want to avoid that, I must limit total upload speed
arround 8600 bytes/s :

From HTB and PPP point of view
60 * 92 + 2 * 1420 = 8360 bytes/s

Real :
60 * (92+26) + 2 * (1420+26) = 9972 bytes/s

That's OK but when only sending an email :

HTB allows :
8600 / 1420 = 6 packets/s

Real :
6 * (1420 +26) = 8676 bytes/s

Arround 1500 bytes/s of bandwidth are lost.

------

So, (finally...), the question is :

How to take into account pppoe overhead when using HTB
or any other qdisc/class with Linux ?

*Any* suggestions would be appreciated !

LE ROY Philippe





_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

                 reply	other threads:[~2003-05-27 12:02 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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-105403734230802@msgid-missing \
    --to=philippe@liddell-prod.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.