dziwaczne pytanie o sieć LAN

Mam Stadie - dostałem za darmo więc popróbowałem i lagów nie zauważyłem ale muszę przyznać że wielkim graczem nie jestem, Do google.com mam 5ms i to nie jest głowny powód lagów. Warto obejrzeć to:

No pisalem ci przeciez, ikxy na odleglosc 2000km chodza calkiem ok. Tak sundayman napisal ze robi w eda to jakikolwiek lag w zakresie lokalnego ethernetu bedzie zerowym problemem.

Ty chyba ostatnio wi iksach nie pracowales. Totalnie nie potwierdzam takich doswiadczen a i z iksami (over citrix) i z rdp mam do czynienia co dzien i nie jest az tak zle jak piszesz. Ale zeby nie bylo ze bez pokrycia sobie fandzole to puscilem nieco apek po ethernecie setce w domu. Glxgears na domyslnym rozmiarze okienka

Pingi mam ponizej 1ms. Mysle ze w tym warsztacie bedzie podobnie.

Jak dla mnie temat jest wyczerpany. SOA#1 - u mnie dziala, Pan sobie naprawi we wlasnym zakresie.

PS. Probowalem sobie puscic apki ikxowe przez atlantyk ale tam nie mam za duzo nainstalowane wiec tylko xev i xterma przetestowalem. Przez atlantyk calosc dziala ok. Lag jest minimalny jak sie uruchomi top czy jakies inne konsolowe wygibasy w okienku na caly ekran fullHD. Tak ze nawet w takim ekstremalnym (pingi po 150ms, a calosc po ssh over vpn) setupie nie jest az tak zle.

sobota, 12 czerwca 2021 o 12:33:02 UTC-5 Grzegorz Niemirowski napisał(a):

W praktyce dzis to juz nie problem w domowych i polprofesjonalnych zastosowaniach. Niedawno bawilem sie jitsi. I puscilem sobie sesje video na trzy osoby z czego jedna to ja sam ale puszczony za atlantyk i spowrotem. Lag wideo byl ponizej 200ms.

Ogolnie i streaming i rdp i nawet biedne iksy w nie ekstremalnych setupach sa calkiem ok. Szczegolnie jak sie ma relatywnie szybka siec. BTW temat long fat pipes jest mi znany. Ale sa metody na ogarnianie tego zeby dzialalo jak u ludzi.

Jakie masz łącze w miejscu tego testu? Na co dzień pracuję przez x11/vnc over ssh w terenie i moje doświadczenie jest takie, że na razie nie udało mi się doświadczyć komfortowej pracy jeśli końcówka jest podłączona przez sieć komórkową (tylko LTE+ bez 5G, w terenie gdzie pracuję jeszcze się nie pojawiło 5G). Odświeżanie ekranu (lub jego fragmentu) to zawsze wolniejsze lub szybsze "przewijanie". Oczywiście w miejscach stacjonarnych gdzie jest możliwość korzystania ze światłowodu komfort jest bez porównania lepszy, praktycznie nieodróżnialny od pracy "lokalnej".

Jest Sat, 12 Jun 2021 23:24:58 -0700 (PDT), ptoki pisze:

Napisał też, że VNC jest dla niego za wolne. A IMO X jest wolniejsze od VNC.

^^^^^^^^^^^ Zaraz, zaraz, stop. Coś mi tu nie gra. Nie znam Citriksa. W jaki sposób realizowana jest sesja X11? Jak wygląda komunikacja klient-serwer? Czy serwer (Twój lokalny host) to standardowy xorg?

U mnie też po LAN. Sesja X forwardowana po ssh z kompresją (ssh -XC):

Domyślny rozmiar okienka:

FHD:

IMO wynik porównywalny.

Inkscape działa i u mnie też w miarę normalnie. Choć oczywiście daleko do wrażenia, że pracuje się lokalnie. A lokalna maszyna ma małą wydajność 2D. Na czymś lepszym różnica byłaby bardziej wyraźna. Ale daje się pracować, tylko chyba nie o to do końca chodziło.

Już Librecada nie chciało mi się instalować. W przypadku FreeCAD-a z modelem 3D jest dramatycznie wolno. Nawet opercjom na widokach 2D (powiększenie, przesuwanie) towarzyszy duży lag. Tu jest dokładnie jak pisałem.

Średnio 0,2 ms.

No nie wiem czy jest tu coś do naprawiania.

k.

W dniu 11.06.2021 o 23:58, sundayman pisze:

Będzie Pan zadowolony!

yabba

niedziela, 13 czerwca 2021 o 01:58:48 UTC-5 Marek napisał(a):

Ethernet.

Nie istotna technologia. Istotny w sumie jest tylko ping. Jak powyzej 100ms to jest slabo dla X11. Powyzej 250 jest tak se dla ssh. Powyzej 800ms jest slabo dla ssh.

Ale IMHO trudno dzis znalesc tak kiepskie lacza. Za atlantyk mam jakies 130ms. To jest z mojej dziury w dupie do drugiej dziury w dupie ale za oceanem. Przy czym obie dziury w dupie maja lacza nie dsl-owe. Ale to wiele nie powinno zmienic w temacie pinga.

Nawet DSL jest ok.

Ale lacza komorkowe nawet jak sa 4/5G to czasem po prostu zasieg jest tak kiepski ze co jakis pakiet wypada i zanim tcp window sie pokapuje ze cos nie doszlo to trwa nieco.

Ogolnie temat jest ciekawy ale sporo laczy nawet domowych dzis jest tak szybka ze w sumie nie jest to problemem.

Mam taka robote ze ogarniam klientow ktorzy maja datacenter pare tysiecy km odemnie i ani ssh ani rdp ani nawet ten jeden gdzie iksow uzywam z firefoxem nie jest problemem. A sporo z tych rdp-ow leci po citrixie wiec dodatkowe opoznienie tam jest.

A jak sie ma kiepskie lacze to w sumie tylko ssh i to nawet bez midnight commandera trza uzywac bo sie tnie. Ale to rzadkosc ostatnio. I oby sie nie zmienilo...

niedziela, 13 czerwca 2021 o 13:34:07 UTC-5 Krzysztof Gajdemski napisał(a):

Przeczytaj co napisal. Napisal ze jak sie kiedys bawil (kiedy? gdzie? jaka siec? ) to bylo kiepsko. A dzis ma mocny serwer, pewnie nowsza siec i nawet vnc pewnie lepiej ogarnia odswierzanie ekranu bo kiedysiejsze to po prostu pakowaly screenshoty w jpeg i pchaly do klienta. Dzis mozna nieco lepiej...

Mam jeden setup gdzie stosik jest taki: Server do ktorego sie wbijam->citrix->mobaterm (ssh do tego serwera)->firefox po iksach->iksowa sesja-citrix klient u mnie-mojkomp i tam jest szybko jak lokalnie.

Mam drugi setup gdzie stosik jest podobny ale bez citrixa: server do ktorego sie wbijam->vpn->mobaterm u mnie (ssh)->firefox po iksach i dupy nie urywa ale dziala na tych 2000km (ping na poziomie 50ms).

Tak i lokalny jak i zdalne hosty to raczej standardowe xorgi z centosa i ubuntu oraz mobatermowy klient bo lap roboczy ma winde.

Jak w domu kiedys mialem cnc to obslugiwalem je przez vnc po setce ethernecie i bylo zupelnie ok. W sensie ze jak widzialem ze frez mi na ekranie zakreca to slyszalem z drugiego pokoju zmiane halasu jaki cnc robila.

Sedno przeslania: Na kiepskiej sieci wszystko kiepsko dziala. Na setce lokalnie wszystko wymienione powyzej (vnc, ssh, iksy, rdp) jest raczej bezproblemowe poza naprawde drastycznymi zastosowaniami.

No wlasnie. Nie wglebialem sie gdzie jest dokonywany rendering i czy po tej setce leci bitmapa spakowana czy komendy opengl-owe ale dziala zjadliwie.

No to nie rozumiem przeslania. Jak widac, dziala i jest zjadliwe. A pisales ze nie bardzo.

Tak czy siak. Pan zadowolony, ja zadowolony a sundayman niech montuje te swoje srodowisko i przyjdzie sie pochwalic ze dziala albo ponarzekac ze z czyms ma problem. Wtedy sie usiadzie i na spokojnie przy herbatce wymysli jak ogarnac...

Praktyka jest taka, że na LTE+ przy ping 30ms przewija, a na DSL ping

Jest Sun, 13 Jun 2021 22:01:03 -0700 (PDT), ptoki pisze:

OK, w takim kontekście inaczej to wygląda.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Ej, pisałem, że tam gdzie instensywnie wykorzystywana jest grafika będzie wolno nawet po LAN. I jest bardzo wolno np. w przypadku FreeCAD-a. To samo np. w Blenderze (nawet tylko z domyślną kostką jest już słabo). Tak więc przesłanie jest takie, że akurat w takich przypadkach X11 będzie najwolniejszy ze wszystkich tego typu rozwiązań (ze względu na specyfikę protokołu). Np. VNC (który demonem prędkości nie jest) na tym samym łączu i w takich samych testach był – zgodnie z przewidywaniami – nieporównywalnie szybszy. RDP nie znam, ale jest jeszcze SPICE, NX. Oba (w szczególności ten ostatni) powinny być wyraźnie szybsze od VNC, o X nie wspominając.

Popieram. :)

k.

Jest Sun, 13 Jun 2021 21:44:48 -0700 (PDT), ptoki pisze:

Do najcięższych przypadków jest jeszcze mosh:

k.

poniedziałek, 14 czerwca 2021 o 01:04:23 UTC-5 Marek napisał(a):

Najpewniej tcp window albo jakims niedopasowaniem rozmiaru pakietu. Nie badalem tematu dokladnie bo staram sie unikac takich lacz do zastosowan gdzie wymagane jest wydajnosc i niezawodnosc ale jak sobie nagrasz te sama komunikacje po tym lte i po dsl powinienes zlbo zobaczyc ze roudn trip dla lte jest wyzszy od dsl-owego nawet pomimo niskich pingow dla lte albo tam masz jakies retransmisje bo pakiety sa utracone.

W skrocie: trzy najczestsze sytuacje gdzie lte/gprs i podobne maja problem:

1. Rozmiar pakietu jest niedopasowany (tzw MTU). Wtedy klient wysyla pakiet ktory albo modem albo urzadzenie po drodze musi podzielic. To nie do konca jest problem laga ale powoduje ze wydajnosc lacza spada a round trip sie robi czasem wiekszy. Widoczne przy transmisjach raczej strumieniowych.
2. Utracone pakiety. Jak zasieg kiepski to czasem pakiet/ramka sie straci i trzeba troche poczekac aby sie obie strony polaczenia tcp pokapowaly i sobie utracone dane doslaly. Niby powinno sie samo skalowac ale nie zawsze sie udaje osiagnac optimum. A dla laczy slabych bedzie widoczne.
3. Malo pasma w danym nadajniku. Wiele sie poradzic nie daje na to. Moze zmiana operatora?

Potestowac mozna sobie za pomoca pingow o wiekszym rozmiarze. Popuszczac troche malych i troche coraz wiekszych. W pewnym momencie bedzie widac skokowe przyrosty czasow odpowiedzi. Tak jak sie testuje rozmiar cache. Dodatkowo mtr sobie puscic i obserwowac jak sie zachowuje. No i nagrac tcpdumpem transmisje i sobie zanalizowac w jakich momentach sie rwie. Bo wiesz, ping lata szybko a transmisja nie musi byc obslugiwana na tym samym priorytecie. Gupie ale nie takie oszustwa telekomy wyczyniaja.

Zalezy do czego potrzebujesz. Czasem ustawienie MTU pomoze, czasem lepsza antena, zmiana operatora a czasem ustawienie swojego vpn po udp i odpowiednie wyregulowanie niskopoziomowych aspektow tcp w tym polaczeniu. Jak problemem jest tcp window to mozna nieco sobie w ten sposob poprawic.

Cudow sie zrobic nie daje ale cos tam ulepszyc sie daje.

poniedziałek, 14 czerwca 2021 o 02:54:13 UTC-5 Krzysztof Gajdemski napisał(a):

Nadal sie nieco nie zgodze. Popuszczalem sobie freecada nieco i nie jest zle tu u mnie lokalnie. Moze u ciebie ogolnie byl problem z opengl-em po stronie lokalnej i sie cos sypalo? Nie wiem. Iksy nie sa stworzone do pracy w sieciach bardzo rozleglych ale tez nie byly robione tylko do pracy lokalnej (w obrebie jednego hosta). Na sensownej sieci domowej iksy dzialaja znosnie.

Tak opcji jest sporo. Oczywiscie mozna tez wymienic te interfejsy hdmi po dwu skretkach albo nawet sygnal analogowy (SVGA) po tychze skretkach. U siebie mialem jakies 40m puszczone wprost z dsub-a do rzutnika na byle cat5 (byle odpowiednio skretki polutowac zeby zaklocen nie bylo) i dzialalo ok. Ale te 40m na tym pasciatym kablu juz pozwalalo zauwazyc pewne powidoki (moze przyciecie dlugosci odpowiednio by je zmniejszylo, nie testowalem, szkoda kabla mi bylo) - rozdzielczosc 1024x768. Dawno to bylo...

Obaczymy, mysle ze rdp mu zadziala akceptowalnie.

poniedziałek, 14 czerwca 2021 o 02:56:59 UTC-5 Krzysztof Gajdemski napisał(a):

Fajny. Choc ja zazwyczaj screena uzywam a laga po prostu cierpie...

Ale mialem kiedys fajna akcje.

Mialem w domu polaczenie do mojego domowego serwera zrobione po vpn. I sesje ssh otwarta. Troche bez sensu bo calosc byla w tej samej sieci ale se tak bylo.

Laptopa bez konczenia sesji zahibernowalem i zalecialem za atlantyk.

Prawie dwa dni pozniej laptopa wlaczylem, zanim wrocilem do niego po chwili vpn sie spowrotem polaczyl a ja wcisnalem enter na teh sshowej sesji. Sesja byla nadal zywa.

Taki pozytywny ewenement.

Oczywiscie to zachowanie zalezy od paru ustawien ale milo mnie zaskoczylo bo nie ustawialem tego pod taki przypadek.

Dnia Mon, 14 Jun 2021 10:34:20 -0700 (PDT), ptoki napisał(a):

Do trzymania sesji dobry jest "screen".

Jest Mon, 14 Jun 2021 10:30:22 -0700 (PDT), ptoki pisze:

Zgodnie z tradycją wątku, zamiast się upierać potestowałem trochę. Użyłem innych maszyn, wykonałem testy w obu kierunkach etc. Ograniczyłem się do FreeCAD-a, ale jak wspomniałem taki np. Blender zdradza podobne zachowania. U mnie rezultaty są spójne: za każdym razem efekt taki sam, operacje wykonywane są wolno, spowolnienie wzrasta wraz ze złożonością modelu. Może mamy inne definicje tego, co oznacza, że nie jest źle? Da się pracować, jednak odświeżenie grafiki jest wyraźne, wszelkie operacje, w których pożądana jest płynność (obroty etc) nie są płynne. Taka sama próba przy użyciu x11vnc daje daleko lepsze rezultaty.

Nie wygląda mi na to, żeby były tu jakieś problemy z GL, mesą etc. Glxinfo nie pokazuje niczego niepokojącego w żadnym z przypadków (w jednym rzeczywiście zgłosił błędy, ale tu od razu było widać, że nie działa to dobrze – upierdliwy, własnościowy sterownik grafiki, testy odpuściłem). Zresztą widziałeś wyniki z glxgears. W innych testowanych przypadkach były porównywalne.

ZTCP, X jest stworzony do pracy w sieci i działa efektywnie do momentu, kiedy nie musi wysyłać dużej ilości danych. Np. rysując UI, wysyła co się da w formie instrukcji, co oczywiście bardzo dobrze wpływa na wydajność. Jednak kiedy przychodzi do przesyłania grafiki jest dużo gorzej. Nie pamiętam w tej chwili szczegółów implementacji. Były też podejmowane próby poprawy tej sytuacji, ale nie obiło mi się o uszy, żeby wyniki były spektakularne. Dlatego np. powstał NX.

Też pomyślałem o jakimś bardziej sprzętowym rozwiązaniu tego zagadnienia.

k.

Hmm.. tak mówię do klienta, kiedy nie mogę się z czegoś wytłumaczyć...

W dniu 21.06.2021 o 02:36, sundayman pisze:

Ja nie umiem wytłumaczyć dlaczego właśnie RDP, a nie inny, ale ... będzie Pan zadowolony.

yabba

poniedziałek, 21 czerwca 2021 o 06:40:37 UTC-5 yabba napisał(a):

Bo rdp jest dosyc gleboko wpiety w system i jest swiadomy co sie odrysowalo ostatnio wiec nie zgaduje ani nie przesyla calego obrazu. To tak w skrocie bo rdp umie pare innych rzeczy robic zeby nawet przy modemowych predkosciach dzialac znosnie.

No i dosyc dobrze pakuje to co wysyla wiec pasma potrzebuje niewiele.

No i, tak, bedzie pan zadowolony.