[ producer011 @ 10.05.2018. 17:08 ] @
Pozdrav!
Imam potrebu da na mikrotiku, na koji se klijenti kace bezicno (ne vise od 5 uredjaja istovremeno) limitiram brzinu interneta.
Posto ne zelim da im dodajem staticke IP adrese, postoji li mogucnost da se limit postavi na odredjeni dhcp pool koji bi isao na taj wlan interfejs?
inace mikrotik ne radi nista drugo sem klasicnog rutiranja, i sluzi da obezbedi internet za tih 5 korisnika. Ostatak ljudi kojima ne treba ogranicavati brzinu, jer su povezani kablom idu preko drugog rutera. Mikrotik je podesen fabricki, menjano je jedino ssid i sifra za internet!
Unapred zahvalan!
[ Predrag Supurovic @ 10.05.2018. 18:31 ] @
Namestis jedan simple queue, vezes ga za interfejs i ogranicis brzinu.
[ producer011 @ 10.05.2018. 18:56 ] @
bilo bi prelepo da si objasnio postupak
[ producer011 @ 10.05.2018. 19:28 ] @
mislim da je ovo dovoljno! ako gresim neka me neko ispravi.
[ bmarkovic06 @ 10.05.2018. 19:44 ] @
Lease to Simple Queues skripta ti je najlaksa. U okviru DHCP servera dodas lease skriptu:


#Lease to Simple Queues
#V.1 By Virtual IT Export

:local queueName "Client- $leaseActMAC";

:if ($leaseBound = "1") do={
/queue simple add name=$queueName target=($leaseActIP . "/32") max-limit=3M/3M comment=[/ip dhcp-server lease get [find where active-mac-address=$leaseActMAC && active-address=$leaseActIP] host-name];
} else={
/queue simple remove $queueName
}



Ovde u Max limirt sto stiji 3m/3m ogranicavas koliko ce biti up/down

edit: Samo da pojasnim, za svaki dodat lease kreira se queue za tu ip adresu i tako se svaki klijent ogranicava sa posebnim protokom. E sad nema ogranicenja ako klijent postavi staticku ip sam.
[ producer011 @ 10.05.2018. 22:13 ] @
ne radi...
iako je po skripti uneto, na speed testu i dalje ide protok po maksimalnoj brzini
[ Predrag Supurovic @ 11.05.2018. 06:56 ] @
Izgleda da nabadanje nije pomoglo. Znači ipak moraš nešto i da pročitač. Ili da angažuješ nekog ko zna.
[ pctel @ 11.05.2018. 07:47 ] @
Ako moze neko da mi objasni - koji je smisao ogranicavanja downlink brzine na mikrotiku? Na mikrotiku ne mozes da ogranicavas sta ce provajder da salje ka mikrotiku, znaci u interesu ti je da uzmes sve sto je poslao, jer ako ogranicavas tada ce neki paketi biti izgubljeni i umesto jednom linija ce biti zauzeta dva ili vise puta za iste pakete podataka, znaci ne mozes nikako ograniciti i time drzati veci deo linka slobodnim. Sa uplink brzinu je naravno logicno - sto manje mikrotik salje prema provajderu, to ce zauzetost linka biti manja. Indirektno se ogranicenjem uplinka ogranicava i downlink, ali kad su u pitanju online igre i youtube to bas i ne funkcionise, jer oni sa malim uplink paketima kreiraju ogromne downlink pakete.
[ Mile-Lile @ 11.05.2018. 10:05 ] @
Prosto je. Porbaću sa analogijom:
Tvoji ukućani kojih ima npr. 5 ti traže da svakom daš po 5 dinara... kreneš da deliš i kod trećeg shvatiš da si ostao bez para :)
Dakle, nije svako kod ISP-a zakupio isti paket... Ruter ne zna koji paket imaš tj. kolika je propusna moć....
Kako ISP-ovi ne prodaju zagarantovane pakete već reklamiraju "brzine do ...", onda kako postoji kod ADSL-a "overhead" potrebno je da se nekoliko puta uradi speedtest u "špicu" dakle petkom uveče oko 20č...
Onda uzmeš od te brzine 80%-90% i ograničiš DL/UL pa ga podeliš na korisnike i radiće...
[ pctel @ 12.05.2018. 04:28 ] @
Hajde da onda probam i ja sa tvojom analogijom - 5 ukucana ti trazi po 5 dinara, ti imas 15 dinara. Ti das prvom 2 dinara, a 3 dinara bacis u smece, drugom isto 2 dinara i 3 u smece i trecem isto tako i ostao si bez para. Sto je najgore, tvoji ukucani sada traze 3+3+3+5+5=19 dinara, a da nisi bacao u smece falilo bi ti 10 dinara sto je bolja solucija. Mislim da ogranicavanje brzine od provajdera ka tebi dovodi do analogije bacanja dela saobracaja u smece. Provajder salje saobracaj brzinom naprimer 15 mbps, a tvoj mikrotik uzme naprimer 3mbps, a ostalo baci u smece. Tcp/ip protokol utvrdi da nije stiglo pa salje ponovo. 15mbps. Ti opet pustis 3, a 12 bacis u smece. I tako umesto jednom provajder salje 5x i tvoj link je 5x optereceniji nego da nemas ogranicenje downloada.

Nasuprot tome, kod uploada je sasvim u redu - prema provajderu ce ici samo onoliko koliko dozvolis, a ici ce 5x od korisnika do mikrotika, sto naravno nije problem jer tu nije usko grlo saobracaja.
[ Branimir Maksimovic @ 12.05.2018. 04:42 ] @
Ma to se resava sa QOS. Stavis nekom veci nekom manji prioritet, a nekom garantovanu brzinu ;)
[ Predrag Supurovic @ 12.05.2018. 06:41 ] @
pctel, to o čemu ti pričaš može da se namesti ali je komplikovano i ima smisla raditi samo u nekim složenijim i važanijim mrežama i sa veoma jakim likovima. Najčešće je skuplja dara nego mera.

Ako ti je potreban QOS (kontroa protoka) onda recimo pre svega ne smeš a dozvoliš da bude povučen maksimalan protok, jer ako se to desi QOS je nemoguće da radi. Uvek mora da ima neka neiskorišćena rezerva. Kod malih mreža praktično nemaš prostora za tu rezervu tako da i QOS može da bude samo jednostavan i svodio se na to da korisnicima ograničič koliko mogu da povuku, eventualno staviš neke prioritete među njima za slučaj da baš počnu da se kolju oko protoka i to je to.
[ calexx @ 12.05.2018. 09:56 ] @
Da li nisam razumeo pitanje ili ostatak diskusije? Potrebno je da se nekim korisnicima ograniči brzina da bi ostali imali koliko je potrebno. Ako se njima pusti sve što dolazi od provajdera, možda ostali, važniji, nemaju ništa. Imaš neke pare, ukućani traže, ti im daš sve što imaš i posle toga nema ni za buđav lebac ni za struju.
[ Mile-Lile @ 12.05.2018. 11:47 ] @
shvatio je pctel samo se se to ne uklapa u njegove planove i želje...

Citat:
pctel: Ako moze neko da mi objasni - koji je smisao ogranicavanja downlink brzine na mikrotiku? Na mikrotiku ne mozes da ogranicavas sta ce provajder da salje ka mikrotiku, znaci u interesu ti je da uzmes sve sto je poslao



evo imaš ovde... u prvih par poglavlja ćeš naći odrgovor...
https://mikrotik.com/testdocs/ros/2.9/root/queue.php

[ producer011 @ 12.05.2018. 14:47 ] @
cackao sam malo po netu i skapirao da postoji mogucnost da se blokiraju ip adrese koje su rucno unete a ne dodeljene od dhcp-a, sto bi dosta resilo problem!
[ gilopile @ 12.05.2018. 14:56 ] @
Ti bi da ogranicis samo neke na tom Wlan-u ili komplet svi koji se kace?

Ako mislis komplet, onda jednostavno ubacis interface Wlan u quene. Ako hoces samo neke, onda uzmi IP koji dodeli DHCP ponaosob od svakog i ubacis u Quene. Trebalo bi IP da je uvek rezverisan, tj. da je uvek isti, jer ako se ne varam, neka kalkulacija MAC-a se veze za odredjen IP i uvek ce dodeliti isti klijentu, al to proveri ipak.
[ pctel @ 12.05.2018. 16:58 ] @
Mislim da je pitanje vrlo jednostavno, da li mikrotik moze da naredi provajderu kojom ce brzinom da mu salje koje podatke, ili moze samo da odbije da primi ono sto je brze nego sto mu odgovara?
[ bachi @ 13.05.2018. 07:50 ] @
Ne može da naredi provajderu, a i kako bi i zašto bi?
[ pctel @ 13.05.2018. 08:03 ] @
Ok, ako sto smo to konstatovali, onda mozemo da predjemo na pitanje broj dva - ako provajder salje punu brzinu, da li je u interesu da se sve to preuzme, ili da se 90 posto odbaci kao previse brzo, pa da provajder salje iznova i iznova? Pretpostavljam da ovde ima ljudi koji su zavrsili ETF i potpuno razumeju da saobracaj nije ono sto mikrotik prihvati, vec zbir onoga sto prihvati i odbije. Imam utisak da pojedinci ovde pokusavaju da tvrde da ono sto se odbaci kao previse brzo nekako oslobadja link i povecava mu propusnu moc. Ja sam racunarske mreze polagao pre mnogo godina, pa me ispravite ako je tcp/ip protokol komunikacije u mejuvremenu izmenjen.
[ Branimir Maksimovic @ 13.05.2018. 08:12 ] @
Mislim da tu nema odbijanja nego jednostavno brzina kojom mikrotik vuce ne bude maksimalna. Znaci ako sa limitiom od 3mb povezes 5 korisnika na link od 10mb ako svi povuku svakako da nece svi imati 3mb. Isto tako ako svih 5 vuku manje od 10mb nece biti iscrpljena pipa.
Ono sto nema svrhe je ogranicavati bw pojedinacno na neki maks zato sto recimo u trenutku samo jedan vuce i sto onda ograniciti na 3mb kad moze da vuce 10mb kad niko drugi ne koristi. O tome se radi. Otud prioriteti i QOS.
[ bachi @ 13.05.2018. 08:17 ] @
Tako je, brzina ne bude maksimalna, dakle ne šalje provajder 100Mb/s pa ti onda pola toga bacaš u vodu, već ti od provajdera vučeš onoliko koliko si ograničio, dakle vučeš onoliko koliko ti treba. Dakle, ako je tebi link ka provajderu 100/100Mb, a ti si ograničio da WiFi klijent može da vuče 10/10, kada wifi klijent krene da skida/šalje nešto sa i na Internet i to traje 1 minut na primer, ruter od provajdera ne vuče svih 100Mb i baca 90Mb podataka u vodu tokom te minute, već povlači samo 10Mb.

Mislim, slično kao kad ograničiš brzinu na torrent klijentu.
[ Branimir Maksimovic @ 13.05.2018. 08:51 ] @
Pa da, kako bi provajder inace video kolko si posrkao u toku meseca i ako imas 24/7 upaljene torrente onda te opomene za 'fair use' ;)
[ pctel @ 13.05.2018. 09:21 ] @
Izgleda da sagovornicima koji nisu zavrsili etf dugujem detaljno ali jednostavno objasnjenje - telekomunikacioni signal ne mozes usporiti u smislu u kom mozes naprimer automobilski saobracaj, da postavis rampu na granici i propustas recimo 1 vozilo u minutu. Mozes da postavis rampu, ali sve sto ne propustis u momentu pristizanja ce se vec sledeceg trenutka samounistiti. Ne mozes nikako da ostavis signal da ceka a red ispred mikrotika Da li se slazemo oko toga?

Ako se slazemo, onda sledece - svaki paket koji ne stigne do korisnika se salje ponovo. A. Ko ne stigne ni iz drugog pokusaja, onda ide treci put. I tako dalje do n-tog pokusaja, kada protokol konstatuje da upornost ne pomaze i odustaje od daljeg pokusavanja.

Kako bi to u praksi izgledalo - provajde posalje 10mb paketa podataka, mikrotik propusti koliko mu je podeseno, naprimer 1 mb paketa. Provajder konstatuje da 9 mb paketa nije primljeno i salje ih opet. Mikrotik opet propusti 1mb paketa. Provajder posalje ponovo 7mb.... Pa u sledecem koraku 6mb... Pa 5... I tako dalje dok ne posalje sve sto je trazeno.

Rezultat toga, ogranicavanje je dovelo do 10+9+8+7+6+5+4+3+2+1=55 mb paketa saobracaja, umesto 10mb koliko bi se prenelo bez ogranicenja. Jedino sto se postiglo je ogranicenje brzine od mikrotika do korisnika, ali kome to treba kad je na stetu komunikacije izmedju mikrotika i provajdera?

Bachi, negde u secanju imam da si ti zavrsio ETF ne tako davno, pa sigurno mozes da mi ukazes gde tacno pravim gresku, ako je pravim. Vas dvojica dakle tvrdite da na mikrotiku podesavate koliko ce paketa provajder da posalje, a ne koliko ce mikrotik da prihvati?
[ Branimir Maksimovic @ 13.05.2018. 09:36 ] @
Ne ide to tako. Sa nivoa protokola nema nikakav retry, niti provajder salje bilo sta sto niko nije poslao. Slanje i prijem paketa se uvek odvija maksimalnom brzinom, a limit se pravi tako sto se meri koliko je podataka poslato u jedinici vremena pa se throtluje.
[ bachi @ 13.05.2018. 10:07 ] @
Nisam ja završio ETF, a ti izgleda link od provajdera zamišljaš kao crevo kroz koje non stop teče voda i gde nema nikakvih ventila koji mogu da uspore taj protok ili zaustave, već da voda neprekidno teče kao česma na izvoru, a ti onda sipaš koliko ti treba, dok ostalo ide u odvod.

https://en.wikipedia.org/wiki/Traffic_shaping
[ pctel @ 13.05.2018. 10:23 ] @
Bachi, evo i na tom linku se pominje da se to radi kontrolom brzine slanja a ne prijema.

Branislave, hoces da kazes da se na brzinu downloada isto utice regulisanjem brzine uploada? To mi je logicno - sve sto je od provajdera krenulo uzmes, ali onda umanjis slanje tcp/ip paketa prema provajderu i tako postignes da provajder manje salje tebi? To sam i ja isto nasao kao jedino resenje dok sam eksperimentisao sa tim.
[ Branimir Maksimovic @ 13.05.2018. 10:28 ] @
Hocu da kazem da provajder mora da throtluje softverski posto nema drugog nacina da ogranicis brzinu. Recimo kod kablovskih modema to trotlovanje je u samom modemu pa ako haknes modem mozes imati maksimalnu brzinu koju imas na linku ;0)
[ bachi @ 13.05.2018. 10:30 ] @
Ruter ima dva interfejsa, dakle kontrola brzine slanja ka uređaju koji je na lan interfejsu rutera efektivno utiče na brzinu downloada tog uređaja u lanu, dok brzinom slanja ka provajderu efektivno utiče na brzinu uploada tog uređaja u LANu.

Ali ima više algoritama i načina implementacije ograničavanja saobraćaja, jedan od njih je dummynet pipe - http://info.iet.unipi.it/~luigi/dummynet/
[ Predrag Supurovic @ 14.05.2018. 08:48 ] @
I slannje i preuzimanej podataka preko linka je proces koji iam dva kraja (izvor i odredišta) i oba onautiču na brzinu.
Ne teba to međati sa fizičkom brzinom protoka koji omogućava link.

Kada uzmeš optički link, fizička brzina protoka kroz njega uvek ide maksikmalnom brzinom linka, (što može da bude u Gbps ili Tbps) ali svejedno ti podatke nećeš dobiti tom brzinom nego onom koju si platio. Isto tako i ti tu brzinu koju dobijap od provajdera (a ne fizičku brzinu linka ka provajderu) možeš da podeliš dvojim lokalnim korisnicima, kako kome.

Kakose to radi? Pa na primer najbanalnije je namernom zadrškom paketa.
[ pctel @ 14.05.2018. 09:31 ] @
Citat:
Kada uzmeš optički link, fizička brzina protoka kroz njega uvek ide maksikmalnom brzinom linka, (što može da bude u Gbps ili Tbps) ali svejedno ti podatke nećeš dobiti tom brzinom nego onom koju si platio.

Predraze, ja sam svojevremeno upravo suprotan problem, pa mozda zato moje pitanje deluje cudno onima koji se sa tim nikada nisu sreli - bio je uplacen maksimalni paket kod provajdera, ali su stare bakarne parice bile usko grlo. Tu je fizicka brzina prenosa bila jednaka ili manja od brzine dozvoljene kod provajdera. Zato je meni bilo u interesu da sve sto dodje do rutera preuzmem i distribuiram racunarima, kako ne bi bezveze doslo do istog saobracaja dvaput ili vise puta, jer je primitivna tehnologija za ogranicenje downloada u to vreme radila tako, ne znam da li je danas bolje. A podelu linka po racunarima sam radio tako sto racunarima ogranicim koliko podataka mogu da posalju prema provajderu, pa sto manje posalju, manje i dobiju. Ali, tu sam onda imao problem sto naprimer youtube sa vrlo malim uploadom generise ogroman download, pa ako ne ogranicim download imam veliki saobracaj, a ako ga ogranicim imam jos veci zbog gubitka paketa i ponovnog transfera istih.
[ Doktor Hlad @ 14.05.2018. 09:40 ] @
Citat:
bachi:
Tako je, brzina ne bude maksimalna, dakle ne šalje provajder 100Mb/s pa ti onda pola toga bacaš u vodu, već ti od provajdera vučeš onoliko koliko si ograničio, dakle vučeš onoliko koliko ti treba. Dakle, ako je tebi link ka provajderu 100/100Mb, a ti si ograničio da WiFi klijent može da vuče 10/10, kada wifi klijent krene da skida/šalje nešto sa i na Internet i to traje 1 minut na primer, ruter od provajdera ne vuče svih 100Mb i baca 90Mb podataka u vodu tokom te minute, već povlači samo 10Mb.


Uh, nikako. Procitaj de malo o mreznoj komunikaciji pre nego sto izjavis ovako nesto :)

Zadatak svakog mreznog uredjaja bilo na L2 ili L3 nivou je da kada mu paket stigne na ulaz: da ga se resi sto pre!

Ako se to ima u vidu onda se lako dolazi do zakljucka da brzinu downloada (ako gledamo sa strane krajnjeg korisnika) odredjuje onaj ko podatke salje plus svi ostali mrezni uredjaji izmedju. Znaci, ako neki udaljeni server salje brzinom 100Mbit/s i svi tranzitni mrezni uredjaji mogu tom brzinom da prebacuju pakete onda do korisnikovog uredjaja paketi stizu tom brzinom.

Najcesci nacin je upravo onaj koji si opisao: drop. Dakle, sve sto je visak baca se u vodu i onda druga strana salje ponovo. To kod UDP-a ili ICMP-a moze da bude problem jer drugu stranu bas zabole da li je stigao ili nije pa nece nista da salje ponovo. Zato se uglavnom takvom saobracaju daje najveci prioritet kako npr VoIP ne bi trpeo ili neki watchdog procesi koji se oslanjaju na ICMP.
[ bmarkovic06 @ 14.05.2018. 09:52 ] @
Aman ljudi o cemu vi to? Ako se podesava ogranicenje brzine na mikrotiku za odredjenog klijenta u lokalnoj mrezi, to nema veze sa brzinom koju vama provajder pruza/ogranicava. A to sad kako cete podesiti ogranicenja itd zavisi od toga sta zelite ograniciti/uraditi.

Kao sto je vec Pedja napisao to se radi najbanalnije moguce, zadrzavanjem paketa. Medjutim mikrotik ima nekoliko nacina ogranicavanja a najvise se koristi FIFO sistem.
[ Predrag Supurovic @ 14.05.2018. 09:52 ] @
Citat:
pctel:
Citat:
Kada uzmeš optički link, fizička brzina protoka kroz njega uvek ide maksikmalnom brzinom linka, (što može da bude u Gbps ili Tbps) ali svejedno ti podatke nećeš dobiti tom brzinom nego onom koju si platio.

Predraze, ja sam svojevremeno upravo suprotan problem, pa mozda zato moje pitanje deluje cudno onima koji se sa tim nikada nisu sreli - bio je uplacen maksimalni paket kod provajdera, ali su stare bakarne parice bile usko grlo. Tu je fizicka brzina prenosa bila jednaka ili manja od brzine dozvoljene kod provajdera. Zato je meni bilo u interesu da sve sto dodje do rutera preuzmem i distribuiram racunarima, kako ne bi bezveze doslo do istog saobracaja dvaput ili vise puta, jer je primitivna tehnologija za ogranicenje downloada u to vreme radila tako, ne znam da li je danas bolje. A podelu linka po racunarima sam radio tako sto racunarima ogranicim koliko podataka mogu da posalju prema provajderu, pa sto manje posalju, manje i dobiju. Ali, tu sam onda imao problem sto naprimer youtube sa vrlo malim uploadom generise ogroman download, pa ako ne ogranicim download imam veliki saobracaj, a ako ga ogranicim imam jos veci zbog gubitka paketa i ponovnog transfera istih.


Imali smo svojevremeno svi taj problem, neko zato što vod nije mogao a neko zato što je bilo skupo pa smo morali da se dobvijamo sa manjim protokom :)

Gledaj ovako svaki ruter ima bar dva interfejsa, jedan koji se korsiti za WAN i jedan koji se korsiti za LAN. Oba imaju dva queue-a: input i output. Ono sto ne mozes da kontrolises kao input jednog interfejsa mozes da kontrolises kao output drugog interfejsa i obrnuto. Ono što je na računaru u lanu input, to je na ruteru na lan interfejsu output a na wan interfejsu input.

Kao što je internet provadjer tebi dobavljac protoka, tako si i ti dobavljac korisnicima u svojoj mrezi i sve što provadjer može da radi tebi možeš i ti njima :)

Kada ograničavaš brzinu protoka, ne bi trebalo da dolazi do gubitaka paketa, nego samo do njihovog sporijeg protoka, jer inače ništa ne bi imalo smisla. Postoji mogućnost da se na ruteru zaista ograničava broj paketa pa i broj konekcija i tada se zaista gube paketi i konekcije ali to je nešto drugo.
[ Doktor Hlad @ 14.05.2018. 11:07 ] @
Citat:
Predrag Supurovic: Kada ograničavaš brzinu protoka, ne bi trebalo da dolazi do gubitaka paketa, nego samo do njihovog sporijeg protoka


Samo ukoliko je u pitanju TCP.
[ pctel @ 14.05.2018. 14:57 ] @
Citat:
bmarkovic06:
Kao sto je vec Pedja napisao to se radi najbanalnije moguce, zadrzavanjem paketa. Medjutim mikrotik ima nekoliko nacina ogranicavanja a najvise se koristi FIFO sistem.

Mislim da je zadrzavanje kod TCP/IP tesko moguce, tj. moze samo u nekoj minimalnoj meri upravo iz razloga jer ono sto ne stigne na vreme smatra se da nikad nece ni stici i salje se ponovo a to je meni bio veliki problem jer mi je usko grlo linija izmedju provajdera i mikrotika, a ne brzina koja se placa provajderu.

Da li mikrotik moze da primi i potvrdi prijem TCP/IP paketa koji je poslao provajder, pa da ga zadrzi u memoriji i tek nakon toga prosledi korisniku? Mislim da ne moze uopste, a ako i moze pitanje je koliko paketa moze, tj. moze neki vrlo mali broj. Nadam se da se svi slazemo da mikrotik ne moze da postavi rampu na internet saobracaj i uzima po malo, a ostalo da mu stoji ispred i ceka svoj red, to je kod telekomunikacionih signala nemoguce, nego ili preuzimas istog momenta, ili sledeceg momenta taj signal ne postoji. dakle, zadrzavanje je teoretski moguce jedino u sopstvenoj memoriji i ima smisla jedino ako mozes da odgovoris provajderu da si primio paket i da ga ne treba slati ponovo.

Kako mislis da realizujes zadrzavanje, ako provajder nonstop gruva prema meni neki youtube HD video brzinom 10mbps, a ti zelis da mi ogranicis prijem na 1mbps? Ne mozes da uzmes ono sto provajder posalje za minut, pa da mi to polako distribuiras narednih 10 minuta Otprilike jedino sto mozes je da odbacis prebrzih 90% paketa i potom ih primis u jednom od narednih pokusaja, zar ne?
[ bachi @ 15.05.2018. 08:01 ] @
Ako ne može da zadržava pakete, onda ih dropuje i pošto je TCP u pitanju, druga strana zbog toga USPORI slanje tih paketa.

Kad je UDP u pitanju, on nema mogućnost da uspori slanje paketa, jer onaj ko šalje preko UDP pojma nema da li si ti dobio paket ili nisi, tako da tu ide nešto na baferovanje i na dropovanje paketa.

Ali i pokraj toga to ne znači da server gleda da tebi kao korisniku maksimalnom brzinim isporuči pakete odmah ka što neko tvrdi, jer svi rade qos na svojoj strani, kako im jedan korisnik ne bi povukao ceo protok.

U praksi limitiraš na ruteru 90 - 95% od stvarne brzine neta i onda radiš ograničavanje brzine, šejpovanje, itd, a tih 5-10% su međuprostor da se da fore upravo tim UDP paketima.

I naposletku, same aplikacije koje koriste UDP rade neku optimizaciju u brzini slanja samih UDP paketa, jer nema potrebe ako nešto zahteva 1Mb/s protoka ka primaocu, da mu se zatrpa sa 100Mb/s podataka. Tako recimo torrent klijent iako koristi UDP većinom za p2p komunikaciju, uspešno ograničava brzinu slanja preko same aplikacije (ukoliko ti tako želiš, a želiš).
[ pctel @ 15.05.2018. 08:58 ] @
Citat:
USPORI slanje tih paketa

E, zaustavi se sad tu gde si... Mislim da se na nivou TCP/IP protokola ne pravi razika izmedju aplikacija koje su poslale zahtev. Znaci, imas ruter sa IP adresom kod sebe i slican takav mrezni uredjaj na strani provajdera. Ukoliko se ucestalo javlja DROP, tada ce TCP/IP oboriti brzinu celokupne komunikacije ka tvom ruteru a ne odredjenog racunara u lokalnoj mrezi ili odredjene aplikacije na tom racunaru, zar ne? Treba li da objasnjavam zasto je to kontraproduktivno?

Konkretno, u vreme kad sam se ja sa time zlopatio, brzine su bile dosta manje od danasnjih, pa sam imao zadatak da propusnu moc starih bakarnih parica od prosecno 5mbps sto bolje razdelim na 15 racunara, tako da svaki moze da koristi browser i povremeno skype. Problem je pravio youtube, jer kad ga neko otvori na svom racunaru, tako drugima skype pocinje da stuca. I ja eksperimentalno probam da svima ogranicim download na ~300kbps, i stvarno ovome sa youtubom video sporije stize, ali se internet veza ne rastereti i ne popravi se rad Skype-a, jer sve sto je ruter radio, radio je drop suvisnog saobracaja
Eksperiment je pokazao da se postigne cak i kontra efekat - zbog dropa se javlja slanje jednog sadrzaja vise puta i ovom skype radi jos losije nego dok ogranicenja downloada uopste nema. Nasuprot tome, ogranicenje uploada savrseno funkcionise, jer lokalna mreza radi na visestruko vecoj brzini i nikakav drop joj ne predstavlja zagusenje.
[ bachi @ 15.05.2018. 10:08 ] @
Usporiće se brzina te TCP/IP sesije/konekcije, a ne celokupnog ostalog saobraćaja ka ruteru.

Dakle, ti si radio fiksno obaranje brzina ka korisnicima u LAN mreži, to i ja sad radim za WiFi u firmi, svako dobije po 10/1 brzinu i to radi lepo. Kako su kod tebe bile male brzine, a stavio fiksne brzine, bez prioritizacije samih paketa, odnosno saobraćaja, dobio si to što si dobio. Takođe, nisi ograničio nominalni saobraćaj na 90% do 95% od onog što ti ISP isporučuje, jer Skype koristi UDP.

Dakle, recept je i ograničenje pojedinačne brzine i prioritizacija saobraćaja, generički poznato kao QoS.

Mada sam ja u to vreme problem youtubea rešavao tako što sam ukinuo youtube, sad sa ovolikim downloadom je sve to nebitno, osim prioritizacije uploada.

A postoje i one varijante dinamičke distribucije gde je ukupan protok 10Mb i ako jedan korisnik vuče, dobije 10Mb, ako ih 2, dobiju po 5Mb, ako ih je 10, dobiju po 1Mb, itd.

Dakle, sve u svemu postoji više načina, više raznih algoritama i metoda, to je čitava nauka, a ne znam lično ni 10% od te teorije nego sve što sam radio jeste po trial&error fazonu uz dosta googlovanja.

Sreća pa su linkovi takvi da više i nemam potrebe da se zamajavam sa tim, sem ovo što wifi korisnike ograničavam, a to pfsense i na pojedinim mestima unifi controller rade sasvim lepo.
[ Mile-Lile @ 15.05.2018. 11:21 ] @
@pctel
ti pričaš o "bandwidth limiting"-u a ne o QoS...
QoS radi i bandwidth limiting između ostalog ali primarni zadatak mu je da postigne kvalitet za određeni tip saobraćaja/servisa...
da bi to uradio ruter mora da bude sposoban da prepozna vrstu saobraćaja... to ne može na L3 nivou nego na L7...
u današnje vreme kada se i dns saobraćaj enkriptuje (npr. DnsCrypt) i kada ne prolazi kroz port 53 već kroz 443 kroz koji ide sve maltene, to je3 jako teško...
Mora se raditi DPI (deep packet inspection) i onda na osnovu prepoznatog saobraćaja raditi prioritizacija saobraćaja po klasama...
Nije svakom isti saobraćaj prioritetan... Ali kada taka nešto ne bi postojalo ljudi ne bi mogli da koriste servise kao što je VOIP u mrežama gde posotji gomila drugog saobraćaja...

kada se saobraćaj prepozna i razvrsta po klasama QoS npr. 4 klase da bi bilo lakše:

klasa 1. sa max prioritetom:
dns
dhcp
ntp
ssdp
icmp

klasa 2. sa premium prioritetom:
VOIP

klasa 3. sa standard prioritetom
http
https
ssl

klasa 4. sa bulk prioritetom
youtube
torrent

onda QoS radi "bandwidth limiting":

prva klasa dobija 40% propusne moći linka
druga klasa dobija 30% propusne moći linka
treća klasa dobija 20% propusne moći linka
četvrta klasa 10% propusne moći lnika

samo dok ne potekne saobraćaj kroz lulicu.
Ruter, ako je ukupan link 100Mbps, ograniči torrent (klasa 4.) na 10Mbps... dropuje 90% zahteva za saobraćaj koji torrent klasa 4. šalje ka provajderu. Provajder šalje samo tih 10Mbps ka klasi 4. tako da ostaje dovoljno mesta za ostale klase...
e, sad da se vratim na "samo dok ne potekne saobraćaj kroz lulicu". Kad potekne sve vreme se rade jako složene kalkulacije, tipa koje su sve klase aktivne... ako nemaš ni jednu app iz prve tri klase torrenti će moći da povuku 100% linka...
tvoje pitanje zašto se ograničava DL na ruteru je zato što ruter ne zna koliki je tebi link... to je promenljiva složićeš se? Danas imaš jedan pake sutra zakupiš drugi... Ruter mora da zna kolika je propusna moć linka da bi ga mogao podeliti po klasama kada su sve klase na mreži...
prosto tako je u kodu... nije još smišljeno nešto pametnije...

+ postoji tu još gomila sitnica, bufferbloat u mreži zbog retransmisija o kojima si pričao i o kojima je pričao bachi (kod UDP), prioritizacija sitnih paketa, ograničavanje broja konkuretnih konekcija algoritmi razni itd... QoS na linuxu (routeros) je jako kompleksan.... Ali mora se ograničavati DL... nije to nikakvo bacanje jer ne znam šta ti znači da imaš link koji je npr. nekom gejmeru neupotrebljiv...

ja volim da posle podešavanja QoS uradim ovaj test http://www.dslreports.com/speedtest

znači rezultati su mi katastrofa bez QoS-a... nisam kod kuće ali ako stignem večeras okačiću rezultate sa i bez QoS...

inače stalno koristim QoS kod kuće jer sam na adslu-u... paket mi je 10/1Mbps i kad klinci uključe hbogo ili eon slikam se kad nemam QoS...








[ pctel @ 15.05.2018. 14:34 ] @
Citat:
@pctel
ti pričaš o "bandwidth limiting"-u a ne o QoS...

Da. Prvi razlog je sto se tema tako zove :)
Drugi je sto ja nisak nisam imao prilike da konfigurisem QoS, mreze su mi bile usputni posao. Teorije se jos jedva pomalo secam, QoS treba da bude dogovoren i implementiran identicno sa obe strane, je li tako? Inace, malo postizes ako si ti youtube-u dodelio najnizi prioritet, a provajder gruva te pakete prema tebi najvisim prioritetom :D

Dodatni razlog zasto ja nisam bio u prilici da koristim QoS je sto fizicka propusna moc bakarnih parica nije konstanta, vec ti zakupis kod provajdera naprimer 8mbps, a bakarne parice mogu da propuste od 3 do 10, zavisno kako u kom trenutku. Tu ne dobijas bog zna kakav rezultat ako ogranicis saobracaj na 90-95% od tih 8mbps, realno bi mogao nesto postici ako ogranicis na 30%, ali to je vec kontraproduktivno. Bilo kako bilo, proslo je oko deceniju od kad sam se ja zlopatio sa time i sada su i mrezni hardver i softver i veze sa provajderom sigurno na nekom visem nivou. Eventualno bi trebalo pokretaca teme pitati da li je kod njega usko grlo fizicka veza sa provajderom, ili uplacena sirina propusnog opsega, jer od toga zavisi da li je dropovanje paketa problem ili nije.

Da li na svakom jeftinijem ruteru funkcionise QoS i prepoznavanje tipa saobracaja, naprimer na onim Tenda i TPlink ruterima koji su najcesce u upotrebi, ili je to odlika skupljih uredjaja?
[ bachi @ 15.05.2018. 19:15 ] @
Koliko se sećam, kod jeftinih rutera imaš samo da ograničiš brzinu na pojedinu IP adresu ili pojedine IP adrese i da prioritizuješ saobraćaj po portovima (i to nemaju svi modeli). Tako da ako staviš najniži prioriter na sve portove iznad 1024, za kućne korisnike je to i više nego dovoljno, jer se tako smanjuje silovanje p2p klijenata poput torrenata, dok surf onda ide neometano.

Ali na skupljim modelima (može i tplink pa da se stavi openwrt/lede, on ima dodatni paket za QoS, ali je komplikovano za podešavanje za kućne korisnike) se nalazi upravo sve ono što smo pisali i što se Mile potrudio lepo da objasni (svaka čast).
[ Mile-Lile @ 16.05.2018. 07:27 ] @
@pctel
podešavanje QoS na obe strane (provajder-korisnik) o kome pričaš, postoji... viđao sam po ruterima/modemima da ga zovu ATM QoS i imaš opcije UBR/CBR i tako dalje... (ovo pričam za ADSL jer sam se sa tim susretao za optiku sam samo čuo:) )
koliko sam shvatio kada sam čitao o tome on služi da ako imaš IPTV i Internet da zagarantuje protok IPTV-u... za Internet dobiješ ono što se zove "best effort"...
ali u tome i jeste poenta da ti kod sebe na svom ruteru to što dođe do tebe iskoristiš što bolje... Ako je problem u ISP-u ti to ne možeš rešiti...
Ruteri su se nekad pravili sa jako malo memorije i tu nije bilo mesta za QoS... prosto nije bilo potrebe...
danas se situacija menja i kućni SOHO (Small Office Home Office) ruteri sve više liče na linux servere koji služe za administraciju... pa tako imaju moćne firewall-ove, pa dva-tri USB porta 2.0 ili čak 3.0 sa kojima možeš da radiš SAMBA share,
NAS, OpenVPN, Hotspot-ove i svašta nešto... nejjeftiniji modeli to nemaju... Kada kod nas svaku druga kuća bude dobila optiku i mi ćemo razmišljati o kupovini takvih uređaja...
Na stranim forumima ako nemaš Dual Core CPU u ruteru maltene neće da pričaju sa tobom :)




@Bachi,

baci pogled na SQM paket na OpenWRT...

Code:
opkg update
opkg install luci kmod-sched-cake luci-app-sqm


nakona par sekundi posle instalacije pojaviće si se u GUI-ju...
bukvalno te vodi da izabereš koju vrstu linije imaš i objašnjava ti da uneseš vrednosti linka... uz par klikova je gotovo. Pa ako stigneš prenesi utiske...
[ bachi @ 16.05.2018. 17:18 ] @
E super, nisam znao da ima dodatak za LUCI. 10x, pogledaću.
[ Mile-Lile @ 16.05.2018. 20:21 ] @
link ADSL 10/1 Mbps (izvlačim oko 9/0,85 Mbps ali kad skidam neki linux ISO)

bez QoS



sa QoS (ograničeno na 7700/700 kbps)



malo pre testirano.
OpenWRT sa tzv. "piece of cake" skriptom na tp link 740n (najjeftiniji ruter na našem tržištu)...
[ bachi @ 17.05.2018. 07:29 ] @
delete_me