[ff-firmware-devel] Mesh-VPN Begrenzung in Prozent
Kai 'wusel' Siering
wusel at guetersloh.freifunk.net
Sa Sep 27 22:41:08 CEST 2014
On 27/09/14 19:51, Nils Schneider wrote:
> Nur mal so als Idee:
>
> Man könnte auch den tatsächlichen Traffic über einen längeren Zeitraum
> beobachten. Wenn man dazu noch die Queues anschaut, dürfte man die
> tatsächliche maximal Bandbreite gut abschätzen können.
Und womit startet man dann, 1000/100? Wie haben hier leider selbst im
Stadtgebiet Anschlüsse (auch bei Firmen), die im Rahmen von 3 MBit/sec
liegen, wenn man da "full pull" zuläßt bis man glaubt sagen zu können,
was der Anschluß hergibt, sehe ich Probleme :( Ich denke schon, daß ein
Check zum Bootzeitpunkt gemacht werden sollte -- um User (und uns) zu
schützen aber max. 1x pro Woche.
Ein anderes Extrem sind natürlich richtig dicke Anschlüsse:
root at ffgt-Testinst@155MLink:~# time wget -O /dev/null
http://guetersloh.freifunk.net/testfile-10M.img
Connecting to guetersloh.freifunk.net (193.26.120.20:80)
null 100% |*******************************| 10240k
0:00:00 ETA
real 0m 1.43s
user 0m 0.04s
sys 0m 0.28s
root at ffgt-Testinst@155MLink:~# time wget -O /dev/null
http://guetersloh.freifunk.net/testfile-100M.img
Connecting to guetersloh.freifunk.net (193.26.120.20:80)
null 100% |*******************************| 100M
0:00:00 ETA
real 0m 10.62s
user 0m 0.36s
sys 0m 3.15s
wusel at luggage:~$ echo "scale=3; (10485760*8)/1.43/1024/1024"|bc
55.944
wusel at luggage:~$ echo "scale=3; (104857600*8)/10.62/1024/1024"|bc
75.329
(Wenn ich mich jetzt nicht mit Bits und Kilos verheddert habe, sind das
MBit/sec, so um und bei.)
IPv6 ist dann ein weiteres lustiges Problem:
root at ffgt-Testinst@155MLink:~# time wget -O /dev/null
http://gw04.guetersloh.freifunk.net/ffgt/testfile-10M.img
Connecting to gw04.guetersloh.freifunk.net ([2a01:4a0:2001:2577::2]:80)
null 100% |*******************************| 10240k
0:00:00 ETA
real 0m 10.14s
user 0m 0.19s
sys 0m 0.55s
root at fffgt-Testinst@155MLink:~# time wget -O /dev/null
http://gw04.guetersloh.freifunk.net/ffgt/testfile-10M.img
Connecting to gw04.guetersloh.freifunk.net ([2a01:4a0:2001:2577::2]:80)
wget: can't connect to remote host: Operation not permitted
Command exited with non-zero status 1
real 0m 0.01s
user 0m 0.01s
sys 0m 0.00s
wusel at luggage:~$ echo "scale=3; (10485760*8)/10.14/1024/1024"|bc
7.889
Knapp 8 MBit/sec, und es geht mit 85% CPU für fastd über den Tunnel
(TP-Link TL-WDR3600 v1; simple_tc ist deaktiviert; und aus dem
fastd-Tunnel-Mesh geht's direkt in den tinc-Tunnel für den IPv6-Exit via
Berlin ...).
root at ffgt-Testinst@155MLink:~# time wget -O /dev/null
http://130.185.104.56/ffgt/testfile-10M.img
Connecting to 130.185.104.56 (130.185.104.56:80)
null 100% |*******************************| 10240k
0:00:00 ETA
real 0m 1.00s
user 0m 0.02s
sys 0m 0.35s
wusel at luggage:~$ echo "scale=3; (10485760*8)/1.00/1024/1024"|bc
80.000
Derzeit macht IIRC es eh' keinen großen Sinn, jenseits 16 MBit/sec
shapen zu wollen, denn das ist das fastd-Limit der aktuellen
TP-Link-Kisten mit dem aktuellen Code, right?
Sicher, eine solche fette Leitung wie oben ist die Ausnahme; wobei
Kabelanschlüsse ja in änhlichen Regionen (im Download) liegen sollen?
Insofern würde ich aktiv testen und dann aus dem Ergebnis "wissend
raten", wie schnell der Anschluß sein mag, jenseits 16 MBit/sec im
Ergebnis nicht mehr shapen und darunter halt mit sinkenden Downstream
den Upstream stärker begrenzen, falls es halt DSL ist (oder Kabel, da
gibt's in Releation zum Down- Upstream ja nur in homoöpathischen Dosen).
MfG,
-kai
P.S.: Welche Option gibt es, besagte Leitung "etwas" mehr auszulasten,
so auf 16 bis 40 MBit/sec zumindest würde ich gerne kommen.
At Sat, 27 Sep 2014 19:43:27 +0200, Wolfgang Behrens wrote:
>> [1 <multipart/alternative (7bit)>]
>> [1.1 <text/plain; UTF-8 (8bit)>]
>>
>> [1.2 <text/html; UTF-8 (8bit)>]
>> Werden denn viele Knoten täglich rebootet?
>>
>> Auf die Idee bin ich zugegeben noch nicht gekommen, wäre aber ja durchaus möglich...
>>
>> Am 27.09.2014 um 19:30 schrieb Frank Rühlemann:
>>
>> Also 3,3GB monatlich pro Knoten mit direktem Uplink ist eine stolze
>> Größe, nur damit dieser vermessen wird.
>>
>> Wahrscheinlich reichen maximal 3 Messungen täglich auch, wahrscheinlich
>> weniger, wenn man das noch grob statistisch auswertet. So stark sollte
>> das nicht schwanken, sonst sind eher andere Dinge an dem Anschluss kaputt.
>>
>> Gruß
>> Frank
>>
>> Am 27.09.2014 um 17:56 schrieb Wolfgang Behrens:
>>
>> Am 27.09.2014 um 15:53 schrieb Matthias Schiffer:
>>
>> Moin,
>> wann und wie genau wird die Messung gemacht? Wenn das ganze gut
>> funktioniert, ist es sicherlich eine �berlegung wert, das so �hnlich in
>> den Gluon-Master aufzunehmen...
>>
>> Bei dem wann (und bei vielem anderen) bin ich noch am experimentieren,
>> derzeit mache ich nach jedem Router-Reboot 11 Messungen im Abstand von
>> je 8000s und nehm das Maximum.
>>
>> Das deckt ca. einen ganzen Tag ab und sollte zu starke Abweichungen
>> durch tageszeitliche Schwankungen usw. halbwegs erledigen.
>>
>> Nachdem ich erstmal mit dem arbeiten muss, was ich habe, laufen die
>> Messungen:
>>
>> 1. Download: via Laden einer 10MB-Datei von einem GW bzw. öffentlichen
>> Servern - Ich versuche allerdings nicht zu raten, was für ein Anschluß
>> das ist, ich nehm die Bandbreite wie ich sie sehe.
>>
>> 2. Upload: iperf-Server auf GWs bzw. öffentlichen Servern
>>
>> Die öffentlichen Server sind Fallback für den Fall, dass im Moment des
>> Tests die GWs grad nicht erreichbar sind... sollte zwar nicht passieren,
>> aber wer weiß.
>>
>> Sollte sich die Idee durchsetzen, könnte man sich da ja evtl.
>> gegenseitig aushelfen...
>>
>> Grüße
>> Wolfgang
>>
>>
>> [2 <text/plain; iso-8859-1 (quoted-printable)>]
>> --
>> firmware-devel mailing list
>> firmware-devel at freifunk.net
>> http://lists.freifunk.net/mailman/listinfo/firmware-devel-freifunk.net
--
Freifunk-Initiative Gütersloh
℅ Kai Siering
Schalückstraße 107
33332 Gütersloh
info at guetersloh.freifunk.net
Tel.: (05241) 96 46 269
Mehr Informationen über die Mailingliste firmware-devel