🚀 go-pugleaf

Date: Sun, 28 Jan 2007 10:38:17 +0100
From: Stanislaw Chmielarz
> Witam!
> Jest aplikacja na serwerze Unix'owym skladajaca sie z bazy danych
> i executables dzialajacych poprzez sesje Telnet.
> Poniewaz aplikacja jest tak skonstruowana, ze kazdy znak jest
> przesylany na serwer wystepuje spore marnotrawstwo pasma
> sieciowego. Czy oprocz kompletnej przebudowy aplikacji jest jakis
> sposob aby oszczedzic pasmo zajmowane przez stacje klienckie
> pracujace Telnetem?

ssh -C

Pozdrawiam,
R.

-- 
Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski
Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"

Dominik 'Rathann' Mierzejewski wrote:

>> przesylany na serwer wystepuje spore marnotrawstwo pasma
>> sieciowego. Czy oprocz kompletnej przebudowy aplikacji jest
>> jakis sposob aby oszczedzic pasmo zajmowane przez stacje
>> klienckie pracujace Telnetem?
> 
> ssh -C

Czy ten sposob nie powoduje, ze do kazdego znaku dolaczane sa
smiecie zeby wypelnic minimalna pojemnosc datagramu?
Chodzilo mi raczej o jakas forme cache'owania - kompresji kilku
znakow w jeden datagram.

-- 
Pozdrowienia!!StaCH
Sieci,systemy,serwis PC,alarmy,kamery,domofony,sterowniki PLC.
http://www.uniprojekt.com  mobile:wap.uniprojekt.com

Stanislaw Chmielarz napisał(a):
> Chodzilo mi raczej o jakas forme cache'owania - kompresji kilku
> znakow w jeden datagram.

Ale to już jest robione na poziomie stosu IP. Dane są buforowane i jeśli 
  w określonym czasie nie nazbiera się tego więcej to pakiet jest 
wysyłany, to tak w ogólności. W przypadku wysyłania pakietów z kodami 
naciśniętych klawiszy to nie wyobrażam sobie innej funkcjonalności jak 
wysyłanie jednego kodu klawisza/pakiet, w przeciwnym razie otrzymałbyś 
mocno nieinteraktywny system. W odwrotną stronę kiedy przerysowywane są 
całe okienka czy ramki to w takim wypadku dane pakowane są w większe 
pakiety. Przed chwilą sprawdziłem i doświadczenie zdaje sie potwierdzać 
moje dywagacje: naciśnięcie klawisza to pakiet o wielkości 
kilkudziesięciu bajtów, przerysowana ramka to już kilkaset do 1500 
bajtów a nawet i więcej.

pozdr

Radek

Radoslaw Korzeniewski wrote:

> to w takim wypadku dane pakowane są w większe pakiety. Przed
> chwilą sprawdziłem i doświadczenie zdaje sie potwierdzać moje
> dywagacje: naciśnięcie klawisza to pakiet o wielkości
> kilkudziesięciu bajtów, przerysowana ramka to już kilkaset do
> 1500 bajtów a nawet i więcej.

Napisalem to na podstawie takich samych doswiadczen ale zaczalem
sie zastanawiac czy nie da sie tego obejsc bez przebudowy
aplikacji.


-- 
Pozdrowienia!!StaCH
Sieci,systemy,serwis PC,alarmy,kamery,domofony,sterowniki PLC.
http://www.uniprojekt.com  mobile:wap.uniprojekt.com

Stanislaw Chmielarz <schmielarz@uniprojekt.com.pl> wrote:
>> to w takim wypadku dane pakowane są w większe pakiety. Przed
>> chwilą sprawdziłem i doświadczenie zdaje sie potwierdzać moje
>> dywagacje: naciśnięcie klawisza to pakiet o wielkości
>> kilkudziesięciu bajtów, przerysowana ramka to już kilkaset do
>> 1500 bajtów a nawet i więcej.
> 
> Napisalem to na podstawie takich samych doswiadczen ale zaczalem
> sie zastanawiac czy nie da sie tego obejsc bez przebudowy
> aplikacji.

Moze sprobuj 'na chama' zmienic tryb pracy terminala uzywanego
przez aplikacje?  W sensie, 'stty co-tam-potrzebujesz < /dev/ttypXX',
gdzie w miejsce co-tam-potrzebujesz wstawisz wylaczenie cbreak,
zwiekszenie 'min' czy 'time', czy co tam ci pasuje.

-- 
If you cut off my head, what would I say?  Me and my head, or me and my body?

Stanislaw Chmielarz napisał(a):
> Radoslaw Korzeniewski wrote:
> 
>> to w takim wypadku dane pakowane są w większe pakiety. Przed
>> chwilą sprawdziłem i doświadczenie zdaje sie potwierdzać moje
>> dywagacje: naciśnięcie klawisza to pakiet o wielkości
>> kilkudziesięciu bajtów, przerysowana ramka to już kilkaset do
>> 1500 bajtów a nawet i więcej.
> 
> Napisalem to na podstawie takich samych doswiadczen ale zaczalem
> sie zastanawiac czy nie da sie tego obejsc bez przebudowy
> aplikacji.
> 

Korzystasz z TCP/IP? to jakoś nie za bardzo to widzę. Narzut protokołów 
(enkapsulacja) będzie zawsze znacząco większy niż pojedynczy kod 
klawisza do przesłania.

pozdr

Radek

Ponure Zacietrzewienie wrote:

> Stanislaw Chmielarz <schmielarz@uniprojekt.com.pl> wrote:
>>> to w takim wypadku dane pakowane są w większe pakiety. Przed
>>> chwilą sprawdziłem i doświadczenie zdaje sie potwierdzać moje
>>> dywagacje: naciśnięcie klawisza to pakiet o wielkości
>>> kilkudziesięciu bajtów, przerysowana ramka to już kilkaset do
>>> 1500 bajtów a nawet i więcej.
>> 
>> Napisalem to na podstawie takich samych doswiadczen ale
>> zaczalem sie zastanawiac czy nie da sie tego obejsc bez
>> przebudowy aplikacji.
> 
> Moze sprobuj 'na chama' zmienic tryb pracy terminala uzywanego
> przez aplikacje?  W sensie, 'stty co-tam-potrzebujesz <
> /dev/ttypXX', gdzie w miejsce co-tam-potrzebujesz wstawisz
> wylaczenie cbreak, zwiekszenie 'min' czy 'time', czy co tam ci
> pasuje.

Na podstawie literatury okazuje sie, ze nie moge przestawic trybu
do przesylania linii (po Enter) bo nie da sie w ten sposob
zrealizowac kombinacji klawiszy (zwykly plus funkcyjny).
W zasadzie przy pracy z typowym terminalem (Sherwood ST 7000) malo
mi to przeszkadza bowiem koszt stanowiska pracy jest nizszy niz
jak jest teraz gdzie stoi normalny wypasiony pecet z pelnym
oprogramowanie biurowym i programem terminalowym do pracy w
aplikacji i dobrze byloby wykorzystac jego moce przerobowe.
Czyli w zasadzie nalezaloby "przepisac" aplikacje...


-- 
Pozdrowienia!!StaCH
Sieci,systemy,serwis PC,alarmy,kamery,domofony,sterowniki PLC.
http://www.uniprojekt.com  mobile:wap.uniprojekt.com

Radoslaw Korzeniewski wrote:

> Stanislaw Chmielarz napisał(a):
>> Radoslaw Korzeniewski wrote:
>> 
>>> to w takim wypadku dane pakowane są w większe pakiety. Przed
>>> chwilą sprawdziłem i doświadczenie zdaje sie potwierdzać moje
>>> dywagacje: naciśnięcie klawisza to pakiet o wielkości
>>> kilkudziesięciu bajtów, przerysowana ramka to już kilkaset do
>>> 1500 bajtów a nawet i więcej.
>> 
>> Napisalem to na podstawie takich samych doswiadczen ale
>> zaczalem sie zastanawiac czy nie da sie tego obejsc bez
>> przebudowy aplikacji.
>> 
> 
> Korzystasz z TCP/IP? to jakoś nie za bardzo to widzę. Narzut
> protokołów (enkapsulacja) będzie zawsze znacząco większy niż
> pojedynczy kod klawisza do przesłania.

Czyli marnotrawstwo pasma mozna zakonczyc "przepisujac" aplikacje
w sposob wykorzystujacy moce koncowki klienckiej.

-- 
Pozdrowienia!!StaCH
Sieci,systemy,serwis PC,alarmy,kamery,domofony,sterowniki PLC.
http://www.uniprojekt.com  mobile:wap.uniprojekt.com

Stanislaw Chmielarz <schmielarz@uniprojekt.com.PL> writes:

> Jest aplikacja na serwerze Unix'owym skladajaca sie z bazy danych
> i executables dzialajacych poprzez sesje Telnet.
> Poniewaz aplikacja jest tak skonstruowana, ze kazdy znak jest
> przesylany na serwer wystepuje spore marnotrawstwo pasma
> sieciowego.

A duzo jest tego marnotrawstwa?
-- 
Krzysztof Halasa

On 2007-01-30, Krzysztof Halasa wrote:
>> Jest aplikacja na serwerze Unix'owym skladajaca sie z bazy danych
>> i executables dzialajacych poprzez sesje Telnet.
>> Poniewaz aplikacja jest tak skonstruowana, ze kazdy znak jest
>> przesylany na serwer wystepuje spore marnotrawstwo pasma
>> sieciowego.
> A duzo jest tego marnotrawstwa?
nagłówki Ethernet/FDDI/cokolwiek + nagłówki IP + nagłówki TCP : 1 znak?

-- 
Damian Szuberski

Damian 'legion' Szuberski <legion@wmid.amu.edu.pl.cutthisjunk> writes:

>> A duzo jest tego marnotrawstwa?
> nagłówki Ethernet/FDDI/cokolwiek + nagłówki IP + nagłówki TCP : 1 znak?

Mialem na mysli w bajtach/sekunde, oczywiscie. Albo w % przepustowosci
linkow.
-- 
Krzysztof Halasa

Damian 'legion' Szuberski wrote:

> On 2007-01-30, Krzysztof Halasa wrote:
>>> Jest aplikacja na serwerze Unix'owym skladajaca sie z bazy
>>> danych i executables dzialajacych poprzez sesje Telnet.
>>> Poniewaz aplikacja jest tak skonstruowana, ze kazdy znak jest
>>> przesylany na serwer wystepuje spore marnotrawstwo pasma
>>> sieciowego.
>> A duzo jest tego marnotrawstwa?
> nagłówki Ethernet/FDDI/cokolwiek + nagłówki IP + nagłówki TCP :
> 1 znak?

Zapomniales o dopelnieniu datagramu do wymaganego minimum :-))) Na
oko rzeczywista informacja to pewnie ponizej 10% ruchu. Ale byc
moze, ze problem wolnego odpowiadania aplikacji (odswiezanie
ekranow) lezy gdzies indziej ...

-- 
Pozdrowienia!!StaCH
Sieci,systemy,serwis PC,alarmy,kamery,domofony,sterowniki PLC.
http://www.uniprojekt.com  mobile:wap.uniprojekt.com

Stanislaw Chmielarz <schmielarz@uniprojekt.com.PL> writes:

>>> A duzo jest tego marnotrawstwa?
>> nagłówki Ethernet/FDDI/cokolwiek + nagłówki IP + nagłówki TCP :
>> 1 znak?
>
> Zapomniales o dopelnieniu datagramu do wymaganego minimum :-))) Na
> oko rzeczywista informacja to pewnie ponizej 10% ruchu. Ale byc
> moze, ze problem wolnego odpowiadania aplikacji (odswiezanie
> ekranow) lezy gdzies indziej ...

Tak przypuszczam, stad bylo wlasnie to pytanie (ktore nie doczekalo sie
na razie odpowiedzi) o ilosc tego marnotrawstwa.

Bo jesli mamy segment sieci np. 100 Mb/s i zapuszczamy na takim
segmencie np. 50 sesji terminalowych, to na glowe przypada 2 Mb/s,
i to jest duuuuzo wiecej niz mozna wysycic piszac na klawiaturze,
a nawet duzo wiecej niz normalny program uzywajacy prawidlowo
np. (n)curses potrafi wyslac do terminala.

Ale oczywiscie jesli program po kazdym wyswietlonym znaku robi redraw
calego ekranu, to pewnie dowolne łącze mozna zapchac.

Podobnie, jesli pracujemy na łączach 2400 bps to program powinien
umiec pracowac w trybie bez wyswietlania zbednych rzeczy.
-- 
Krzysztof Halasa

Krzysztof Halasa wrote:

> Stanislaw Chmielarz <schmielarz@uniprojekt.com.PL> writes:
> 
>>>> A duzo jest tego marnotrawstwa?
>>> nagłówki Ethernet/FDDI/cokolwiek + nagłówki IP + nagłówki TCP
>>> : 1 znak?
>>
>> Zapomniales o dopelnieniu datagramu do wymaganego minimum :-)))
>> Na oko rzeczywista informacja to pewnie ponizej 10% ruchu. Ale
>> byc moze, ze problem wolnego odpowiadania aplikacji
>> (odswiezanie ekranow) lezy gdzies indziej ...
> 
> Tak przypuszczam, stad bylo wlasnie to pytanie (ktore nie
> doczekalo sie na razie odpowiedzi) o ilosc tego marnotrawstwa.

Lacze WAN 1Mbit (teoretycznie bo CIR sporo mniejszy) dla okolo 50
pracujacych.
 
> Bo jesli mamy segment sieci np. 100 Mb/s i zapuszczamy na takim
> segmencie np. 50 sesji terminalowych, to na glowe przypada 2
> Mb/s, i to jest duuuuzo wiecej niz mozna wysycic piszac na
> klawiaturze, a nawet duzo wiecej niz normalny program uzywajacy
> prawidlowo np. (n)curses potrafi wyslac do terminala.
> 
> Ale oczywiscie jesli program po kazdym wyswietlonym znaku robi
> redraw calego ekranu, to pewnie dowolne łącze mozna zapchac.

Wlasnie tak jest ale nie po kazdym znaku tylko po kazdym
wypelnionym polu (np.: nazwisko).

> Podobnie, jesli pracujemy na łączach 2400 bps to program
> powinien umiec pracowac w trybie bez wyswietlania zbednych
> rzeczy.

Dlatego mysle, ze najkorzystniej byloby "przepisac" aplikacje ale
na to pewnie firma nie pojdzie.
Aplikacja pomyslana byla do pracy w LAN (tak jak przypuszczales) i
wtedy ten narzut nie przeszkadzal specjalnie choc mnie
draznil :-)) ale ktos madry inaczej zrobil oszczednosc i
zlikwidowal lokalne maszyny Unix'owe i przewalil wszystko na
centralna po WAN i zaczely sie lagi.

-- 
Pozdrowienia!!StaCH
Sieci,systemy,serwis PC,alarmy,kamery,domofony,sterowniki PLC.
http://www.uniprojekt.com  mobile:wap.uniprojekt.com

Stanislaw Chmielarz <schmielarz@uniprojekt.com.pl> wrote:

[..]

>> Podobnie, jesli pracujemy na łączach 2400 bps to program
>> powinien umiec pracowac w trybie bez wyswietlania zbednych
>> rzeczy.
> 
> Dlatego mysle, ze najkorzystniej byloby "przepisac" aplikacje ale
> na to pewnie firma nie pojdzie.
> Aplikacja pomyslana byla do pracy w LAN (tak jak przypuszczales) i
> wtedy ten narzut nie przeszkadzal specjalnie choc mnie
> draznil :-)) ale ktos madry inaczej zrobil oszczednosc i
> zlikwidowal lokalne maszyny Unix'owe i przewalil wszystko na
> centralna po WAN i zaczely sie lagi.

Gdzies (README do Emacsa?) widzialem sugestie, zeby uruchomic taka
aplikacje (Emacsa ;-) pod screenem, ktory potrafi ponoc odrysowywac
ekran w nieco bardziej rozsadny sposob.

-- 
If you cut off my head, what would I say?  Me and my head, or me and my body?

Stanislaw Chmielarz <schmielarz@uniprojekt.com.PL> writes:

> Lacze WAN 1Mbit (teoretycznie bo CIR sporo mniejszy) dla okolo 50
> pracujacych.

To jest jakies PVC miedzy oddzialami firmy czy VPN po publicznym
Internecie?
I rzeczywiscie sie wysyca?
Jesli sie wysyca, to moze po prostu trzeba dodac drugi Mb/s. Moze
wysyca sie w "centrali" i to tam trzeba zwiekszyc rure?

1 Mb/s po IP dla takiego programu x 50 nie powinno byc jakims wielkim
problemem, w koncu konsole 9600 bps dzialaja zupelnie sensownie.

>> Ale oczywiscie jesli program po kazdym wyswietlonym znaku robi
>> redraw calego ekranu, to pewnie dowolne łącze mozna zapchac.
>
> Wlasnie tak jest ale nie po kazdym znaku tylko po kazdym
> wypelnionym polu (np.: nazwisko).

Tak czy owak program nie powinien robic redraw, tylko jakis refresh
(np. ncurses wiedza co jest wyswietlone na ekranie i nie potrzebuja
tego ponownie wyswietlac).
-- 
Krzysztof Halasa

Krzysztof Halasa wrote:

> Stanislaw Chmielarz <schmielarz@uniprojekt.com.PL> writes:
> 
>> Lacze WAN 1Mbit (teoretycznie bo CIR sporo mniejszy) dla okolo
>> 50 pracujacych.
> 
> To jest jakies PVC miedzy oddzialami firmy czy VPN po publicznym
> Internecie?

PVC przez TPSA.

> I rzeczywiscie sie wysyca?
> Jesli sie wysyca, to moze po prostu trzeba dodac drugi Mb/s.
> Moze wysyca sie w "centrali" i to tam trzeba zwiekszyc rure?

Raczej tak bo jest okolo 300 jednostek (nie wszystkie oczywiscie
po 50 userow).

> 1 Mb/s po IP dla takiego programu x 50 nie powinno byc jakims
> wielkim problemem, w koncu konsole 9600 bps dzialaja zupelnie
> sensownie.

Wiem, bo sam puszczalem terminale na laczach 14400bps pod
Multiuser DOS 7 GOLD.


>>> Ale oczywiscie jesli program po kazdym wyswietlonym znaku robi
>>> redraw calego ekranu, to pewnie dowolne łącze mozna zapchac.
>>
>> Wlasnie tak jest ale nie po kazdym znaku tylko po kazdym
>> wypelnionym polu (np.: nazwisko).
> 
> Tak czy owak program nie powinien robic redraw, tylko jakis
> refresh (np. ncurses wiedza co jest wyswietlone na ekranie i nie
> potrzebuja tego ponownie wyswietlac).

Chodzilo mi raczej o wskazanie jak funkcjonuja niektore firmy a
raczej ich dzialy IT, ktore bez zastanowienia sie nad tym jak
dziala aplikacja przenosza serwer z LAN 100Mbit do WAN 1Mbit z
niepelnym gwarantowanym pasmem. W zasadzie poza przepisaniem
aplikacji na WEB niczego sensownego sie nie da zrobic poza
poszerzaniem rur.


-- 
Pozdrowienia!!StaCH
Sieci,systemy,serwis PC,alarmy,kamery,domofony,sterowniki PLC.
http://www.uniprojekt.com  mobile:wap.uniprojekt.com

Stanislaw Chmielarz <schmielarz@uniprojekt.com.pl>:

> > Ale oczywiscie jesli program po kazdym wyswietlonym znaku robi
> > redraw calego ekranu, to pewnie dowolne łącze mozna zapchac.
> 
> Wlasnie tak jest ale nie po kazdym znaku tylko po kazdym
> wypelnionym polu (np.: nazwisko).

Tyle że akurat ta operacja jest tania (w mierze zapotrzebowania
na pasmo), bo przesyłana jest większa porcja danych w jedną
stronę bez przesyłu w drugą - czyli i narzut kolejnych warstw
jest relatywnie mniejszy, i pojawia się możliwość ewentualnego
stosowania kompresji danych. Co z kolei oznacza, że to raczej
nie ona jest źródłem Twoich problemów. Jakoś nie wydaje mi się,
że 50 sesji z interfejsem znakowym zapycha pasmo rzędu 512Kb/s.
Średnio daje to ponad 9600 na jedną sesję, a sam najlepiej wiesz,
że interfejs "bebeesoidalny" przy pracy przez modem jest całkiem
nieźle używalny; oczywiście nie jest to to samo, co praca z tym
samym programem, uruchomionym na lokalnej maszynie, ale...

> Aplikacja pomyslana byla do pracy w LAN (tak jak przypuszczales) i
> wtedy ten narzut nie przeszkadzal specjalnie choc mnie
> draznil :-)) ale ktos madry inaczej zrobil oszczednosc i
> zlikwidowal lokalne maszyny Unix'owe i przewalil wszystko na
> centralna po WAN i zaczely sie lagi.

Mam obawy, że tak łatwo nie zlikwidujesz lagów; TCP/IP nie jest raczej
protokołem zapewniającym równy podział pasma i stabilny czas odpowiedzi.

-- 
	Leszek.

-- lech7@lech.pse.pl                -- REAL programmers use INTEGERS --
-- speaking just for myself...

Stanislaw Chmielarz <schmielarz@uniprojekt.com.PL> writes:

>> I rzeczywiscie sie wysyca?
>> Jesli sie wysyca, to moze po prostu trzeba dodac drugi Mb/s.
>> Moze wysyca sie w "centrali" i to tam trzeba zwiekszyc rure?
>
> Raczej tak bo jest okolo 300 jednostek (nie wszystkie oczywiscie
> po 50 userow).

To moze tam po prostu sie to wysyca, tam tez jest tylko FR np. 2 Mb/s?

Kilkaset sesji terminalowych moze 2 Mbps wysycic. Moze trzeba na ATM
w "centrali" zmienic?

> Chodzilo mi raczej o wskazanie jak funkcjonuja niektore firmy a
> raczej ich dzialy IT, ktore bez zastanowienia sie nad tym jak
> dziala aplikacja przenosza serwer z LAN 100Mbit do WAN 1Mbit z
> niepelnym gwarantowanym pasmem. W zasadzie poza przepisaniem
> aplikacji na WEB niczego sensownego sie nie da zrobic poza
> poszerzaniem rur.

Aplikacje terminalowe to zwykle stara sprawa, powstawaly na dlugo
przed WWW itp. Tak czy owak HTTP tez potrzebuje pasma, moze mniej
ale bez przesady. Za to opoznienia przy HTTP sa duzo mniej widoczne
bo nie sa po kazdym wcisnieciu jakiegos klawisza itp.

Tak czy owak, mysle ze zwykle przeniesienie serwisu do centrali
i ew. poszerzenie pasma to jednak krok w dobrym kierunku, zwlaszcza
jesli nie ma problemow z niezawodnoscia, a tylko z wydajnoscia.
-- 
Krzysztof Halasa

Lech Szychowski <lech7@lech.pse.pl> writes:

> Mam obawy, że tak łatwo nie zlikwidujesz lagów; TCP/IP nie jest raczej
> protokołem zapewniającym równy podział pasma i stabilny czas odpowiedzi.

Ale on to przeciez ma na wydzielonych PVC FR, o ile nie ma tam jakiegos
waskiego gardla w rodzaju 2 Mb/s dla wezla (nie wiem czy sa jeszcze
takie w ogole), to one dzialaja bez takich problemow.
-- 
Krzysztof Halasa

Krzysztof Halasa <khc@pm.waw.pl>:

> > Mam obawy, że tak łatwo nie zlikwidujesz lagów; TCP/IP nie jest raczej
> > protokołem zapewniającym równy podział pasma i stabilny czas odpowiedzi.
> Ale on to przeciez ma na wydzielonych PVC FR, o ile nie ma tam jakiegos
> waskiego gardla w rodzaju 2 Mb/s dla wezla (nie wiem czy sa jeszcze
> takie w ogole), to one dzialaja bez takich problemow.

O ile w całą sprawę nie są zaangażowane jakies inne bliskie
wysycenia elementy sieci, to oczywiście masz rację - PVC
"samo z siebie" nie zrobi żadnego problemu...

-- 
	Leszek.

-- lech7@lech.pse.pl                -- REAL programmers use INTEGERS --
-- speaking just for myself...

Krzysztof Halasa wrote:

> Tak czy owak, mysle ze zwykle przeniesienie serwisu do centrali
> i ew. poszerzenie pasma to jednak krok w dobrym kierunku,
> zwlaszcza jesli nie ma problemow z niezawodnoscia, a tylko z
> wydajnoscia.

Tym bardziej, ze koszt szerszej rury nie da sie porownac z kosztem
przepisania aplikacji. Moze byc rowniez malo wydajny serwer w
centrali a to juz troche kosztuje.

-- 
Pozdrowienia!!StaCH
Sieci,systemy,serwis PC,alarmy,kamery,domofony,sterowniki PLC.
http://www.uniprojekt.com  mobile:wap.uniprojekt.com

Citrix rozwiąze twoje problemy :)

Stanislaw Chmielarz wrote:
> Witam!
> Jest aplikacja na serwerze Unix'owym skladajaca sie z bazy danych
> i executables dzialajacych poprzez sesje Telnet.
> Poniewaz aplikacja jest tak skonstruowana, ze kazdy znak jest
> przesylany na serwer wystepuje spore marnotrawstwo pasma
> sieciowego. Czy oprocz kompletnej przebudowy aplikacji jest jakis
> sposob aby oszczedzic pasmo zajmowane przez stacje klienckie
> pracujace Telnetem?
> Jak przebudowc zeby bylo lepiej to wiem.
> 
Można spróbować wykorzystać tryb liniowy telneta jeżeli aplikacja
sobie z tym poradzi.

hint:
^]
mode line

Mariusz Wołoszyn wrote:

> Stanislaw Chmielarz wrote:
>> Witam!
>> Jest aplikacja na serwerze Unix'owym skladajaca sie z bazy
>> danych i executables dzialajacych poprzez sesje Telnet.
>> Poniewaz aplikacja jest tak skonstruowana, ze kazdy znak jest
>> przesylany na serwer wystepuje spore marnotrawstwo pasma
>> sieciowego. Czy oprocz kompletnej przebudowy aplikacji jest
>> jakis sposob aby oszczedzic pasmo zajmowane przez stacje
>> klienckie pracujace Telnetem?
>> Jak przebudowc zeby bylo lepiej to wiem.
>> 
> Można spróbować wykorzystać tryb liniowy telneta jeżeli
> aplikacja sobie z tym poradzi.

Nie poradzi sobie bo uzywa znakow sterujacych.
Gdzies to w man'ie wyczytalem.

-- 
Pozdrowienia!!StaCH
Sieci,systemy,serwis PC,alarmy,kamery,domofony,sterowniki PLC.
http://www.uniprojekt.com  mobile:wap.uniprojekt.com

>> przesylany na serwer wystepuje spore marnotrawstwo pasma
>> sieciowego. Czy oprocz kompletnej przebudowy aplikacji jest jakis
>> sposob aby oszczedzic pasmo zajmowane przez stacje klienckie
>> pracujace Telnetem?
>> Jak przebudowc zeby bylo lepiej to wiem.
>> 
> Można spróbować wykorzystać tryb liniowy telneta jeżeli aplikacja
> sobie z tym poradzi.
>
telnet i tak generuje mały ruch. co Pan ma za łącze. jeśli po modemie to 
kwestia wrzucenia kompresji poprawi kilka razy

Wojciech Puchar wrote:

>>> przesylany na serwer wystepuje spore marnotrawstwo pasma
>>> sieciowego. Czy oprocz kompletnej przebudowy aplikacji jest
>>> jakis sposob aby oszczedzic pasmo zajmowane przez stacje
>>> klienckie pracujace Telnetem?
>>> Jak przebudowc zeby bylo lepiej to wiem.
>>> 
>> Można spróbować wykorzystać tryb liniowy telneta jeżeli
>> aplikacja sobie z tym poradzi.
>>
> telnet i tak generuje mały ruch. co Pan ma za łącze. jeśli po
> modemie to kwestia wrzucenia kompresji poprawi kilka razy

Kazde nacisniecie klawisza generuje pakiet i odpowiedz.

-- 
Pozdrowienia!!StaCH
Sieci,systemy,serwis PC,alarmy,kamery,domofony,sterowniki PLC.
http://www.uniprojekt.com  mobile:http://wap.uniprojekt.com

Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl> napisał(a):
>   This message is in MIME format.  The first part should be readable text,
>   while the remaining parts are likely unreadable without MIME-aware tools.
>
> --0-1500536997-1181375348=:1467
> Content-Type: TEXT/PLAIN; charset=iso-8859-2; format=flowed
> Content-Transfer-Encoding: 8BIT
>
>>> przesylany na serwer wystepuje spore marnotrawstwo pasma
>>> sieciowego. Czy oprocz kompletnej przebudowy aplikacji jest jakis
>>> sposob aby oszczedzic pasmo zajmowane przez stacje klienckie
>>> pracujace Telnetem?
>>> Jak przebudowc zeby bylo lepiej to wiem.
>>> 
>> Można spróbować wykorzystać tryb liniowy telneta jeżeli aplikacja
>> sobie z tym poradzi.
>>
> telnet i tak generuje mały ruch. co Pan ma za łącze. jeśli po modemie to 
> kwestia wrzucenia kompresji poprawi kilka razy
> --0-1500536997-1181375348=:1467--

Zależy od aplikacji.
W przypadku krytycznym, każde naciśnięcie klawisza powoduje przerysowanie
całego ekranu (ok 2 kB danych). Szybko klikając możesz wybenerować ze 128kbps.
Kompresja na pewno pomoże, bo takie dane to nawet prymitywny algorytm ściśnie
kilkukrotnie.
BTW, jeśli to nie modem, to może warto zastąpić telneta przez ssh (ma wbudowaną
kompresję w protokuł).

-- 
WARNING: my e-mail is encrypted by ROT13
Xbaenq Fgrcvra <xbaenq@vagreqngn.arg.cy>

Stanislaw Chmielarz <schmielarz@uniprojekt.com.PL> napisał(a):
> Wojciech Puchar wrote:
>
>>>> przesylany na serwer wystepuje spore marnotrawstwo pasma
>>>> sieciowego. Czy oprocz kompletnej przebudowy aplikacji jest
>>>> jakis sposob aby oszczedzic pasmo zajmowane przez stacje
>>>> klienckie pracujace Telnetem?
>>>> Jak przebudowc zeby bylo lepiej to wiem.
>>>> 
>>> Można spróbować wykorzystać tryb liniowy telneta jeżeli
>>> aplikacja sobie z tym poradzi.
>>>
>> telnet i tak generuje mały ruch. co Pan ma za łącze. jeśli po
>> modemie to kwestia wrzucenia kompresji poprawi kilka razy
>
> Kazde nacisniecie klawisza generuje pakiet i odpowiedz.
>
Nieprawda. Zależy od trybu pracy telnet-a, a w najgorszym przypadku
zawsze działa elgorytm Nagla.

-- 
WARNING: my e-mail is encrypted by ROT13
Xbaenq Fgrcvra <xbaenq@vagreqngn.arg.cy>

Konrad Stepien wrote:

> Stanislaw Chmielarz <schmielarz@uniprojekt.com.PL> napisał(a):
>> Wojciech Puchar wrote:
>>
>>>>> przesylany na serwer wystepuje spore marnotrawstwo pasma
>>>>> sieciowego. Czy oprocz kompletnej przebudowy aplikacji jest
>>>>> jakis sposob aby oszczedzic pasmo zajmowane przez stacje
>>>>> klienckie pracujace Telnetem?
>>>>> Jak przebudowc zeby bylo lepiej to wiem.
>>>>> 
>>>> Można spróbować wykorzystać tryb liniowy telneta jeżeli
>>>> aplikacja sobie z tym poradzi.
>>>>
>>> telnet i tak generuje mały ruch. co Pan ma za łącze. jeśli po
>>> modemie to kwestia wrzucenia kompresji poprawi kilka razy
>>
>> Kazde nacisniecie klawisza generuje pakiet i odpowiedz.
>>
> Nieprawda. Zależy od trybu pracy telnet-a, a w najgorszym
> przypadku zawsze działa elgorytm Nagla.
 
W tym konkretnym przypadku prawda.

-- 
Pozdrowienia!!StaCH
Sieci,systemy,serwis PC,alarmy,kamery,domofony,sterowniki PLC.
http://www.uniprojekt.com  mobile:http://wap.uniprojekt.com

Stanislaw Chmielarz <schmielarz@uniprojekt.com.PL> napisał(a):
> Konrad Stepien wrote:
>
>> Stanislaw Chmielarz <schmielarz@uniprojekt.com.PL> napisał(a):
>>> Wojciech Puchar wrote:
>>>
>>>>>> przesylany na serwer wystepuje spore marnotrawstwo pasma
>>>>>> sieciowego. Czy oprocz kompletnej przebudowy aplikacji jest
>>>>>> jakis sposob aby oszczedzic pasmo zajmowane przez stacje
>>>>>> klienckie pracujace Telnetem?
>>>>>> Jak przebudowc zeby bylo lepiej to wiem.
>>>>>> 
>>>>> Można spróbować wykorzystać tryb liniowy telneta jeżeli
>>>>> aplikacja sobie z tym poradzi.
>>>>>
>>>> telnet i tak generuje mały ruch. co Pan ma za łącze. jeśli po
>>>> modemie to kwestia wrzucenia kompresji poprawi kilka razy
>>>
>>> Kazde nacisniecie klawisza generuje pakiet i odpowiedz.
>>>
>> Nieprawda. Zależy od trybu pracy telnet-a, a w najgorszym
>> przypadku zawsze działa elgorytm Nagla.
>  
> W tym konkretnym przypadku prawda.
>

Znaczy, chcesz powiedzieć, że w tym przypadku algorytm Nagla
nie działa? Możesz coś więcej?

-- 
WARNING: my e-mail is encrypted by ROT13
Xbaenq Fgrcvra <xbaenq@vagreqngn.arg.cy>

Konrad Stepien wrote:

> Stanislaw Chmielarz <schmielarz@uniprojekt.com.PL> napisał(a):
>> Konrad Stepien wrote:

>>>> Kazde nacisniecie klawisza generuje pakiet i odpowiedz.
>>>>
>>> Nieprawda. Zależy od trybu pracy telnet-a, a w najgorszym
>>> przypadku zawsze działa elgorytm Nagla.
>>  
>> W tym konkretnym przypadku prawda.
>>
> 
> Znaczy, chcesz powiedzieć, że w tym przypadku algorytm Nagla
> nie działa? Możesz coś więcej?

Wiecej juz bylo i nie bede sie powtarzal.

-- 
Pozdrowienia!!StaCH
Sieci,systemy,serwis PC,alarmy,kamery,domofony,sterowniki PLC.
http://www.uniprojekt.com  mobile:http://wap.uniprojekt.com

Stanislaw Chmielarz <schmielarz@uniprojekt.com.PL> napisał(a):
> Konrad Stepien wrote:
>
>> Stanislaw Chmielarz <schmielarz@uniprojekt.com.PL> napisał(a):
>>> Konrad Stepien wrote:
>
>>>>> Kazde nacisniecie klawisza generuje pakiet i odpowiedz.
>>>>>
>>>> Nieprawda. Zależy od trybu pracy telnet-a, a w najgorszym
>>>> przypadku zawsze działa elgorytm Nagla.
>>>  
>>> W tym konkretnym przypadku prawda.
>>>
>> 
>> Znaczy, chcesz powiedzieć, że w tym przypadku algorytm Nagla
>> nie działa? Możesz coś więcej?
>
> Wiecej juz bylo i nie bede sie powtarzal.
>

Mniej więcej śledziłem wątek, i nigdzie nie zauważyłem niczego
co by miało spowodować, że algorytm Nagla nie będzie działał.
Aż teraz spojrzałem w archiwum i _nigdzie_ nie pisałeś, że
coś ustawia TCP_NODELAY. A jeśli się tego nie ustawi, to algorytm
Nagla działa, bo jest zaimplementoway na poziomie stosu TCP/IP. 

PS. wiem, że przy debilnej aplikacji to niewiele zmienia.

-- 
WARNING: my e-mail is encrypted by ROT13
Xbaenq Fgrcvra <xbaenq@vagreqngn.arg.cy>

Konrad Stepien <xbaenq@vagreqngn.arg.cy> writes:

> Mniej więcej śledziłem wątek, i nigdzie nie zauważyłem niczego
> co by miało spowodować, że algorytm Nagla nie będzie działał.
> Aż teraz spojrzałem w archiwum i _nigdzie_ nie pisałeś, że
> coś ustawia TCP_NODELAY. A jeśli się tego nie ustawi, to algorytm
> Nagla działa, bo jest zaimplementoway na poziomie stosu TCP/IP. 

Swoja droga, nie przypominam sobie programu, ktory pracujac znakowo
(telnet, ssh, rsh, cokolwiek) powodowalby jakiekolwiek problemy
przy linku np. 28k8 b/s.

W tej chwili pracuje na zdalnym terminalu graficznym z szybkoscia
128 kb/s (przez publiczny internet) i w ogole tego nie czuje. Tu nie
tylko kazde nacisniecie klawisza generuje pakiet, tu nawet dobre
ruszenie mysza generuje przynajmniej kilka.
-- 
Krzysztof Halasa

Krzysztof Halasa wrote:

> Konrad Stepien <xbaenq@vagreqngn.arg.cy> writes:
> 
>> Mniej więcej śledziłem wątek, i nigdzie nie zauważyłem niczego
>> co by miało spowodować, że algorytm Nagla nie będzie działał.
>> Aż teraz spojrzałem w archiwum i _nigdzie_ nie pisałeś, że
>> coś ustawia TCP_NODELAY. A jeśli się tego nie ustawi, to
>> algorytm Nagla działa, bo jest zaimplementoway na poziomie
>> stosu TCP/IP.
> 
> Swoja droga, nie przypominam sobie programu, ktory pracujac
> znakowo (telnet, ssh, rsh, cokolwiek) powodowalby jakiekolwiek
> problemy przy linku np. 28k8 b/s.
> 
> W tej chwili pracuje na zdalnym terminalu graficznym z
> szybkoscia 128 kb/s (przez publiczny internet) i w ogole tego
> nie czuje. Tu nie tylko kazde nacisniecie klawisza generuje
> pakiet, tu nawet dobre ruszenie mysza generuje przynajmniej
> kilka.

Ale roznice widac jak sie przechodzi z 300 lokalnych serwerow na
jeden centralny i pare tysiecy uzytkownikow klepie w klawisze na
tych samych laczach.
Lagi sa ewidentne co uzytkownik widzi golym okiem ale niech sie
martwi ten co to wymyslil :-)))

-- 
Pozdrowienia!!StaCH
Sieci,systemy,serwis PC,alarmy,kamery,domofony,sterowniki PLC.
http://www.uniprojekt.com  mobile:http://wap.uniprojekt.com

Stanislaw Chmielarz <schmielarz@uniprojekt.com.PL> writes:

> Ale roznice widac jak sie przechodzi z 300 lokalnych serwerow na
> jeden centralny i pare tysiecy uzytkownikow klepie w klawisze na
> tych samych laczach.
> Lagi sa ewidentne co uzytkownik widzi golym okiem ale niech sie
> martwi ten co to wymyslil :-)))

Moze trzeba wywalic tego starego polpaka w centrali i kupic jakis
link w rodzaju np. 10 Mb/s albo wiecej. Jesli uzytkownikow sa
tysiace to koszt lacza bedzie pomijalny.
-- 
Krzysztof Halasa

Krzysztof Halasa wrote:

> Stanislaw Chmielarz <schmielarz@uniprojekt.com.PL> writes:
> 
>> Ale roznice widac jak sie przechodzi z 300 lokalnych serwerow
>> na jeden centralny i pare tysiecy uzytkownikow klepie w
>> klawisze na tych samych laczach.
>> Lagi sa ewidentne co uzytkownik widzi golym okiem ale niech sie
>> martwi ten co to wymyslil :-)))
> 
> Moze trzeba wywalic tego starego polpaka w centrali i kupic
> jakis link w rodzaju np. 10 Mb/s albo wiecej. Jesli uzytkownikow
> sa tysiace to koszt lacza bedzie pomijalny.

Pewnie masz racje ale to nie jest na dzisiaj moje zmartwienie
tylko moich bylych uzytkownikow.

-- 
Pozdrowienia!!StaCH
Sieci,systemy,serwis PC,alarmy,kamery,domofony,sterowniki PLC.
http://www.uniprojekt.com  mobile:http://wap.uniprojekt.com

Krzysztof Halasa <khc@pm.waw.pl> napisał(a):
> Konrad Stepien <xbaenq@vagreqngn.arg.cy> writes:
>
>> Mniej więcej śledziłem wątek, i nigdzie nie zauważyłem niczego
>> co by miało spowodować, że algorytm Nagla nie będzie działał.
>> Aż teraz spojrzałem w archiwum i _nigdzie_ nie pisałeś, że
>> coś ustawia TCP_NODELAY. A jeśli się tego nie ustawi, to algorytm
>> Nagla działa, bo jest zaimplementoway na poziomie stosu TCP/IP. 
>
> Swoja droga, nie przypominam sobie programu, ktory pracujac znakowo
> (telnet, ssh, rsh, cokolwiek) powodowalby jakiekolwiek problemy
> przy linku np. 28k8 b/s.
>
Jeszcze zależy od RTT.
Przy paracyu przez komórkę (nieważne, GPRS czy klasyczny wdzwaniany)
praca poptrafi być mocno upierdliwa. UMTS i wyżej już jest lepiej.

> W tej chwili pracuje na zdalnym terminalu graficznym z szybkoscia
> 128 kb/s (przez publiczny internet) i w ogole tego nie czuje. Tu nie
> tylko kazde nacisniecie klawisza generuje pakiet, tu nawet dobre
> ruszenie mysza generuje przynajmniej kilka.

Zauwazyłem, że przy programach typu NX ważna jest stałość paramatrów
łącza. Lepiej się pracuje na stabilnych 128kbps niż "pływającym"
megabicie. Zresztą, mam jeden strwer stojący na łączy 3 mbps, wolę
na nim pracować przez zapyziałą dzierżawką 115200, za to punkt-punkt
niż mam sshować się przez Warszawę, Kraków i diabli wiedzą co jeszcze.

-- 
WARNING: my e-mail is encrypted by ROT13
Xbaenq Fgrcvra <xbaenq@vagreqngn.arg.cy>