tfbilly (13.2.2007 12:46:12)
Vím že už se to tu několikrát řešilo, ale zajímalo by mě jaká je opravdu nejvhodnější hodnota MTU (ČRa). Vím přesně co to je, ale jde mi o to, že jsem slyšel od techniků několik variant a pokaždé to byla jiná hodnota. 1 technik - 1400 (od O2) 2. technik - 1500 což je standartní nastavení (ČRa) 3. Jsem zde četl, že maximální hodnota je 1500-8= 1492 Jak to tedy je? Prosím o radu někoho zkušeného, díky.
Anonym (13.2.2007 13:34:02)
1500 1500-8 je hodnota ICMP protokolu PING bez hlavičky (proto -8)
tfbilly (13.2.2007 16:11:48)
o.k. díky moc, měl jsem v tom zmatek když jsem slyšel z každý strany jiný číslo :-) díky
Anonym (13.3.2007 12:15:22)
ale stejne to nevysvetluje co mame u adsl pouzivat.. spis jen chodite okoro horke kase :) takze 1492 nebo 1500?
Anonym (13.3.2007 13:06:54)
Viz 14. února 2007 v 01:23. Správná odpověď je 1492 a méně. U PPPoA to je jedno, ale mělo by to být méně než 1500.
Anonym (14.2.2007 01:23:02)
takže ... U protokolu PPPoE (zjednodušeně) 1) Každá hodnota menší než 1492B je správná. 2) 1492B je to proto, že použitý linkový protokol je Ethernet II, který má maximální velikost payloadu rámce 1500B, ale používá se je ho rozšíření LLC/SNAP, které spotřebuje dalších 8B, tz 1500B - 8B je 1492B ICMP pakety s tím nemají nic společného
tfbilly (14.2.2007 08:56:16)
Aha, díky moc za vysvětlení, tak už vidíte, proč se ptám, každý mi říká něco jiného:-) A když na modemu/routeru (Linksys WAG 54GS) nastavím hodnotu na automatic, je to dobré nebo tam mám radši použít manual a 1492? Díky.
Anonym (14.2.2007 15:08:56)
U linksys bych klině nechal automat, pokud by zlobilo, tak zkusit snížit (klidně i pod 1492), to se prostě musí vyzkoušet.
mr_dadi (10.3.2007 12:09:53)
Standartně je to opravdu 1492 a je to tak u většiny modemů nastaveno, ale setkal jsem se se spoustou případů, kdy se nezobrazovaly nějteré stránky a pomohlo jen snížení MTU. Ptal jsem se jak a proč tomu tak je a bylo mi sděleno, že než požadavek projde tam kam chceme, tak jde přes véce směrovačů a ne každý směrovač je nastaven stejně, proto někdy dojde k nesouladu. Někdy jsem se setka i s tím, že na TeSu nějakého produktu doporučili snížit hodnotu MTU na 1300 a potom jim daný produkt šlapal jak měl.
Wosic (11.3.2007 22:24:23)
Pokud ma nektery router nastaveno MTU nizsi nez 1500 B tak se pakety fragmentuji, to ale nema vliv na vysledek - sit funguje korektne, stranky se zobrazi. Nizsi MTU se cilene nastavuje hlavne tam, kde je linka mene kvalitni na fyzicke vrstve.
tfbilly (13.3.2007 10:34:13)
Díky chlapi.
Vanislav (19.5.2007 22:13:02)
hele neseouhlasim, zaprve nemuzes vedet prez vsechno to pujde, takze fyz. prvstvu ani neznas a za druhe jsem mel stejny problem na CISCU rada 4500 blize nevim, MTU to vyresilo.
Anonym (20.5.2007 14:56:43)
S tim kudy to pujde se zatezovat nemusis.
Anonym (22.5.2007 06:49:15)
wosic ma skutecne pravdu....kolikrat samozřejmě víš, že budeš komunikovat skrze fyz. medium horší kvality (např vzduch nebo nekvalitní metal) Tvuj problem mohlo zapricinit omezení velikosti MTU na routeru po ceste....i to se dá nastavit.....mohl si mít nastaven flag na nefragmentovat a problem je na svete.
Anonym (22.5.2007 13:10:31)
Ale ne. Fyzická vrstva vůbec neřeší nějaký MTU. Navíc rámce fyzický vrstvy mají konstantní velikost, takže to nějakým MTU nevyřešíš. Nižší MTU pomůže tam, kde jsou linky zatížený, nebo mají nízkou přenosovou rychlost (dialup, třeba). Jinak v rámci IP sítí ISP se stejně většïnou používají jumbo rámce, takže je tam nějaký MTU naprosto nezajímavý.
Anonym (23.5.2007 06:27:35)
není to zase až tak uplne pravda, budes-li posílat veliké rámce po nespolehlivém médiu, budes jich zahazovat daleko více, než rámců krátkých. Nezapomeň že se tady bavíme o několika vrstvách OSI a tomu TCP není jedno, že mu pakety nedošli kompletně, nebo jen částečně. Proto zopakuje vyslání celého packetu, tedy přenos klidně i několika rámců po ethernetu a ztratí-li se jen jeden, posílá vše znova....proto se při nespolehlivých mediích nastavuje malé MTU, aby pravděpodobnost zdařilého přenosu byla co největší.
Anonym (23.5.2007 10:51:20)
Ještě jednou. Rámce fyzické vrstvy mají konstantní velikost. Takže, i když do nich vložíš menší paket, tak stejně je ten rámec pořád stejně velký. A když mu nesedí CRC, tak je v čudu, ať je v něm malý paket, nebo velký paket.
Anonym (24.5.2007 09:37:13)
odpověděl sis v podstatě sám, když máš delší packet, než je jeden rámec, tak ho musíš rozdělit a tím pádem ti stoupá pravděpodobnost, že nepřeneseš oba rámce
Anonym (24.5.2007 10:17:23)
Ano, to by mělo samozřejmě vliv, ale třeba u ADSL je to opět úplně jedno, protože se ti to stejně rozsype do 48B bloků kvůli ATM. Takže fragmentaci tak jako tak nezabráníš. Nicméně dobře. Jistý vliv to mít může, ale naprosto, naprosto minimální. MTU/MRU se skutečně primárně používá, aby se zajistila lepší datová prostupnost sítí s např. rozdílnými rychlostmi.
Anonym (24.5.2007 11:17:32)
A kde beres tu jistotu ze aDSL bez po ATM?
Nargon (24.5.2007 13:04:03)
Treba z toho duvodu, ze O2 ma paterni sit na ATM technologii.
Anonym (24.5.2007 15:27:23)
Joo, milej Nargone, to platilo tak pred 3-4 lety, jsi zcela vedle...
Anonym (24.5.2007 17:52:15)
Jj, dneska už by s tím neuspěl, SDH rulez
Anonym (24.5.2007 23:35:15)
Ehm, ATM sit bezi nad SDH vrstvou, tedy jsi jaksi velmi vedle.
Anonym (25.5.2007 07:25:08)
presto ne vsechno ADSL bezí pres síte ATM, nyní běží hlavně na IP síti a to co neběží jistě velmi rychle přemigruje...samozřejmě IP běží buď na SDH nebo na WDM
Anonym (25.5.2007 08:28:34)
myslim ze vetsine zakazniku je uplne ukradeny na cem to bezi, hlavne ze to bezi dobre
Anonym (25.5.2007 16:54:04)
Takže abych osvětlil vaši nevědomost, sdělím vám, že spojení modem/DSLAM je realizováno VŽDY po ATM (nebo STM). Jak je realizováno propojení DSLAMu dál do sítě ISP je už vedlejší, protože k fragmentaci do ATM buňek stejně dochází.
Anonym (26.5.2007 17:12:53)
Tak to já osvětlim tvoji zřejmou nevědomost (míchat pojmy ATM a STM to je fakt nářez), V čím dál tím větší míře jsou nasazovány tzv IP DSLAMy, které jsou připojeny na IP L2 síť a žádné ATM tam není. A mezi modemem a DSLAMem už vůbec není žádné ATM, ale DSL.....tedy to podle čeho se ta technologie vlastně jmenuje. Představ si, kolik by asi muselo stát spojení pro jednu linku....ATM koncové zařízení + ATM DSLAM ....tedy hodně přes 100 KKč
Anonym (26.5.2007 18:04:00)
Mluvíte o koze a já o voze. 1) Pokud si přečtete, co jsem napsal, zjistíte, že jsem mluvil pouze o části modem --- DSLAM. Jak je realizováno propojení DSLAMu dál je v celku irelevantní (a tady máte pravdu, skutečně). Mimochodem, IP L2 síť je logický nesmysl. 2) ADSL je v podstatě podle ISO/OSI protokol 1. vrstvy. Služby vyšších vrstev zajišťuje ATM. Proč myslíte, že v tom modemu nastavujete VPI/VCI?? A překvapivě, i u IP DSLAMů se musí nastavovat VPI/VCI. A je to proto, že L2 síť začíná až za tím DSLAMem (v ideálním případě). A mezi DSLAMem a modemem je opět ATM okruh. 3) Míchat pojmy ATM a STM ... Ne. STM nemyslím synchronous transport module, ale synchronous transfer mode.
Anonym (27.5.2007 18:37:47)
1) pokud mluvíte pouze o části modem - DSLAM...ano, tam nad DSL fyzickou vrstvou je skutečně aplikováno ATM a nad ním třeba PPPoE (viz PPPoEoA) a IP L2 je skutečně jako takové nesmysl....to je moje chyba....chtel jsem rici, ze dnes již nejsou DSLAMy připojovány přes ATM, ale přes Ethernetovou L2 síť a komunikace tam probíhá pomocí IP nebo snad MPLS 2) ano, ADSL je fyzická vrstva je nad ní ATM použité hlavně z důvodu AAL 3) pojem STM znám pouze ve spojitosti s SDH atp....tedy vámi uváděný první případ, s pojmem "synchronous transfer mode" se setkávám poprvé...mohl by jste mi vysvětlit v kostce o co se jedná? Na wiki jsem nalezl pouze odkaz na DTM... Jinak mě zajímá, co člověk s vašimi znalostmi dělá na tomto fóru??
Anonym (27.5.2007 20:28:36)
1) jj. Nedá se než souhlasit. 2) Opět beze zbytku souhlasím 3) STM ... V tomhle případě myšleno jako synchronní přenos dat (pomocí time division multiplexingu) jako protějšek asynchronního přenosu. Jinak DTM je v podstatě to samé, akorát že dokáže dynamicky přiřazovat sloty konkrétnímu okruhu a tím pádem zajišťovat QoS. Je pravda, že teď zpětně je to trochu offtopic, protože naše diskuze se přecejen posunula trošku jinam. Ale snad mi to odpustíte, máte pravdu v tom, že když si to zpětně přečtu, tak to z toho moc pochopit nejde, už kvůli kontextu. Přecejen, ATM je dosti rozsáhlý koncept:-( Jinak, jak prakticky vypadá STM u ADSL se dá dočíst v ITU G992. Ad. vaše poslední otázka... Asi to samé, co vy:-)
Anonym (26.5.2007 12:15:51)
technik CRa mi doporucil nastavit MTU na 1500.. ale vy tady rikate ze to nejde, ze maximum je 1492 takze co se stane pri 1500? naka fragmentace? se to pak samo rozdeluje na 1492 a 3 ??
Anonym (26.5.2007 12:16:18)
*oprava 1492 a 8 :)
Anonym (26.5.2007 14:27:35)
Můžeš mít problémy se dostat např. na nějaký stránky atp. U radiokomunikací tomu nerozumí:-(
Nargon (26.5.2007 14:34:20)
Na "funkcnost" internetu by to nemelo mit vubec zadny vliv. Takze stranky by meli fungovat i tak normalne. Jen tou fragmentaci trochu klesne rychlost, trochu muze narust ping a trochu se muze zvysit ztratovost. Jinak nic jinyho.
Anonym (26.5.2007 14:46:44)
Ale ano. Může a to dost výrazně. Při příliš striktní konfiguraci QoS na routerech to může způsobit i nedostupnost některých serverů (typicky, seznam.cz).
Anonym (26.5.2007 17:24:05)
takze rikate ze je lepsi nastavit este min nez 1492? kolik mate nastaveno u vas? nastavovat MTU treba na 10 mi prijde uz moc hardcore :)
Anonym (26.5.2007 18:27:32)
Tak něco kolem 1460B... Plus mínus. U kombinace USB modem/win 98 tak na 576B
Richard (27.5.2007 20:12:46)
Souhlasim, ja s touto hodnotou experimentoval na G684T 3Mbit CRa a pri 1500 se mi napr. vubec nenacetl microsoft.com apd. 1500 tedy osobne nedoporucuji... s defaultni hodnotou 1492 jsem zatim nemel zadny problem
Anonym (25.6.2007 11:57:02)
narůst ping? zvýšit ztrátovost? ty asi sítím moc nerozumíš, že?
Nargon (25.6.2007 23:48:39)
No, asi jsem to mel predtim zopakovat, ale odpoved byla smerovana na stav pri fragmentaci packetu. A tou fragmentaci se pingy zvysi a i ztratovost. Je to tim, ze ten jeden packet se musi rozdelit na dva packety, ktere jsou mensi nez MTU, ktere skutecne projde. takze se prenasi o trochu vice dat. Vice se tim zahlti linka, a tedy i naroste ping, ale narust je to temer neznatelny, odhadem v radech ns. A ztratovost. Kdyz na zacatku treba 10KB, rozdelis do 10ti packetu po 1KB, a jeden se ztrati, tak preneses 90% a ztratovost mas jen 10%. Ovsem, pokud to posles jako jeden packet, ktery se musi rozfragmentovat a ztrati se jeden fragment, tak se zahodi i tech 9 dalsich. Takze mas ztratovos 100% :( je to sice nerealny priklad, ale pro nazornost staci.
Anonym (26.6.2007 14:27:58)
Takže sítím nerozumíš, měl jsem pravdu :-)
Anonym (26.6.2007 16:34:40)
lol
Dibi (26.11.2009 11:39:03)
ja myslim ("vím"), že ma pravdu on, spis ty tu bez argumentu rikas ze nekdo necemu nerozumi misto toho, aby jsi rekl jak to je. PS: ta ztratovost se mimochodem liší podle zařízení... u starších k tomu dochází a u novějších už moc ne, protože oznami pomoci icmp že jsou zahlceny (což dělaji i starší) ale pak nasledně ty pakety některe co maji v buffru nesmažou.
Nargon (26.6.2007 16:43:42)
Kdyz si to myslis, vyvracet ti to nebudu. Co me je do toho jak myslis :)
Fib (23.6.2007 13:45:24)
ono to neni tak jednoduche, pokud chcete opravdu optimalni nastaveni pro ADSL tak je to v kazdem pripade trochu jine MTU obsahuje 20bajtu IP a 20bajtu TCP hlavicky pred prenosem se prida dalsich 32bajtu dalsi hlavicky, obsahujici PPP(2), PPPoE(6), ethernet MAC (14), PAD(2), LLC+SNAP (8), plus dalsich 8 bajtu CCPS-PDU, coz nam pak da dohromady 1488bajtu. Toto je pote fragmentovano do ATM, presneji do 31 atm bunek - kazda ATM bunka ma fixnich 48bajtu, kazda ATM si ale prida dalsich 5bajtu atm hlavicky, coz nam dava dohromady 1643bajtu takze z hlediska efektivity v tomto pripade 1408 data bajtu potrebuje 1643 bajtu prenesenych pres adsl linku, efektivita 85.7% v tomto pripade je nejoptimalnejsi MTU 1454 Dalsi vec - hodne lidi pouziva LLC encapsulaci, pokud to ISP podporuje tak je lepsi pouzivat VC, ktere nam usetri 8bajtu prave z LLC+SNAP hlavicky (detaily www. ietf.org/rfc/rfc1483.txt) Optimalni MTU nam tedy stoupne na 1456, prenasi se 1416 data bajtu, takze dohromady 1643 bajtu pres adsl linku, efektivita stoupne na 86.2% pro VC multiplexed PPPoE PPPoA s VC multiplexingem je pro DSL nejefektivnejsi, protoze usetrime 6bajtu z PPPoE, 14bajtu ethernet MAC a 2 PAD bajty takze PPPoA si vystaci pouze s 2bajty PPP hlavicky a dalsich 8bajtu CPCS-PDU a ATM hlavickami (podrobnosti www. ietf.org/rfc/rfc2364.txt) v tomto pripade (PPPoA s VC) nam optimalni MTU stoupne na 1478 - 1438 datovych bajtu - dohromady 1643 bajtu pres adsl linku - efektivita 87.5% pro ty kterym se to nechce cist vam tu shrnu optimalni MTU v jednotlivych pripadech PPPoE pres LLC - MTU 1454 PPPoE pres VC - MTU 1456 PPPoA pres VC - MTU 1478 optimalni MTU ma nejvetsi efekt na rychlost pokud jste limitovani pouze synchronizacni rychlosti modemu, v tomto pripade s optimalnim MTU muzete ziskat az 10-20KB/s navic diky tomu ze jsou data nejlepe optimalizovana pro prenos pres ATM
Tiger (23.6.2007 23:07:51)
Ty hodnoty fungujou pekne, ziskal jsem cca 10 Kb/s.
Anonym (24.6.2007 01:11:52)
No nevim. 10Kbps je spíš chyba měření:-)
Tiger (24.6.2007 01:14:13)
Neni. Nemerim to samozrejme tady na dsl, ale podle stahovani velkeho souboru v radu desitek MB.
Anonym (24.6.2007 11:00:14)
Tak tím spíš to bude chyba měření:-)
Tiger (24.6.2007 22:56:00)
Aj, ted koukam vynechal shift :-) Melo tam byt samozrejme 10KB/s, 10 Kb/s by jinak ta chaba mereni asi byla :-))
Anonym (25.6.2007 15:03:13)
narust pingu? zvysit ztratovost? heh naopak optimalizace MTU snizuje ping a ztratovost diky tomu ze to je optimalizovany pro ATM a dokaze to ATM timpadem perfektne vyuzit tim ze v ATM nevznika zbytecne overhead nebo nekdy volny misto.. proste fragmentace v ATM zmizi.. neni to nejaky velky rozdil ale napriklad odezva mi klesla z prumernych 8ms - nix.cz na 7ms - nix.cz rychlost narust 20az30KB/s rychlostni narust hlavne kvuli tomu ze sem limitovanej sync speed na modemu a ne rychlosti nekde dal u ISP (mam 8mbit a modem se sesynchronizuje na 6mbit).. mam PPPoE LLC sem zmenil na VC a MTU upravil na 1456
Anonym (27.6.2007 23:28:40)
nargone, to plati u normalnich siti ale ne u neceho jako ADSL ktery mas omezeny velikosti ATM, takze mas jeden packet rozkouskovanej na nekolik desitek "ATM packetu".. synchronizaci se spojis na 8mbit, ale i kdyz ses pul metru od ustredny tak z toho nevymackes vic jak 6,5mbit prave proto ze te omezuje atm a prave diky upravam treba MTU ziskas velikost packetu kterej se presne napasuje treba do 31atm packetu, horsi je kdyz se to nevejde presne a zabralo by to treba 32,5 atm packetu - tim nam vznikaji ztraty, pomalejsi rychlost a teoreticky i horsi ping musime si uvedomit ze nejsme na optice :) - limituje nas prave adsl prenos a ten je treba co nejlepe optimalizovat
tomix (4.2.2010 16:13:19)
je mozne se tato hodnota ma i vliv na to ze kdyz tece moc dat pres modem tak vylitnou pingy nebo je to problem neceho jineho
Telefon: +420277270707
☎ O2: +420277270772
☎ T-Mobile: +420277270773
☎ Vodafone: +420277270777
Dostupnost: Po–Pá: 8:00–18:00
E-mail: info@dsl.cz
