No jasne, to me nenapadlo! Jsem to ale blb. On to zapakuje jeste pred sifrovanim. To bych si nafackoval! Nicmene aspon uz vim, proc to opravdu funguje :-)
takze predevsim data prenasena pres SSH se sifruji, coz je takovym zpusobem rozhazi, ze komprese na nizsi vrstve proste nema sanci, takze komprese modemu nebude mit na ssh zadny podstatny vliv. Zpanuti komprese v SSH je samozrejme pekna vec, a prekresleni obrazovky se opravdu znatelne zrychli, bohuzel z principu neexistuje nic co by odstranilo skoro sekundovou latenci na GPRS a proto takoveto interaktini veci proste budou prse GPRS znacne nepohodlne
No taky jsem pouzival telnet/ssh pres analogovy modem, drive V.34, pozdeji V.90 ktery je sice rychlejsi co se tyce prenosove rychlosti, ale rozdil v interaktivite tj. dobe odezvy jsem nezaznamenal. Analogove modemy maji bezne latenci cca 100-150 ms, coz je priblizne ctvrtina az petina toho co GPRS, takze pres modem sice citite, ze to neni jako by clovek sedel primo u toho, ale da se pres to v pohode pracovat, ale GPRS je proste nouzovka, kdyz se neco posere, tak vam to umozni zjednat napravu, ale pro normalni praci to neni, to je muj dojem z pouzivani ssh pres gprs.
Se začátkem souhlasím. Taky mě to velmi překvapilo. Modem standardně kompresi dělá, mj. je to i vidět v monitoru připojení. Mám Microcom, který při přenášení dat šustí (opravdu dělá tiché šustivé zvuky). Když si pustím Putty (SSH klient) na SSH2 protokolu s kompresí a bez komprese, např. překreslení obrazovky Midnight Commanderu je znatelné jednak v kratší době šustění, ale i vizuelně, ta obrazovka je zkrátka hotová dřív. Nemám to samozřejmě nijak změřené, jen jsem si jednou ze zvědavosti (právě proto, že až dosud jsem věřil tomu, co píšete v prvních dvou větách) zapnul a od té doby to mám zapnuté pořád.
Když už jsme odbočili od GPRS, vrátím se a dodám, že přes GPRS se data defaultně nekomprimují (pokud nemáte speciální udělátko), takže tam by to IMHO mělo pomoci dost, když nad tím tak přemýšlím.
Pokud si jiz neco pohraje s entropii a udela dobrou kompresi dat, pak dalsi komprese nemuze pomoci. To je myslim teoreticky fakt. Opravdu na tom modemu pouzivate kompresovany SSH kanal a pri nasledne SW/HW kompresi linky to jede jeste lepe? Pak by me zajimalo cim to je. Neni tu nejaky odbornik na tuto problematiku? Diky.
DD,
pozoruji taktez odezvy tak zhruba pod vterinu. na ssh to je dostacujici. Osobne jsem vytrenovany z 33kbit/sec analogove linky od CTc. Vrele na jakoukoliv dulezitou praci doporucuji screen. Kdyz vam GPRS vyhnije tak se screen automaticky detachne a po novem prihlaseni jde pokracovat v praci jako by se nic nestalo pouhym attachnutim screenu.
Pokud kolegove z ET hodlaji zavest kompresi ktera implicitne povede k optickemu zrychleni, tak se veci hybou dobrym smerem.
ja data-nonstop pouzivam v podstate misto pevne linky, bezne mivam otevreno nekolik vzdalenych ssh relacich, na kterych pracuji (editace souboru, vypisy db ...). jako editor pouzivam vim s nastavenim :set mouse=a (tudiz klikaci) a pracovat se da. mohlo by to byt sice lepsi ale jde to :)
Aha, promin, mea culpa. Povazuju ed a vi(m) za dve strany teze mince. V nejmenovanem OS to dokonce byla jedna binarka, jenom jednou byla spoustena v celoobrazovkovem a jednou v radkovem rezimu (ono je to logicke, chovalo se to stejne).
Kdyz uz mam na OS "vim", tak to uz tam mohu mit i cokoliv jineho a "vim" tedy neni ta prava spasa. Problem je, kdyz tam mas jen "ed" (protoze neni k dispozici celoobrazovkovy terminal). Take pokud bych mel jmenovat viteze v kategorii "nezastupitelny editor", pak by to byl on.
Je tomu tak, latence je celkem vysoka a dost kolisa, pouzivam SSH a jde to, ale dre to a to dost, kdyz jke potreba udelat nejaky zasah na serveru, tak se to da realizovat, ale na rutinni praci je to utrpeni.
Myslim, ze vetsina lidi ma problem editovat soubory tim zpusobem, ze odpocitava na monitoru pozice znaku :-) Na pozici deset jsem bez potizi schopen skocit, ale treba 64 pozici uz bych mel (nikoliv aritmeticky) problem odpocitat.
Spise jsem mel na mysli, ze diky promyslenemu systemu horkych klaves se tam da obejit bez mackani kurzorovych sipek 10x apod. Ma funkce pro presun na zadane pismeno v radce, apod.
Latence jsou pomerne velke (500-700ms pro male pakety na nevytizene lince), ale to, jestli se na tom pracuje dobre nebo spatne je do jiste miry otazka stylu prace. U psani prikazu na prikazove radce to IMHO celkem nevadi - tam snad preci nekoukate co se pise a se psanim nasledujiciho pismenka necekate na to, az se predchozi zobrazi. Jista komplikace je to pri pouzivani (napriklad) celoobrazovkovych editoru, kde "najeti" do predem vybraneho mista vyzaduje skutecne urcity cvik a neni to tak pohodlne, jak by mohlo byt ...
Dost spatne je relativni pojem. Proste pocitejte s tim, ze po zmacknuti klavesy je cca 0,5 - 1 sec prodleva, nez se znak objevi na konzoli. Psat se tak da, pokud nedelate chyby moc casto - horsi to je, kdyz potrebuje clovek neco umazat - porad mi chybi odhad, jak dlouho ten backspace drzet :-).
Ja se obcas pripojuji z Palmu pres Oskarovo GPRS v totalni vidli, kde mam 1-2 carky. Neni to zadna slava, obcas se mi spojeni rozpadne, ale pouzit se to da (napr. se jsem takto uspesne pridavat a menil zaznamy v SQL databazi apod.).
Netusim vsak, nakolik to bylo opravdu dementnim signalem a nakolik pouzitim GPRS.
Mam dotaz - jak je to na tom GPRS pripojeni s latencemi - co vim, tak jsou pomerne velike a interaktivni provoz (telnet, ssh) se pres to provozuje dost spatne. Je to pravda?
ČLÁNKY DO MAILU