Forum Debian Users Gang

Tak samo.

Na tym na którym masz sprawne sterowniki do NIC.

arecki napisał(-a):

Tak samo.

No nie wiem czy będzie działać tak samo. xD Nie znam się na windowsach i nie wiem jak one sobie dobierają konfigurację sieci ale na linux to można np. zrobić to poniższe:

- można wyłączyć znaczniki czasów (tcp_timestamps) o ile się nie ma się gigabitowego łącza. To zawsze zaoszczędza 12 bajtów w 1500 bajtowym pakiecie, co się przekłada na większy transfer, no i oczywiście maszyna nie musi poświęcać zasobów by te znaczniki brać pod uwagę przy wysyłaniu/odbieraniu pakietów, a to zawsze jakiś ułamek sekundy zajmuje, a że pakietów są mln, to nawet sporo czasu może zając.... patrząc w skali roku... xD
- można przepisać timeout'y dla konkretnych stanów połączeń, oraz dostosować ilość prób przesyłanych pakietów SYN/ACK, dzięki czemu można "poprawić net" w słabszych sieciach, np. wifi, lte i innych takich ze słabym zasięgiem. Bo jak masz niskie timeouty/mało pakietów SYN/ACK, to ci połączenia będą się zrywać, a tak to można odpalić 20 stron w ff, zrobić se kawę i wrócić za 5 min i strony się załadują ... prędzej czy później. xD
- można włączyć selektywne potwierdzenia, przez co nie trzeba potwierdzać każdego pakietu danych pakietem ACK, tylko zbiorczo będzie szło potwierdzenie, co skutkuje też mniejszą ilości retransmisji, a co za tym idzie wzrost transferu z racji niemarnowania przepustowości łącza na retransmisję zagubionych segmentów. Bufory na pakiety w tranzycie też idzie dostosować, przez co prędkość transferu może ulec zwiększeniu.
- można też wysyłać dane w pakietach SYN od razu bez potrzeby czekania na zakończenie fazy 3WHS (TCP Fast Open), co z kolei daje dość mocny boost przy krótkich połączeniach, np. tych http/https (jakieś 30-50% albo nawet i więcej)
- można powyłączać mechanizmy kontroli zatorów, które czasem robią więcej złego niż dobrego, np. na wifi czy lte ze słabym zasięgiem.
- można też dostosować algorytm kontroli zatorów — ostatnio wszedł BBR (Bottleneck Bandwidth and Round-trip propagation time) od Google.
- można włączyć tcp_autocorking i zamiast wysyłać wiele małych pakietów, to wysyłać jeden większy.
- można podbić initcwnd/initrwnd, które z kolei wpływają na początkowy rozmiar okna używanego w fazie szybkiego startu, co z kolei zaoszczędza RTT (czasem nawet dobrych kilkaset ms na połączenie).
- można też dostosować połączenia keepalive wraz z ignorowaniem procedury wolnego startu, gdy dane w takim połączeniu IDLE zaczną być znów przesyłane (np. w sesji ssh).
- można wymusić odpowiednie MSS jeśli z jakiegoś powodu system ustawia zbyt małe, zakładając, że robi to błędnie... xD
- można dostosować też całą masę opcji wpływających na wykorzystanie RAM'u, co z kolei może jako takiego netu nie poprawi ale kompa może odciążyć. xD

Tyle mi przyszło do głowy po rzuceniu okiem na swój sysctl. ale to i tak pewnie tylko czubek pewnego organu. xD

I tak mi przyszło jeszcze do głowy -- można zrobić tylko INPUT w nftables bez potrzeby posiadania pozostałej infrastruktury FW, co przyśpiesza przetwarzanie pakietów. xD

I w sumie jeszcze można by zrobić sobie własny zoptymalizowany kernel, np. można wkompilować wszystkie potrzebne maszynie moduły na stałe i wywalić cały kod odpowiedzialny za ładowanie/wyładowanie modułów. Taki zabieg czyni kernel mniejszym, prostszym i szybszym.

Ostatnio edytowany przez morfik (2019-12-22 14:14:21)

Nie ma czegoś takiego jak "normalnie działający internet", i to czy będzie on chodził lepiej czy gorzej zależy od całej masy rzeczy. Internet to nie tylko kabel od jednego międzymordzia do drugiego. xD Sporo większą rolę odgrywa system maszyny, która adresuje pakiety (lub też te pakiety odbiera, w sensie serwer, router, itp.). Pomijając tuning pewnych ustawień, które już mogą ci dać spory boost (a czy dadzą, to zależy), to jeszcze w grę wchodzi cały proces adresowania pakietów, który może przebiegać wolniej albo szybciej, a czas spędzony na adresację (zanim pakiet dotrze do NIC) dolicza się do czasu jaki pakiet musi spędzić w tranzycie. Później trzeba czekać na przetworzenie pakietu na maszynie docelowej, co też może zająć mniej lub więcej czasu, no i ta druga strona musi ci jeszcze odesłać zwrotny ACK, który ty z kolei musisz przetworzyć u siebie. xD. Jak masz zasyfiony system albo serwer nie wyrabia to proces związany przetwarzaniem pakietów może przebiegać naprawdę wolno i net będzie mulił, podobnie jak odpalisz setki połączeń (np. p2p) i jedne połączenia będą dławić inne. Pewne rzeczy można poprawić, np. stosując TC (kontrolę ruchu), gdzie będzie odczuwalny wręcz ogromny boost, np. w przeglądarce przy ciągle odpalonym torrencie. Można wymienić podzespoły w kompie, by zwiększyć jego moc obliczeniową, czy też ładować sporo rzeczy bezpośrednio do RAM, by ciągle nie odwoływać się do wolnego dysku. Można zmienić też aplikacje z tych bardziej krowiastych na te prostsze. Te wszystkie rzeczy wpływają na to jak przetwarzane są informacje w systemie -- im szybciej to jest jest robione tym szybciej masz pakiety gotowe do wysyłki, a co za tym idzie masz lepszej jakości net. xD

urbinek napisał(-a):

Już nie wydziwiaj :p Doskonale wiesz co mam na myśli mówiąc normalny.

Nie wiem. xD

urbinek napisał(-a):

O nie pytam o teoretyczne usprawnienia tylko realne cyferki.

No waśnie problem w tym, że te cyferki będą różne, bo zależą od całej masy czynników. xD

urbinek napisał(-a):

Obecnie mając Internet z upc czy od innego dostawcy jestem nw stanie zamknąć rurke 250/10mbps i dalej mieć pingi poniżej 80ms do serwerów Valve w Amsterdamie.

Jak ja bym ci zapchał tę rurę to byś miał ping 16K... xD Wszystko się sprowadza do przetwarzania pakietów, które lądują pierw w kolejce zanim zostaną wysłane/odebrane. Jak maszyna (twój komp) sobie nie radzi z odbieraniem/wysyłaniem pakietów, tj. za szybko one napływają niż system jest w stanie je przetworzyć, to kolejki zaczynają się zapełniać. Im dłuższa kolejka, tym większe opóźnienia będą występować (ilość pakietów w kolejce można dostosować). Jak taki stan rzeczy się utrzymuje przez dłuższą chwilę, to kolejka ulega zapełnieniu, czego efektem jest gubienie pakietów i to jest sygnał dla drugiej strony by zwolnić nadawanie. Im większa kolejka, tym większy ping gdy zrobi się na kablu tłoczno. Szybki procek + wiele rdzeni o wiele sprawniej sobie radzi z opróżnianiem pakietów w tych kolejkach. Ale wciąż 80ms to dużo. Przy pewnym tuningu (TC, priorytetach i małych kolejkach) można by zejść do wartości którą masz gdy żadne pakiety nie wędrują po kablu. Więc bez znaczenia by było jak bardzo zapchasz rurę, to pewne pakiety będą uprzywilejowane na tyle, by z kolejek je odebrać jako pierwsze, co z kolei przekłada się na niskie opóźnienia. Ja taki schemat miałem u siebie non stop przez parę lat jak miałem jeszcze łącze kablowe. Miałem co prawda tylko 15/1mbit/s ale byłem w stanie wysłać ponad 1TiB danych via p2p (obrazy z linux xD) w ogóle tego nie zauważając — miałem cały upload zapchany zawsze, a mimo to przeglądarka miała ping 20-30ms. Odpowiednia konfiguracja systemu to podstawa by "net działał jak trza". xD

urbinek napisał(-a):

Poza tym azybkość ładowania www to nie jedyna oznaka stosu tcp a największe opóźnienia obecnie generuje raczej wolny serwet hostujacy

Tak jak napisałem wyżej — cała masa rzeczy ma wpływ na to czy "net będzie działał przyzwoicie". xD