Warum unternimmt die EU nichts gegen PPPoE?

Ich bin schon länger kein Freund von PPPoE; warum man aus einem Stand­leitungs­pro­dukt partout mit Krampf ein Einwahlprodukt machen will … schätze, da fehlt mir einfach das Marketing-Fachwissen.

Ich habe mein Testbed jetzt mit einem Raspberry Pi als PPPoE-Gegenstelle an den Start gebracht, d. h. die DSL-Session terminiert auf dem ALL126AM2, die PPPoE-Session auf dem Raspberry:

16.02.14 02:31:45 Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: 198.51.100.2, DNS-Server: 192.168.5.1 und 8.8.8.8, Gateway: 192.168.5.119, Breitband-PoP: raspberrypi

Aufgesetzt grob nach diesem Blogpost, wobei ich bei der Authentifizierung großzügig war: anything goes ;) Spart mir unter anderem die Umkonfiguration der Testboxen …

Der RPi fungiert hier als PPPoE-Server und NATet die VDSL-IPs auf seine eigene; nun würde man erwarten, das macht jede aktuelle CPU mit links, aber wie ich schon 2007 feststellte: PPPoE ist ein ziemlicher Overhead.

(Seinerzeit kam eine Cyrix-CPU mit 266 MHz nicht über 4 MBit/sec PPPoE-Traffic hinaus. Heute machen 20 MBit/sec rd. 50% CPU-Last auf einem RPi.)

Ich weiß derzeit nicht, wo es klemmt: natürlich indizieren 50% CPU bei 20 MBit/sec, daß der Raspberry Pi für diesen Einsatzzweck zu schwachbrüstig ist — final soll diese Rolle aber auch ein ODROID übernehmen, er ist Freitag in Berlin eingetroffen und ich werde ich dann wohl am Montag abend für’s Testbed in Betrieb nehmen. (Später soll er den RPi, den ich nach Ausfall meine Dockstars als temporären Router in Berlin nutze, ersetzen.)

Aber zurück zum Raspberry Pi: Wüßte ich nicht, daß die Leitung 100/30 MBit/sec zu leisten im Stande ist, würde ich von den RTT-Werten ja denken, bei 20 MBit/sec im Downstream sei Schluß. Nun, der RPi muß ich mit PPPoE und dem NATing herumschlagen, vielleicht limitiert dies den Durchsatz?

Mit iperf alleine läßt sich das jedenfalls nicht erklären:

testnode# iperf -c death.uu.org
------------------------------------------------------------
Client connecting to death.uu.org, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.8.22 port 40464 connected with 192.251.226.52 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.1 sec  15.1 MBytes  12.6 Mbits/sec

raspberrypi:~# iperf -c death.uu.org
------------------------------------------------------------
Client connecting to death.uu.org, TCP port 5001
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.5.119 port 47388 connected with 192.251.226.52 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  63.1 MBytes  52.8 Mbits/sec

Wie man sehen kann, bekommt der RPi durchaus ~50 MBit/sec »mal eben so« hin, während von hinter der VDSL-Strecke bei sogar nur 12 MBit/sec Schluß ist. Das ändert sich auch nicht mit größeren Fenstern:

testhost# iperf --window 32k -c death.uu.org 
------------------------------------------------------------
Client connecting to death.uu.org, TCP port 5001
TCP window size: 64.0 KByte (WARNING: requested 32.0 KByte)
------------------------------------------------------------
[  3] local 192.168.8.22 port 50757 connected with 192.251.226.52 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  14.5 MBytes  12.1 Mbits/sec

Auch per wget im »LAN« läßt sich das nicht erklären:

raspberry:
100%[======================================>] 78,361,056  8.23M/s   in 10s     

2014-02-16 02:30:26 (7.45 MB/s) - `/dev/null' saved [78361056/78361056]

testnode:
100%[======================================>] 78,361,056  1.85M/s   in 41s     

2014-02-16 02:31:08 (1.80 MB/s) - `/dev/null' saved [78361056/78361056]

Irgendwo ist noch ‘ne Handbremse angezogen, und ich vermute mal, daß der RPi diese derzeit darstellt.