ST 2110 Sistemlerinde PTP ve SMPTE ST 2059: Zaman Senkronizasyonu Olmadan IP Broadcast Olmaz

Özet

• PTP, ST 2110 sisteminin saatidir: Video, ses ve ANC akışlarının aynı zaman referansına kilitlenmesini sağlar
• SMPTE ST 2059, broadcast ortamlarında IEEE 1588 PTP’nin nasıl kullanılacağını tanımlar
• ST 2110-10, sistem timing modelini PTP zamanına bağlar
• ST 2110-21, video RTP paketlerinin gönderici çıkışındaki zamanlama davranışını tarif eder
• TAI/UTC/leap second ve ST 2059-1, PTP zamanının video frame, audio sample ve RTP timestamp dünyasına nasıl bağlandığını açıklar
• Grandmaster seçimi, BMCA, boundary clock ve transparent clock üretim ortamında kritik tasarım kararlarıdır
• PTP düzgün değilse görüntü var gibi görünse bile audio drift, lip-sync problemi, buffer taşması, jitter ve receiver lock sorunları görülebilir

Not: Bu yazı ST 2110 kampüs, ST 2110 routing, ST 2110 monitoring, NMOS ve Intel MTL yazılarını zaman senkronizasyonu açısından tamamlar.

1. PTP neden bu kadar önemli?

SDI dünyasında cihazlar genellikle black burst veya tri-level sync ile aynı referansa kilitlenirdi. ST 2110 dünyasında medya IP paketleriyle taşınır; fakat bu, zaman referansının ortadan kalktığı anlamına gelmez. Tam tersine, zaman daha merkezi bir probleme dönüşür.

ST 2110’da video, audio ve ancillary data ayrı RTP akışlarıdır. Bu akışlar farklı multicast adreslerinden, farklı portlardan ve hatta farklı cihazlardan gelebilir. Receiver’ın bu akışları doğru hizalaması için herkesin aynı zaman dilimini kullanması gerekir. Bu ortak zaman dili PTP ile sağlanır.

Basit söylemek gerekirse:

• RTP paketleri medyayı taşır
• SDP akışı tarif eder
• NMOS bağlantıyı yönetir
• PTP ise sistemin ne zaman olduğunu söyler

PTP yoksa ST 2110 hâlâ paket gönderebilir; fakat broadcast sistemi gibi davranmaz. Cihazlar aynı frekansta çalışmıyorsa zamanla drift oluşur. Cihazlar aynı epoch’a ve alignment point’e kilitli değilse frame, audio sample ve ANC zamanlaması doğru yorumlanamaz.

2. SMPTE ST 2059 neyi çözer?

IEEE 1588 genel amaçlı bir Precision Time Protocol standardıdır. Finans, enerji, telekom, endüstriyel ağlar ve broadcast gibi birçok alanda kullanılabilir. Broadcast için ise yalnızca “PTP kullanıyoruz” demek yeterli değildir. Hangi profil, hangi epoch, hangi domain, hangi mesaj aralıkları ve hangi alignment davranışı kullanılacak?

SMPTE ST 2059 ailesi bu soruya broadcast cevabı verir:

ST 2110 sistemlerinde özellikle SMPTE ST 2059-2 PTP profile önemlidir. Bu profil, cihazların aynı broadcast zaman davranışını beklemesini sağlar.

Buradaki kritik nokta şudur: Switch veya cihaz “PTP destekliyorum” dediğinde bunun broadcast için yeterli olup olmadığı ayrıca kontrol edilmelidir. Bir cihaz IEEE 1588 destekleyebilir ama SMPTE ST 2059-2 profilini doğru desteklemeyebilir.

3. ST 2059 epoch, TAI, UTC ve leap second ilişkisi

PTP zamanını anlamak için UTC ve TAI farkını bilmek gerekir.

PTP’nin broadcast için değerli olmasının sebeplerinden biri, zaman dağıtımını deterministik ve leap second etkilerinden kontrollü hale getirmesidir. Grandmaster genellikle GNSS gibi bir referanstan UTC bilgisi alır, UTC-TAI offset bilgisini bilir ve PTP domain’ine doğru zaman bilgisini dağıtır.

ST 2110 tarafında bu zaman doğrudan “ekranda saat kaç?” sorusu için değil, frame, audio sample ve RTP timestamp hizalaması için kullanılır.

RTP timestamp ile PTP aynı şey değildir. RTP timestamp medya akışının kendi zaman eksenidir; PTP ise tesisin ortak zaman referansıdır. Receiver bu ikisini birlikte yorumlayarak “bu video frame hangi anda oynatılmalı, bu audio sample hangi frame ile hizalanmalı?” sorusunu cevaplar.

ST 2110 ortamında bu ilişki SDP içinde de görünür. ts-refclk receiver’a timestamp reference clock’un PTP olduğunu, mediaclk ise RTP media clock’un bu referansa nasıl bağlandığını anlatır.

1
2

a=ts-refclk:ptp=IEEE1588-2008:00-1D-C1-FF-FE-12-34-56:127
a=mediaclk:direct=0

Buradaki detay önemlidir: Paketler doğru multicast adrese gidiyor olabilir, ama SDP’de clock reference yanlış tarif edilmişse receiver medya zamanını yanlış yorumlayabilir. Bu yüzden PTP troubleshooting sırasında SDP clock satırları da kontrol edilmelidir.

4. ST 2059-1: Video faz hizalaması

ST 2059-2 PTP profilini tarif eder; ST 2059-1 ise PTP zamanından video/audio sinyal fazının nasıl türetileceğini anlatır.

Başka bir deyişle: PTP zamanını aldık, peki video frame başlangıcı hangi ana denk geliyor? 1080p50, 1080i59.94 veya 2160p50 sinyallerinin PTP epoch’una göre faz ilişkisi nasıl kuruluyor? ST 2059-1 bu soruların modelidir.

Örnek olarak:

• 1080p50 frame periyodu 20 ms’dir
• 2160p50 için frame periyodu yine 20 ms’dir, fakat payload ve bandwidth farklıdır
• 59.94 tabanlı formatlarda 1000/1001 zaman yapısı dikkat ister
• Audio sample clock, video frame boundary ve RTP timestamp birlikte hizalanmalıdır

Bu yüzden ST 2059 yalnızca “cihaz saatleri aynı olsun” meselesi değildir. Aynı zamanda cihazların video frame başlangıcını, audio sample hizasını ve medya presentation zamanını aynı matematikle hesaplamasını sağlar.

5. PTP, NTP ve genlock aynı şey mi?

Hayır.

NTP sistem logları, monitoring ve genel işletim sistemi zamanı için hâlâ işe yarar. Fakat ST 2110 media essence hizalaması için NTP kullanılmaz. Burada gereken şey hardware timestamping destekli PTP senkronizasyonudur.

6. Grandmaster, ordinary clock, boundary clock, transparent clock

PTP ağında her cihazın rolü aynı değildir.

Küçük lab ortamında grandmaster doğrudan endpoint’lere ulaşabilir. Büyük production fabric’te ise boundary clock veya transparent clock tasarımı neredeyse zorunlu hale gelir.

Yanlış tasarımda grandmaster iyi olsa bile endpoint kötü zaman görebilir. Bunun nedeni switch path gecikmesi, queueing, PTP paketlerinin QoS önceliği almaması veya boundary/transparent clock davranışının yanlış yapılandırılması olabilir.

7. BMCA: Grandmaster nasıl seçilir?

PTP ağında birden fazla grandmaster adayı olabilir. Hangi clock’un master olacağını Best Master Clock Algorithm (BMCA) belirler.

BMCA tipik olarak şu parametrelere bakar:

• priority1
• clock class
• clock accuracy
• offset scaled log variance
• priority2
• clock identity

Production ortamında BMCA’yı “otomatik bir sihir” gibi bırakmak risklidir. İstenen grandmaster’ın gerçekten seçildiği, backup grandmaster’ın doğru sırada beklediği ve failover anında sistemin beklenen davranışı verdiği test edilmelidir.

Clock Class, BMCA kararında ve operasyonel monitoring’de özellikle önemlidir. Değerler profile ve cihaz davranışına göre yorumlanmalıdır; yine de sahada sık görülen örnekler şöyledir:

Bu nedenle yalnızca “GM var” demek yeterli değildir. GM’in clock class değeri, reference state’i ve holdover davranışı da izlenmelidir.

Önemli pratik uyarı: Failover yalnızca “cihaz B master oldu” diye başarılı sayılmaz. Receiver’lar lock kaybediyor mu, audio drift oluyor mu, ST 2022-7 path’leri farklı master’a mı bakıyor, bunlar ayrıca izlenmelidir.

8. Yedekli zaman mimarisi

Gerçek ST 2110 tesislerinde tek grandmaster tasarımı genellikle yeterli kabul edilmez. Yaygın yaklaşım, aynı referans kaynağına veya kontrollü yedek referanslara bağlı iki grandmaster kullanmaktır.

Bu mimaride üç davranış özellikle test edilmelidir:

Holdover “sistem çalışmaya devam ediyor” anlamına gelir; “zaman kalitesi aynı kaldı” anlamına gelmez. Bu yüzden holdover süresi, clock class değişimi ve offset drift’i monitoring tarafında alarm üretmelidir.

9. PTP domain ve profile karmaşası

Broadcast sahalarında birden fazla zaman domain’i görülebilir:

• ST 2059-2 domain’i
• AES67 audio domain’i
• test/lab domain’i
• vendor default domain’i
• control network tarafında farklı PTP/NTP düzeni

En sık yapılan hatalardan biri, cihazların aynı multicast media fabric’te görünmesine rağmen farklı PTP domain’lerine kilitlenmesidir. Bu durumda receiver SDP’yi alır, multicast join yapar, paketler gelir; ama medya zamanlaması yanlış olabilir.

Özellikle ST 2110 ve AES67 birlikte kullanıldığında domain konusu çok sık hata üretir. Pratikte SMPTE ST 2059-2 için varsayılan domain 127, AES67 için varsayılan domain 0 olarak görülür. AES67 cihazları domain 0’da kalırken ST 2059 cihazlarının domain 127’de çalışması, “paket geliyor ama zaman uyumu bozuk” tipinde zor teşhis edilen sorunlara yol açabilir.

Production notu: 127’nin default olması onu her tesis için en iyi seçim yapmaz. Bazı tasarımlar, vendor default değerleriyle çakışmayı azaltmak için dokümante edilmiş farklı domain değerleri kullanır. Önemli olan domain’in tesiste bilinçli seçilmesi, tüm cihazlarda aynı şekilde uygulanması ve monitoring’de açıkça izlenmesidir.

10. PTP mesaj tipleri: Ağda hangi mesajlar geziyor?

PTP’yi troubleshoot ederken yalnızca “PTP var mı?” diye bakmak yetmez. Hangi mesajların düzenli geldiğini bilmek gerekir.

ST 2059-2 ortamında Announce mesajları BMCA davranışını anlamak için özellikle kritiktir. Sync ve Follow_Up ise zaman dağıtımının kalitesini görmeye yardım eder. Delay mesajları path delay hesaplamasında rol oynar.

Burada One-Step Clock ve Two-Step Clock ayrımı da önemlidir:

Grandmaster, switch ve endpoint davranışını incelerken bu fark Wireshark tarafında doğrudan görünür. Follow_Up mesajı beklediğiniz halde gelmiyorsa veya cihaz one-step/two-step beklentisiyle uyumsuzsa PTP analizi yanıltıcı olabilir.

Delay mechanism de aynı derecede önemlidir:

E2E ve P2P davranışını aynı PTP domain içinde kontrolsüz karıştırmak, path delay hesaplarını ve receiver lock davranışını bozabilir. Switch, grandmaster ve endpoint’lerin aynı delay mechanism beklentisiyle çalıştığı doğrulanmalıdır.

11. QoS: PTP küçük pakettir ama etkisi büyüktür

PTP trafiği bandwidth olarak küçüktür; fakat delay variation’a çok hassastır. Bu yüzden broadcast ağlarında PTP çoğu zaman en yüksek öncelikli queue’ya alınır.

Tipik tasarım mantığı:

DSCP/CoS değerleri vendor ve tesis politikasına göre değişebilir. Bazı yapılarda PTP için CS7 veya benzeri en yüksek sınıflar, media için EF/AF tabanlı sınıflandırma kullanılabilir. Burada önemli olan ezber değer değil, tüm switch fabric boyunca aynı QoS politikasının korunmasıdır.

Arista, Cisco, NVIDIA/Mellanox, Evertz, Grass Valley, Imagine veya Lawo gibi farklı ekosistemlerde komutlar değişebilir; fakat prensip aynıdır: PTP paketleri queue içinde bekletilmemeli, switch residence time belirsizliği minimumda tutulmalıdır.

12. ST 2022-7 ve PTP ilişkisi

ST 2022-7 media redundancy sağlar; PTP redundancy sağlamaz. Bu ayrım kritik önemdedir.

ST 2022-7 ile aynı RTP stream A ve B path üzerinden taşınır. Receiver iki path’ten gelen paketleri sequence number ve zaman davranışına göre birleştirir. Fakat A path ve B path farklı PTP domain, farklı grandmaster veya farklı clock kalitesi görüyorsa seamless switching beklenenden kötü davranabilir.

Kötü örnekler:

• A path GM A’ya, B path GM B’ye kilitli ama GM’ler aynı referansa bağlı değil
• A path domain 127, B path domain 0
• A network boundary clock kullanıyor, B network transparent clock kullanıyor ve gecikme davranışı farklı
• Media ST 2022-7 redundant, fakat PTP sadece tek path üzerinden geliyor

Production tasarımda A/B media path’lerinin yanı sıra PTP stratejisi de redundant düşünülmelidir. Endpoint’lerin hangi GM identity’yi gördüğü, A/B path offset farkı ve failover anında receiver davranışı birlikte test edilmelidir.

13. ST 2110-30, AES67 ve audio clock recovery ilişkisi

ST 2110-30, AES67 timing kavramlarıyla yakından ilişkilidir. Video tarafında frame boundary ne kadar önemliyse, audio tarafında sample clock ve packet time hizası da o kadar önemlidir.

PTP, audio sampling clock için de referanstır. 48 kHz audio sample rate kullanan bir sistemde sender ve receiver aynı zaman referansına kilitlenmezse audio drift, sample slip, click/pop veya lip-sync problemleri oluşabilir.

Bu nedenle PTP problemleri yalnızca video lock sorunu olarak görünmez. Bazen ilk belirti, sesin zamanla kayması veya nadir duyulan audio artifact’leri olabilir.

14. Linux tarafı: ptp4l, phc2sys ve hardware timestamping

Software-based ST 2110 sistemlerinde Linux host’un PTP davranışı kritik hale gelir. Özellikle Intel MTL, FFmpeg, GStreamer veya custom RTP uygulamalarıyla çalışırken NIC hardware clock, kernel clock ve uygulama timestamp davranışı doğru anlaşılmalıdır.

Temel bileşenler:

Basitleştirilmiş akış:

Örnek kontrol komutları:

1
2
3
4
5

ethtool -T eth0
pmc -u -b 0 'GET CURRENT_DATA_SET'
pmc -u -b 0 'GET TIME_STATUS_NP'
journalctl -u ptp4l -f
journalctl -u phc2sys -f

ethtool -T çıktısında hardware timestamping desteği yoksa, yüksek doğruluklu ST 2110 timing beklemek gerçekçi değildir. Lab testleri çalışabilir; production davranışı başka bir konudur.

15. ST 2110-21 ve PTP ilişkisi

ST 2110-21, video RTP göndericisinin paketleri nasıl zamanladığını tarif eder. PTP burada “saat kaç?” sorusunu cevaplar; ST 2110-21 ise “bu video paketleri bu saate göre nasıl çıkmalı?” sorusuna cevap verir.

PTP doğru olsa bile sender bursty davranıyorsa receiver buffer sorun yaşayabilir. Tersine, sender pacing iyi olsa bile PTP offset veya drift kötüyse stream senkronizasyonu bozulabilir. Bu yüzden PTP ve packet pacing ayrı ama birbirine bağlı iki konudur.

1
2
3
4
5

Kötü durum:
PTP offset + bursty packet output + küçük receiver buffer = lock/drop/jitter problemi

İyi durum:
Stable PTP + ST 2110-21 uyumlu pacing + doğru buffer = deterministik media flow

16. Minimal lab topolojisi

PTP öğrenmek için devasa bir fabric gerekmez. Ama lab ortamı production gibi düşünülmelidir.

Minimum kontrol listesi:

• Grandmaster ST 2059-2 profile ile çalışıyor mu?
• Switch PTP paketlerine QoS önceliği veriyor mu?
• Endpoint’ler aynı PTP domain’i görüyor mu?
• NIC hardware timestamping aktif mi?
• ptp4l offset ve frequency adjustment değerleri stabil mi?
• RTP stream üzerinde packet loss veya sequence gap var mı?
• Receiver buffer doluluk oranı ve lock state izleniyor mu?

17. Production tasarım checklist’i

PTP tasarımı çizim üzerinde doğru görünse bile test edilmeden güvenilmez. Özellikle failover testleri planlı bakım zamanında değil, kurulum kabul sürecinde yapılmalıdır.

18. İzleme: hangi metrikler takip edilmeli?

PTP monitoring yalnızca “locked/unlocked” değildir. Bir cihaz lock görünüp yine de kötü zaman kalitesi üretebilir.

İzlenmesi gereken temel metrikler:

• grandmaster identity
• clock class
• PTP domain
• offset from master
• mean path delay
• frequency adjustment
• port state
• announce/sync/follow_up message counters
• BMCA state changes
• servo state
• GM failover event’leri

Buradaki PTP servo, endpoint’in local clock’unu grandmaster’a yaklaştıran kontrol döngüsüdür. Servo state dalgalanıyorsa offset metriği anlık iyi görünse bile sistem kararlı kabul edilmemelidir.

Örnek alarm mantığı:

Örnek operasyon eşikleri tesis politikasına ve cihaz toleranslarına göre değişir; yine de başlangıç için şu mantık kullanılabilir:

PTP metrikleri RTP metrikleriyle birlikte okunmalıdır. Örneğin aynı anda PTP offset yükseliyor, RTP jitter artıyor ve receiver buffer dalgalanıyorsa problem tek tek değil sistemik düşünülmelidir.

19. Wireshark ile hızlı PTP kontrolü

Sahada ilk bakılacak araçlardan biri hâlâ Wireshark’tır.

1
2
3
4
5
6

ptp
ptp.v2
ptp.v2.messageid == 0x0    # Sync
ptp.v2.messageid == 0x8    # Follow_Up
ptp.v2.messageid == 0xb    # Announce
ptp.v2.domainNumber == 127 # örnek domain kontrolü

Bakılacak noktalar:

• Announce mesajları düzenli geliyor mu?
• Aynı network’te beklenmeyen ikinci bir grandmaster var mı?
• Domain number doğru mu?
• Source MAC/vendor beklenen GM veya boundary clock’a mı ait?
• Sync ve Follow_Up mesajları beklenen aralıkta mı?

Wireshark PTP’nin her problemini çözmez; fakat yanlış domain, beklenmeyen GM, kayıp announce veya VLAN/QoS yanlışlığı gibi hataları hızlı görünür hale getirir.

20. Sık görülen arızalar

Bu bölüm sahada daha kullanışlı olsun diye problem/kanıt/çözüm formatında okunmalıdır. PTP sorunları çoğu zaman tek bir log satırıyla yakalanmaz; PTP, RTP, switch telemetry ve receiver state birlikte değerlendirilmelidir.

Pratik sıralama:

1. Önce GM identity, domain ve clock class doğrulanır.
2. Sonra endpoint offset, mean path delay ve servo state kontrol edilir.
3. Ardından RTP sequence, packet pacing ve receiver buffer davranışı incelenir.
4. En son switch QoS, boundary/transparent clock ve host tuning detaylarına inilir.

21. PTP tasarımında dikkatli olunması gerekenler

PTP’yi media network’ten bağımsız düşünmeyin. PTP paketleri küçük olabilir ama etkisi büyüktür. QoS, VLAN, switch queue ve boundary clock davranışı medya kalitesini doğrudan etkileyebilir.

Aynı cihazda birden fazla zaman kaynağı varsa açık karar verin. GNSS, black burst, PTP, NTP ve internal clock birlikte görünüyorsa hangi referansın master olduğu net olmalıdır.

Vendor default değerlerine güvenmeyin. Domain, priority, announce interval ve profile değerleri cihazdan cihaza değişebilir.

A/B redundancy’de iki path’in PTP davranışını ayrı izleyin. ST 2022-7 medya path’i redundant olsa bile zaman referansı tarafında asimetri varsa failover anında sürpriz yaşanabilir.

Software-based ST 2110 için host tuning önemlidir. PTP doğru olsa bile CPU jitter, NIC queue, IRQ affinity, NUMA ve driver ayarları sender/receiver davranışını bozabilir.

22. PTP ile NMOS ilişkisi

NMOS cihazları keşfeder, kaynakları tarif eder ve bağlantıları yönetir. PTP ise zaman referansını sağlar. Bunlar aynı problemi çözmez.

Bir receiver NMOS ile doğru sender’a bağlanabilir, SDP doğru olabilir, multicast join başarılı olabilir; fakat PTP yanlışsa medya yine problemli çalışır. Bu yüzden ST 2110 troubleshooting sırasında “NMOS bağlantısı tamam” demek yeterli değildir.

23. Sonuç

ST 2110 sistemlerinde PTP yardımcı bir servis değil, media fabric’in temel zaman katmanıdır. SMPTE ST 2059 olmadan ST 2110 akışları teknik olarak paketlenebilir; fakat güvenilir, senkron ve broadcast davranışı beklemek gerçekçi değildir.

Sağlam bir ST 2110 tasarımında PTP şu şekilde ele alınmalıdır:

• grandmaster ve backup grandmaster planı net olmalı
• BMCA davranışı test edilmeli
• switch’lerin boundary/transparent clock rolü bilinmeli
• endpoint’lerin aynı ST 2059-2 profile ve domain’de olduğu doğrulanmalı
• PTP offset, GM identity ve servo state sürekli izlenmeli
• failover, cable pull ve restart senaryoları gerçek medya akışlarıyla test edilmeli

Kısacası: ST 2110’da görüntüyü RTP taşır, sesi ST 2110-30 taşır, ANC’yi ST 2110-40 taşır; ama hepsini aynı yayının parçası yapan şey zamandır. O zamanı da PTP ve SMPTE ST 2059 sağlar.

PTP golden rules

Kaynaklar

• SMPTE ST 2110 Standards
• SMPTE ST 2059-2:2021
• SMPTE EG 2059-10:2023
• linuxptp documentation: ptp4l
• linuxptp documentation: phc2sys
• Wireshark RTP Analysis
• İlgili yazı: ST 2110 ile Bir Televizyon Kampüsüne Genel Bakış
• İlgili yazı: SMPTE ST 2110 Sistemlerinin İzlenmesi
• İlgili yazı: Intel Media Transport Library ile ST 2110