Autor: RoMan Mandziejewicz (RoMan.Mandziejewicz_at_f88.n484.z2.fidonet.org)
Data: Sun 04 May 1997 - 11:14:54 MET DST
Romuald Zylla wrote:
>> RZ> wielu mozliwych sytuacji. Nie uwzgledniala tez kompresji
>> RZ> i korekcji. Kompresja zwiekszy przepustowose lacza
>> RZ> a korekcja ja zmniejszy.
>> Korekcja _zwieksza_ przepustowosc o jakies 16%, dzieki przejsciu transmisji
>> DCE-DCE w tryb synchroniczny, czyli pozbyciu sie bitow startu i stopu.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
RZ> Jesli przez korekcje rozumiemy odtwarzanie przeklamanych bitow
RZ> na podstwaie reszty z tych bitow to zgodnie z zasadami informatyki
RZ> klasycznej przy transmisji z korekcja musi sie wysylac _wiecej_
RZ> bitow danych zeby bylo z czego odtwarzac bity zagubione.
Wlaczenie korekcji == przejsciu w tryb synchroniczny, co dawaloby wzrost
wydajnosci o 25%, gdyby nie nadmiarowosc zwiazana z sumami kontrolnymi itp. Poza
tym - korekcja V42 czy MNP4 nie bawi sie w korygowanie poszczegolnych bitow,
tylko zada ponownego przeslania _blokow_ danych (REJ/SREJ).
Dla czystej linii w ostatecznym efekcie masz wzrost wydajnosci wlasnie o ok.
16%:
14400 bps -> 1670 cps
16800 bps -> 1950 cps
28800 bps -> 3350 cps
33600 bps -> 3900 cps
Wyniki w cps dotycza oczywiscie plikow nie dajacych sie juz kompresowac. Na
plikach nieskompresowanych wyniki beda o wiele lepsze, jesli bedzie wlaczona
kompresja V42b/MNP5.
RZ> Wiec twoje obliczenie jest tylko czesciowo sluszne - ile dokladnie
RZ> to mi sie teraz nie chce liczyc :-)
Sa dosc dokladne i wynikaja z dlugoletniej praktyki.
RZ> Moze to byc w zasadzie dowolna liczba z zakresu -10% do +10% :-)
Ot, wymyslil - odrozniaz choc tryb synchroniczny od asynchronicznego?
-- RoMan (2:484/88_at_fidonet.org) mailto:roman_at_silesia.pik-net.pl
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 16:04:56 MET DST