UCXLog Windows XP Parallels Desktop Max OS X

[DL7UCX]

Hallo Gerd,

habe bei der Reversebeacon.net Message-Flut im WWDX160 die Quelle der höchsten CPU-Last entdeckt:
Das Schreiben des Logfiles (schaltbar in Settings - Station - Other interfaces - DX Cluster ... - Logfile).

73 Ben

[DL7UCX]

Version 6.70 Beta 1 mit reduzierter CPU-Last bei DX-Cluster-Meldungen (auch mit Logfile).

73 Ben

[DJ4KW]

Hallo Ben

danke dass Du dem Langsamerwerden weiter nachgegangen bist. Das Logfile war bei mir nicht eingeschaltet. Aber ich habe den Eindruck, dass das Auslagern der von Dir genannten Listen viel gebracht hat. Im CQ 160 m Contest lief es auch bei QSO-Raten über 100 QSO/Minute sehr gut. Allerdings habe ich das DX-Cluster ganz abgeschaltet, nicht nur wegen der CPU-Last, sondern auch um nicht "Assisted" zu arbeiten.

73
V31YN

[DL7UCX]

Hallo Gerd,

mit allen Listen und einem "normalen" Cluster liege ich unter 5% CPU-Last.
Reversebeacon.net bringt gerade > 3 Meldungen/s, wenn so ein Burst von 5...10 Meldungen kommt, geht die Last auf 20% hoch.
Auch dabei kann ich keine Verzögerungen bei der Call-Eingabe bemerken.

73 Ben

[DL7UCX]

Hallo Gerd,

ich habe das heute ausgiebig beobachtet, gemessen und analysiert.
Durch den WW160 laufen sehr viele reversebeacon.net Messages ein.
Nach 4 Stunden und ca. 50.000 Cluster-Meldungen wurde auch bei mir die Eingabe verzögert.

Die erste Annahme, daß es an den Such- und Sortier-Vorgängen liegt, hat sich nicht bestätigt.
Die Verarbeitung einer Message (mit allen Listen) beansprucht bei mir im Haupt-Thread ca. 2ms.
Die weitere Filterung und Anzeige in einem untergeordneten Thread liegt ähnlich, 2 Cores werden schön symmetrisch ausgelastet.

Ich konnte dann die Ursache finden, die Last bei der primären Anzeige im Telnet-Fenster wurde immer größer.
Eigentlich war die Anzeige auf 500 Zeilen begrenzt, ist aber ungewollt immer größer geworden, wenn vom Telnet-Server große Datenblöcke mit mehreren Meldungen kamen.

In 6.70 Beta 3 sollte dieses Problem dann endlich behoben sein ...

73 Ben

[DJ4KW]

Hallo Ben,

ein Jahr und etliche Updates weiter mal keine Fehler-, sondern eine Erfolgsmeldung. Alles läuft schnell und stabil, sowohl an der Feststation auf iMac als auch bei der V3-Expedition auf Mac Book Pro; beides mit Windows XP Professional. Ich denke, dass Updates auf allen Ebenen das bewirkt haben. Eine Version für den Mac ist vermutlich nicht geplant?

[DL7UCX]

Hallo Gert,

vorerst ist nichts für Mac geplant, weil das sehr kompliziert und aufwendig ist, mit meinem gegenwärtigen Delphi als Compiler geht es gar nicht. Das aktuelle Delphi bietet da eventuell Möglichkeiten, aber ein Umstieg ist schon unter Windows gewagt (vom knapp 4-stelligen Preis mal abgesehen, einen Mac müßte ich dann auch noch anschaffen).

Schon die unterschiedlichen Pfad-/Datei-Namen (Windows-Laufwerke!) bedingen Hunderte Änderungen und das ist nur der Anfang.

Diese Plattform-Unabhängigkeit ist schnell und gern gefordert ... wird aber wahrscheinlich von weniger als 5% der Nutzer gebraucht.

73 Ben

[DL6ER]

Hallo Gert,
gibt es keine Möglichkeit Windows-Programme über eine Simulation nativ in Macs Betriebssystem laufen zu lassen?

Beispiel: Linux
Auf meinem Netbook ist ein aktuelles Debian Linux installiert und da kann ich UcxLog im vollen Umfang nutzen
Mir fällt keine Funktion ein, die nicht funktionieren würde (nicht getestet, da bisher nicht benötigt: TRX-Steuerung, CW-Tastung, Network, Cloud, LotW).
Ansonsten läuft alles stabil Out-Of-The-Box.
WINE erzeugt für die WIndows-Programme eine virtuelle Laufwerksstruktur, die der WIndows-Situation ähnlich ist (C:/, D:/, etc sind die Inhalt der Ordner drive_c, drive_c, ...; danach werden CD-Laufwerke und zum Schluss Wechselmedien eingebunden, über das Laufwerk Z:/ hat man schließlich Zugriff aufs Wurzelverzeichnis und kann sich alles von überall aus dem System besorgen).


73 Dominik

[DL7UCX]

Hallo Dominik,

so wie ich Gert verstand, läuft das schon lange erfolgreich so auf dem Mac.

73 Ben

[DL6ER]

Hallo Ben,

sowohl an der Feststation auf iMac als auch bei der V3-Expedition auf Mac Book Pro; beides mit Windows XP Professional.

Ich meinte da das Betriebssystem Mac-OS (oder wie es auch genau heißt), denn zwei Betriebssysteme installiert zu haben, ist auch etwas umständlich. Und ich kaufe mir ja keinen Mac, um dort Windows zu installieren.
Das kann ich auch mit Acer, HP, ... deutlich günstiger zu vergleichbarer Qualität habe

73 Dominik

[DL7UCX]

Gert nutzt "Parallel Desktops":
viewtopic.php?f=38&t=462&start=15#p3367

Ich verstehe das als Windows XP innerhalb des Mac-OS.
Das ist doch ok, wenn's funktioniert.

73 Ben

[DL6ER]

Ja...ok, wer lesen kann ist klar im Vorteil...

Wenn man das Betriebssystem mit Parallels Desktop auch einfrieren kann (sodass man nicht jedes mal neu hochfahren muss), dann will ich mal nichts gesagt haben, dann ist ja alles wunderbar

73 Dominik

[DJ4KW]

Gert nutzt "Parallel Desktops":
viewtopic.php?f=38&t=462&start=15#p3367

Ich verstehe das als Windows XP innerhalb des Mac-OS.
Das ist doch ok, wenn's funktioniert.

73 Ben

Hallo Dominik und Ben,

an der Feststation läuft XP unter "Bootcamp" tatsächlich 'native' denn die Hardware ist ja kompatibel. Zum Wechsel des Betriebssystems wird der Rechner heruntergefahren und mit dem neuen System gestartet, wobei in beschränktem Umfang die Daten des nicht verwendeten Systems zugänglich sind. Mit dieser Umgebung kommen UCXLog und unerfahrene Besucher im Contestbetrieb mit DK0IU am besten zurecht.

Portabel läuft auf Mac Book Pro das XP mit Mac OS X zusammen unter "Parallels Desktop" neben allen anderen Mac Programmen, wobei XP auf den ganzen Plattenspeicher als 'Netzlaufwerk' zugreifen kann (Ben hat anderer Stelle erläutert, wie man trotz anfänglicher Fehlermeldung die Log-Daten außerhalb C: anlegt). Windows kann die Hardware 'native' wie sie ist nutzen, also keine Verluste, indem ein anderer Rechner simuliert wird. Mac Book Notebooks schaltet man normalerweise nicht aus, sondern klappt sie nur zu. XP verkraftet das in dieser Konstellation meist nicht.

[DL7BJ]

Moin,

vorerst ist nichts für Mac geplant, weil das sehr kompliziert und aufwendig ist

In der Tat. Und man muss die Hardware oder VMware Workstation > 9.x + OS X haben.

, mit meinem gegenwärtigen Delphi als Compiler geht es gar nicht. Das aktuelle Delphi bietet da eventuell Möglichkeiten, aber ein Umstieg ist schon unter Windows gewagt (vom knapp 4-stelligen Preis mal abgesehen, einen Mac müßte ich dann auch noch anschaffen).

Ich habe über Jahre mit Delphi gearbeitet. Heute benutze ich entweder FLTK oder Lazarus/CodeTyphon. FLTK ist das Toolkit,
auf dem fldigi & co. basieren. Pures C/C++, wunderbar klein, wunderbar schnell.

Lazarus, oder besser CodeTyphon macht schon Spaß und ich kann viele Delphi-Quelltexte 1:1 übernehmen. Manche haben
ganze Delphi-Projekte einfach mit Lazarus neu kompiliert (die Anforderung hatte ich bisher nicht). Die LCL ist nahezu 100%
kompatible zur VCL und somit geht das recht einfach. Außer, man hat viel an der VCL vorbei programmiert oder extrem viele
Komponenten, die sich nicht umsetzen lassen. Die Wichtigsten sind bei dem CodeTyphon Projekt bereits alle eingebunden,
ob das Report Designer, diverse SQL Komponenten oder die komplette Indy-Suite ist. Bei Lazarus müsste man das alles erst
machen.

Lange Rede, kurzer Sinn (Tipp): Ein Blick auf CodeTyphon oder Lazarus lohnt sich für den Delphi-Entwickler immer. Es ist
alles kostenlos, alles Open Source, kompatibel und läuft unter Linux und Windows, die OS X Variante ist in Arbeit.

Schon die unterschiedlichen Pfad-/Datei-Namen (Windows-Laufwerke!) bedingen Hunderte Änderungen und das ist nur der Anfang.
Diese Plattform-Unabhängigkeit ist schnell und gern gefordert ... wird aber wahrscheinlich von weniger als 5% der Nutzer gebraucht.

Was mit obigen Tools nicht so das Problem ist. Genauso wenig wie die seriellen Schnittstellen usw. Insbesondere bei den mir
bekannten Funkamateuren dürfte die Linux-Nutzer Quote eher bei 50% liegen, aber das hat nichts zu sagen

Hier die Links, vielleicht interessiert das ja jemanden. Ist auch mittlerweile alles ziemlich ausgereift:

http://www.pilotlogic.com/sitejoom/index.php/codetyphon
http://www.lazarus.freepascal.org/
http://www.freepascal.org/

73, Tom

[DL7UCX]

Hallo,

dank der Shareware-Gebühren konnte ich mir das aktuelle Delphi leisten, der Umstieg darauf macht schon unter Windows genug Probleme und ist noch nicht vollzogen.
Für Mac fehlt weiter die Hardware und vor allem die Zeit.

Ein Blick auf andere Compiler ist für mich aus Zeit-, Aufwands- und Risiko-Gründen absolut indiskutabel.

In den jetzt über 140 000 Zeilen Source-Code stecken viele trickreiche, mühsam gefundene Lösungen von Windows- und Delphi-Problemen, die ich nicht antasten werde.

73 Ben