praegune kellaaeg 17.06.2024 04:08:45
|
Hinnavaatlus
:: Foorum
:: Uudised
:: Ärifoorumid
:: HV F1 ennustusvõistlus
:: Pangalink
:: Telekavad
:: HV toote otsing
|
|
autor |
sõnum |
|
KrikU
HV veteran
liitunud: 14.12.2001
|
29.09.2005 19:41:47
|
|
|
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 |
|
|
JanQ
HV kasutaja
liitunud: 04.07.2002
|
29.09.2005 19:47:46
|
|
|
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 |
|
|
wookie
HV kasutaja
liitunud: 08.08.2005
|
29.09.2005 21:34:48
|
|
|
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 |
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 |
|
|
taifunk
HV Guru
liitunud: 06.01.2005
|
29.09.2005 21:35:07
|
|
|
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 |
|
|
wookie
HV kasutaja
liitunud: 08.08.2005
|
29.09.2005 21:55:11
|
|
|
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 |
|
|
Supiplex
HV veteran
liitunud: 11.12.2002
|
30.09.2005 09:20:30
|
|
|
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
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 |
|
|
KrikU
HV veteran
liitunud: 14.12.2001
|
20.10.2005 12:43:41
|
|
|
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
Päris rahul olen Aga alati tahaks veel rohkem
Ja siin ta on, järgmine goal:
http://www.adsl-optimizer.dk/
Kuri projekt 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 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 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 |
|
|
jurabaz
HV vaatleja
liitunud: 19.01.2005
|
|
tagasi üles |
|
|
|
lisa lemmikuks |
|
|
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.
|