[Freifunk_info] Stnadby-Traffic eines FFV-APs sehr hoch
Hi, im Zuge des Projekts, entlang der Kammloipe an den GK-Kamera-Standorten Freifunk-APs aufzustellen, wurden LTE-Router mit Vertrag über 30GB Datenvolumen beschafft. Leider scheint der AP nur fürs Existieren schon sehr viel Datenvolumen zu verbrauchen, ich komme auf ein knappes Gigabyte pro Tag - und da sind noch keine Clients eingebucht gewesen. Mache ich was falsch? Kann man das ändern? Alleine fürs Betreiben ist der Vertrag damit ja schon fast ausgelastet. Carsten
Hi, ich hab mal das Trafficaccounting für diesen Client im Netz angeschalten. Da geht tatsächlich eine ganze Menge sinnloser Traffic übers Netz. Ob das jetzt 1GB/Tag ist, kann ich noch nicht abschätzen, aber aus der Hochrechnung der letzten Stunde würde ich sagen mindestens 500MB, Tendenz ist eher höher. Ich rechne da mal lieber vorsichtiger, weil bei mir sind tatsächlich Clients verbunden. Völlig inakzeptabel, imho. Grüße Alex On Wednesday, 28 December 2016 11:30:00 CET Carsten Weber via Freifunk_info wrote:
Hi,
im Zuge des Projekts, entlang der Kammloipe an den GK-Kamera-Standorten Freifunk-APs aufzustellen, wurden LTE-Router mit Vertrag über 30GB Datenvolumen beschafft.
Leider scheint der AP nur fürs Existieren schon sehr viel Datenvolumen zu verbrauchen, ich komme auf ein knappes Gigabyte pro Tag - und da sind noch keine Clients eingebucht gewesen. Mache ich was falsch? Kann man das ändern? Alleine fürs Betreiben ist der Vertrag damit ja schon fast ausgelastet.
Carsten _______________________________________________ Freifunk_info mailing list Freifunk_info@freifunk-vogtland.net http://mx.hateotu.de:8025/mailman/listinfo/freifunk_info
Hallo Ihrs, das ist systembedingt, da das Mesh uebers VPN gefahren wird. D.h. es gibt regelmaessig Routingprotokoll-Overhead (alle paar Sekunden ein Paket von jedem Knoten) und Broadcasts aus dem gesamten Netz (groesstenteils die Clients - DHCP Requests, ARP requests, etc). Das ist nicht so viel, aber stetig, und in der Summe (pro Tag) schon eine Menge. Das steigt natuerlich auch mit der Anzahl der aktiven Knoten und (Gesamt)Clients. Das Problem ist durchaus bekannt, einfach mal nach "Gluon Grundrauschen" googlen. Spontan habe ich leider keine Alternative fuer den LTE Uplink - eventuell koennen wir einen anderen fastd Server schalten wo "wenig" Nutzer drauf sind. Ich muss da mal drueber nachdenken ... Falls Ihr etwas seht, sagt Bescheid. Viele Gruesse, Simon On Monday, January 2, 2017 11:09:07 AM CET Alexander Heidenreich via Freifunk_info wrote:
Hi,
ich hab mal das Trafficaccounting für diesen Client im Netz angeschalten. Da geht tatsächlich eine ganze Menge sinnloser Traffic übers Netz. Ob das jetzt 1GB/Tag ist, kann ich noch nicht abschätzen, aber aus der Hochrechnung der letzten Stunde würde ich sagen mindestens 500MB, Tendenz ist eher höher. Ich rechne da mal lieber vorsichtiger, weil bei mir sind tatsächlich Clients verbunden.
Völlig inakzeptabel, imho.
Grüße Alex
On Wednesday, 28 December 2016 11:30:00 CET Carsten Weber via Freifunk_info
wrote:
Hi,
im Zuge des Projekts, entlang der Kammloipe an den GK-Kamera-Standorten Freifunk-APs aufzustellen, wurden LTE-Router mit Vertrag über 30GB Datenvolumen beschafft.
Leider scheint der AP nur fürs Existieren schon sehr viel Datenvolumen zu verbrauchen, ich komme auf ein knappes Gigabyte pro Tag - und da sind noch keine Clients eingebucht gewesen. Mache ich was falsch? Kann man das ändern? Alleine fürs Betreiben ist der Vertrag damit ja schon fast ausgelastet.
Carsten _______________________________________________ Freifunk_info mailing list Freifunk_info@freifunk-vogtland.net http://mx.hateotu.de:8025/mailman/listinfo/freifunk_info
Hi, wie zum letzten Treffen mal besprochen haben wir eine Analyse durchgefuehrt. Unten [1] gibts das Ergebnis. Wir hatten einen einzelnen AP isoliert, einen PC dazwischen gehaengt und saemtlichen Traffic uebers Wochenende gedumpt und offline analysiert. Wie man sieht haben wir knapp 1 Gigabyte Grundrausch-Traffic pro Tag (bei unser derzeitigen Netzgroesse von ca. 200 online APs), wobei die zwei groessten Posten OGMs (Protokoll) und Broadcast Traffic sind. Broadcast teilt sich dann weiter auf in ARP Traffic (der schon durch DAT reduziert ist) und IPv6 Traffic. Dieser wiederum besteht wieder aus verschiedenen Komponenten, wobei MLD (Multicast Listenery Discovery) der groesste Posten ist. Low Hanging fruits um das ganze merklich einzudaempfen sehe ich gerade nicht (ausser domains splitten), aber ich wuerd das erstmal sacken lassen ... :) Viele Gruesse, Simon [1] UDP(TOTAL) 917.264 MByte/day OGM 498.585 MByte/day ICMP 0.529 MByte/day UCAST 3.701 MByte/day UCAST4 2.200 MByte/day BCAST 410.491 MByte/day ARPREQUEST 129.582 MByte/day (includes UCAST4) ARPREPLY 1.118 MByte/day (includes UCAST4) IGMP 12.055 MByte/day ICMPv6 270.635 MByte/day IPv6-allnodes 9.641 MByte/day IPv6-RS 5.298 MByte/day IPv6-RA 6.928 MByte/day IPv6-NS 75.624 MByte/day IPv6-NA 0.918 MByte/day MLDQ 1.099 MByte/day MLDR 171.521 MByte/day MLDD 0.970 MByte/day MLD2R 8.273 MByte/day On Monday, January 2, 2017 12:11:02 PM CET Simon Wunderlich via Freifunk_info wrote:
Hallo Ihrs,
das ist systembedingt, da das Mesh uebers VPN gefahren wird. D.h. es gibt regelmaessig Routingprotokoll-Overhead (alle paar Sekunden ein Paket von jedem Knoten) und Broadcasts aus dem gesamten Netz (groesstenteils die Clients - DHCP Requests, ARP requests, etc). Das ist nicht so viel, aber stetig, und in der Summe (pro Tag) schon eine Menge. Das steigt natuerlich auch mit der Anzahl der aktiven Knoten und (Gesamt)Clients.
Das Problem ist durchaus bekannt, einfach mal nach "Gluon Grundrauschen" googlen.
Spontan habe ich leider keine Alternative fuer den LTE Uplink - eventuell koennen wir einen anderen fastd Server schalten wo "wenig" Nutzer drauf sind. Ich muss da mal drueber nachdenken ... Falls Ihr etwas seht, sagt Bescheid.
Viele Gruesse, Simon
On Monday, January 2, 2017 11:09:07 AM CET Alexander Heidenreich via
Freifunk_info wrote:
Hi,
ich hab mal das Trafficaccounting für diesen Client im Netz angeschalten. Da geht tatsächlich eine ganze Menge sinnloser Traffic übers Netz. Ob das jetzt 1GB/Tag ist, kann ich noch nicht abschätzen, aber aus der Hochrechnung der letzten Stunde würde ich sagen mindestens 500MB, Tendenz ist eher höher. Ich rechne da mal lieber vorsichtiger, weil bei mir sind tatsächlich Clients verbunden.
Völlig inakzeptabel, imho.
Grüße Alex
On Wednesday, 28 December 2016 11:30:00 CET Carsten Weber via Freifunk_info
wrote:
Hi,
im Zuge des Projekts, entlang der Kammloipe an den GK-Kamera-Standorten Freifunk-APs aufzustellen, wurden LTE-Router mit Vertrag über 30GB Datenvolumen beschafft.
Leider scheint der AP nur fürs Existieren schon sehr viel Datenvolumen zu verbrauchen, ich komme auf ein knappes Gigabyte pro Tag - und da sind noch keine Clients eingebucht gewesen. Mache ich was falsch? Kann man das ändern? Alleine fürs Betreiben ist der Vertrag damit ja schon fast ausgelastet.
Carsten _______________________________________________ Freifunk_info mailing list Freifunk_info@freifunk-vogtland.net http://mx.hateotu.de:8025/mailman/listinfo/freifunk_info
Vllt hilft es die Geschwindigkeit des Broadcast zu drosseln? :) Bitrate used for multicast/broadcast packets. mesh_mcast_rate Oder wird dann alles langsamer? Am 09.01.2017 um 17:47 schrieb Simon Wunderlich via Freifunk_info:
Hi,
wie zum letzten Treffen mal besprochen haben wir eine Analyse durchgefuehrt. Unten [1] gibts das Ergebnis. Wir hatten einen einzelnen AP isoliert, einen PC dazwischen gehaengt und saemtlichen Traffic uebers Wochenende gedumpt und offline analysiert.
Wie man sieht haben wir knapp 1 Gigabyte Grundrausch-Traffic pro Tag (bei unser derzeitigen Netzgroesse von ca. 200 online APs), wobei die zwei groessten Posten OGMs (Protokoll) und Broadcast Traffic sind. Broadcast teilt sich dann weiter auf in ARP Traffic (der schon durch DAT reduziert ist) und IPv6 Traffic. Dieser wiederum besteht wieder aus verschiedenen Komponenten, wobei MLD (Multicast Listenery Discovery) der groesste Posten ist.
Low Hanging fruits um das ganze merklich einzudaempfen sehe ich gerade nicht (ausser domains splitten), aber ich wuerd das erstmal sacken lassen ... :)
Viele Gruesse, Simon
[1]
UDP(TOTAL) 917.264 MByte/day OGM 498.585 MByte/day ICMP 0.529 MByte/day UCAST 3.701 MByte/day UCAST4 2.200 MByte/day BCAST 410.491 MByte/day ARPREQUEST 129.582 MByte/day (includes UCAST4) ARPREPLY 1.118 MByte/day (includes UCAST4) IGMP 12.055 MByte/day ICMPv6 270.635 MByte/day IPv6-allnodes 9.641 MByte/day IPv6-RS 5.298 MByte/day IPv6-RA 6.928 MByte/day IPv6-NS 75.624 MByte/day IPv6-NA 0.918 MByte/day MLDQ 1.099 MByte/day MLDR 171.521 MByte/day MLDD 0.970 MByte/day MLD2R 8.273 MByte/day
On Monday, January 2, 2017 12:11:02 PM CET Simon Wunderlich via Freifunk_info wrote:
Hallo Ihrs,
das ist systembedingt, da das Mesh uebers VPN gefahren wird. D.h. es gibt regelmaessig Routingprotokoll-Overhead (alle paar Sekunden ein Paket von jedem Knoten) und Broadcasts aus dem gesamten Netz (groesstenteils die Clients - DHCP Requests, ARP requests, etc). Das ist nicht so viel, aber stetig, und in der Summe (pro Tag) schon eine Menge. Das steigt natuerlich auch mit der Anzahl der aktiven Knoten und (Gesamt)Clients.
Das Problem ist durchaus bekannt, einfach mal nach "Gluon Grundrauschen" googlen.
Spontan habe ich leider keine Alternative fuer den LTE Uplink - eventuell koennen wir einen anderen fastd Server schalten wo "wenig" Nutzer drauf sind. Ich muss da mal drueber nachdenken ... Falls Ihr etwas seht, sagt Bescheid.
Viele Gruesse, Simon
On Monday, January 2, 2017 11:09:07 AM CET Alexander Heidenreich via
Freifunk_info wrote:
Hi,
ich hab mal das Trafficaccounting für diesen Client im Netz angeschalten. Da geht tatsächlich eine ganze Menge sinnloser Traffic übers Netz. Ob das jetzt 1GB/Tag ist, kann ich noch nicht abschätzen, aber aus der Hochrechnung der letzten Stunde würde ich sagen mindestens 500MB, Tendenz ist eher höher. Ich rechne da mal lieber vorsichtiger, weil bei mir sind tatsächlich Clients verbunden.
Völlig inakzeptabel, imho.
Grüße Alex
On Wednesday, 28 December 2016 11:30:00 CET Carsten Weber via Freifunk_info
wrote:
Hi,
im Zuge des Projekts, entlang der Kammloipe an den GK-Kamera-Standorten Freifunk-APs aufzustellen, wurden LTE-Router mit Vertrag über 30GB Datenvolumen beschafft.
Leider scheint der AP nur fürs Existieren schon sehr viel Datenvolumen zu verbrauchen, ich komme auf ein knappes Gigabyte pro Tag - und da sind noch keine Clients eingebucht gewesen. Mache ich was falsch? Kann man das ändern? Alleine fürs Betreiben ist der Vertrag damit ja schon fast ausgelastet.
Carsten _______________________________________________ Freifunk_info mailing list Freifunk_info@freifunk-vogtland.net http://mx.hateotu.de:8025/mailman/listinfo/freifunk_info
_______________________________________________ Freifunk_info mailing list Freifunk_info@freifunk-vogtland.net http://mx.hateotu.de:8025/mailman/listinfo/freifunk_info
Hi Denis, nein, hat damit leider nix zu tun - das Datenaufkommen kommt ja "vom Kabel" bzw. vom VPN, das wird nicht weniger bloss weil wir es langsamer (mit niedrigerer Modulation) uebers WLAN senden. Das verbraet dann nur mehr airtime. Der Broadcast Traffic ist prinzipiell von unseren Clients generierte Pakete, d.h. die Clients machen ARP-Requests, IPv6 MLDs, etc - und die muessen eben ausgeliefert werden. Das kriegen wir nicht langsamer, wir koennen bestenfalls filtern. Viele Gruesse, Simon On Monday, January 9, 2017 7:31:01 PM CET Denis Mitlacher via Freifunk_info wrote:
Vllt hilft es die Geschwindigkeit des Broadcast zu drosseln? :)
Bitrate used for multicast/broadcast packets. mesh_mcast_rate
Oder wird dann alles langsamer?
Am 09.01.2017 um 17:47 schrieb Simon Wunderlich via Freifunk_info:
Hi,
wie zum letzten Treffen mal besprochen haben wir eine Analyse durchgefuehrt. Unten [1] gibts das Ergebnis. Wir hatten einen einzelnen AP isoliert, einen PC dazwischen gehaengt und saemtlichen Traffic uebers Wochenende gedumpt und offline analysiert.
Wie man sieht haben wir knapp 1 Gigabyte Grundrausch-Traffic pro Tag (bei unser derzeitigen Netzgroesse von ca. 200 online APs), wobei die zwei groessten Posten OGMs (Protokoll) und Broadcast Traffic sind. Broadcast teilt sich dann weiter auf in ARP Traffic (der schon durch DAT reduziert ist) und IPv6 Traffic. Dieser wiederum besteht wieder aus verschiedenen Komponenten, wobei MLD (Multicast Listenery Discovery) der groesste Posten ist.
Low Hanging fruits um das ganze merklich einzudaempfen sehe ich gerade nicht (ausser domains splitten), aber ich wuerd das erstmal sacken lassen ... :)
Viele Gruesse,
Simon
[1]
UDP(TOTAL) 917.264 MByte/day OGM 498.585 MByte/day ICMP 0.529 MByte/day UCAST 3.701 MByte/day UCAST4 2.200 MByte/day BCAST 410.491 MByte/day
ARPREQUEST 129.582 MByte/day (includes UCAST4) ARPREPLY 1.118 MByte/day (includes UCAST4) IGMP 12.055 MByte/day ICMPv6 270.635 MByte/day
IPv6-allnodes 9.641 MByte/day IPv6-RS 5.298 MByte/day IPv6-RA 6.928 MByte/day IPv6-NS 75.624 MByte/day IPv6-NA 0.918 MByte/day MLDQ 1.099 MByte/day MLDR 171.521 MByte/day MLDD 0.970 MByte/day MLD2R 8.273 MByte/day
On Monday, January 2, 2017 12:11:02 PM CET Simon Wunderlich via Freifunk_info> wrote:
Hallo Ihrs,
das ist systembedingt, da das Mesh uebers VPN gefahren wird. D.h. es gibt regelmaessig Routingprotokoll-Overhead (alle paar Sekunden ein Paket von jedem Knoten) und Broadcasts aus dem gesamten Netz (groesstenteils die Clients - DHCP Requests, ARP requests, etc). Das ist nicht so viel, aber stetig, und in der Summe (pro Tag) schon eine Menge. Das steigt natuerlich auch mit der Anzahl der aktiven Knoten und (Gesamt)Clients.
Das Problem ist durchaus bekannt, einfach mal nach "Gluon Grundrauschen" googlen.
Spontan habe ich leider keine Alternative fuer den LTE Uplink - eventuell koennen wir einen anderen fastd Server schalten wo "wenig" Nutzer drauf sind. Ich muss da mal drueber nachdenken ... Falls Ihr etwas seht, sagt Bescheid.
Viele Gruesse,
Simon
On Monday, January 2, 2017 11:09:07 AM CET Alexander Heidenreich via
Freifunk_info wrote:
Hi,
ich hab mal das Trafficaccounting für diesen Client im Netz angeschalten. Da geht tatsächlich eine ganze Menge sinnloser Traffic übers Netz. Ob das jetzt 1GB/Tag ist, kann ich noch nicht abschätzen, aber aus der Hochrechnung der letzten Stunde würde ich sagen mindestens 500MB, Tendenz ist eher höher. Ich rechne da mal lieber vorsichtiger, weil bei mir sind tatsächlich Clients verbunden.
Völlig inakzeptabel, imho.
Grüße Alex
On Wednesday, 28 December 2016 11:30:00 CET Carsten Weber via Freifunk_info
wrote:
Hi,
im Zuge des Projekts, entlang der Kammloipe an den GK-Kamera-Standorten Freifunk-APs aufzustellen, wurden LTE-Router mit Vertrag über 30GB Datenvolumen beschafft.
Leider scheint der AP nur fürs Existieren schon sehr viel Datenvolumen zu verbrauchen, ich komme auf ein knappes Gigabyte pro Tag - und da sind noch keine Clients eingebucht gewesen. Mache ich was falsch? Kann man das ändern? Alleine fürs Betreiben ist der Vertrag damit ja schon fast ausgelastet.
Carsten _______________________________________________ Freifunk_info mailing list Freifunk_info@freifunk-vogtland.net http://mx.hateotu.de:8025/mailman/listinfo/freifunk_info
_______________________________________________ Freifunk_info mailing list Freifunk_info@freifunk-vogtland.net http://mx.hateotu.de:8025/mailman/listinfo/freifunk_info
Hm, Freifunk sollte ja generell nicht filtern. Aber so Broadcasts ala „ist ein Drucker im Netz“ oder „Apple TV bitte melde dich“ könnten wir doch filtern, oder? Können wir das und würde das etwas bringen? VG, Abdré Gesendet von meinem Windows 10 Phone Von: Simon Wunderlich via Freifunk_info Gesendet: Montag, 9. Januar 2017 20:49 An: freifunk_info@freifunk-vogtland.net; info@freifunk-vogtland.net Cc: Simon Wunderlich Betreff: Re: [Freifunk_info] Stnadby-Traffic eines FFV-APs sehr hoch Hi Denis, nein, hat damit leider nix zu tun - das Datenaufkommen kommt ja "vom Kabel" bzw. vom VPN, das wird nicht weniger bloss weil wir es langsamer (mit niedrigerer Modulation) uebers WLAN senden. Das verbraet dann nur mehr airtime. Der Broadcast Traffic ist prinzipiell von unseren Clients generierte Pakete, d.h. die Clients machen ARP-Requests, IPv6 MLDs, etc - und die muessen eben ausgeliefert werden. Das kriegen wir nicht langsamer, wir koennen bestenfalls filtern. Viele Gruesse, Simon On Monday, January 9, 2017 7:31:01 PM CET Denis Mitlacher via Freifunk_info wrote:
Vllt hilft es die Geschwindigkeit des Broadcast zu drosseln? :)
Bitrate used for multicast/broadcast packets. mesh_mcast_rate
Oder wird dann alles langsamer?
Am 09.01.2017 um 17:47 schrieb Simon Wunderlich via Freifunk_info:
Hi,
wie zum letzten Treffen mal besprochen haben wir eine Analyse durchgefuehrt. Unten [1] gibts das Ergebnis. Wir hatten einen einzelnen AP isoliert, einen PC dazwischen gehaengt und saemtlichen Traffic uebers Wochenende gedumpt und offline analysiert.
Wie man sieht haben wir knapp 1 Gigabyte Grundrausch-Traffic pro Tag (bei unser derzeitigen Netzgroesse von ca. 200 online APs), wobei die zwei groessten Posten OGMs (Protokoll) und Broadcast Traffic sind. Broadcast teilt sich dann weiter auf in ARP Traffic (der schon durch DAT reduziert ist) und IPv6 Traffic. Dieser wiederum besteht wieder aus verschiedenen Komponenten, wobei MLD (Multicast Listenery Discovery) der groesste Posten ist.
Low Hanging fruits um das ganze merklich einzudaempfen sehe ich gerade nicht (ausser domains splitten), aber ich wuerd das erstmal sacken lassen ... :)
Viele Gruesse,
Simon
[1]
UDP(TOTAL) 917.264 MByte/day OGM 498.585 MByte/day ICMP 0.529 MByte/day UCAST 3.701 MByte/day UCAST4 2.200 MByte/day BCAST 410.491 MByte/day
ARPREQUEST 129.582 MByte/day (includes UCAST4) ARPREPLY 1.118 MByte/day (includes UCAST4) IGMP 12.055 MByte/day ICMPv6 270.635 MByte/day
IPv6-allnodes 9.641 MByte/day IPv6-RS 5.298 MByte/day IPv6-RA 6.928 MByte/day IPv6-NS 75.624 MByte/day IPv6-NA 0.918 MByte/day MLDQ 1.099 MByte/day MLDR 171.521 MByte/day MLDD 0.970 MByte/day MLD2R 8.273 MByte/day
On Monday, January 2, 2017 12:11:02 PM CET Simon Wunderlich via Freifunk_info> wrote:
Hallo Ihrs,
das ist systembedingt, da das Mesh uebers VPN gefahren wird. D.h. es gibt regelmaessig Routingprotokoll-Overhead (alle paar Sekunden ein Paket von jedem Knoten) und Broadcasts aus dem gesamten Netz (groesstenteils die Clients - DHCP Requests, ARP requests, etc). Das ist nicht so viel, aber stetig, und in der Summe (pro Tag) schon eine Menge. Das steigt natuerlich auch mit der Anzahl der aktiven Knoten und (Gesamt)Clients.
Das Problem ist durchaus bekannt, einfach mal nach "Gluon Grundrauschen" googlen.
Spontan habe ich leider keine Alternative fuer den LTE Uplink - eventuell koennen wir einen anderen fastd Server schalten wo "wenig" Nutzer drauf sind. Ich muss da mal drueber nachdenken ... Falls Ihr etwas seht, sagt Bescheid.
Viele Gruesse,
Simon
On Monday, January 2, 2017 11:09:07 AM CET Alexander Heidenreich via
Freifunk_info wrote:
Hi,
ich hab mal das Trafficaccounting für diesen Client im Netz angeschalten. Da geht tatsächlich eine ganze Menge sinnloser Traffic übers Netz. Ob das jetzt 1GB/Tag ist, kann ich noch nicht abschätzen, aber aus der Hochrechnung der letzten Stunde würde ich sagen mindestens 500MB, Tendenz ist eher höher. Ich rechne da mal lieber vorsichtiger, weil bei mir sind tatsächlich Clients verbunden.
Völlig inakzeptabel, imho.
Grüße Alex
On Wednesday, 28 December 2016 11:30:00 CET Carsten Weber via Freifunk_info
wrote:
Hi,
im Zuge des Projekts, entlang der Kammloipe an den GK-Kamera-Standorten Freifunk-APs aufzustellen, wurden LTE-Router mit Vertrag über 30GB Datenvolumen beschafft.
Leider scheint der AP nur fürs Existieren schon sehr viel Datenvolumen zu verbrauchen, ich komme auf ein knappes Gigabyte pro Tag - und da sind noch keine Clients eingebucht gewesen. Mache ich was falsch? Kann man das ändern? Alleine fürs Betreiben ist der Vertrag damit ja schon fast ausgelastet.
Carsten _______________________________________________ Freifunk_info mailing list Freifunk_info@freifunk-vogtland.net http://mx.hateotu.de:8025/mailman/listinfo/freifunk_info
_______________________________________________ Freifunk_info mailing list Freifunk_info@freifunk-vogtland.net http://mx.hateotu.de:8025/mailman/listinfo/freifunk_info
Glaube nicht. Das ist ja das Ergebnis einer Offline-Messung. Ich verstehe das so, dass da kein Client dran hing. Am 09.01.2017 um 21:06 schrieb andre.fiedler--- via Freifunk_info:
Hm, Freifunk sollte ja generell nicht filtern. Aber so Broadcasts ala „ist ein Drucker im Netz“ oder „Apple TV bitte melde dich“ könnten wir doch filtern, oder? Können wir das und würde das etwas bringen?
VG,
Abdré
Gesendet von meinem Windows 10 Phone
*Von: *Simon Wunderlich via Freifunk_info <mailto:freifunk_info@freifunk-vogtland.net> *Gesendet: *Montag, 9. Januar 2017 20:49 *An: *freifunk_info@freifunk-vogtland.net <mailto:freifunk_info@freifunk-vogtland.net>; info@freifunk-vogtland.net <mailto:info@freifunk-vogtland.net> *Cc: *Simon Wunderlich <mailto:sw@simonwunderlich.de> *Betreff: *Re: [Freifunk_info] Stnadby-Traffic eines FFV-APs sehr hoch
Hi Denis,
nein, hat damit leider nix zu tun - das Datenaufkommen kommt ja "vom Kabel"
bzw. vom VPN, das wird nicht weniger bloss weil wir es langsamer (mit
niedrigerer Modulation) uebers WLAN senden. Das verbraet dann nur mehr
airtime.
Der Broadcast Traffic ist prinzipiell von unseren Clients generierte Pakete,
d.h. die Clients machen ARP-Requests, IPv6 MLDs, etc - und die muessen eben
ausgeliefert werden. Das kriegen wir nicht langsamer, wir koennen bestenfalls
filtern.
Viele Gruesse,
Simon
On Monday, January 9, 2017 7:31:01 PM CET Denis Mitlacher via Freifunk_info
wrote:
Vllt hilft es die Geschwindigkeit des Broadcast zu drosseln? :)
Bitrate used for multicast/broadcast packets.
mesh_mcast_rate
Oder wird dann alles langsamer?
Am 09.01.2017 um 17:47 schrieb Simon Wunderlich via Freifunk_info:
Hi,
wie zum letzten Treffen mal besprochen haben wir eine Analyse
durchgefuehrt. Unten [1] gibts das Ergebnis. Wir hatten einen einzelnen
AP isoliert, einen PC dazwischen gehaengt und saemtlichen Traffic uebers
Wochenende gedumpt und offline analysiert.
Wie man sieht haben wir knapp 1 Gigabyte Grundrausch-Traffic pro Tag (bei
unser derzeitigen Netzgroesse von ca. 200 online APs), wobei die zwei
groessten Posten OGMs (Protokoll) und Broadcast Traffic sind. Broadcast
teilt sich dann weiter auf in ARP Traffic (der schon durch DAT reduziert
ist) und IPv6 Traffic. Dieser wiederum besteht wieder aus verschiedenen
Komponenten, wobei MLD (Multicast Listenery Discovery) der groesste
Posten ist.
Low Hanging fruits um das ganze merklich einzudaempfen sehe ich gerade
nicht (ausser domains splitten), aber ich wuerd das erstmal sacken lassen
... :)
Viele Gruesse,
Simon
[1]
UDP(TOTAL) 917.264 MByte/day
OGM 498.585 MByte/day
ICMP 0.529 MByte/day
UCAST 3.701 MByte/day
UCAST4 2.200 MByte/day
BCAST 410.491 MByte/day
ARPREQUEST 129.582 MByte/day (includes UCAST4)
ARPREPLY 1.118 MByte/day (includes UCAST4)
IGMP 12.055 MByte/day
ICMPv6 270.635 MByte/day
IPv6-allnodes 9.641 MByte/day
IPv6-RS 5.298 MByte/day
IPv6-RA 6.928 MByte/day
IPv6-NS 75.624 MByte/day
IPv6-NA 0.918 MByte/day
MLDQ 1.099 MByte/day
MLDR 171.521 MByte/day
MLDD 0.970 MByte/day
MLD2R 8.273 MByte/day
On Monday, January 2, 2017 12:11:02 PM CET Simon Wunderlich via
Freifunk_info>
wrote:
Hallo Ihrs,
das ist systembedingt, da das Mesh uebers VPN gefahren wird. D.h. es gibt
regelmaessig Routingprotokoll-Overhead (alle paar Sekunden ein Paket von
jedem Knoten) und Broadcasts aus dem gesamten Netz (groesstenteils die
Clients - DHCP Requests, ARP requests, etc). Das ist nicht so viel, aber
stetig, und in der Summe (pro Tag) schon eine Menge. Das steigt
natuerlich
auch mit der Anzahl der aktiven Knoten und (Gesamt)Clients.
Das Problem ist durchaus bekannt, einfach mal nach "Gluon Grundrauschen"
googlen.
Spontan habe ich leider keine Alternative fuer den LTE Uplink - eventuell
koennen wir einen anderen fastd Server schalten wo "wenig" Nutzer drauf
sind. Ich muss da mal drueber nachdenken ... Falls Ihr etwas seht, sagt
Bescheid.
Viele Gruesse,
Simon
On Monday, January 2, 2017 11:09:07 AM CET Alexander Heidenreich via
Freifunk_info wrote:
Hi,
ich hab mal das Trafficaccounting für diesen Client im Netz
angeschalten.
Da geht tatsächlich eine ganze Menge sinnloser Traffic übers Netz. Ob
das
jetzt 1GB/Tag ist, kann ich noch nicht abschätzen, aber aus der
Hochrechnung der letzten Stunde würde ich sagen mindestens 500MB,
Tendenz
ist eher höher. Ich rechne da mal lieber vorsichtiger, weil bei mir sind
tatsächlich Clients verbunden.
Völlig inakzeptabel, imho.
Grüße
Alex
On Wednesday, 28 December 2016 11:30:00 CET Carsten Weber via
Freifunk_info
wrote:
Hi,
im Zuge des Projekts, entlang der Kammloipe an den GK-Kamera-Standorten
Freifunk-APs aufzustellen, wurden LTE-Router mit Vertrag über 30GB
Datenvolumen beschafft.
Leider scheint der AP nur fürs Existieren schon sehr viel Datenvolumen
zu verbrauchen, ich komme auf ein knappes Gigabyte pro Tag - und da
sind noch keine Clients eingebucht gewesen. Mache ich was falsch? Kann
man das ändern? Alleine fürs Betreiben ist der Vertrag damit ja schon
fast ausgelastet.
Carsten
_______________________________________________
Freifunk_info mailing list
Freifunk_info@freifunk-vogtland.net
_______________________________________________
Freifunk_info mailing list
Freifunk_info@freifunk-vogtland.net
_______________________________________________ Freifunk_info mailing list Freifunk_info@freifunk-vogtland.net http://mx.hateotu.de:8025/mailman/listinfo/freifunk_info
Richtig, da hing kein Client dran. Allerdings haben wir trotzdem alle Broadcast-Nachrichten von Knoten bekommen, die auch woanders dran haengen - weil die eben uebers VPN durchs gesamte Mesh verteilt werden. Ein Client fragt per ARP nach der MAC-Adresse des Gateways? Die Anfrage bekommt auch der Knoten in Klingenthal. Zu dem Punkt von Andre - soweit ich weiss wird der groebste Unfug (Bonjour, SMB, etc) bereits gefiltert. Wie genau weiss ich aber gerade nicht. In jedem Fall macht ICMPv6 (270 MB) und ARP (130 MB, abzgl UCAST4 wegen DAT ca. 128 MB) zusammen mit 398 MB den Grossteil des Broadcast Traffics (410 MB) aus. Der Rest scheint dann noch IGMP zu sein (12 MB), und dann bleibt da eigentlich nix mehr uebrig. :) Beim Broadcast koennen wir bzgl. Filtern also: * DAT verbessern um mehr ARPs zu filtern (technisch eher schwierig) * IPv6 weiter einschraenken, z.B. mit Linus' Multicast-Patches experimentieren (ja, das ist experimentell) Einfacher waer da vielleicht noch, broadcast domains zu splitten (siehe andere Mail). Viele Gruesse, Simon On Monday, January 9, 2017 9:16:54 PM CET Michael Gutmann via Freifunk_info wrote:
Glaube nicht. Das ist ja das Ergebnis einer Offline-Messung. Ich verstehe das so, dass da kein Client dran hing.
Am 09.01.2017 um 21:06 schrieb andre.fiedler--- via Freifunk_info:
Hm, Freifunk sollte ja generell nicht filtern. Aber so Broadcasts ala „ist ein Drucker im Netz“ oder „Apple TV bitte melde dich“ könnten wir doch filtern, oder? Können wir das und würde das etwas bringen?
VG,
Abdré
Gesendet von meinem Windows 10 Phone
*Von: *Simon Wunderlich via Freifunk_info <mailto:freifunk_info@freifunk-vogtland.net> *Gesendet: *Montag, 9. Januar 2017 20:49 *An: *freifunk_info@freifunk-vogtland.net <mailto:freifunk_info@freifunk-vogtland.net>; info@freifunk-vogtland.net <mailto:info@freifunk-vogtland.net> *Cc: *Simon Wunderlich <mailto:sw@simonwunderlich.de> *Betreff: *Re: [Freifunk_info] Stnadby-Traffic eines FFV-APs sehr hoch
Hi Denis,
nein, hat damit leider nix zu tun - das Datenaufkommen kommt ja "vom Kabel"
bzw. vom VPN, das wird nicht weniger bloss weil wir es langsamer (mit
niedrigerer Modulation) uebers WLAN senden. Das verbraet dann nur mehr
airtime.
Der Broadcast Traffic ist prinzipiell von unseren Clients generierte Pakete,
d.h. die Clients machen ARP-Requests, IPv6 MLDs, etc - und die muessen eben
ausgeliefert werden. Das kriegen wir nicht langsamer, wir koennen bestenfalls
filtern.
Viele Gruesse,
Simon
On Monday, January 9, 2017 7:31:01 PM CET Denis Mitlacher via Freifunk_info
wrote:
Vllt hilft es die Geschwindigkeit des Broadcast zu drosseln? :)
Bitrate used for multicast/broadcast packets.
mesh_mcast_rate
Oder wird dann alles langsamer?
Am 09.01.2017 um 17:47 schrieb Simon Wunderlich via Freifunk_info:
Hi,
wie zum letzten Treffen mal besprochen haben wir eine Analyse
durchgefuehrt. Unten [1] gibts das Ergebnis. Wir hatten einen einzelnen
AP isoliert, einen PC dazwischen gehaengt und saemtlichen Traffic uebers
Wochenende gedumpt und offline analysiert.
Wie man sieht haben wir knapp 1 Gigabyte Grundrausch-Traffic pro Tag
(bei
unser derzeitigen Netzgroesse von ca. 200 online APs), wobei die zwei
groessten Posten OGMs (Protokoll) und Broadcast Traffic sind. Broadcast
teilt sich dann weiter auf in ARP Traffic (der schon durch DAT reduziert
ist) und IPv6 Traffic. Dieser wiederum besteht wieder aus verschiedenen
Komponenten, wobei MLD (Multicast Listenery Discovery) der groesste
Posten ist.
Low Hanging fruits um das ganze merklich einzudaempfen sehe ich gerade
nicht (ausser domains splitten), aber ich wuerd das erstmal sacken
lassen
... :)
Viele Gruesse,
Simon
[1]
UDP(TOTAL) 917.264 MByte/day
OGM 498.585 MByte/day
ICMP 0.529 MByte/day
UCAST 3.701 MByte/day
UCAST4 2.200 MByte/day
BCAST 410.491 MByte/day
ARPREQUEST 129.582 MByte/day (includes UCAST4)
ARPREPLY 1.118 MByte/day (includes UCAST4)
IGMP 12.055 MByte/day
ICMPv6 270.635 MByte/day
IPv6-allnodes 9.641 MByte/day
IPv6-RS 5.298 MByte/day
IPv6-RA 6.928 MByte/day
IPv6-NS 75.624 MByte/day
IPv6-NA 0.918 MByte/day
MLDQ 1.099 MByte/day
MLDR 171.521 MByte/day
MLDD 0.970 MByte/day
MLD2R 8.273 MByte/day
On Monday, January 2, 2017 12:11:02 PM CET Simon Wunderlich via
Freifunk_info>
wrote:
Hallo Ihrs,
das ist systembedingt, da das Mesh uebers VPN gefahren wird. D.h.
es gibt
regelmaessig Routingprotokoll-Overhead (alle paar Sekunden ein
Paket von
jedem Knoten) und Broadcasts aus dem gesamten Netz (groesstenteils die
Clients - DHCP Requests, ARP requests, etc). Das ist nicht so viel,
aber
stetig, und in der Summe (pro Tag) schon eine Menge. Das steigt
natuerlich
auch mit der Anzahl der aktiven Knoten und (Gesamt)Clients.
Das Problem ist durchaus bekannt, einfach mal nach "Gluon
Grundrauschen"
googlen.
Spontan habe ich leider keine Alternative fuer den LTE Uplink -
eventuell
koennen wir einen anderen fastd Server schalten wo "wenig" Nutzer drauf
sind. Ich muss da mal drueber nachdenken ... Falls Ihr etwas seht, sagt
Bescheid.
Viele Gruesse,
Simon
On Monday, January 2, 2017 11:09:07 AM CET Alexander Heidenreich via
Freifunk_info wrote:
Hi,
ich hab mal das Trafficaccounting für diesen Client im Netz
angeschalten.
Da geht tatsächlich eine ganze Menge sinnloser Traffic übers Netz. Ob
das
jetzt 1GB/Tag ist, kann ich noch nicht abschätzen, aber aus der
Hochrechnung der letzten Stunde würde ich sagen mindestens 500MB,
Tendenz
ist eher höher. Ich rechne da mal lieber vorsichtiger, weil bei
mir sind
tatsächlich Clients verbunden.
Völlig inakzeptabel, imho.
Grüße
Alex
On Wednesday, 28 December 2016 11:30:00 CET Carsten Weber via
Freifunk_info
wrote: > Hi, > > > > im Zuge des Projekts, entlang der Kammloipe an den
GK-Kamera-Standorten
> Freifunk-APs aufzustellen, wurden LTE-Router mit Vertrag über 30GB > > Datenvolumen beschafft. > > > > Leider scheint der AP nur fürs Existieren schon sehr viel
Datenvolumen
> zu verbrauchen, ich komme auf ein knappes Gigabyte pro Tag - und da > > sind noch keine Clients eingebucht gewesen. Mache ich was falsch?
Kann
> man das ändern? Alleine fürs Betreiben ist der Vertrag damit ja > schon > > fast ausgelastet. > > > > Carsten > > _______________________________________________ > > Freifunk_info mailing list > > Freifunk_info@freifunk-vogtland.net > > http://mx.hateotu.de:8025/mailman/listinfo/freifunk_info
_______________________________________________
Freifunk_info mailing list
Freifunk_info@freifunk-vogtland.net
_______________________________________________ Freifunk_info mailing list Freifunk_info@freifunk-vogtland.net http://mx.hateotu.de:8025/mailman/listinfo/freifunk_info
Ich spinne mal bissl rum ;) Ist es machbar, und wenn ja, ist es sinnvoll, derartige Teilnetze zu "kapseln"? Also das Mesh auf der Kammloipe nicht unbedingt von Knoten in Plauen Kenntnis haben muss? Oder ist das das, was du mit "domains splitten" meinst, Simon? Wobei mir da grad ein Haken bewusst wird. Wie soll dann der Traffic via LTE entlastet werden, wenn das Mesh keine potentiellen Knoten in der Nachbarschaft kennt? Gibt es entlang der Kammloipe (das ist ja der Aufhänger der Diskussion) überhaupt die Möglichkeit "normale" Mesh-Verbindungen zu kabelgebundenen Routern aufzubauen? Wenn ja, will man sich diese ja nicht filtern. Oder gibt es in der Konfiguration etwas in der Art "Wenn LTE, dann weniger oft rumfragen"? Am 09.01.2017 um 17:47 schrieb Simon Wunderlich via Freifunk_info:
Hi,
wie zum letzten Treffen mal besprochen haben wir eine Analyse durchgefuehrt. Unten [1] gibts das Ergebnis. Wir hatten einen einzelnen AP isoliert, einen PC dazwischen gehaengt und saemtlichen Traffic uebers Wochenende gedumpt und offline analysiert.
Wie man sieht haben wir knapp 1 Gigabyte Grundrausch-Traffic pro Tag (bei unser derzeitigen Netzgroesse von ca. 200 online APs), wobei die zwei groessten Posten OGMs (Protokoll) und Broadcast Traffic sind. Broadcast teilt sich dann weiter auf in ARP Traffic (der schon durch DAT reduziert ist) und IPv6 Traffic. Dieser wiederum besteht wieder aus verschiedenen Komponenten, wobei MLD (Multicast Listenery Discovery) der groesste Posten ist.
Low Hanging fruits um das ganze merklich einzudaempfen sehe ich gerade nicht (ausser domains splitten), aber ich wuerd das erstmal sacken lassen ... :)
Viele Gruesse, Simon
[1]
UDP(TOTAL) 917.264 MByte/day OGM 498.585 MByte/day ICMP 0.529 MByte/day UCAST 3.701 MByte/day UCAST4 2.200 MByte/day BCAST 410.491 MByte/day ARPREQUEST 129.582 MByte/day (includes UCAST4) ARPREPLY 1.118 MByte/day (includes UCAST4) IGMP 12.055 MByte/day ICMPv6 270.635 MByte/day IPv6-allnodes 9.641 MByte/day IPv6-RS 5.298 MByte/day IPv6-RA 6.928 MByte/day IPv6-NS 75.624 MByte/day IPv6-NA 0.918 MByte/day MLDQ 1.099 MByte/day MLDR 171.521 MByte/day MLDD 0.970 MByte/day MLD2R 8.273 MByte/day
On Monday, January 2, 2017 12:11:02 PM CET Simon Wunderlich via Freifunk_info wrote:
Hallo Ihrs,
das ist systembedingt, da das Mesh uebers VPN gefahren wird. D.h. es gibt regelmaessig Routingprotokoll-Overhead (alle paar Sekunden ein Paket von jedem Knoten) und Broadcasts aus dem gesamten Netz (groesstenteils die Clients - DHCP Requests, ARP requests, etc). Das ist nicht so viel, aber stetig, und in der Summe (pro Tag) schon eine Menge. Das steigt natuerlich auch mit der Anzahl der aktiven Knoten und (Gesamt)Clients.
Das Problem ist durchaus bekannt, einfach mal nach "Gluon Grundrauschen" googlen.
Spontan habe ich leider keine Alternative fuer den LTE Uplink - eventuell koennen wir einen anderen fastd Server schalten wo "wenig" Nutzer drauf sind. Ich muss da mal drueber nachdenken ... Falls Ihr etwas seht, sagt Bescheid.
Viele Gruesse, Simon
On Monday, January 2, 2017 11:09:07 AM CET Alexander Heidenreich via
Freifunk_info wrote:
Hi,
ich hab mal das Trafficaccounting für diesen Client im Netz angeschalten. Da geht tatsächlich eine ganze Menge sinnloser Traffic übers Netz. Ob das jetzt 1GB/Tag ist, kann ich noch nicht abschätzen, aber aus der Hochrechnung der letzten Stunde würde ich sagen mindestens 500MB, Tendenz ist eher höher. Ich rechne da mal lieber vorsichtiger, weil bei mir sind tatsächlich Clients verbunden.
Völlig inakzeptabel, imho.
Grüße Alex
On Wednesday, 28 December 2016 11:30:00 CET Carsten Weber via Freifunk_info
wrote:
Hi,
im Zuge des Projekts, entlang der Kammloipe an den GK-Kamera-Standorten Freifunk-APs aufzustellen, wurden LTE-Router mit Vertrag über 30GB Datenvolumen beschafft.
Leider scheint der AP nur fürs Existieren schon sehr viel Datenvolumen zu verbrauchen, ich komme auf ein knappes Gigabyte pro Tag - und da sind noch keine Clients eingebucht gewesen. Mache ich was falsch? Kann man das ändern? Alleine fürs Betreiben ist der Vertrag damit ja schon fast ausgelastet.
Carsten _______________________________________________ Freifunk_info mailing list Freifunk_info@freifunk-vogtland.net http://mx.hateotu.de:8025/mailman/listinfo/freifunk_info
_______________________________________________ Freifunk_info mailing list Freifunk_info@freifunk-vogtland.net http://mx.hateotu.de:8025/mailman/listinfo/freifunk_info
Hi Michael, On Monday, January 9, 2017 9:17:40 PM CET Michael Gutmann via Freifunk_info wrote:
Ich spinne mal bissl rum ;)
Ist es machbar, und wenn ja, ist es sinnvoll, derartige Teilnetze zu "kapseln"? Also das Mesh auf der Kammloipe nicht unbedingt von Knoten in Plauen Kenntnis haben muss? Oder ist das das, was du mit "domains splitten" meinst, Simon?
ja, das ist grundsaetzlich die Idee - also Teilnetze ala ein Netz pro Stadt, oder die LTE-Knoten "abkapseln". Theoretisch scheinen das auch schon auch schon andere Communities zu machen, aber wir muessen mal schauen ob das fuer uns so passt. Da gibts schon noch einige Fallstricke, wir wollen ja weiterhin ein zusammenhaengendes Netz und eine einheitliche Firmware nutzen. Falls wir aber weiter sehr stark wachsen kommen wir frueher oder spaeter da ohnehin nicht drumrum.
Wobei mir da grad ein Haken bewusst wird. Wie soll dann der Traffic via LTE entlastet werden, wenn das Mesh keine potentiellen Knoten in der Nachbarschaft kennt?
Das Mesh wird ja auch ueber die VPN-Verbindung zu unseren Servern aufgebaut. Die Grundlast von der wir hier sprechen geht eben ueber diese VPN-Verbindung, da muss kein anderer Knoten in der Naehe sein. Sind in einem Netz weniger Knoten und/oder Clients, sinkt damit auch die Grundlast.
Gibt es entlang der Kammloipe (das ist ja der Aufhänger der Diskussion) überhaupt die Möglichkeit "normale" Mesh-Verbindungen zu kabelgebundenen Routern aufzubauen? Wenn ja, will man sich diese ja nicht filtern.
Soweit ich weiss ja, in Schoeneck gibts wohl dann Verbindung zum Skihang oder so.
Oder gibt es in der Konfiguration etwas in der Art "Wenn LTE, dann weniger oft rumfragen"?
Naja, der Punkt ist ja dass alle andere Knoten weiterhin in ihren regelmaessigen Abstaenden rumfragen - und die kommen dann auch ueber die LTE Verbindung bei den mobilen Knoten an. Die bekommen das auch "ungefragt". :) Viele Gruesse, Simon
Am 09.01.2017 um 17:47 schrieb Simon Wunderlich via Freifunk_info:
Hi,
wie zum letzten Treffen mal besprochen haben wir eine Analyse durchgefuehrt. Unten [1] gibts das Ergebnis. Wir hatten einen einzelnen AP isoliert, einen PC dazwischen gehaengt und saemtlichen Traffic uebers Wochenende gedumpt und offline analysiert.
Wie man sieht haben wir knapp 1 Gigabyte Grundrausch-Traffic pro Tag (bei unser derzeitigen Netzgroesse von ca. 200 online APs), wobei die zwei groessten Posten OGMs (Protokoll) und Broadcast Traffic sind. Broadcast teilt sich dann weiter auf in ARP Traffic (der schon durch DAT reduziert ist) und IPv6 Traffic. Dieser wiederum besteht wieder aus verschiedenen Komponenten, wobei MLD (Multicast Listenery Discovery) der groesste Posten ist.
Low Hanging fruits um das ganze merklich einzudaempfen sehe ich gerade nicht (ausser domains splitten), aber ich wuerd das erstmal sacken lassen ... :)
Viele Gruesse,
Simon
[1]
UDP(TOTAL) 917.264 MByte/day OGM 498.585 MByte/day ICMP 0.529 MByte/day UCAST 3.701 MByte/day UCAST4 2.200 MByte/day BCAST 410.491 MByte/day
ARPREQUEST 129.582 MByte/day (includes UCAST4) ARPREPLY 1.118 MByte/day (includes UCAST4) IGMP 12.055 MByte/day ICMPv6 270.635 MByte/day
IPv6-allnodes 9.641 MByte/day IPv6-RS 5.298 MByte/day IPv6-RA 6.928 MByte/day IPv6-NS 75.624 MByte/day IPv6-NA 0.918 MByte/day MLDQ 1.099 MByte/day MLDR 171.521 MByte/day MLDD 0.970 MByte/day MLD2R 8.273 MByte/day
On Monday, January 2, 2017 12:11:02 PM CET Simon Wunderlich via Freifunk_info> wrote:
Hallo Ihrs,
das ist systembedingt, da das Mesh uebers VPN gefahren wird. D.h. es gibt regelmaessig Routingprotokoll-Overhead (alle paar Sekunden ein Paket von jedem Knoten) und Broadcasts aus dem gesamten Netz (groesstenteils die Clients - DHCP Requests, ARP requests, etc). Das ist nicht so viel, aber stetig, und in der Summe (pro Tag) schon eine Menge. Das steigt natuerlich auch mit der Anzahl der aktiven Knoten und (Gesamt)Clients.
Das Problem ist durchaus bekannt, einfach mal nach "Gluon Grundrauschen" googlen.
Spontan habe ich leider keine Alternative fuer den LTE Uplink - eventuell koennen wir einen anderen fastd Server schalten wo "wenig" Nutzer drauf sind. Ich muss da mal drueber nachdenken ... Falls Ihr etwas seht, sagt Bescheid.
Viele Gruesse,
Simon
On Monday, January 2, 2017 11:09:07 AM CET Alexander Heidenreich via
Freifunk_info wrote:
Hi,
ich hab mal das Trafficaccounting für diesen Client im Netz angeschalten. Da geht tatsächlich eine ganze Menge sinnloser Traffic übers Netz. Ob das jetzt 1GB/Tag ist, kann ich noch nicht abschätzen, aber aus der Hochrechnung der letzten Stunde würde ich sagen mindestens 500MB, Tendenz ist eher höher. Ich rechne da mal lieber vorsichtiger, weil bei mir sind tatsächlich Clients verbunden.
Völlig inakzeptabel, imho.
Grüße Alex
On Wednesday, 28 December 2016 11:30:00 CET Carsten Weber via Freifunk_info
wrote:
Hi,
im Zuge des Projekts, entlang der Kammloipe an den GK-Kamera-Standorten Freifunk-APs aufzustellen, wurden LTE-Router mit Vertrag über 30GB Datenvolumen beschafft.
Leider scheint der AP nur fürs Existieren schon sehr viel Datenvolumen zu verbrauchen, ich komme auf ein knappes Gigabyte pro Tag - und da sind noch keine Clients eingebucht gewesen. Mache ich was falsch? Kann man das ändern? Alleine fürs Betreiben ist der Vertrag damit ja schon fast ausgelastet.
Carsten _______________________________________________ Freifunk_info mailing list Freifunk_info@freifunk-vogtland.net http://mx.hateotu.de:8025/mailman/listinfo/freifunk_info
_______________________________________________ Freifunk_info mailing list Freifunk_info@freifunk-vogtland.net http://mx.hateotu.de:8025/mailman/listinfo/freifunk_info
participants (6)
-
Alexander Heidenreich -
andre.fiedler＠me.com -
Carsten Weber -
Denis Mitlacher -
Michael Gutmann -
Simon Wunderlich