Avaleht
uus teema   vasta Hinnavaatlus »  Andmeside ja kõnelevi »  traffic shaper koju, tööle.. märgi kõik teemad loetuks
märgi mitteloetuks
vaata eelmist teemat :: vaata järgmist teemat
mine lehele eelmine  1, 2
Hinnavaatlus :: Foorum :: Uudised :: Ärifoorumid :: HV F1 ennustusvõistlus :: Pangalink :: Telekavad :: HV toote otsing
autor
sõnum Saada viide sõbrale. Teata moderaatorile
otsing:  
KrikU
HV veteran
KrikU

liitunud: 14.12.2001




sõnum 29.09.2005 19:41:47 vasta tsitaadiga

Ma jõudsin selleni kunagi välja, et HTB on vaja tööle saada... see tahtis kerneli uuesti kompilleerimist, ei mäletagi mille taha jäi see asi...
Kommentaarid: 129 loe/lisa Kasutajad arvavad:  :: 0 :: 0 :: 119
tagasi üles
vaata kasutaja infot saada privaatsõnum mine selle kasutaja kodulehele
JanQ
HV kasutaja

liitunud: 04.07.2002




sõnum 29.09.2005 19:47:46 vasta tsitaadiga

Paar enda kogemust.
P166 32MB mälu, 16MB Compact Flash, Linux Bering. Kernel oma järgi kompileeritud.
Scriptid nii üles kui allalaadimise piiramiseks, portide kaupa eraldi.
Koduses ja jagatud võrgus 4 masinat, mitte keegi pole kaevanud, kuigi pidevalt tõmmmatakse.
Enne päris tõõteviimist tegin katseid, ühendasin 5 masinat taha, kõikidel P2P käima
ip connectide arv oli üle 4000. Proovisin samal ajal ftpd, webi ja üleslaadimist. Sai normaalselt hakkama...
Nii et mängimisruumi on küllalt, vaja ainult mõnda aega netis istuda ja manuaale lugeda, siis miks mitte
ka mitme masinaga reaalselt proovida kas tootab ja kui vaja kohendada.
Kommentaarid: 48 loe/lisa Kasutajad arvavad:  :: 0 :: 0 :: 46
tagasi üles
vaata kasutaja infot saada privaatsõnum
wookie
HV kasutaja
wookie

liitunud: 08.08.2005




sõnum 29.09.2005 21:34:48 vasta tsitaadiga

Supiplex kirjutas:
tsitaat:
Jah, saab.
Samas, seni kuni Sa rakendad QoS'i seda ainult enda poolses otsas ning ISP pool on ikka FIFO scheduler, ei saa see QoS ühelgi juhul olla kuigi efektiivne, tehtagu seda siis millega tahes.

Ma vaidleks vastu...

Oleneb loomulikult, mida sa loed efektiivsuseks. Üldiselt on TCP voojuhtimine niivõrd küps asi, et ACK pakettide kinnihoidmisega annab üpris edukalt vastuvõtja poolelt QoS-i teha. Saatja võtab reeglina paari sekundiga kiiruse maha nii, nagu vastuvõtjale sobib. Kui FTP & sõprade riba kusagile 80-90% peale piirata ja väljaminevate pakettide seas kiireloomulised tegelased ette lasta, siis jääb u. 80-90% UDP pakettide viide väga ilusaks. Eks ta natuke ümber nurga ja vindiga käib, aga keskmise mänguri jaoks kõlbab see kenasti. Katsetatud, töötab. Mmm, jagatud internet koos korraliku QoS-iga ruuteris on nirvaanalähedane icon_smile.gif


Jah täpselt nii seda tehaksegi ning täpselt sellel samal põhjusel, et me hoiame kinni ACK pakette, lootes, et teine pool selle peale vaiksemaks võtab (tavaliselt võtab), ongi asi ebaefektiivne ning sarnaneb hammaste parandamisele läbi urruaugu.

Mitte kunagi ei saa teada, kui agressiivselt peaks ACK pakette kinni hoidma, samuti mitte kunagi ei saa teada, kui palju tähtsat liiklust meile tegelikult tahab sisse tulla, mistõttu ei saa tegelik ribalaius kunagi kuigi efektiivselt ära kasutatud ning kunagi ei saa olla veendunud, et meie QoS iga ilmaga toimib.

Eriti vahvaks läheb asi aga siis, kui me arvestame, et TCP ei pruugi olla ainuke suure liiklusmahuga protokoll. Mis saab juhul, kui selle ühenduse sees käib mõni vahva VPN? Reeglina ei jooksuta mõistlikud inimesed VPN'e TCP sees.

Kokkuvõtteks, väga palju lihtsam ja töökindlam, kui hakata Ulmelist Keemiat[tm] aretama, on lasta ISP'l paika panna vastavad QoS reeglid meile sisse tuleva liikluse jaoks ning ise seadistada QoS reeglid meilt väljuva liikluse tarbeks. Tulemuseks saavad reeglid, mis on suhteliselt lihtsad, konkreetsed ning ilma suurema vaevata hallatavad - Keep It Simple.

P.S (TCP rate controli kohta).
Tõesti.. mänguri jaoks käib küll, produktsiooni ma niisuguse lahendusega minna ei julgeks.
Kommentaarid: 11 loe/lisa Kasutajad arvavad:  :: 0 :: 0 :: 11
tagasi üles
vaata kasutaja infot saada privaatsõnum
taifunk
HV Guru
taifunk

liitunud: 06.01.2005



Autoriseeritud ID-kaardiga

sõnum 29.09.2005 21:35:07 vasta tsitaadiga

tsitaat:

Kokkuvõtteks, väga palju lihtsam ja töökindlam, kui hakata Ulmelist Keemiat[tm] aretama, on lasta ISP'l paika panna vastavad QoS reeglid meile sisse tuleva liikluse jaoks ning ise seadistada QoS reeglid meilt väljuva liikluse tarbeks. Tulemuseks saavad reeglid, mis on suhteliselt lihtsad, konkreetsed ning ilma suurema vaevata hallatavad - Keep It Simple


Kas see eeldab ka miskit kangemat paketti ISPlt, mingeid lisatasusid või piisab ka lihtsalt kokkuleppele jõudmisest?


(Eks see olene ka ISPst kuid nii üldiselt võttes)

_________________
Remember this day, men, for it will be yours for all time.
Kommentaarid: 45 loe/lisa Kasutajad arvavad:  :: 3 :: 5 :: 36
tagasi üles
vaata kasutaja infot saada privaatsõnum
wookie
HV kasutaja
wookie

liitunud: 08.08.2005




sõnum 29.09.2005 21:55:11 vasta tsitaadiga

taifunk kirjutas:

Kas see eeldab ka miskit kangemat paketti ISPlt, mingeid lisatasusid või piisab ka lihtsalt kokkuleppele jõudmisest?


Loogiline on, et ISP'd viitsivad pakkuda erilahendusi valdavalt ärikasutajatele. Oleks naiivne, mingilt kodus kannimise paketilt, hinnaga sada krooni kuus, loota mingeid standardkonfiguratsioonist erinevaid lahendusi.
Samuti, on täiesti loomulik, et teenus maksab ning ISP poolne QoS on teenus.
Seega ongi nõnda, et saja krooni eest koduinternetti tarbivad tegelased võivad selleks, et mäng mõnusalt jookseks, piirata ACK'de arvu ajaühikus või teha muid imetrikke, leppides, et saadav tulemus ei ole ehk kõige efektiivsem (lihtsam oleks mängu ajaks muud aplikatsioonid ehk sulgeda?). Ärikasutajad, kellele jaoks on QoS ühel või teisel põhjusel oluline, lepivad ISP'ga vastavalt kokku, vajadusel maksavad teenuse eest ning tunnevad end hästi.
Niisugust asja nagu tasuta, kõike ja rohkem ning värvilisemalt, lihtsalt ei eksisteeri.

Teisalt, ma ei välista, et mõne ISP puhul võib ka tavaline kodukasutaja vastavate teenuste osas kokkuleppele saada.
Kommentaarid: 11 loe/lisa Kasutajad arvavad:  :: 0 :: 0 :: 11
tagasi üles
vaata kasutaja infot saada privaatsõnum
Supiplex
HV veteran
Supiplex

liitunud: 11.12.2002




sõnum 30.09.2005 09:20:30 vasta tsitaadiga

Kõik alljärgnev jutt on kodukasutaja vajadusi silmas pidades.

Sa oled ülearu pessimistlik.

wookie kirjutas:
Jah täpselt nii seda tehaksegi ning täpselt sellel samal põhjusel, et me hoiame kinni ACK pakette, lootes, et teine pool selle peale vaiksemaks võtab (tavaliselt võtab), ongi asi ebaefektiivne ning sarnaneb hammaste parandamisele läbi urruaugu.


Reaalsuses on TCP puhul asi üpris OK. Kui eesmärgiks on mingitele teenustele kindlaid parameetreid garanteerida (viide, läbilaskevõime, misiganes) siis on kliendipoolne QoS kodukasutaja jaoks väga kasulik nähtus. Töötab piisavalt hästi, et end õigustada.

Vaat UDP puhul võivad asjad kahtlaseks minna. Seal pole voojuhtimist protokolli sisse ehitatud ja nii saab kehvavõitu saatev rakendus sigatseda... A sellega peavad UDP kasutajad arvestama.

tsitaat:
Mitte kunagi ei saa teada, kui agressiivselt peaks ACK pakette kinni hoidma, samuti mitte kunagi ei saa teada, kui palju tähtsat liiklust meile tegelikult tahab sisse tulla, mistõttu ei saa tegelik ribalaius kunagi kuigi efektiivselt ära kasutatud ning kunagi ei saa olla veendunud, et meie QoS iga ilmaga toimib.


Automaatikud ja süsteemiteoreetikud peaksid siinkohal ehk pika loengu maha, aga minu teada pole hilistatud tagasisidega süsteemi juhtimine mingi eriline kunsttükk. 100% efektiivsust pole lihtsalt vaja, on vaja et SSH töötaks ja surfata saaks ja mängida saaks, sellal kui filme, mänge ja pornot tiritakse.

tsitaat:
Eriti vahvaks läheb asi aga siis, kui me arvestame, et TCP ei pruugi olla ainuke suure liiklusmahuga protokoll. Mis saab juhul, kui selle ühenduse sees käib mõni vahva VPN? Reeglina ei jooksuta mõistlikud inimesed VPN'e TCP sees.


Seda ei oska ma kommenteerida, pole olnud vajadust VPN-i teha. A universaalne rohi on ikkagi lihtne - FTP-l ja P2P-l lihtsalt kõri koomale tõmmata ja kõik asjad töötavad paremini icon_smile.gif

Kui ma õieti mäletan, siis vähemasti Linuxi QoS ei olnud transportkihi protokollist sõltuv. Eks see teeb interfeissi keerulisemaks kah, aga tegelikult käis otsuste langetamine IP päiste järgi - bitmaskimine väljade kaupa. Võta siis milline protokoll tahad. Ja keerulisemate asjade jaoks tulevad iptables reeglid appi, sellega võid seitse ilmaimet korda saata.

tsitaat:
Kokkuvõtteks, väga palju lihtsam ja töökindlam, kui hakata Ulmelist Keemiat[tm] aretama, on lasta ISP'l paika panna vastavad QoS reeglid meile sisse tuleva liikluse jaoks ning ise seadistada QoS reeglid meilt väljuva liikluse tarbeks. Tulemuseks saavad reeglid, mis on suhteliselt lihtsad, konkreetsed ning ilma suurema vaevata hallatavad - Keep It Simple.


Kelle jaoks Ulmeline Keemia[tm], kelle jaoks töötav lahendus.

tsitaat:
P.S (TCP rate controli kohta).
Tõesti.. mänguri jaoks käib küll, produktsiooni ma niisuguse lahendusega minna ei julgeks.


Aga sa proovi, ehk leiad meeldivaid üllatusi ...

_________________
The young lady had an unusual list,
Linked in part to a structural weakness.
She set no preconditions.
Kommentaarid: 38 loe/lisa Kasutajad arvavad:  :: 0 :: 1 :: 34
tagasi üles
vaata kasutaja infot saada privaatsõnum
KrikU
HV veteran
KrikU

liitunud: 14.12.2001




sõnum 20.10.2005 12:43:41 vasta tsitaadiga

Olen praeguseks saanud asja käima: http://www.tldp.org/HOWTO/ADSL-Bandwidth-Management-HOWTO/implementation.html

Ja töötabki nüüd, peale mitmeid kerneli patchimisi/confi muutmisi thumbs_up.gif thumbs_up.gif thumbs_up.gif
Päris rahul olen icon_biggrin.gif Aga alati tahaks veel rohkem icon_lol.gif

Ja siin ta on, järgmine goal:

http://www.adsl-optimizer.dk/

Kuri projekt thumbs_up.gif Tasub seda pikka pdf faili 'thesis' lugeda. Igaljuhul see on lahendus mis arvestab ka ADSL-i ATM kihi overheadi ja värki nii bridged kui routed ja PPoE ühenduse puhul. Samas on jube segane selle softi realiseerimine, pole ühtset script faili, vaid configud on laiali ja minu jaoks veel veidi arusaamatud icon_confused.gif thumbs_down.gif Eriti kui sooviks veel selle häid omadusi (overheadi arvestamine, ACK pakettidele kindla riba jätmine uploadi kanalis täiskiirusega downloadimiseks jne.) ühildada praeguse configa, muutes siis omale vastavalt ainult prioriteete ja iptablesiga pakettide märkimist. Selle optimizeriga on väga service haaval kogu asi tehtud... tahaks ikka portide gruppe määratleda erinevate prioriteetidega...
Keegi targem võib veel kommenteerida seda ülal antud linki/saiti icon_idea.gif 8)

Üldse võiks linuxi teemas ka siia teema viide olla, või siis kogu see teema viia üles linuxi foorumisse...
Kommentaarid: 129 loe/lisa Kasutajad arvavad:  :: 0 :: 0 :: 119
tagasi üles
vaata kasutaja infot saada privaatsõnum mine selle kasutaja kodulehele
jurabaz
HV vaatleja

liitunud: 19.01.2005




sõnum 30.03.2006 17:28:27 vasta tsitaadiga

Raagin oma praktikast.
Mul on Elioni kodu3 2048/256 kbit/sec ADSL yhendus.
Tehtud shaper selle moodi:
http://www.tldp.org/HOWTO/ADSL-Bandwidth-Management-HOWTO/implementation.html

Uploadi kiiruse limit panin 150kbit/sec. Sellega ping ei t6use rohkem, kui 80msec.
Kui paned rohkem, m6nikord ping t6useb 200-300 - ni.

Kompileerisin ara kernel ja iptables http://www.adsl-optimizer.dk patchidega.

nüüd ping ei t6use rohkem, kui 80msec juba 200mbit/sec uploadi limiigida.
tagasi üles
vaata kasutaja infot saada privaatsõnum
näita postitusi alates eelmisest:   
uus teema   vasta Hinnavaatlus »  Andmeside ja kõnelevi »  traffic shaper koju, tööle.. mine lehele eelmine  1, 2
[vaata eelmist teemat] [vaata järgmist teemat]
 lisa lemmikuks
näita foorumit:  
 ignoreeri teemat 
sa ei või postitada uusi teemasid siia foorumisse
sa ei või vastata selle foorumi teemadele
sa ei või muuta oma postitusi selles foorumis
sa ei või kustutada oma postitusi selles foorumis
sa ei või vastata küsitlustele selles foorumis
sa ei saa lisada manuseid selles foorumis
sa võid manuseid alla laadida selles foorumis



Hinnavaatlus ei vastuta foorumis tehtud postituste eest.