"HF5BS" <h...@...pl> writes:

> No, zgadza się. Dlatego też zapewne w traktach cyfrowych nie szło to
> jako część kanałowej paczki danych, tylko TCK-30 (de facto -32) mając
> 30 kanałów cyfrowych, miały dodatkowe dwa (szczelina 1 i 16 OIDP) na
> wyłącznie sygnalizację.

Dokładniej rzecz biorąc, szczelina 0 była wykorzystywana do sygnalizacji
niskopoziomowej (w szczególności do synchronizacji strumienia w czasie,
do CRC-4 itd), natomiast TS16 - na wyższym poziomie (np. do zestawiania
połączeń telefonicznych, odpowiednik kanału D w PRI).

Jeśli dany link służył do połączeń "permanentnych" (kanały dzierżawione
zamiast telefonii - PVC), i przypisanie kanał logiczny <> zestaw
szczelin było stałe, to sygnalizacja w TS16 była zbędna, i jeśli tylko
wszystkie urządzenia to wspierały, można było używać 31 szczelin.

Jeśli cały link był używany jako jeden strumień (np. Internet dla
jednego klienta), to można było w ogóle zrezygnować z interfejsu Nx64,
i wykorzystywać pełne 2048 kb/s w sposób przezroczysty (bez ramkowania
G.704). Zresztą była to tańsza opcja, Nx64 to był dodatkowy koszt.
Ew. mógłby tam być jakiś problem, gdybyśmy chcieli przemultipleksować
E1 w E3 (nadgorliwy multiplekser mógł nie lubić sygnału bez TS0).

Telefonia (normalna cyfrowa, nie VoIP) nie wykorzystywała kompresji
(pomijając kompresję dynamiki), dane były przesyłane synchronicznie
(w "paczkach" jednobajtowych) i bez pakietyzacji. Stąd brak związanych
z tym opóźnień.

> Ano - i już masz przyrost czasu na tyle, że daje się odczuć - jak
> zrobisz eksperyment, że zadzwonisz z jednego telefonu na drugi,
> będziesz do jednego mówić, a z drugiego słuchać, to czasem rozrzut
> czasowy może być bardzo duży i przestaniemy się dziwić, że przy
> szybkiej dyskusji rozmówca przestaje nas rozumieć.

Albo zbyt długie czasy "propagacji" (RTT) - kiepskie łącza, albo kiepska
implementacja buforowania. Czas kompresji - praktycznie bez znaczenia.

> OK, ale sam czas dla danych, to się raczej ściąć nie da, to co mówiny,
> nie wypowie się nagle szybciej, a skoro kodeki mocniejsze, to i czas,
> który musimy przesunąć, także...?

Eee tam. Mocniejszy kodek = obecnie mniejsze pasmo po kompresji, czasy
się praktycznie nie zmieniły. Natomiast jakby ktoś chciał przesyłać
zamiast mowy np. muzykę, to może się zdziwić.

> Nie bardzo sobie wyobrażam, aby, przerysowując, ilość danych, gdzie
> mówimy "wyindywidualizowaliśmy się z rozentuzjazmowanego tłumu
> prestidigitatorów", które wypowiadam w 3.8 sekundy, nagle miało się
> wypowiedzieć w 2.1 sekundy. Może, mając już taką treść gotową w pliku
> WAV, to podstawiamy i zakoduje się w 0.1 sekundy. Ale i tak, jak np.
> gadam przez fona, czy "skajpa", to i tak, zanim kodek otrzyma paczkę
> danych, to te 3.8 sekund minie, zakoduje sobie w 0.1 i mamy zwłokę
> 3.9...

Tyle że taka paczka danych to np. 25 lub 30 ms, nie jakieś sekundy.
I to się specjalnie nie zmieniało w ciągu ostatnich 20+ lat.
Opóźnienia były związane z długimi czasami propagacji, np. przez
geostacjonarnego satelitę - dodatkowo ok. 500 ms. Od czasu, gdy do
łączności z Ameryką zaczęto używać (tylko) podwodnych kabli, ten problem
przestał być istotny (to tu był problem w praktyce).

BTW starodawne układy DSP pakowały np. 30 ms w czasie do 15 ms (jeden
DSP pakował na zmianę 2 rozmowy). Obecne scalaki potrafią spakować
dziesiątki/setki rozmów jednocześnie, to jest zysk "do 15 ms" :-)

> Jednak - kablówka i telewizja, rozrzyt czasowy między dwiema drogami
> transmisji, gdy odbieram jakiś przekaz jeden np. przez kablówkę
> analogową, a drugi cyfrową, to niekiedy miewałem ponad 10 sekund, choć
> to się potrafi zmieniać.

Kwestia przekodowania - kablówki przekodowują sygnał przed wpuszczeniem
go w kabel. Samo H.264 z GOP 50 i dwukierunkową kompresją dodaje 2
(enkoder) + 2 (dekoder) sekundy opóźnienia (a także do 2 sekund czekania
na obraz po zmianie kanału TV). Jeśli sygnał wejściowy także używa
dwukierunkowych ramek B, to mamy następne np. 2 sekundy opóźnienia.
Plus buforowanie.

> W UPC tak mam, jak porownywałem, to
> analogowo, dostawałem sygnał mocno później, niż cyfrowo.

Dziwne, normalnie analog powinien być szybciej, przecież nie trzeba
czekać na koniec GOP. Nawet jeśli sygnał cyfrowy nie używa kodowania
2-kierunkowego, to analog nie powinien być później.

> Ale rozmawiać z szefem, gdzie dyskutujemy o projekcie, czy nawet z
> kimś starszym, gdzie istotne jest, czy w rozmowie odpowiem na jakieś
> zdanie teraz, czy za pół sekundy, może już mieć ogromne znaczenie. I
> wierzcie, rodzi to problemy.

Dlatego te protokoły są nieco inne niż w TV. Także stosuje się H.264
(w przyszłości pewnie H.265), ale w ustawieniach bardziej "low latency".
W praktyce można zejść poniżej 200 ms (całkowitego opóźnienia obraz -
obraz) z transmisją video.
Dla dźwięku to byłoby dość długo (mikrofony i kamery nie wprowadzają
opóźnień takich jak kamery i monitory), ale w kiepskim VoIPie używanym
przez POTS i/lub GSM wcale by mnie nie zdziwiło.

> No właśnie - kodek musi chyba jednak dostać całą paczkę danych, by
> mógł ją przetworzyć. A tu znów granica, że 10 kB danych wypowiedzi
> online Wujka Zenka nie powstanie w żaden sposób szybciej.

Tak. Tyle że to, na szczęście, są dużo mniejsze paczki danych.
Tak czy owak, opóźnienia powstają głównie przez buforowanie, związane
z (ewentualnymi, przewidywanymi, możliwymi itd) opóźnieniami w wartwie IP.

> Protokoły, sprzęt, krasnoludki, złe moce, itd, cokolwiek, każde ucina
> coś dla siebie. Nawet na analogowej krotnicy dostajemy opóźnienie
> związane z przetwarzaniem, ale tu może się o pół fonemu opóźni przy
> dużej ilości krotnic, prawie do pominięcia.

Tam są "opóźnienia" liczone w mikrosekundach, nie ms.
--
Krzysztof Hałasa