Auslastung des eigenen Segments ansehen

[sparkie]

sondern sich einen Zeitstempel zu jeder SID speichert, und dann aufsummiert, wie viele unterschiedliche SIDs man in den letzten 30 Sekunden gesehen hat (was der Standard-Timeout ist, einen Ranging-Zeitschlitz zu bekommen).

und wieso macht man das so umstaendlich?

die meisten Pakete duerften ja wohl in Echtzeit eintreffen (zumindest was die hier geforderte Genauigkeit anbetrifft).

warum also nicht gleich 30s lange messen und anschliessend die unterschiedlichen SIDs innerhalb dieser 30s Messzeit aufsummieren?

[Flole]

Vermutlich weil es so ein fließendes Zeitfenster ist, anders wäre es immer eine 30 Sekunden Messung nach der anderen. Der Aufwand da einen Zeitstempel mit einzubauen dürfte da nicht so groß sein. Funktionieren wird wohl beides, ob man nun den Zeitstempel des Starts der Messung vergleicht oder einen Zeitstempel pro SID dürfte egal sein. Ich würde aber auch das fließende Zeitfenster bevorzugen.

[sparkie]

ok danke, klingt plausibel

wenn ich mal Zeit habe kann ich es testweise in den docsis-ts-scanner einbauen.

[robert_s]

Ein Tutorial wie man einen Docsis Parser programmiert? Standard lesen und dann entsprechend umsetzen. Eventuell Wiresharks Parser als Vorlage nutzen. Ich glaube besonders anders hat Robert das auch nicht gemacht, oder?

Ich habe mir vor Jahren mal eine C++ Klasse gebastelt, um mit Linux DVBAPI Tunern Datenströme empfangen zu können, und mir damit ein paar C/C++ Tools gebastelt, z.B. um einen Multiplex komplett zu dumpen, für eine Sendersuche, und einen kleinen "Remote Tuning" Server, der auf einen angeforderten Transponder(oder Kanal) tunet und Signalwerte liefert - und als Pendant dazu eine Android-App, welche die dann darstellt, um damit im Garten die Sat-Schüssel feintunen zu können.

Und als ich zum DOCSIS-Thema kam, habe ich mir eben C++ Klassen gebastelt, um den DOCSIS-Stream und die Management-Nachrichten zu parsen, die ich da so fand...

[treefiddy]

Ein Tutorial wie man einen Docsis Parser programmiert? Standard lesen und dann entsprechend umsetzen. Eventuell Wiresharks Parser als Vorlage nutzen. Ich glaube besonders anders hat Robert das auch nicht gemacht, oder?

Ich habe mir vor Jahren mal eine C++ Klasse gebastelt, um mit Linux DVBAPI Tunern Datenströme empfangen zu können, und mir damit ein paar C/C++ Tools gebastelt, z.B. um einen Multiplex komplett zu dumpen, für eine Sendersuche, und einen kleinen "Remote Tuning" Server, der auf einen angeforderten Transponder(oder Kanal) tunet und Signalwerte liefert - und als Pendant dazu eine Android-App, welche die dann darstellt, um damit im Garten die Sat-Schüssel feintunen zu können.

Und als ich zum DOCSIS-Thema kam, habe ich mir eben C++ Klassen gebastelt, um den DOCSIS-Stream und die Management-Nachrichten zu parsen, die ich da so fand...

Du nerd.

[pcfreakxd]

Läuft jetzt endlich bei mir ordentlich

[pcfreakxd]

Nachts ist die Auslastung bei mir lächerlich gering. Den Spike habe ich durch einen 10GB Download ausgelöst.

CableLoadMonitor_1h.png

[HanzDampf]

Hallo zusammen,

Nachdem seit kurzem auf meiner VF WEST Fritz Mietbox 6591 jetzt auch mit der neuen Firmware 7.22 das DVB-C Streaming funktioniert,
habe ich für ein einfaches dauerhaftes Segment Monitor ohne extra DVB-C Hardware folgendes ausprobiert:
Auf einem Banana Pi Linux wird mittels VLC Commandline Tool cvlc ein DOCSIS 3.0 DS Kanal per rtsp dauerhaft an den Pi gestreamt.
Sonst läuft auf dem Pi nichts wesentliches, was Netzwerktraffic verursacht. Fast sämtlicher eingehender Netzwerktraffic im PI ist somit der aktuell auf dem DOCSIS Kanal übertragene Nutzdatenanteil
(NULL Packets konnte ich per Stream nicht übertragen lassen, auch wenn die Null PID mit aufgerufen wurde)

Visualisierung/Protokollierung erfolgt dann einfach mitttels den in Vielzahl vorhandenen Tools zum Netzwerkmonitoring
(ich habe dieses mit Perl/RRDTool hier verwendet, da schön kompakt und einfach: https://martybugs.net/linux/rrdtool/ )

Beispiel Aufruf vlc commandline für Kanal 570 MHz, damit das dauerhaft läuft, speichern des Streams in /dev/null (cvlc ist Bestandteil Package vlc)

Code: Alles auswählen

cvlc "rtsp://fritz.box:554/?avm=1&freq=570&bw=8&msys=dvbc&mtype=256qam&sr=6952&specinv=1&pids=8190" --sout=file/ts:/dev/null

(Als reine Softwarelösung ohne extra Hardware könnte das ganze auch in einer virtuellen Maschine Virtualbox o. ä. laufen, Problem hier allerdings evtl gesharede Netzwerkverbindung)

Das dauerhafte Mitschneiden des rtsp Streams hat nur mit VLC funktioniert, anders Tools wie FFMPEG sind abgebrochen, da Stream kein Audio/Video enthielt.
Lässt sich der rtsp stream außer mit vlc noch anderweitig permanent übertragen?

Die Fritzbox kann ja 4 Streams, es lässt sich aber nur ein Kanal per rtsp pro Rechner gleichzeitig übertragen. Wird cvlc nochmal gestartet, bricht sogar der bereits laufen rtsp Stream ab.
Ist diese Beschränkung auf ein Stream ja Rechner bei rtsp generell der Fall?

viele Grüße, HanzDampf

Ergebnis erster Wurf (Lücken beabsichtigt )

eth0-2hour.png

[Modular]

Jetzt ist die 33%-Marke geknackt, es gibt aber kaum noch Überraschungen:

Code: Alles auswählen

 969 active cable modems on all UCIDs (100 bridges, 98 active bridged devices)

 323 [ 33%] active cable modems with identified tariffs (182 [56%] with WLAN hotspot):
 101 [ 31%] Red Internet & Phone Cable 200 (70 with WLAN hotspot)
  57 [ 17%] Red Internet & Phone Cable 100 (27 with WLAN hotspot)
  99 [ 30%] Red Internet & Phone Cable 32 (57 with WLAN hotspot)
  41 [ 12%] Red Internet & Phone Cable 25 (24 with WLAN hotspot)
   1 [  0%] Red Internet & Phone Cable 10
   7 [  2%] Red Internet & Phone Business Cable 200
   1 [  0%] Red Internet & Phone Business Cable 100
   5 [  1%] Red Internet & Phone Business Cable  50 (3 with WLAN hotspot)
   1 [  0%] Red Internet Cable 200 ? (200/12.1Mbps) (1 with WLAN hotspot)
   1 [  0%] Red Internetanschluss 16 [EOM]
   5 [  1%] Red Phone ? (512/256kbps)
   1 [  0%] Red Phone ? (128/128kbps)
   3 [  0%] Red Phone ? (64/64kbps)

Known subscribed bandwidth: 35993380000/2521150000 bps
Estimated total subscribed bandwidth: 107980140000/7563450000 bps
Estimated oversubscription ratio: 100/70-210 times

Es bleibt bei 33% 200Mbps-Kunden und >50% Kunden mit >= 100Mbps, und auch bei einem hochgerechneten Überbuchungsfaktor von 100.

Neu ist eigentlich nur, dass sich tatsächlich noch ein Kunde mit dem alten "Internetanschluss 16" (16/1Mbps) gefunden hat...

Hallo,
hast du dein(e) Skript(e) noch? Bzw. wurde es irgendwo veröffentlicht?

LG

[Flole]

Mich würde ja mal interessieren was passiert, wenn man der GitHub Copilot KI das Tool von Robert vorwirft und sagt "bau mal auf RTSP um". Erfahrungsgemäß ist die KI erstaunlich gut, keineswegs fehlerfrei aber etwas, was irgendwie funktioniert, hat man am Ende eigentlich immer und kann dann noch ein paar mal nachsteuern und schon hat man ein durchaus brauchbares Ergebnis.