Vykom modemu v obou smerech Was: Re: Kapacita pevne linky

[Zdenek Hladik]

> On Sat, 8 Nov 1997, Zdenek Hladik wrote:
>
> > > Nekdy to muze byt jeste horsi. Mate predpokladam pevnou synchronni linku
> > > 128 kbps a bez jakekoliv komprese dat na ni. Jenze klasicky modem 28.800
> > > umi bezne komprimovat data 1:2 (+/-) podle prenasenych dat. Takze pokud je
> > > pripojen k PC rychlosti 115200 bps tak muze vytvorit tok dat o vyssi
> > > rychlosti nez je udavana rychlost spojeni (28.800). Ten zvyseny tok dat je
> > > ale mozny vzdy jen jednim smerem. Pokud 5 takovych modemu bude stahovat
> > > soubory pres linku 128 kbps, tak uz to bude zrejme znat, oproti napriklad
> > > trem.
>
> > Nechapu proc jen jednim smerem? ISP ma obvykle take modem zamcen na 115200,
> > takze bohuzel ci bohudik, zvysem zatizeni je mozne obema smery.
>
> Pokud je mi znamo tak modemy na tech nejvyssich rychlostech funguji tak ze
> prenost jednim smerem snizi a diky tomu mohou vyuzit vyssi rychlost pri
> prenosu druhym smerem. Snizi si mnozstvi informace (signalu) ktery musi
> 'odfiltrovavat' aby ziskaly signal protistrany a naopak. Tim je dosazeno

Pokud je znamo me , mylite se!

Doufam ze mi prominete Off-topic a delku prispevku, ale snad se mi podari
vyvratit predchozi velmi rozsiremou spatnou predstavu o tom jak dnesni
modemy funguji.

Na ceste k maximalni prenosove rychlosti se pouzivalo ruznych, velmi
chytrych fint. Jednou z prekazek byla prilis velka cena, pozdeji prilis
maly vykon signalovych procesoru pro modemy. Proto byly vyvinuty
nesymetricke protokoly: USR HST, Telebit PEP koneckoncu i velmi stary V.23
(1200/75bps). Aby mohly jet oba kanaly proti sobe, lze pouzit dve reseni:

1. ruzne kmitocty (to pouzivaji vpodstate vsechny nesymetr. protokoly). Pak
ale musi mit jeden kanal dost uzke pasmo protoze druhy se snazi o mit
maximalni. HST a PEP tenhle handicap resi tim ze si umi kanaly prohazovat
HST rychle PEP vemi pomalu. V pasmu telefonni linky je velmi "tesno".

2. Stejny kmitocet a vyuziti dukladne kompenzace vlastniho echa. Kazdy modem
slysi bohuzel i svuj vlastni signal. Je to komplikovano tim ze jeho signal
se odrazi na nekolika ruznych rozhranich s ruznym zpozdenim a fazovym
zkreselenim. Teprve od urcite doby bylo mozne, stejne jako dalsi "dabelske"
finty,  toto stihat dostatecne vykonnym signalovym procesorem.

Dnesnim modemum je koneckoncu uplne jedno a nijakym zpusobem nerozlisuji zda
dratem tecou uzitecna data, nebo prazdy scramble obsahujici pouze
monitorovaci pakety. Kmitoctove vytizeni je  stale stejne!! Proto opravdu
NEMUZE zahajeni prenosu uzitecnych dat ovlivnit prenos druhym smerem.
Zduraznuji ze se to tyka POUZE signalove cesty modemu!

Otazkou je jak jsou na tom dnesni levne noname modemy s vykonem signalovych
i komprimacnich procesoru. Pri malem vykonu procesoru lze predpokladat prave
vami zjisteny  nize uvedeny efekt zpomaleni prenosu obema smery.

> tech vyssich prenosovych rychlosti. Pred chvili jsem si udelal nasledujici
> test :
>
> Soubor 115kByte - prenost z meho pocitace pres modem na server - 40 sec.
>                   prenost ze serveru na muj pocitac            - 45 sec.
>
>       soucasne prenost toho souboru z meho pocitace na server
>       a prenost ze serveru na muj pocitac (dve okna)      - 80 a 85 sec.
>
> Modemy byly spojeny na 24.000 bps.
>
> Co tomu rikate ??
>

Viz vyse, ale navic:

U vaseho pokusu je prilis mnoho prvku ve hre: Multitask, systemy na obou
stranach (predpokladam ze nejedete z DOSu), implementace TCP/IP na obou
stranach, kvalita a vykon procesoru modemu i  vykon a zatizeni procesoru
obou pocitacu.

BTW: TCP/IP implementace Microsoftu je povazavana za velmi spatnou prave z
hlediska vykonu a jeho regulace. TCP protokol ma v sobe vestavenou
regulacni smycku, ktera ma za ukol zabranovat ucpani kriticky zatizenych
uzlu. Pokud dojde k ucpani trasy, TCP prudce zpomali opakovani pokusu, aby
umoznilo zotaveni uzlu a pomalu zatez opet zvysuje do hodnoty blizke
saturaci. Microsoft pry ma parametry teto smycky nastaveny prilis
"agresivne" coz mu dava vyhodu lepsiho vykonu na dobre pruchodne trase, ale
ve svem dusledku (je-li hodne uzivatelu s MS TCP/IP) zpusobuje castejsi
zahlceni uzlu Internetu.

Zajimalo by mne, zda nekdo nema ukazovatka na konkretnejsi informace o tomto
problemu. Dle me osobni zkusenosti pokud otevru v NS Navigatoru download z
blizkeho serveru. W95 mi nedovoli otevrit druhe spojeni- padne to na
timeout. To by slusna TCP/IP implementace nemela udelat!!!

Asi lze vcelku snadno realizovat pokus ktery da vysledky blizsi ocekavanym
hodnotam: Vemte dve silna PC pentium pod DOSem , dva dobre modemy s
vykonnymi strevy (napr USR courier), slusnou linku a zkuste pokus z
terminalu se Zmodemem. Pokud to lze nastavte u Zmodemu siri okna na maximum.

>
> > Empiricky pomer uzivatele/kapacita linky bude ovsem (nastesti pro ISP)
> > asi uplne jiny:
> >
> > 1. Pro dnes nejcasteji pouzivanou apikaci: WWW je vetsina prenasenych dat
> > komprimovana! Jak JPG tak GIF se temer nedaji dale stlacit. HTML kod je
> > objemove asi zanedbatelny. Vetsina souboru stahovanych z FTP serveru je take
> > komprimovana.
>
> To je pravda - uvedomte si ale ze okolo prenosu techto komprimovanych dat
> je spousta komprimovatelneho balastu v hlavickach packetu, velikost html
> kodu bych take nepodcenoval. Versina zprav v e-mailu je dobre
> komprimovatelna

Ano ale kolik prumernych E-mail zprav = 1 prumerne tucny obrazek na prumerne
WWW strance? Hlavicka paketu se obvykle komprimuje uz Van Jacobsonovym
algoritmem a u bezne pouzivane delky paketu 1500B netvori zas tak velke
procento.

>
> > 2. Prenos je velmi casto brzden  dale na trase. Pokud uvazuji ze mam
>
> Samozrejme uvazuji prenos bez zpozdeni zpusobenymi pomalymi linkami na
> trase.
> |                          Petr Simek   APS JU                           |
> |                             petrsi at jcu.cz                              |

                                               Zdenek Hladik
                                            I N F I M A - W A N
                           /""""""\      Internet,LAN,WAN consulting
                         ( (o)  (o) )     Zazvorkova 2008 Praha 5, Czech
                             (..)           tel/fax +4202-6512836
                             ----       Internet: hladikz at infima.cz
                            \____/  --,      BBS 3122741(30 lines)
                                     / ,  ,     BBS.INFIMA.CZ
                                    `--+--|    FTP,WWW,TELNET
                                       '  '    FIDO: 2:420/59