SvxServer bugfix

    Erfahrung mit der alten "?.?.?" - Version versus 0.2:
    Die sporadischen Aussetzer kompletter Durchgänge sind in der alten/1. Version nicht vorhanden. Sie läuft bei mir jetzt wieder seit einigen Wochen, nachdem bei der 0.2 sporadisch ca. 10% der Durchgänge nicht übertragen wurden.

    Hm, weiß nicht so recht, ich teste das hier mal auf dem QRL-Rechner. So richtig schlau werde ich momentan da nicht draus. Wir sollten mal testen, bin über den Tag hier QRV verbinde Dich bitte einfach mal.

    73s de Adi, DL1HRC

    Hallo zusammen,

    das Problem mit den Aussetzern kompletter Durchgänge kann ich nicht bestätigen. Sowohl bei der Version ?.?.? als auch bei 0.0.2 ist dies bei uns bisher noch nicht aufgetaucht. Dafür aber ein anderes, nicht ganz so gravierendes Problem:

    Teilweise gibt es ganz kurze "Mikroaussetzer" auf allen Signalen, die über den Link kommen. Es gibt aber kein Klötzeln und auch kein Knacken, es ist einfach nur ganz kurze Zeit (<100ms) das NF-Signal weg. Netzwerktechnisch scheint alles ok zu sein, sowohl Bandbreiten als auch Ping-Zeiten (<20ms) sind ok. Auch Rechenleistung ist genug da (SvxLink<10%, SvxServer kaum messbar). Dies bei Version SvxServer ?.?.? und auch bei 0.0.2.

    Allerdings arbeiten wir im Moment nur mit dem GSM-Codec. Sollten wir vielleicht mal auf SPEEX/OPUS umstellen?

    Schönen Gruß
    Frank, DL3DCW

    Hi Frank,

    das mit den Mikro-Aussetzern habe ich auch festgestellt, habe momentan leider keine Idee woran es liegt.
    Eventuell muß ich darüber nachdenken de Audiostream etwas zu puffern.

    vy 73s de Adi, DL1HRC

    Hallo Adi,

    ok, dann brauche ich ja nicht weiter zu suchen, hi. Ja, ich denke ein Puffer wäre vielleicht nicht schlecht und könnte das Problem lösen. Ein dadurch entstehendes Delay wäre ja nicht weiter tragisch.

    Schönen Gruß
    Frank, DL3DCW

    Hallo zusammen,

    hier mal ein kurzer Erfahrungsbericht mit dem SvxServer (0.0.2). Dieser läuft bei uns mit einer ganzen Reihe angeschlossenen Stationen seit einiger Zeit recht stabil. Ein paar "Kleinigkeiten" sind bisher noch aufgefallen:

    - Manchmal gibt es "Mikroaussetzer" im Audio (siehe Beitrag oben)
    - 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

    Wir verwenden derzeit übrigens den OPUS-Codec mit Standardeinstellungen. Dieser läuft auch auf den Raspberrys (2B) sehr stabil. Zudem ist die Audioqualität perfekt und deutlich besser als GSM. Die Systemlast von SvxLink liegt beim Senden damit etwa bei 20%.

    Schönen Gruß
    Frank, DL3DCW

    Hallo Frank,

    ja, die 3 Punkte brennen noch ein bisschen auf den Nägeln. Die Ursache für den Absturz habe ich möglicherwiese gefunden. Ich bin wie gesagt dran.
    Vielen Dank für die Rückmeldung und den Fehlerbericht. So etwas hilft immer weiter.

    vy 73s de Adi, DL1HRC

    Kurzer Zwischenbericht mit heutigem Phänomen:
    svxserver lief seit ca. > 2 Wochen anstandslos durch. Offensichtlich auch ohne nennenswerte Aussetzer. Heute aber wurde kein Audiostream mehr durchgeleitet. Der daemon - Prozess lief noch, der letzte Logeintrag war auch "sauber" von 11:45. Danach stand nichts mehr im Log und der Prozess (nicht der Rechner!) mußte neu gestartet werden. Danach lief wieder alles problemlos.

    Hmmm, das sind Fehler die ich liebe, 14 Tage geht es problemlos und dann plötzlich nicht mehr ohne Fehlermeldung.
    Das Audio wurde gar nicht mehr weitergeleitet? Von nirgendwo nach nirgendwo?

    vy 73s de Adi, DL1HRC

    Genau - von nirgendwo nach nirgendwo. Heute, nach knapp 24h, trat der Fehler wieder auf. Der letzte Eintrag in das Logfile ist:
    16.09.2015 18:44:05: IS Master:99.2xx.220.228
    .. dann ist das file zu ende.

    Nachtrach: Es häuft sich leider, heute morgen keine Reaktion mehr. Letzter Eintrag im Log:
    18.09.2015 08:26:00: IS Master:93.xx9.221.2x4

    Ich starte den Prozess neu.

    Hallo Frank,

    Quote

    Kurzer Zwischenbericht mit heutigem Phänomen:
    svxserver lief seit ca. > 2 Wochen anstandslos durch. Offensichtlich auch ohne nennenswerte Aussetzer. Heute aber wurde kein Audiostream mehr durchgeleitet. Der daemon - Prozess lief noch, der letzte Logeintrag war auch "sauber" von 11:45. Danach stand nichts mehr im Log und der Prozess (nicht der Rechner!) mußte neu gestartet werden. Danach lief wieder alles problemlos.

    Ich glaube ich habe eine mögliche Ursache gefunden. Dieser Effekt tritt auf wenn bei irgendeiner Logik (vorranging NetLogic's) die Rauschsperre geöffnet wird und dann aus welchen Gründen auch immer geöffnet bleibt. Das Problem konnte ich hier nachvollziehen und es ist reproduzierbar, wenn Du einfach mal in der [NetLogic]-Definition den Parameter OPEN_SQL_FLANK=OPEN auskommentiert. Das hat dann eine fatale Wirkung.

    ...Adi ist dran... :D

    vy 73s de Adi, DL1HRC

    Na das mach ich doch gleich mal ... in welcher conf? svxserver.conf oder bei allen Teilnehmern in der svxlink.conf bzw. remotetrx.conf?

    Das habe ich bei 2 Teilnehmerm gemacht und es führte zu unkrontollierten "Ausfällen". Ich konnte nicht nachvollziehen, wann eine Übertragung stattfindet und wann nicht bzw. wann welcher SQL öffnet. Im Verbund "hing" lt. Log offenbar regelmäßig ein SQL- blieb also offen - und die Übertragung konnte nicht stattfinden. Nach dem Löschen der Auskommentierung, also der Aktivierung von OPEN_SQL_FLANK=OPEN ging wieder alles normal.

    Im eigenen NetLink-Netzwerk habe ich es jetzt aktiviert, im FIB-NetLink ist es auskommentiert. Soll ich es so lassen? Beim gestrigen QSO mit DL2HXA via FIB-NEtlink gab es jede Menge fehlende Übertragungen.

    Was genau macht OPEN_SQL_FLANK?

    Nach genauerem Lesen der Manpage von svxlink versuche ich jetzt mal zu sortieren. Ausgangskonfiguration bei mir:
    2 x NetLogic
    die 1. mit einem Verbund von 3 Simplexstationen
    die 2. mit dem Verbund Fichtelberg & Co.

    Der Parameter open_on_sql gilt nur für für TYPE=Repeater, beide Netlink Sections beginnen mit TYPE=Repeater. Ist das korrekt, auch für die 1. Konfiguration?
    Müssen zwischen der 1. und 2. Version noch andere Parameter beim Netlinken beachtet werden? Leider lesen ich aus der Manpage keine weiteren Details raus.

    Hallo zusammen,

    in der vergangenen Zeit haben wir eine Reihe von Systemen via SvxServer zusammengeschaltet. Die OMs sind begeistert, dementsprechend hat auch die Aktivität zugenommen. Soweit also alles super.

    Den weiter oben beschriebenen Fehler können wir inzwischen bestätigen: Es gehen manchmal einzelne Durchgänge verloren. Sie sind dann zwar auf dem lokalen Relais zu hören, jedoch nicht auf den verlinkten Systemen. Ob in dem Moment alle verlinkten Systeme betroffen sind oder nicht, kann ich noch nicht genau sagen.

    Es handelt sich meistens nur um einen Durchgang, danach ist wieder alles ok. Auch tritt es recht selten auf. Die Logdateien sind vorhanden, es ist jedoch nicht ganz einfach, diese zu analysieren und hilfreiche Schlüsse daraus zu ziehen.

    Auffälligkeiten im Log:

    Repeater A (hier war kein Betrieb)

    Sat Nov 14 09:25:13 2015: NetRx: The squelch is OPEN (1)
    Sat Nov 14 09:25:16 2015: NetRx: The squelch is CLOSED (0)
    Sat Nov 14 09:25:16 2015: NetRx: The squelch is OPEN (1)
    Sat Nov 14 09:25:26 2015: NetRx: The squelch is CLOSED (0)
    Sat Nov 14 09:25:35 2015: NetRx: The squelch is OPEN (1)
    Sat Nov 14 09:25:53 2015: NetRx: The squelch is CLOSED (0)
    Sat Nov 14 09:25:54 2015: NetRx: The squelch is OPEN (1)
    Sat Nov 14 09:26:06 2015: NetRx: The squelch is CLOSED (0)
    Sat Nov 14 09:26:08 2015: NetRx: The squelch is OPEN (1)
    Sat Nov 14 09:26:12 2015: NetRx: The squelch is CLOSED (0)
    Sat Nov 14 09:26:13 2015: NetRx: The squelch is OPEN (1)
    Sat Nov 14 09:26:16 2015: NetRx: The squelch is CLOSED (0)

    Repeater B

    Sat Nov 14 09:25:13 2015: Rx1: The squelch is OPEN (0.787928)
    Sat Nov 14 09:25:17 2015: NetRx: The squelch is OPEN (1)
    Sat Nov 14 09:25:18 2015: NetRx: The squelch is CLOSED (0)
    Sat Nov 14 09:25:26 2015: Rx1: The squelch is CLOSED (6.66778)
    Sat Nov 14 09:25:35 2015: Rx1: The squelch is OPEN (7.75712)
    Sat Nov 14 09:25:52 2015: Rx1: The squelch is CLOSED (6.61783)
    Sat Nov 14 09:25:54 2015: NetRx: The squelch is OPEN (1)
    Sat Nov 14 09:26:06 2015: NetRx: The squelch is CLOSED (0)
    Sat Nov 14 09:26:08 2015: Rx1: The squelch is OPEN (2.47315)
    Sat Nov 14 09:26:12 2015: Rx1: The squelch is CLOSED (7.26746)
    Sat Nov 14 09:26:13 2015: NetRx: The squelch is OPEN (1)
    Sat Nov 14 09:26:16 2015: NetRx: The squelch is CLOSED (0)


    Repeater C

    Sat Nov 14 09:25:13 2015: NetRx: The squelch is OPEN (1)
    Sat Nov 14 09:25:16 2015: NetRx: The squelch is CLOSED (0)
    Sat Nov 14 09:25:16 2015: NetRx: The squelch is OPEN (1)
    Sat Nov 14 09:25:17 2015: Rx1: The squelch is OPEN (3.2999)
    Sat Nov 14 09:25:18 2015: NetRx: The squelch is CLOSED (0)
    Sat Nov 14 09:25:18 2015: NetRx: The squelch is OPEN (1)
    Sat Nov 14 09:25:19 2015: NetRx: The squelch is CLOSED (0)
    Sat Nov 14 09:25:19 2015: NetRx: The squelch is OPEN (1)
    Sat Nov 14 09:25:20 2015: NetRx: The squelch is CLOSED (0)
    Sat Nov 14 09:25:20 2015: NetRx: The squelch is OPEN (1)
    Sat Nov 14 09:25:26 2015: NetRx: The squelch is CLOSED (0)
    Sat Nov 14 09:25:33 2015: Rx1: The squelch is CLOSED (6.40527)
    Sat Nov 14 09:25:35 2015: NetRx: The squelch is OPEN (1)
    Sat Nov 14 09:25:53 2015: NetRx: The squelch is CLOSED (0)
    Sat Nov 14 09:25:53 2015: Rx1: The squelch is OPEN (6.7324)
    Sat Nov 14 09:26:06 2015: Rx1: The squelch is CLOSED (6.46108)
    Sat Nov 14 09:26:08 2015: NetRx: The squelch is OPEN (1)
    Sat Nov 14 09:26:08 2015: NetRx: The squelch is CLOSED (0)
    Sat Nov 14 09:26:08 2015: NetRx: The squelch is OPEN (1)
    Sat Nov 14 09:26:09 2015: NetRx: The squelch is CLOSED (0)
    Sat Nov 14 09:26:09 2015: NetRx: The squelch is OPEN (1)
    Sat Nov 14 09:26:12 2015: NetRx: The squelch is CLOSED (0)
    Sat Nov 14 09:26:13 2015: Rx1: The squelch is OPEN (2.08464)
    Sat Nov 14 09:26:16 2015: Rx1: The squelch is CLOSED (6.41925)

    Eigentlich sollten die Logs doch "synchron" sein, oder? Bei Repeater C gibt es jedoch deutlich mehr Einträge als bei A und B. Ich blicke da leider noch nicht ganz durch. Bin mir aber nicht sicher, ob es zu diesem Zeitpunkt wirklich einen "Ausfall" gegeben hat. An anderen Stellen in den Logs gibt es übrigens ähnliche Auffälligkeiten.

    Ich werde demnächst noch einmal gezielter drauf achten und dann einmal die Zeit ganz genau notieren. Was könnte ich sonst noch tun?

    Schönen Gruß
    Frank, DL3DCW

    Hi Frank,

    das ist sehr interessant. Vielen Dank. Eventuell gibt mir das 'ne neue Inspiration :D
    Ich habe mal eine neue Version eingecheckt, hast Du die Chance das mal parallel zu installieren, d.h. die alte Variante auf dem System belassen und mal die Neue einfach so zu starten (also kein git pull sondern eine parallele Installation)? Die Netzwerk-Protokoll-Version ist die Selbe, ich habe nur ein paar Änderungen eingebaut.

    vy 73s de Adi

    Hallo Adi,

    ok, ich werde mal auf einem separaten System eine Parallelinstallation machen.

    Die obigen Beispiele zeigen, das die "NetRx-SQL" auf einem System (Repeater C) flappt. Warum auch immer. Ich habe noch weitere Logs hier, die ich aber noch auswerten muss. Falls ich dort weitere Auffälligkeiten finde, werde ich diese hier posten.

    Schönen Gruß
    Frank, DL3DCW

    BTW: Ich habe mal auf dem SvxServer die Ausgabe der Zeit erweitert (1000tel Sekunden), wichtig hier ist natürlich eine möglichst genaue Synchronisation der ntpd-Server zur "wahren" Zeit.

    vy 73s de Adi, DL1HRC