Erfahrungen SvxServer

  • Hallo zusammen,


    die aktuelle Version des SvxServer läuft inzwischen sehr gut. Die bekannten "Problemchen" des SvxServer (aus einem älteren Thread) führe ich übersichtshalber hier noch einmal auf:


    Quote

    - Manchmal gibt es "Mikroaussetzer" im Audio
    - Ganz selten beendet sich der SvxServer selbstständig und muss dann neu gestartet werden
    - Wenn die Verbindung zum Server verloren geht, während ein Client gerade ein NetRX-Signal aussendet, bleibt dieser auf Dauersendung


    Die Mikroaussetzer sind bisher nicht mehr aufgefallen. Vermutlich lag es an schlechten IP-Verbindungen oder hohen Latzenzzeiten. Das selbstständige Beenden des SvxServer tritt ebenfalls nur sehr selten auf. Durch den Einbau in eine Endlosschleife (siehe hier) wird der SvxServer nach dem Beenden sofort wieder neu gestartet. Damit ist das Problem nicht mehr ganz so tragisch.


    Der letzte Punkt (Dauersendung bei Verbindungsproblemen) ist jedoch etwas unschön, auch wenn es recht selten auftritt: Wenn ein Client gerade ein Signal empfängt, via SvxServer zu allen anderen Clients sendet und dabei die Verbindung zum SvxServer verloren geht, bleibt bei allen Clients die PTT weiterhin betätigt.


    Kommt die Verbindung wieder, ist es abhängig davon, ob die alte oder eine neue TCP-Verbindung verwendet wird. Bei der alten Verbindung reicht ein "RX off" Signal des Clients aus, um die Aussendung aller anderen Clients wieder zu beenden. Bei einer neuen TCP-Verbindung wird der Client jedoch nicht mehr als die gleiche Station angesehen und somit bleibt die Daueraussendung bestehen. In diesem Fall muss SvxLink auf allen Clients per Hand neu gestartet werden.


    Ähnlich ist es, wenn bei einem gerade sendenden Client die Netzwerkverbindung verloren geht. Dann bleibt dieser ebenfalls auf Dauersendung.


    Schönen Gruß
    Frank, DL3DCW

  • Hallo zusammen,


    nachdem Adi die Probleme mit dem zeitweisen Verlust ganzer Durchgänge (siehe hier) super behoben hat, läuft unser kleiner Relaisverbund auf Basis des SvxServer nun sehr stabil.


    Inzwischen wurde sogar eine Station aus dem Münchner Raum an den Server im Ruhrgebiet angebunden. Auch hier wird ausschließlich das HAMNET eingesetzt. Die Signale gehen also beim Client über die Antenne 'raus und kommen beim Server über die Antenne wieder 'rein. Die Verbindung klappt perfekt, die Sprachqualität (OPUS-Codec) ist hervorragend und das Ganze funktioniert bisher völlig ohne irgendwelche Aussetzer.


    Unser Verbund umfasst damit bisher neun aktive Standorte (siehe hier). Bei allen wird ein Raspberry Pi (HAMServerPi RadioBox/RepeaterBox) eingesetzt. Der SvxServer läuft ganz locker problemlos auf einem der Clients mit.


    Schönen Gruß
    Frank, DL3DCW

  • Hallo Frank,


    freut mich sehr, dass es bei Euch so gut läuft. Ich möchte Dich bitten das noch gut zu beobachten. Leider habe ich hier noch einige Probleme, die ich noch untersuchen muß. Das hatte ich ja schon anderweitig geschrieben. Ich will schon, dass es unter allen Umständen verläßlich funktioniert und da bin ich momentan auch bei der Version die Du einsetzt noch nicht ganz überzeugt davon.


    vy 73s de Adi, DL1HRC

  • Hallo Adi,


    die "kleineren" Probleme, welche uns bisher noch aufgefallen sind, habe ich ja weiter oben schon einmal beschrieben. Wenn diese gelöst werden, wäre der SvxServer natürlich absolut perfekt! Durch entsprechende "Workarounds" fangen wir das im Moment so weit wie möglich ab:


    • Ganz selten beendet sich der SvxServer selbstständig und muss dann neu gestartet werden
    • Wenn die Netzwerkverbindung zum Server verloren geht, während ein Client gerade dorthin sendet, bleiben alle anderen Clients auf Dauersendung


    Das zeitweise Beenden des Svxservers fangen wir durch eine "Endlosschleife" ab. Damit wird der Server nach dem Beenden automatisch wieder neu gestartet.


    Das Problem mit der Dauersendung aller Clients bei Netzwerkproblemen lässt sich nur durch einen manuellen Neustart von SvxLink auf allen Clients beheben. Ist natürlich umständlich und auch nicht ganz so schön. Vor allem, wenn man es mal nicht sofort merkt und alle Systeme die ganze Nacht (oder noch länger) ohne weitere Funktion durchsenden ...


    Schönen Gruß
    Frank, DL3DCW

  • Ich muß leider einen Absturz der aktuellen Programmversion vermelden, die letzten Logzeilen waren ....


    13.12.2015 19:33:35: NO Master:13.41.200.242
    13.12.2015 19:33:35: ... 13.41.200.242.sql_open=0
    13.12.2015 19:33:36: ... s->mode() = 2, resetting Master
    13.12.2015 19:33:36: ... 13.41..126.191.sql_open=0
    13.12.2015 19:33:36: ... s->mode() = 2, resetting Master
    13.12.2015 19:33:36: ... 13.41.200.242.sql_open=0
    13.12.2015 19:33:36: ... s->mode() = 2, resetting Master
    13.12.2015 19:33:36: ... 192.168.222.21x.sql_open=0
    13.12.2015 19:33:36: ... s->mode() = 1, setting Master: 192.168.10.181
    13.12.2015 19:33:36: IS Master:192.168.10.181
    13.12.2015 19:33:36: ... 192.168.222.21x.sql_open=1
    13.12.2015 19:33:37: ... s->mode() = 1, setting Master: 13.41..126.191
    13.12.2015 19:33:37: ... 13.41..126.191.sql_open=1
    13.12.2015 19:33:37: ... s->mode() = 1, setting Master: 13.41.200.242
    13.12.2015 19:33:37: ... 13.41.200.242.sql_open=1


    Die Loop im Cronjob kommt dann wieder ein.

  • Vielen Dank für die Info, ist natürlich nicht so aussagekräftig. Besser wäre es das Ganze in einer Debugumgebung laufen zu lassen. Aber ich bin hier auch aktiv und habe schon wieder jede Menge umgebaut. Bitte noch etwas Geduld...alte Männer sind nicht mehr so schnell :) Habe hier eine Laptop-/PC-/BananaPi-Farm aufgebaut und gehe damit auf Fehlersuche.


    Ich habe das Debugging erweitert (für webbasierte Ausgaben), so dass die Daten besser ausgewertet werden können, das sieht das etwa so aus (durch die Pipes als Trennung kann man besser greppen und für php o.ä. aufbereiten):



    Das wird dann auch per pty-device gehen (im Endausbau), so dass man dann per Befehl Stationen herausnehmen kann. Zumindest stelle ich mir das so vor.
    Weiterhin wird von jeder Station auch noch ein Call oder besser gesagt ein STATIONNAME übertragen, so dass man bei wechselnden IP-Adressen nicht mehr raten muß wer das jeweils ist.


    vy 73s de Adi, DL1HRC

  • Hallo Adi,


    sieht sehr gut aus! Ich habe inzwischen neue Erkenntnisse zum "Dauersende"-Problem bei Unterbrechung der Netzwerkverbindung:


    Wenn ein Client zum SvxServer hin sendet und dabei die Netzwerkverbindung zwischen diesem Client und dem Server verloren geht, stürzt SvxLink auf allen anderen Clients ab und beendet sich selbst! Die PTT bleibt überall betätigt, es ist keinerlei Funktion mehr gegeben. Da nun SvxLink nicht mehr läuft, reicht ein manuelles Starten und der jeweilige Client arbeitet wieder normal.


    Ich werde heute Abend mal schauen, ob ich den Fehler gezielt provozieren kann und dann einen Loop einbauen (also so wie beim SvxServer). Vielleicht ist das ein funktionierender Workaround für das Problem.


    Schönen Gruß
    Frank, DL3DCW

  • Quote

    Wenn ein Client zum SvxServer hin sendet und dabei die Netzwerkverbindung zwischen diesem Client und dem Server verloren geht, stürzt SvxLink auf allen anderen Clients ab und beendet sich selbst!


    Ohh, das klingt aber sehr kosmisch :( Das habe ich hier kein einziges Mal reproduzieren können. Momentan habe ich zwischen 10 und 14 Clients ständig am Server hängen und auch bei einer Trennung der NW-Verbindung des sendenden Clients lief alles weiter.
    Hier muß ich aber noch mal schauen ob ich das Verfahren verbessern kann, momentan wird erst nach dem Heatbeat-Timeout festgestellt, dass die Verbindung weg ist. Das kann bis zu 20 Sekunden dauern. In dieser Zeit wird nicht auf den nächsten Client "umgeschaltet". Das kann zu Problemen führen. Eventuell überwache ich noch den Audiostream, beim Ausbleiben kann ein NW-Fehler schneller erkannt werden.


    Bitte mal genau prüfen, welche Version nutzt Du auf den Clients bzw. Nodes?


    vy 73s de Adi, DL1HRC

  • Hallo Adi,


    ich schau heute Abend mal, ob sich das wirklich reproduzieren lässt. Ist so gestern Mittag aufgetreten. Da musste ich dann alle Clients von Hand wieder starten.


    Es laufen derzeit verschiedene Versionen. SvxLink: 1.4.99.3 + 1.4.99.16 + 1.4.99.23 + 1.4.99.30, SvxServer: 0.0.4.


    EDIT: Der Fehler lässt sich nicht reproduzieren. Die Systeme scheinen sich nach einer Unterbrechung wohl alle wieder zu fangen. Muss daher noch eine andere Ursache haben. Die Suche geht also weiter ...


    Schönen Gruß
    Frank, DL3DCW

  • Hallo Adi,


    der Fehler (Absturz aller Clients mit Verbleib auf Dauersendung) ist heute wieder aufgetreten:


    - DB0HAT empfängt Signal via HF und sendet Audiodatenstream zum SvxServer
    - Alle angeschlossenen Clients gehen auf Sendung und übertragen den Audiodatenstream
    - Anschließendes "Heartbeat Timeout" von DB0HAT (Netzwerkunterbrechung?)
    - DB0HAT wird vom SvxServer getrennt (Port 40039), nach etwa 25 Sekunden wird die Verbindung neu aufgebaut (Port 40040)
    - Alle angeschlossenen Clients sind nach wie vor auf Sendung
    - Nach und nach verabschieden sich einzelne Clients (DB0WET, DM0HA -> "Client disconnected")
    - Von den restlichen Clients gibt es keinerlei Eintrag mehr (auch keinen "Heartbeat Timeout")


    Hier mal der Logauszug des SvxServers (Rufzeichen manuell hinzugefügt):



    Danach gibt es keinen Logeintrag mehr, obwohl neben DB0HAT, DB0WET und DM0HA noch 5 weitere Stationen mit dem Server verbunden waren. Nach 15 Minuten haben wird das Problem durch manuelles Neustarten von SvxLink auf allen Clients gelöst. SvxLink scheint also überall abgestürzt zu sein.


    Ist übrigens nach genau dem gleichen Muster auch in der Vergangenheit so gewesen. Auslöser waren auch unterschiedliche Stationen, also nicht nur DB0HAT. Vielleicht hilft das ja irgendwie weiter ;-).


    Schönen Gruß
    Frank DL3DCW

  • Hallo Adi,


    heute Morgen noch einmal der gleiche Fehler. Sieht allerdings im Log etwas anders aus:



    Auffällig: Es gibt zwischen 09:04:34 und 09:28:17 keinerlei Einträge im svxserver.log (weder Disconnects noch Heartbeat Timeouts). Alle anderen Clients waren abgestürzt und auf Dauersendung. Mit "ps -C svxlink" wurde kein laufender Prozess mehr angezeigt. Nach dem Starten von SvxLink auf den Clients lief dann alles wieder normal. Der SvxServer brauchte nicht neu gestartet zu werden.


    Schöne Feiertage!
    Frank, DL3DCW

  • Hi Frank,


    ja genau das ist momentan noch ein großes Problem. Es kommt plötzlich von einer Station ein MsgFlush obwohl eine andere Station Master ist. Den Grund kenne ich noch nicht. Das ganze passiert auch sporadisch, es läuft manchmal 4-5Tag ohne Probleme, dann tritt der Fehler wieder nach 20Minuten auf.
    Wie gesagt, ich bin dran.


    Frohe Weihnachten + vy 73s de Adi, DL1HRC

  • Hallo Adi,


    mach Dir keinen Stress. Schon gar nicht über die Feiertage ;-).


    Solle nur als zusätzliche Info dienen, in der Hoffnung, das es bei der Fehlersuche irgendwie hilfreich ist.


    Frohes Fest!
    Frank, DL3DCW

  • Hallo Adi,


    vielleicht hilft es ja weiter: Heute ist der SvxServer selbst abgestürzt, wurde durch unseren Workaround mit der Endlosscheife aber sofort wieder neu gestartet. Außer einer kurzen Unterbrechung hatte das keine negativen Auswirkungen. Das Ganze hat sich von selbst wieder gefangen:



    Auffällig ist, das auch hier der Absturz erfolgte, während eine Station zum SvxServer hin gesendet hat. Bisher sind die Probleme noch nie im "Leerlauf" aufgetreten. Vielleicht gibt es zwischen den Abstürzen der Clients (mit anschließender Dauersendung) und den Abstürzen des SvxServers ja einen Zusammenhang?


    Schönen Gruß
    Frank, DL3DCW

  • Ich melde einen Absturz:
    Wegen fehlerhafter Schreibrechte konnte logrotate auf das svxserver.log nicht angewendet werden. Bekanntlich ist die Logausgabe recht umfangreich.
    Den Pfad /var/log/ habe ich mit 75MB in das RAM gelegt, um die SD Karte zu schonen. Dieses RAM-Laufwerk war dann nach 3 Tagen voll und svxserver konnte nicht mehr gestartet werden bzw. ist der laufende Prozess kommentarlos ausgestiegen.
    Wenn man sich nicht selber ein Ei auf die Schiene nagelt wie oben beschrieben, läuft die v 0.4 absolut stabil mit zzt. 4 Teilnehmern. Éine vernünftige Latenz sowie geringe Umschaltzeiten vorausgesetzt, gab es keine Aussetzer und Abstürze mehr.


    Tolles Stück Software, macht jeden Tag erneut Spaß!

  • Hi Frank,


    vielen Dank für die Info.
    Ich habe da jetzt noch mal was daran gemacht und noch einen Audio-Timer eingebaut. Leider fehlt ja bei einigen Durchgängen ab und an die MsgFlush-Message. Das habe ich jetzt damit umgangen, dass, so lange ein Audiostream empfangen wird, die sendende Station Master bleibt und wenn dieser ausbleibt nach 1 Sekunde (Timer) die Rücksetzung erfolgt. Das läuft jetzt ganz gut hier. Auch Abstürze gab es in den letzten Tagen nicht mehr.


    vy 73s de Adi / DL1HRC