Tastaturproblem

[dl8dww]

Hallo,
Im WAG-Contest am letzten Wochenende trat bei Tatatureingaben ein Problem auf.
Bei Bedienung der F-Tasten passierte es, daß es zu deutlichen Verzögerungen bei der CW-Zeichenausgabe kam.
Zwischen der Tastenbedienung und Zeichenausgabe gab es Verzögerungen von ca.500ms.
Es kam auch vor, das z.B.zwischen dem 1. und 2, Zeichen des Rufzeichen eine ähnlich lange Pause entstand.
Dieses Problem trat nur vereinzelt und in unregelmäßigen größeren Abständen auf.
Um den Fehler zu beheben, hatte ich erst einmal PTT Delay auf von 50ms auf Null gesetzt.
Die Verzögerung schien nicht mehr aufzutreten. Mehr zufällig beobachtete ich, daß bei Eingaben in Call-Feld der letzte Buchstabe mit bis zu einer Sekunde Verzögerung in der Anzeige verzögert wurde. Auch hier war keine Regelmäßigkeit beim Auftreten dieses Zustandes erkennbar.
In Betrieb waren das DX-Cluster-Fenster und die Bandmap.
Über Telnet 1 kamen DX-Infos und von Telnet 2 gab es Infos von RBN.
Mit DX-Cluster hatte ich noch nie Schwierigkeiten, aber RBN war das erste Mal in Gebrauch.
Also wurde Telnet 2 deativiert und welch Wunder.....das Tastatur- und Anzeigeproblem waren behoben.
Das es an der Rechnerleistung liegen könnte möchte ich ausschließen. 2 Core Intel / 2GHz sollten ausreichend sein.
Im RBN habe ich Filter gesetzt (nur Contestbänder und auch nur CW), aber Spass macht es keinen, RBN im Contest zu nutzen. Im Clusterfenster gibt es kaum Stillstand und in der Bandmap sind eine Vielzahl der Einträge nicht hilfreich. Komisch auch, dass mein Call auf 20m gemeldet wurde , ich aber schon geraume Zeit auf 15m qrv war.
Dieses eigenartige Verhalten hatte auch ein OM aus dem OV bei seiner Hardware beobachtet, aber nicht weiter beachtet.
@ Ben, DL7UCX: was könnte die Ursache sein und was kann man dagegen tun?
Ich persönlich habe schon die Lösung für mich gefunden
73 Wolfgang,

[DL7UCX]

Hallo Wolfgang,

das Problem ist schon länger bekannt und eigentlich gelöst.
Wir kennen die CPU-Last bei Dir nicht, aber wahrscheinlich war sie zeitweise auf 100%.
Bei mir blieb bisher in großen CW-Contesten die Last bei max. 30%.
Auch 2 Kerne, aber es kann in Abhängigkeit von Speicher, Cache und Grafikkarte noch große Unterschiede geben.

Ursache ist die Meldungsflut über RBN, durchaus 50 Meldungen/s und mehr. Da diese in Bursts vom (auch sehr belasteten) Server kommen, werden sie in UcxLog schon in 20ms-Zeitscheiben verteilt und auf max. 50/s beschnitten.
Trotzdem braucht nur das einfache Durchschieben im Telnet-Fenster schon eine ganz erhebliche CPU-Leistung, die kann man nur noch durch Verkleinern/Minimieren des Telnet-Fensters verringern. Diese Last muß leider im Haupt-Thread (blockierend) auftreten, ansonsten wird durchaus die halbe Last auf den zweiten Kern verteilt.
Dein Filter im RBN (nur Contest, nur CW) wird so gut wie nichts weggefiltert haben !

Ich werde das nochmal im WWDX-CW beobachten und möglicherweise die Anzahl der gespeicherten Meldungen (5000) wieder runtersetzen.
Vielleicht ist auch die Länderliste etwas groß geworden, das läuft ja alles für jeden Spot durch.

73 Ben

[dl8dww]

Hallo Ben,
Danke für die ausführliche Info.
73 Wolfgang

[dl3kvr]

Hallo Wolfgang,
vielleicht kann ich helfen, da Leidensgenosse. Obwohl ich RBN im Contest nicht mehr missen möchte.
Das Problem hat mich in der 2. Hälfte fast zum Wahnsinn getrieben. Allerdings liegt das bei mir noch am lahmen Rechner,
der erst am Ende des Monats endgültig getauscht werden wird.
Ich habe nur RBN laufen und das Clusterfenster, sowie die Bandmap auf 5 Minuten gestellt. Das reicht in so einem Contest
völlig aus.
Der Fehler trat auf, als das Clusterfenster sich nach einem Neustart auf die volle Zeit eingestellt hatte.
Bei mir blieb aber alles, bis manchmal 5 Sekunden, stehen.
73 Diet

[dl8dww]

Hallo Diet,
...ja ,da kommt Freude auf, wenn solche Dinge im Contest auftreten. Da waren 500ms Verzögerung noch richtig harmlos.
Auf Empfehlung von einem OM aus dem OV hab ich das erste Mal RBN im Contest genutzt. So, wie es mit meinen Einstellungen gelaufen ist, hat es mich keineswegs überzeugt.Die Bandmap war zwar schön voll, aber viele Einträge leider nicht immer aktuell, also nicht zu verwerten.
Bei den nächsten Contesten werde ich vorerst ohne RBN unterwegs sein.
Mein Rechner ist noch nicht allzu alt, und da bin ich nicht auf die Idee gekommen, das er mit dem Telnetfenster bei entsprechend großer Datenmenge nicht klarkommt. Wenn UCXLog gestartet ist liegt die CPU-Last bei 4%, so zwischendurch ist mal eine kurzeitige Lastspitze mit 10% vorhanden (sieht aus, wie ein Nadelimpuls).Das könnte da bei sehr hoher CPU-Last zu der Verzögerung geführt haben.
Deinen Hinweis auf die 5 Minuten-Einstellung werde ich weitergeben. Ist sicher für langsame Rechner von Nutzen.
TNX und 73, Wolfgang

[DL1DTL]

habt ihr eventuell auch an solche Dinge wie Antiviren-Programm gedacht?
Ich bemerke da gelegentlich kurzzeitige Verzögerungen. Sie erklären sich dann immer, wenn ein Pop-up vom Virenprogramm auftaucht.
RBN nutze ich auch nicht, es sei denn, ich mache nur aus Spass im S&P mit.

73 Klaus

[dl3kvr]

Hallo Klaus,
aus Dir verständlichem Grunde mache ich zu 30% S&P, und da ist RBN unverzichtbar.
Nur damit sind in dieser B-Art bis zu 3 QSO/min machbar.
Die Systemfehler der RBN-Anzeigen sollten bekannt sein, um damit klar zu kommen.
Die 5 Minuten Grenze hilft dabei.
73 Diet

[DL7UCX]

Hallo,

ich habe mir die CPU-Last bei Meldungs-Fluten aus RBN nochmal vorgenommen und zwei Verbesserungen in 7.15 Beta 18 eingeführt:

• Statt 5000 werden nur die letzten 3000 Messages gespeichert, das verkürzt einige langlaufende Operationen.
• Die Länderbestimmung (incl. Special-Calls), die bei jeder Meldung zweimal läuft, wurde um den Faktor 20 beschleunigt, bei mir dauert die jetzt nur noch 10 mikro Sekunden pro Rufzeichen.

Ich konnte keine Unterschiede beim Ergebnis der Länderbestimmung feststellen.
Es wäre aber beruhigend , wenn einige von Euch mal den "Scan - Check countries" vor und mit Beta 18 vergleichen.

73 Ben

[DL6ER]

Hallo Ben,

Es wäre aber beruhigend , wenn einige von Euch mal den "Scan - Check countries" vor und mit Beta 18 vergleichen.

Beta 12:

Unsure: FO4BM FO --> FO FO/A FO/C FO/M

Beta 18:

Wrong : R100W UA3 --> UA9

Nachtrag: Ahhh...gerade gesehen, dass sich genau bei diesen beiden Calls die Länder-Liste geändert hat, was für ein Zufall...aber jetzt ist alles klar!

[DL7UCX]

Hallo,

ich habe im WWDX-CW mit Telnet zu db0sue.de und telnet.reversebeacon.net (RBN) die CPU-Last beobachtet.
Diese lag bei mir (2 Kerne) bei 5 ... 20%.
Es gingen im Durchschnitt 10 RBN-Meldungen/Sekunde ein (mit den bekannten Bursts von 50 und mehr).

Nach mehreren Stunden trat der Effekt auf, daß die Last auf 50% anstieg.

Nach Telnet-Disconnect und Re-Connect war die Last wieder normal gering.
Hierbei wird in den UcxLog-Ressourcen nichts verändert, nur der Windows-Socket wird geschlossen und neu geöffnet.
Es schien sich also im Windows ein Last-Problem aufzuschaukeln.
Wenn "auto"-Connect angekreuzt ist, schließt UcxLog ab Version 7.16 Beta 5 deshalb die Telnet-Verbindungen jeweils nach 1 Stunde und verbindet neu. Das bemerkt man meist gar nicht.
Bei instabilen Internet-Verbindungen passiert das schon früher von alleine.

Danach konnte ich keine erhöhte CPU-Last mehr beobachten.

73 Ben

[dl8dww]

Hallo Ben,

ich habe mir die CPU-Last bei Meldungs-Fluten aus RBN nochmal vorgenommen und zwei Verbesserungen in 7.15 Beta 18 eingeführt:

Statt 5000 werden nur die letzten 3000 Messages gespeichert, das verkürzt einige langlaufende Operationen.
Die Länderbestimmung (incl. Special-Calls), die bei jeder Meldung zweimal läuft, wurde um den Faktor 20 beschleunigt, bei mir dauert die jetzt nur noch 10 mikro Sekunden pro Rufzeichen.

im CQWW gab es durch RBN keine Tastaturprobleme
73, Wolfgang