[Priidik100]

Mul on valguskaabliga 40/40mbs Telia koduinternet, arvuti ka kaabli otsas. Ja probleem on siis selline, et kui midagi arvutis võtab bandwithi nt youtube või midagi muud, siis tekivad ping spikid 200-600ms, umbes 1 - 2tk minutis. Task manageri ja packetstatsi kõrvutades on näha, et ping spike tekib just sel hetkel, kui YT video hakkab laadima ja koormuse korraks 40mbs (maxi) viskab, tekib nagu throttle down efekt.
Googeldasin natuke ja soovitatakse ruuteris bandwidthi kiirust piirata 95% peale, aga ei leidnud telia ruuterisse sisse logides sellist kohta (Genexis Pure ED500). Mul hetkel teine Telia ruuter (X2) ka olemas ja sellega täpselt sama probleem.
Kas keegi on sellise probleemiga kokku puutunud ja oskab soovitada viisi, kuidas bandwidthi kiirust arvutis või ruuteris piirata? Kas Telia ruuterites on seda võimalik teha või tuleb osta mingi kaasaegsem aparaat?

Olen ise testinud kahte erinevat arvutit, kaablit ja ruuterit. Helistasin telia tehnikule ja kõik pidavat nende poolt vaadatuna korras olevat.

[Tint]

Kui kanali täis tõmbab siis viskabki latentsuse üles. Aga kui mängida tahad, siis bandwith limiter, linuxi kerneli jaoks on täitsa olemas kerneli lollitamiseks.

tc qdisc add dev eth0 root tbf rate 1mbit burst 32kbit latency 400ms

tulemus tulemuseks:
$ iperf -c 172.31.0.142
————————————————————
Client connecting to 172.31.0.142, TCP port 5001
TCP window size: 85.3 KByte (default)
————————————————————
[ 3] local 172.31.0.25 port 40232 connected with 172.31.0.142 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-11.0 sec 1.50 MBytes 1.14 Mbits/sec

[Priidik100]

[fuusio]

Hei,
mul oli sama probleem. Juhuse tahtel oli vaja Telia valguskaabli karbikut liigutada.

Nagu karbiku seina pealt lahti lasin, krõps valguskaabel puruks.

Valguskaabli paigaldusel oli tehnik kaablile murde teinud, kuid andis signaali edasi. Aga mahu kasvades tõmbas võrgu kinni.

Tasub üle vaadata valguskaabel.

[indrpo]

Valguskaabel pole nagu spagett, et krõps ja katki.
Sa võid seda praktiliselt pliiatsi ümber kerida ja ei purune.
Kui sa seadme seinalt eemaldasid siis krõpsu see kaabel ei tee, ja kui katki läheb, siis ta ka ei tööta.

Ping aga kasvab mistahes võrgus, kui koormad tellitud kiiruse üle.
Ping kasvab ka siis kui sul on ka 1Gbit ühendus ja laed midagi mahukat täiskiirusel alla.
Ainus viis hoida stabiilselt madalat pingi ongi piirata oma arvutis vms tegevuste kiirust, et mitte ummistada tellitud kiirust.

Ma ei tea kas sellel väikesel kiirusel aitab, aga pane siis youtube jõuga madalama bitrate peale. Võimalik, et bufferdab max kiirusel edasi.

[fuusio]

[kaabakas]

Kiiruse piiramisest üksi on vähe. Vaja on, et ruuter oskaks ja lubaks sise lülitada cake/codel algo, mis on see tegelik maagia, mis töö ära teeb.
Lahendusi on pmst kolm:
- oma ruuter
- kiirem pakett
- õlgu kehitada

[jaakjaak22]

Võrguteadlikumatele inimestele on ammu teada, et IP-protokolli loomise ajal ei mõeldud, et ühel päeval enamus sisu liigub striimides ja kadunud pakettide tagaotsimine ajab puhverduse hulluks Igasugu striimiguvärgi puhul on torujämedusest olulisem ruuterite nutikus bufferbloati ohjamisel, võlusõnadeks on FQ-CODEL või CAKE võimekus. Loeb siit: https://www.bufferbloat.net/projects/ ja testib siin https://www.waveform.com/tools/bufferbloat või www.fast.com

Ise olen kasutanud Mikrotikus CAKE-queue seadistamist ja ka Telia 20/20 ühendusega võisid teised kasutajad vabalt telekat vaadata võid muud võimelda, töövideokõnesid see ei seganud.

[kaabakas]

Kadunud pakett ei ole antud juhul teema. Veelgi enam, pakettide maha viskamine on võrguühenduse mitte ainult vältimatu, vaid tcp puhul lausa kvaliteedi tagamise osa.

Nimelt, mida peab üks võrguseade tegema, kui pakette tuleb rohkem peale, kui toru läbi laseb? Puhvrid ei ole lõputud ja saavad täis, mitte midagi muud ei olegi teha kui pakett maha visata.
Tcp kasutab seda andmevoo kiiruse paika timmimise jaoks. Punkti A ja punkti B vahel oleva ühenduse kiirust pole kuskilt mujalt ennustada kui kohvipaksu pealt. Aga tahaks ometi kasutada kogu kiirust, mis saada on. Mida teha? Alustame ettevaatlikult, ja tõstame aegamööda kiirust. Ühel hetkel hakkab pakette tee peal maha kukkuma, järelikult oleme toru lõhki ajanud. Võtame kiirust maha, kuni kadu enam ei ole.

Codel ja Cake teevad põhimõtteliselt kahte asja. Esiteks hakkavad pakette enne maha viskama, kui toru lõhki läheb. See on see koht, kus sa piirad kiiruse ruuteris tolle ~95% peale. Sellega välditakse pakettide puhvritesse kogunemist, sest puhvrisse venima jäänud pakett tõstab ilmselgelt latentsi. Teiseks prioritiseerivad nad pakette ja andmevooge, nii et latentsitundlikud asjad lastakse eelisjärjekorras läbi, ja tuimemad asjad müttavad taustal ilma kedagi häirimata.

[Dirty Harry]

See on rohkem tiku spetsiifiline aga: kui CPU-nõudlik CAKE on Mikrotiki puhul?

[kaabakas]

Eks ta veidi rohkem oli kui codel. Eks ta teeb ka rohkem.
Oleks nagu kuskilt kõrva jäänud, et umbkaudu 30% rohkem proset sõi.
Pole tegelikult üldse tiku spetsiifiline. Kuni kumbki algo rauas ei jookse, peab prose selle töö ära tegema, ja töö on täpselt sama ükskõik millises ruuteris.

[Etz]

[kaabakas]

Suur muutuja on tegelikult klientide ja voogude arv. Kodukasutajal ei pruugigi mingit vahet olla, aga kui sul sada inimest kontoris, siis on veidi teine pilt.

[Etz]