SvxServer bugfix

    Hallo Adi,

    ok, Installation läuft. Unsere Systeme hängen eigentlich alle am gleichen NTP-Server. Somit sollten diese ja eigentlich alle gleich (falsch) laufen ;-).

    Schönen Gruß
    Frank, DL3DCW

    na ja, gleich falsch ist schon ganz gut. Ich habe hier zu Hause ein GPS-Normal und synchronisiere alles damit inklusive des TX-Trägers per 10MHZ-Referenz, wenn die Zeit um mehr als 8 Mikrosekunden abweicht werde ich schon leicht sauer :D

    Alle 8 Systeme werden nun auf den neuen Server umgeleitet. Die Grundfunktion ist schon mal da.

    Die Zeitangaben im Log sind allerdings nicht in 1000tel Sekunden. Habe ich noch etwas falsch gemacht?

    nee, nicht falsch gemacht, muß nur erweitert werden in der svxserver.conf:

    TIMESTAMP_FORMAT="%d.%m.%Y %H:%M:%S.%f"

    73s de Adi, DL1HRC

    Ok, kaum macht man es richtig, schon geht's ;-).

    Dann solle ich das sinnigerweise auch auf den Clients machen ...

    EDIT: Ist nun auch erledigt. Alle Systeme sind jetzt scharf, hi.

    Hallo Adi,

    habe heute morgen noch einmal nachgeschaut. Es geht definitiv irgendetwas verloren. Ich habe das QSO aber nicht mitgehört und kann daher nicht sagen, ob es wirklich Aussetzer etc. gab. Merkwürdig ist das aber schon, oder?

    Wenn ich das richtig verstanden habe, sollten die Ereignisse in allen Logs ja synchron sein. Trotzdem fehlen auf den Repeatern jeweils Einträge. Dort habe ich zwecks besserer Übersicht einmal Leerzeilen eingefügt. Kann man dann notfalls ausdrucken und nebeneinander legen ;-). Hier die Logs:

    SvxServer (Version 0.0.3b):

    Code
    17.11.2015 09:16:52.202: IS Master:44.224.62.13717.11.2015 09:16:55.647: NO Master:44.224.62.13717.11.2015 09:16:55.726: IS Master:44.224.62.13717.11.2015 09:16:58.418: NO Master:44.224.62.13717.11.2015 09:16:59.882: IS Master:44.225.124.14617.11.2015 09:17:05.697: NO Master:44.225.124.14617.11.2015 09:17:07.022: IS Master:44.224.62.13717.11.2015 09:17:19.610: NO Master:44.224.62.13717.11.2015 09:17:19.731: IS Master:44.224.62.13717.11.2015 09:17:24.849: NO Master:44.224.62.13717.11.2015 09:17:26.583: IS Master:44.225.124.14617.11.2015 09:17:36.097: NO Master:44.225.124.14617.11.2015 09:17:38.313: IS Master:44.224.62.13717.11.2015 09:17:41.731: NO Master:44.224.62.13717.11.2015 09:17:41.797: IS Master:44.224.62.13717.11.2015 09:17:45.824: NO Master:44.224.62.13717.11.2015 09:17:45.883: IS Master:44.224.62.13717.11.2015 09:17:50.020: NO Master:44.224.62.13717.11.2015 09:17:50.134: IS Master:44.224.62.13717.11.2015 09:17:51.439: NO Master:44.224.62.13717.11.2015 09:17:52.592: IS Master:44.225.124.14617.11.2015 09:17:56.907: NO Master:44.225.124.14617.11.2015 09:17:58.218: IS Master:44.224.62.13717.11.2015 09:18:01.441: NO Master:44.224.62.13717.11.2015 09:18:01.498: IS Master:44.224.62.13717.11.2015 09:18:02.738: NO Master:44.224.62.13717.11.2015 09:18:02.874: IS Master:44.224.62.13717.11.2015 09:18:07.715: NO Master:44.224.62.13717.11.2015 09:18:08.982: IS Master:44.225.124.14617.11.2015 09:18:14.526: NO Master:44.225.124.14617.11.2015 09:19:53.351: IS Master:44.225.124.14617.11.2015 09:19:53.621: NO Master:44.225.124.14617.11.2015 09:19:53.646: IS Master:44.225.124.14617.11.2015 09:19:53.889: NO Master:44.225.124.14617.11.2015 09:19:55.083: IS Master:44.225.124.14617.11.2015 09:19:57.588: NO Master:44.225.124.146


    Repeater A (44.224.62.137)

    Code
    17.11.2015 09:16:52.126: Rx1: The squelch is OPEN (2.71503)17.11.2015 09:16:58.434: Rx1: The squelch is CLOSED (6.59207)17.11.2015 09:16:59.894: NetRx: The squelch is OPEN (1)17.11.2015 09:17:05.893: NetRx: The squelch is CLOSED (0)17.11.2015 09:17:06.926: Rx1: The squelch is OPEN (3.69668)17.11.2015 09:17:24.868: Rx1: The squelch is CLOSED (6.52874)17.11.2015 09:17:26.598: NetRx: The squelch is OPEN (1)17.11.2015 09:17:36.361: NetRx: The squelch is CLOSED (0)17.11.2015 09:17:38.226: Rx1: The squelch is OPEN (3.74474)17.11.2015 09:17:51.455: Rx1: The squelch is CLOSED (6.53697)17.11.2015 09:17:52.603: NetRx: The squelch is OPEN (1)17.11.2015 09:17:56.993: NetRx: The squelch is CLOSED (0)17.11.2015 09:17:58.126: Rx1: The squelch is OPEN (2.87217)17.11.2015 09:18:02.756: Rx1: The squelch is CLOSED (1.37335)17.11.2015 09:18:02.825: Rx1: The squelch is OPEN (1.82645)17.11.2015 09:18:07.765: Rx1: The squelch is CLOSED (7.00098)17.11.2015 09:18:08.994: NetRx: The squelch is OPEN (1)17.11.2015 09:18:14.544: NetRx: The squelch is CLOSED (0)17.11.2015 09:19:53.363: NetRx: The squelch is OPEN (1)17.11.2015 09:19:57.835: NetRx: The squelch is CLOSED (0)


    Repeater B (44.225.124.146)

    Schönen Gruß
    Frank, DL3DCW

    Hi Frank,

    vielen Dank für's Überwachen.
    Das sieht so aus, als seien die Aussetze kleine Drops:

    17.11.2015 09:16:52.219: NetRx: The squelch is OPEN (1)
    17.11.2015 09:16:55.739: NetRx: The squelch is CLOSED (0)
    17.11.2015 09:16:55.756: NetRx: The squelch is OPEN (1)
    17.11.2015 09:16:58.500: NetRx: The squelch is CLOSED (0)

    das sind weniger als 0,1 Sekunden.
    Die SQL der Net-Logiken wird aus dem Audiostream generiert, da der Status der Rauschsperre der HF-Logic nicht an die Net-Logik übertragen wird (geht nicht ohne Weiteres, leider). Eventuell wird hier eine Message (wie MsgFlush o.ä.) künstlich erzeugt, das muss ich mal irgendwie ermitteln. Kannst Du mir bitte mal die Parameter OPEN_ON_SQL der Net-Logiken zusenden. Sind die überall gleich bei Euch?

    vy 73s de Adi, DL1HRC

    Hallo Adi,

    wir setzen überall die gleiche Hardware und auch die gleiche Konfiguration ein. Daher ist das einfach: ;)

    [NetLogic]
    OPEN_ON_SQL=50

    Ja, ich habe auch schon gesehen, das es in diesem Fall nur kurze Drops sind. Diese Drops sollten eigentlich auch nicht Ursache für dem Ausfall eines kompletten Durchgangs sein. Zumindest theoretisch, hi.

    Trotzdem werden die auf dem Server registrierten Drops nicht immer alle an die Clients weitergegeben. Das wundert mich etwas ...

    Schönen Gruß
    Frank, DL3DCW

    Hallo Adi,

    ich glaube wir sind den Ausfällen ganz dicht auf der Spur. Folgende Beobachtung:

    Ich sende via Link und bin auf dem entfernten Repeater zu hören. Wird nun auf dem entfernten Repeater ganz kurz auf der Eingabe gesendet, ist mein Durchgang via Link weg. Er kommt auch nicht von selbst wieder sondern erst dann, wenn ich auf dem Link die PTT kurz loslasse und dann wieder betätige. In der "toten" Zeit fällt der Repeater sogar nach der Nachlaufzeit ab, obwohl ich immer noch via Link sende!

    Dieses Szenario passiert vor allem immer dann, wenn man mit mehreren Teilnehmern im QSO ist und zufällig doppelt. Dann ist die Link-NF für die Dauer eines kompletten Durchgangs auf dem Repeater nicht mehr zu hören. Das Problem ist absolut reproduzierbar und deckt sich mit unseren Beobachtungen in der Vergangenheit.

    In den nachstehenden Logs habe ich von DL3DCW via Link zu DM0HA gesendet. Dann wurde auf DM0HA einmal kurz auf der Eingabe die PTT gedrückt. Nun war die NF von DL3DCW nicht mehr zu hören. Anschließend habe ich einmal kurz auf dem Link die PTT losgelassen und die NF von DL3DCW war wieder da:

    DL3DCW (44.225.124.2)

    18.11.2015 20:27:03.933: Rx1: The squelch is OPEN (7.41831)
    18.11.2015 20:27:11.828: Rx1: The squelch is CLOSED (7.53261)
    18.11.2015 20:27:13.433: Rx1: The squelch is OPEN (7.39463)
    18.11.2015 20:27:14.836: Rx1: The squelch is CLOSED (7.33292)

    DM0HA (44.224.62.137)

    18.11.2015 20:27:03.990: NetRx: The squelch is OPEN (1)
    18.11.2015 20:27:06.426: Rx1: The squelch is OPEN (2.25629)
    18.11.2015 20:27:07.155: NetRx: The squelch is CLOSED (0)
    18.11.2015 20:27:07.159: Rx1: The squelch is CLOSED (6.82357)
    18.11.2015 20:27:13.488: NetRx: The squelch is OPEN (1)
    18.11.2015 20:27:14.889: NetRx: The squelch is CLOSED (0)

    DB0TV (nur RX)

    18.11.2015 20:27:03.976: NetRx: The squelch is OPEN (1)
    18.11.2015 20:27:07.223: NetRx: The squelch is CLOSED (0)
    18.11.2015 20:27:13.482: NetRx: The squelch is OPEN (1)
    18.11.2015 20:27:14.922: NetRx: The squelch is CLOSED (0)

    SvxServer

    18.11.2015 20:27:03.976: IS Master:44.225.124.2
    18.11.2015 20:27:11.825: NO Master:44.225.124.2
    18.11.2015 20:27:13.482: IS Master:44.225.124.2
    18.11.2015 20:27:14.834: NO Master:44.225.124.2

    Bei DM0HA (und bei DB0TV) schließt um 20:27:07 die NetRX-Squelch, obwohl das Signal in Wirklichkeit noch da ist. Auch auf dem Server ist es noch vorhanden.

    Alles wird gut ;-).

    Schönen Gruß
    Frank, DL3DCW

    Quote from DL7ATA

    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


    Hallo,

    den gleichen Fehler (letzter Log-Eintrag ebenfalls "IS Master") habe ich heute morgen auch beobachtet. Musste dann den SvxServer von Hand neu starten. Habe nun wieder den Workaround mit der While-Schleife (http://forum.svxlink.de/viewtopic.php?f=4&t=290#p1722) eingebaut. Damit wird das sehr zuverlässig abgefangen.

    Ist also kein Problem, was unbedingt auf den Nägeln drückt ...

    Schönen Gruß
    Frank, DL3DCW

    Hi Frank,

    da das ist doch mal eine Analyse wie ich sie mag, besten Dank dafür! Es ist immer etwas schwierig da anzusetzen wenn kaum Betrieb auf den Relais ist und dieser Fehler immer dann nicht auftritt, wenn man davor sitzt, hi. Du hast die aktuelle Version (mein Trunk, letzte Aktualisierung am 11.11.) laufen?
    Ich schaue mal gezielt danach.

    vy 73s und besten Dank noch mal

    de Adi, DL1HRC

    Hallo Adi,

    kein Problem. Ich freu mich doch, wenn es weitergeht. Bin ja überzeugter SvxServer-Fan ;-).

    Ich habe letztens die aktuelle Version des SvxServers installiert "svxserver v0.0.3b (Nov 16 2015)". Der Fehler war aber auch vorher schon da, allerdings waren mir zu der Zeit die Zusammenhänge noch nicht klar. Habe aber auch das alte System noch und kann in Zweifelsfall relativ einfach umschalten.

    Noch mal eine Verständnisfrage:

    Wie sollte es denn im Normalbetrieb bei obigen Szenario aussehen? Hat ein lokales Signal (vom Relais-RX) Vorrang vor dem Link-Signal oder zählt das jeweils zuerst empfangene Signal? Bin mir im Moment nicht sicher, was am sinnvollsten wäre ...

    Schönen Gruß
    Frank, DL3DCW

    Quote


    Wie sollte es denn im Normalbetrieb bei obigen Szenario aussehen? Hat ein lokales Signal (vom Relais-RX) Vorrang vor dem Link-Signal oder zählt das jeweils zuerst empfangene Signal? Bin mir im Moment nicht sicher, was am sinnvollsten wäre ...

    Hi Frank,

    im Moment werden lokale QSO's auch lokal wieder ausgegeben unabhängig vom Status des SvxServers. Ich muß mal schauen wie sich das mit der Priorisierung verhält. Durch die Master/Slave-Steuerung sollten sich zumindest Dopplungen vermeiden lassen, die extern über zwei/drei/... Stationen gleichzeitig hereinkommen. Ziel war, dass maximal eine externe Station "Ärger" machen kann wenn diese Master ist und lokal jemand auf Senden geht.
    Man könnte alles so weit treiben, dass jeder Audiostream erst zum SvxServer geht und von dort verteilt wird, auch auf das lokale Relais, welches den OM gerade empfängt. Damit würde es kein "Reinsprechen" mehr geben, da immer nur eine Station Master sein kann.
    Nachteile:
    - fällt der SvxServer oder das Netzwerk aus geht gar nix mehr
    - i.A. höhrere Latenzen, auch lokal, was bei den OMs oft zu Verwirrungen führt

    vy 73s de Adi, DL1HRC

    Hallo Adi,

    alle Streams über den Server zu leiten halte ich auch nicht für sinnvoll. Wenn es einen Ausfall gibt, sollte das lokale System schon selbstständig weiter arbeiten können.

    Mach es aber erst einmal so, wie es am einfachsten ist. Komplizierter wird das Ganze dann nachher schon von ganz alleine, hi.

    Wie war es eigentlich vorher ohne Master/Slave: Konnte man da beide/mehrere Signale verstehen oder war das Audio in dem Fall komplett kaputt?

    Schönen Gruß
    Frank, DL3DCW

    Hi Frank,

    eventuell kann ich ja später so was wie ein fallback, analog zum RemoteTrx einbauen, der beim Netzausfall auf Lokalbetrieb umschaltet.

    Quote

    Wie war es eigentlich vorher ohne Master/Slave: Konnte man da beide/mehrere Signale verstehen oder war das Audio in dem Fall komplett kaputt?

    Die eingehenden Audiostreams von allen Stationen wurden so wie sie ankamen an alle weitergeleitet, also mal ein Buffer von Station A, danach ein Buffer von Station B. Da momentan keine sinnvolle Priorisierung möglich ist, muß es manchmal schon ein ganz schöner Kauderwelsch gewesen sein. Jetzt mischt sich lokaler Verkehr mit maximal einem Master-Stream aus dem Netzwerk wobei das priorisierbar ist bzw. wäre (z.B. lokal bevorrechtigt, Netzwerk gemutet).

    vy 73s de Adi, DL1HRC

    Hallo Adi,

    das ist doch zunächst erst mal perfekt. Durch das Master/Slave-Konzept kein Audio-Geschnetzeltes mehr über den Link und Mischen der Streams von Lokal+Link.

    Später konnte man dann mal sehen, ob man den Link-Stream bei lokalem Signal mutet oder umgekehrt. Oder alternativ nur das zuerst empfangene Signal durchstellt (falls das einfach zu realisieren ist). Vielleicht muss man damit aber auch erst einmal ein wenig experimentieren. Luxusversion: Eine vom Sysop konfigurierbare Lösung ;-).

    Schönen Gruß
    Frank, DL3DCW

    Hi Adi,

    die V0.0.3b vom 9.11. läuft bei uns stabil, d.h. das Programm bricht nicht ab und läuft auch nachts beim IP-Wechsel des ISP durch.
    Was die Aussetzer bei einem der drei Teilnehmer in unserem Verbund anbelangt haben wir einen Verdacht:
    Er benutzt zzt. noch eine ältere Version mit dem Effekt, dass er einen zeitlichen Verzug zwischen seinen Logiken von ca. 2 Sek. (!) hat. Wir vermuten, dass es daran liegt. Er wird in Kürze ein Update machen - in der Hoffnung dass der time lag weg ist - und dann testen wir weiter.
    Bis jetzt also alles im grünen Bereich!

    Hallo Frank,

    kannst Du das weiter oben beschriebene Problem bestätigen:

    Quote

    Ich sende via Link und bin auf dem entfernten Repeater zu hören. Wird nun auf dem entfernten Repeater ganz kurz auf der Eingabe gesendet, ist mein Durchgang via Link weg.


    Tritt hier immer wieder mal auf und ist natürlich sehr störend, vor allem, wenn es größere Runden sind. Dann wird gerne mal kurz gedoppelt und via Link ist dann leider der komplette Durchgang nicht mehr zu hören.

    Schönen Gruß
    Frank, DL3DCW