Niestabilny i wysoki czas pakietu w sieci LAN, protokół PTP

Odpowiedz Nowy wątek
2019-11-09 21:25

Rejestracja: 1 rok temu

Ostatnio: 19 godzin temu

0

Nie mogę zaimplementować protokołu PTP, ze względu na wysoki i niestabilny RTT w sieci LAN. Do routera (bez dostępu WAN) mam podłączone 6 tabletów Android/iOS, z których jeden jest serwerem, względem którego, reszta powinna dostroić zegarek. Potrzebuję precyzji rzędu 10 ms.

Do zaimplementowania PTP kluczowe jest oszacowanie ile średnio idzie pakiet z clienta do serwera. W moim wypadku, są to wartości skaczące losowo w zakresie 6 do 250 ms (w LAN!). Oczywiście z takim rozstrzałem protokół jest zupełnie bezużyteczny.

Za taki RTT odpowiada:

  1. Android/iOS generujący takie opóźnienia ?
  2. QtUdpSocket, system signal/slots, event loop czy inny element Qt, przez który pojawia się opóźnienie od momentu otrzymania pakietu, do momentu jego obsługi.
  3. Wahania rzędu 4-250 ms są normalne dla domowych routerów w sieci wan.

Jaki jest inny sposób, żeby zsynchronizować kilka tabletów w jeden duży ekran wyświetlający film?

Pozostało 580 znaków

vtx
2019-11-10 08:12
vtx

Rejestracja: 6 miesięcy temu

Ostatnio: 2 minuty temu

0

Jeśli to ma działać w sieci LAN to może da się zastosować multicasta do emisji obrazu a nie protokoły połączeniowe? Druga rzecz - stworzyć odpowiednie regułki QoS dla komunikatów synchronizujących czas, tak żeby miały najwyższy priorytet.

Pozostało 580 znaków

2019-11-13 02:41

Rejestracja: 1 rok temu

Ostatnio: 19 godzin temu

0

@vtx: To nie do końca jest streaming. Gotowe video są już wgrane na wszystkie urządzenia. Wysyłam tylko małe pakiety, żeby na wszystkich urządzeniach odtwarzanie rozpoczęło się równocześnie i w celu synchronizacji czasu pomiędzy nimi.

  1. Obecnie tablet-serwer wysyła do każdego z sześciu urządzeń oddzielnie komendy po TCP (muszą mieć gwarancje dostarczenia). Albo samemu zaimplementować gwarancję dostarczenia w oparciu o UDP? Może wtedy multicast byłby wydajniejszy niż kilka socketów TCP? Mam małe doświadczenie w programowaniu sieciowym i nie wiem jak wygląda różnica wydajności pomiędzy różnymi rozwiązaniami.
  2. Obecnie wygląda to tak, zarówno dla TCP (wysyłanie komend) jak i UDP (protokół ptp):
    tcpSocket->setSocketOption(QAbstractSocket::LowDelayOption, 1);
    tcpSocket->setSocketOption(QAbstractSocket::KeepAliveOption, 1  );
    tcpSocket->setSocketOption(QAbstractSocket::TypeOfServiceOption, 160); //CRITIC/ECP

    Co jeszcze mógłbym zrobić w ramach QoS?

edytowany 1x, ostatnio: Kamil Raju, 2019-11-13 02:44

Pozostało 580 znaków

vtx
2019-11-13 07:13
vtx

Rejestracja: 6 miesięcy temu

Ostatnio: 2 minuty temu

0

W sumie nie używałem nigdy protokołu PTP, ale skoro kontent video jest już wgrany na każdym z systemów docelowych - czyli nie musisz streamować go, to czy nie wystarczy tylko wysyłać multicastem komunikaty o aktualnym czasie i ewentualnie jakieś inne wymagane informacje do synchronizacji? QoS tutaj nie będzie potrzebny bo nie ma problemu przeplatania pakietów ze streamem i pakietów synchronizujących czas. W takiej sytuacji masz jeden moment, w którym strona nadawcza emituje ramki synchronizujące - czyli nie ma efektu różnych czasów wysyłania pakietów synchro i nie potrzebujesz potwierdzenia że doszły. Wysyłasz jedną ramkę multicast i każdy z zasubskrybowanych systemów odbiera go (na poziomie sterownika karty sieciowej) w tym samym czasie bez rozjazdu spowodowanego kolejkowaniem pakietów w kolejce wyjściowej systemu nadawczego.

Takie rozwiązanie z multicastem wydaje mi się optymalne w takiej sytuacji.

Pozostało 580 znaków

Odpowiedz

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0