Użytkownik "Krzysztof Halasa" <k...@p...waw.pl> napisał w wiadomości
news:m31si32x41.fsf@pm.waw.pl...
> "HF5BS" <h...@...pl> writes:
>
>>> To nawet dzis VoIP dluzej zestawia :-)
>>
>> Ale to z czego innego wynika, silny kodek musi mieć czas na
>> zakodowanie paczki, to już nie ma online.
>
> No bez przesady. Po pierwsze, mamy zestawienie połączenia (które w SIPie
> może trwać milisekundę, ale ogólnie rzecz biorąc, zwłaszcza jeśli to np.
> PSTN <> VoIP <> PSTN itp, trwa to długo).

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ę.

> Po drugie, obie strony muszą buforować dane przez przynajmniej
> kilkadziesiąt ms (realnie), żeby nie dopuścić do underrunów.
> Alternatywnie, dopuszczają do underrunów, i tym sposobem opóźnienie
> wydłuża się tylko tyle, ile trzeba, ale nie jest to typowe.
> Po trzecie, kodek (enkoder) najpierw musi zebrać dane z określonego
> czasu, bo pakowanie następuje na pakiecie, nie na pojedynczej próbce.

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ć.

> Dłuższy pakiet wejściowy = bardziej efektywne pakowanie / przesyłanie.
> Kilkadziesiąt ms. Obecnie czas samego kodowania jest dużo mniejszy od
> czasu trwania pakietu, np. dlatego, że enkoder koduje wiele kanałów
> w przeplocie. "Siła kodeków" voice w tej chwili nie jest w tym

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...?
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... To tak w przerysowaniu, prawda, jestem z tych
staroświeckich i po staremu myślę, nie zastrzegam sobie wyłączności racji,
jednak jeśli paczka danych, owe 3.8 sekund, to raczej nie poleci już w 1.9
sekundzie, bo albo musiało by być wróżką, czarodziejem, albo w treści
zawierać zbędną ciszę.

> kontekście istotna, ma to wpływ na strumień, ale nie na czas samego
> kodowania.

Jasne, wierzę, że w dzisiejszych czasach, przy dzisiejszych mocach
przetwarzania, czas ten zaczyna być pomijalnie mały. Ale i tak, z pustego i
Salomon nie naleje. Może, w waruknach wysokiej przewidywalności co do
zawartości w jakimś momencie, moglibyśmy sobie pozwolić na wróżkowanie, co w
danych poleci, ale co, gdy np. spodziewano się szczekania psa i tak
zakodowano, nagle okaże się miauczenie kota... no i kicha, pudło... no i
stracony bezpowrotnie czas. Coś moze jak sterownik SMARTDRV, tyle, że tu
można było sobie na takie "stratowanie" pozwolić, bo i tak działo się to
daleko szybciej, niż potrzebowaliśmy, co się nie trafi, to i tak system
sobie wciągnie w następnym odczycie dysku, co może wydłuży o 5 ms odczyt,
ale i tak, zanim to z bufora zleci, to zostanie wciągnięte z nowego miejsca
i uzupełni dziurę, a my nie zauważymy. A w danych online, to już bym się tak
chętnie nie porywał na przewidywanie zawartości.
Hmm... no, łatwiej było by mi powiedzieć o co mi chodzi, gdybym pojawił się
na spotkaniu grupowym, z kartką papieru i ołówkiem... i rozrysował, co mam
na myśli.

>
>> Rozrzut czasowy przy silnych
>> kodekach potrafi przekraczać sekundę, co rodzi oczywiście niekiedy
>> niezbyt śmieszne sytuacje, gdy na coś trzeba natychmiast zareagować.
>
> Nieprawdopodobne.

W skrajnym przypadku gdzieś trafiłem na ok. półtorej sekundy, choć
oczywiście, muszę uwzględnić wszystkie miejsca, gdzie mogło dojść do
opóźnienia.
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ć. W UPC tak mam, jak porownywałem, to analogowo, dostawałem sygnał
mocno później, niż cyfrowo. Z telewizorni sygnał wychodzi w jednym momencie,
to i gdzieś po drodze nabywa opóźnień. Ale tu możemy sobie pozwolić na
kombinowanie, gdyż różnica w czasie, gdy po raz któryś Kevin na świeta w 2
telewizorach z różnych źródeł, pojawi się z przesunięciem 5 sekund, to nie
jest taka istotna. 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.

> Natomiast jitter związany z różnymi czasami przesyłania może czasem być
> tego rzędu. Opóźnienie ogólne (round trip time) - może takie czasem być.
>
>> Narzuty na przemiany w nośnej, czy w starych TCK były na tyle
>> niewielkie, że prawie było online.
>
> Praktycznie było online, bo tam nie było pakietyzacji. Dokładnie tak
> samo, jak radio FM albo inne AM jest "online" (m.cz. w stosunku do
> w.cz.). No chyba że weźmiemy software-defined radio, wtedy nie.

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.

>
>> Jednak przejście przez 7 warstw
>> połączenia trochę zajmuje...
>
> 7 warstw ISO/OSI? :-)

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.

>
>> Rewelą by było, aby treść docierała w
>> tyle, ile jest ping na serwerach (na niedalekich trasach często widuję
>> poniżej 20 ms), ale jeszcze ramkowanie, routing...
>
> Ping dokładnie tak samo podlega ramkowaniu i routingowi.
> Ale nie interesuje nas jitter, nie musimy niczego buforować, i nie
> musimy zbierać próbek w pakiety (zawartość pakietu ICMP budowana jest
> "natychmiast").

Ze wszystkimi tego konsekwencjami, jakie umiem i jakich nie umiem sobie
wyobrazić. Nawet w takim silniku spalinowym wyprzedzamy zapłon przez ZZ
tłoka, aby się mieszanka rozpaliła dokładnie w tym momencie, jakiego żądamy.
Inaczej efektywność, jakość pracy spada, a nawet tłok może dostać kopa i
obrócić wał w przeciwną stronę (realne zwłaszcza w dwusuwach, których nie
ogranicza kierunek obrotów, im jest wsio rympał).
Jak już wspominałem, na spotkaniu z kartką i ołówkiem lepiej objaśnię, gdzie
moje myśli wokół tego krążą.

--
Pies może złamać serce tylko raz,
kiedy jego własne przestaje bić...