On Thu, Dec 31, 2015 at 1:58 PM, Guillaume Nault [off-list ref] wrote:

On Thu, Dec 31, 2015 at 12:01:40PM +0100, Sedat Dilek wrote:

quoted

On Thu, Dec 31, 2015 at 11:41 AM, Guillaume Nault [off-list ref] wrote:

quoted

On Thu, Dec 31, 2015 at 08:46:59AM +0100, Sedat Dilek wrote:

quoted

Hi Guillaume,

can you explain why you moved ppp to rtnetlink device handling?
Benefits, etc.?

The objective is to bring all the flexibility of rtnetlink device
creation to ppp interfaces. This is particularly useful for Network
Access Servers which need to define device properties at creation
time. My use case includes setting device name and netns, which is
impossible with the ioctl-based interface without generating transient
effects.

What do you mean by "my use-case"?
Example?

A NAS that terminates connections of PPP clients (usually transported
over PPPoE or L2TP). Clients may have different routing needs so each
PPP device is created in the appropriate network namespace. Without
rtnl the PPP device has to be created in the PPPoE/L2TP server's
namespace and then moved to the client's one. With rtnl, the PPP device
can be directly created in the right namespace.

Just off-topic...

Can you tell something to optimize my PPP Internet connection?

#1: BUFFERBLOAT

From bufferbloat project I have enabled htb and fq_codel network-scheduler.

#2: TXQUEUELEN

What about increasing txqueuelen value?
Default for PPP is "3".

What about the calculation in "RE: ppp0 and it's txqueuelen with HSDPA
gsm modems"?

[ Q ]

What would be "optimal" value for ppp0 device's txqueuelen,
when it is used with HSDPA gsm modem for link which downlink
speed is 1Mbit/s and uplink speed is 384kbit/s and ping
~80..100 ms? Is the default value 3 just OK?

[ A ]
"I would suggest using normal TCP calculation, i.e. that you dimension
the txqueue size after the "BDP rule": bandwidth x delay product. Using
your outbound numbers this is:
1,000,000 x 0.1 = 100,000 bits = 12,500 bytes. Assuming 1500 byte
packets, this is txqueue = 12,500 / 1500 = 8.3 packets. So you could try
txqueue size in the region 8-10, this should prevent queue starvation at
packet drop events caused by traffic overload, even if you only have one
single TCP flow."

[ CALCULATION ]

In my case with HTB and FQ_CODEL...
The latency is small 89ms (~0.1s)
DownLink ~4Mbps
MTU 1.500
( Is byte/packets equal to MTU value? )

4.000.000 (bits/s) x 0.1 (s) = 400,000 bits
400,000 (bits) ./. 8 = 50.000 (bytes)
50.000 (bytes) ./. 1.500 (byte/packets) = 33.3 packets

So a TXQUEUELEN of 33-35 seems to be OK?

root# ip link ls up
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
5: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast state UNKNOWN mode DEFAULT qlen 3
    link/ppp

root# ip link set txqueuelen 35 dev ppp0

root# ip link ls up dev ppp0
5: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast state UNKNOWN mode DEFAULT qlen 35
    link/ppp

I am testing here with SpeedOf.me.
Below some values with qlen=default=3.
[2] and [3] at my castle with recent (net-next + ppp-rtnetlink).
[1] at my brother's castle with an older kernel.
( D == DownLink and U == UpLink. )

SpeedOf.me results:

[1] TUE-TD: D:6.78 || U:3.04 (2015-02-22, w/ run_htb-with-fq_codel_ppp0.sh)
http://speedof.me/show.php?img=150221065031-67247.png

[2] DUS-SD: D:4.16 || U:2.18 (2015-12-31)
http://speedof.me/show.php?img=151231122405-1014.png

[3] DUS-SD: D:4.22 || U:1.63 (2015-12-31, w/ run_htb-with-fq_codel_ppp0.sh)
http://speedof.me/show.php?img=151231122154-8498.png

Suggestions?

Thanks.

- Sedat -

[1] http://www.spinics.net/lists/linux-ppp/msg00509.html
[2] http://speedof.me/