Re: [DDL-ML] Timing Probleme

[Matthias Trute <mtrute@topmail.de>]

Hallo Peer, Olaf

> > > Spricht das eigentlich für eine Bearbeitung
> > > der Einschaltzeit im Server oder eher dagegen?
> >
> > Meiner Meinung nach spricht das derzeit nur gegen die akuelle
> > Implementierung im erddcd.
>
> Also da würde ich schon weiter gehen. Wie ich ausgeführt habe, bin ich
> der Meinung, dass _ausschließlich_ der Server die Einschaltzeit
> verwalten kann. (Es sei denn wir erweitern das Protokoll, so dass der
> Client den tatsächlichen Einschaltzeitpunkt erfährt.)

Kann der Client nicht den Zeitpunkt nehmen, an dem der INFO das
Ereignis kund tut? Da ist das Ereignis *sicher* an der Anlage angekommen.

Für Echtezeitanforderungen im Millisekundenraster halte ich TCP/IP aber
nicht für das geeignete Übetragungsmedium. Das aber mal nur so nebenbei.

Ergo: sowas ist Sache des Servers. Daraus folgt dann aber auch:
Wenn es zeitlich begrenzte Einschaltzeiten geben soll, so sollten
die besser vom Server verwaltet werden. Der Client ist da reichlich
chancenlos, gerade wenn der Server mal "Streß" hat.

>
> > Nach SRCP 0.7.3 muss der Server das können.

die weiteren SRCP's werden da auch kaum abweichen ;=)

> Da stellt sich mir dann die Frage, ist es überhaupt notwendig (und
> sinnvoll), die Einschaltzeit im Client steuern zu können? Könnte man bei
> SET GA nicht <action> weglassen und ein positives Delay fordern?

doch, Sinn macht das mit der Clientseitigen Steuerung schon: Denk mal an
Entkuppler. Die müssen schon mal ein paar viele Zehntelsekunden aktiv sein.
Ohne Pause zwischendurch. Zumindest keine nennenswerte (die IB hat da wohl
welche). Wir sollten nur darauf drängen, das Weichen (die wohl überwätligende
Mehrzahl der GA's) vom server geschaltet werden. j-man und Co vertrauen
da dem Server zuwenig.. ;=)

Würde ein GI == Generic Impulse helfen? Klar: nur wegen der tumben Clients.


>
> connection reset by

na, ich hoffe doch nicht ;=)

Matthias

--
GPGP 1024D/77E30063 mailto:mtrute@topmail.de
http://members.tripod.de/mtrute/