interpretiert die automatische Helligkeitsregelung direktes Sonnenlicht als Nacht und dimmt das Display.
Vorsicht, sowas hatte ich neulich auch, nur dass auch Abdunkeln des Sensors an der Helligkeit erstmal nichts änderte... bis ich dahinter kam, dass das Device wegen Überhitzung durch extremer Sonneneinwirkung die CPU und Helligkeit hart gedrosselt hat um den eigenen Heldentot zu vermeiden.
Das Problem das die Durchleitung des PTP auf den Ports der Switch nie wirklich konstant und gleich erfolgt. Durch zusätzlichen Datenverkehr muss die Switch immer mehr Entscheidungen treffen. Das führt dazu das die Latenz wackelt. Der Algorithmus sorgt dafür das solch ein Gerät nicht Master wird.
Die Anzahl der Entscheidungen lässt kaum einen in den letzten zwei Jahrzehnten gebauten Switch ins schwitzen geraten. Parallel eintreffende Datenpakete auf multiplen Ports, die dann aber nicht gleichzeitig auf einem egress-Ports ausgeleitet werden können, erzeugen hingegen auf jedweder Hardware Jitter.
Aus diesem Grund wird, wenn PTP in ernsthaft kritischer Genauigkeit einen Takt weiterleiten soll, PTP von allen Netzwerkkomponenten gesprochen, inklusive der Switches und Router. Dann ist es irrelevant, wie gross eine Queue im Switch geworden ist oder wie lange ein Router braucht um ein Paket zu forwarden. Der Takt-Zähler ist immer auf den vom Grandmaster bezogenen Takt synchron und durch Queues auftrende Delays der Signalisierungspakete werden beim weiterleiten irrelevant. In dieser Hinsicht ist PTP den anderen Protokollen überlegen, welche nur eine Delay und Jitter-Detection haben, die auf Heuristik basieren oder anderen "das macht es zumindest besser" Optimierungen.
Das ist hauptsächlich im Industrie- und Mobilfunkumfeld ein gängiges Setup und Teil der entsprechenden Produkte. Vorteil: solche Switche sind in der Regel auch etwas robuster, was Temperatur angeht. Würden sich also auch eher weniger daran stören im gleichen Rack eingebaut zu werden, in dem schon 10HE Verstärker vorglühen :wink:
Finanziell werden sich solche Produkte aber kaum für den Veranstaltungssektor rechnen, da die in solchen Netzwerken nötige Genauigkeit für PTP-Verhältnisse klein ist und die Preise für solche Geräte deftig.
Ein Problem vom PTP im Vergleich zu anderen "Zeitsynchronisierungsprotokollen" ist aber, dass es zwar eine automatische Master-Election gibt, diese aber primär von der von den Zeitprovidern angegebenen Genauigkeit gelenkt wird und auf welche Jitter-Detection keinen Einfluss hat (zumindest nicht in den Standard-Profilen). Siehe Abschnitt 9.3 von IEEE Std 1588 (IEC 61588). Sollte der Jitter also wirklich in für die Anwendung relevante Größenordnungen reichen, sollte man evtl. doch in bessere Hardware investieren. Audio ist hier noch nicht wirklich anspruchvoll.
Zudem ist sicherlich auch nicht jeder PTP-Stack, der im Master und Slave-Modus vor sich hinrennt, sinnvoll konfiguriert (der gewöhnliche Normaluser wäre mit der Parametrisierung hinreichend überfordert), so dass Hersteller einfach 08/15 Werte pi mal Daumen vorgeben. Mit dem Ergebnis dass es bei gleichkonfigurierten Geräten in der Realität zu wüsten Quer-Synchronisierungen und Problemen mit Korrektur-Werten kommen kann (TAI vs UTC-Offset mit korrekten Leap-Seconds?)
Daher ist es nicht unwahrscheinlich, dass es einfach verdammt sinnvoll ist, in der Konfiguration aller Geräte festzunageln wer gefälligst Master und wer alles nicht Master sein soll. Das Gerät mit der höchstwahrscheinlich nicht wie ein PC herumeiernden Uhr sollte möglichst nicht den Takt bestimmen und ein Gerät mit sehr gutem Taktgenerator wird höchstwahrscheinlich ein guter Kandidat sein. Und schon ist das Thema gegessen und man sich wieder den kaputten Cat-Kabeln widmen.
so sieht es aus, weiterraten...
