Vlákno názorů k článku Čeká nás rychlostní mýtné na informační dálnici? od Michal Krsek - I proto posilaly nektere ustredny tarifni impulsy :-)
-
Petr (neregistrovaný)Mne to prijde podobne, jako treba policejni radar. Musi to mit atest/certifikat. Musi to byt minimalne tamper-evident (pokud ne tamper-resistent). Musi to mit audit trail pro pripad reklamace.
Pokud se vam neco nelibi, reklamujte. V pripade pevne telefonni linky existuje CTU, ktere ma pravo auditu. V pripadech jinych by to mohla byt policie nebo soudni znalec, co ja vim. -
Hm Hm ... Nekdy by pomohlo nespolehat na to, co IP adrese rekne RIPE. Skutecnost je takova, ze chello ma okruhy do Frankfurtu a Vidne. Takze se provoz do Nizozemi dostane, ale az nasledne :-) Smerovaci politika je vec, ktera je nezavisla na tom, kolik penez vybirate od uzivatelu. Castecne se da sice vylepsit, nicmene zrovna v tomto pripade Vas penize od uzivatelu nepomohou (chello to klidne muze smerovat pres Frankfurt). Napriklad ja ted z jedne ceske site chodim na f.root-servers.net do Amsterdamu, zatimco z jine site se dostanu na prazske anycastove zrcadlo. -
Bilbo (neregistrovaný)No nekdy by pomohly lepsi routy ... treba ze site chello routa do US nejdriv vyleze z "lokalni" prazske site, dalsi hop je v holandsku (!!), pak dalsi je Viden v Rakousku (proc to nemuze jit do rakouska primo a dela to pres 1500km okruh pres holandsko?) a pak to miri do francie a pres ocean.
Takze z chello tam pak mam ping 150 a z "garazove site" kde jsem ted tam mam ping 120 (teda pokud zrovna neni vypadek nebo sit neucpou stahovaci :) - tam to z holandska jde do anglie a pak do statu a ne klickou pres rakousko
Takze casto za to musou blbe navrzeny routy ktery vedou pres pul evropy ... -
J (neregistrovaný)Videl ste nekdy pocitadlo v telefoni ustredne ? Ne ? Ja ano, teda z dost velke vzdalenosti, bliz nas totiz nepustili a i zamestnanci se tomu radsi vyhybali. Kdyby totiz doslo k nejakemu problemu a zjistilo se, ze se v tom nekdo rejpal, tak to samo vsechno zaplati. A ty pocitadla byly samozrejme pravidelne kontrolovana a testovana. Pokud vim, existuji primo normy ktere musi takove pocitadlo v telefoni ustredne splnovat.
-
A pravena to je spravna odpoved, ze kdyby se uz konecne na to ISP vykaslaly, ze by to bylo jen ku prospechu i rozvoji veci (vcetne raketoveho snizeni zisku nekterych hracu, ale i ceny technologii)... Ano na dnesni datove toky nejsou regulerni meridla, fine - souhlasim, tak proc to mnozstvi ISP "meri" a na zaklade toho fakturuje? -
Michal Kára (neregistrovaný)No a ja pisu, proc to neni spatne :-)
ISP prodavaji linku o urcite rychlosti. Presto nevim o tom, ze by meli certifikovana meridla na jeji rychlost. Telekomunikacni operatori pocitaji hovory na cas. Presto pochybuji, ze ta ustredna by byla certifikovana, ze ho meri dobre. Atp. -
Sakrys ze bych si to spocital ? Kolik je vzdusnou carou z Londyna do Ashburnu ...
Prislo mi, ze to je vic nez vyzaduje omezeni rychlosti svetla, ale je pravda ze ten rozdil nebude tak velky, uvazime-li ze trasa kolem cele zemekoule trva celych 134ms (za predpokladu ze je kulata) ...
Jinak, na druzici s geostacionarnim orbitem by to trvalo 120ms (a dalsich 120ms zpatky), takze ty druzice leda kdyby geostacionarni nebyly ... -
Michale, prosim precti si kontext diskuse. Nebavim se o tom, co je soucasna podoba trhu, ale co je na ni spatne. ISP meri neco, co je vyplod powerpointoveho inzenyrstvi. Uz jsem sice dlouho neslysel, ze by se po nahrani nove verze IOSu zmenil stav counteru o 20% (bez toho, ze na druhe strane jsou porad stejna data), na druhou stranu zadne overene meridlo na data neexistuje.
-
Michal Kára (neregistrovaný)Asi proto, ze nedelas retail ISP :-) Typicky zakaznik ma tyto parametry:
1) Chce, aby kdyz pracuje, tak aby to chodilo rychle
2) Moc toho nestahne (= linku vyuzije prumerne na zlomek jeji kapacity)
3) Chce aby to moc nestalo
Takova je poptavka. A nabidka na ni je sice rychla linka, ale s omezenym prenosem. To je nutne pro dodrzeni parametru 3. Pokud nekdo limit nechce, samozrejme si muze zaplatit linku bez limitu, ISP bude jen rad :-) -
Nenavrhoval jsem nahradit smerovac opakovaci. Jen jsem konstatoval, ze pocet smerovacu, jakoz i jejich nizka kvalita, muze zvysovat latenci. I kdyz uznavam, ze na paterni siti jsme patrne na technologickem maximu.
Samozrejme ze nebudete mit milion dratu az domu, to je extrem. Nicmene pokud cesta povede pres 10 bodu (s vetsim poctem propojeni) misto pres 20, bude nizsi latence.
No to nam moc nereklo, tak jina adresa ...# traceroute -m 50 www.ci.san-jose.ca.us traceroute to 156.39.1.80 (156.39.1.80), 50 hops max, 40 byte packets 1 ---.chello.upc.cz (89.176.-----) 5.663 ms 4.173 ms 5.799 ms 2 ---.chello.upc.cz (86.49.----) 6.292 ms 5.567 ms 4.860 ms 3 1hopsem-v101.dkm.cz (62.24.68.73) 8.453 ms 5.313 ms 5.137 ms 4 cz-prg01a-ra2-ge0-0-0-v20.aorta.net (213.46.172.9) 6.743 ms 6.335 ms 6.618 ms 5 at-vie01a-rd1-pos-1-0-0.aorta.net (213.46.160.53) 13.015 ms 11.611 ms 10.689 ms 6 at-vie15a-rd1-ge-15-0.aorta.net (213.46.173.138) 18.249 ms 12.071 ms 11.881 ms 7 213.46.160.249 (213.46.160.249) 34.517 ms 32.034 ms 31.588 ms 8 213.46.183.78 (213.46.183.78) 31.801 ms 31.648 ms 32.229 ms 9 amsxnl.sbcglobal.net (195.69.145.135) 120.533 ms 121.701 ms 127.167 ms 10 bb1-p5-0.amsxnl.sbcglobal.net (151.164.41.232) 117.099 ms 114.711 ms 114.059 ms 11 bb2-p9-0.hrndva.sbcglobal.net (151.164.41.208) 125.564 ms 154.706 ms 125.873 ms 12 core2-p5-0.chrnva.sbcglobal.net (151.164.243.137) 131.413 ms 127.500 ms 132.580 ms 13 core1-p8-0.crhnva.sbcglobal.net (151.164.188.21) 142.238 ms 128.077 ms 128.640 ms 14 core1-p11-0.crcloh.sbcglobal.net (151.164.240.121) 165.703 ms 212.519 ms 219.639 ms 15 core1-p3-0.crchil.sbcglobal.net (151.164.188.181) 189.459 ms 236.418 ms 268.879 ms 16 core2-p1-0.crchil.sbcglobal.net (151.164.188.30) 141.921 ms 143.085 ms 142.489 ms 17 core1-p11-0.crkcmo.sbcglobal.net (151.164.240.117) 156.488 ms 154.239 ms 155.485 ms 18 core1-p5-0.crdnco.sbcglobal.net (151.164.42.22) 165.685 ms 204.762 ms 165.594 ms 19 core1-p11-0.crskut.sbcglobal.net (151.164.243.245) 178.843 ms 175.559 ms 176.378 ms 20 core1-p3-0.crsfca.sbcglobal.net (151.164.243.238) 187.975 ms 189.134 ms 190.173 ms 21 bb1-p12-2.snfcca.sbcglobal.net (151.164.243.118) 189.535 ms 213.519 ms 191.761 ms 22 ded1-g1-3-0.snfcca.sbcglobal.net (151.164.243.94) 189.893 ms 210.297 ms 189.417 ms 23 VIP-CALNET-The-City-of-San-Jose-1048315.cust-rtr.pacbell.net (216.102.161.78) 199.413 ms 197.579 ms 203.175 ms 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * 31 * * * 32 * * * 33 * * * 34 * * * 35 * * * 36 * * * 37 * * * 38 * * * 39 * * * 40 * * * 41 * * * 42 * * * 43 * * * 44 * * * 45 * * * 46 * * * 47 * * * 48 * * * 49 * * * 50 * * *
No, a ? Nejdele to trva z Londyna do Ashburnu a z Ashburnu do LA, mozna bych mohl najit i geograficke lokace v tom prvnim pripade ... myslite ze ty dlouhe hopy by nesly vyresit novym, lepsim HW ? (BTW tipuji ze se jedna bud o transatlanticky kabel nebo o prenos pres druzici).# traceroute -m 40 www.sjsu.edu traceroute: Warning: www.sjsu.edu has multiple addresses; using 130.65.3.107 traceroute to ares.sjsu.edu (130.65.3.107), 40 hops max, 40 byte packets 1 ----.chello.upc.cz (89.176.-----) 6.548 ms 9.290 ms 5.545 ms 2 ------.chello.upc.cz (86.49.----) 5.426 ms 4.773 ms 5.955 ms 3 cz-prg01a-ra1-ge0-0-0-v10.aorta.net (213.46.172.5) 67.583 ms 6.777 ms 6.965 ms 4 de-fra01a-rd2-pos-2-0.aorta.net (213.46.160.29) 29.693 ms 29.782 ms 24.279 ms 5 de-fra01a-rd1-pos-5-0.aorta.net (213.46.179.5) 24.644 ms 27.693 ms 24.904 ms 6 de-fra01a-ri1-ge-2-0-0.aorta.net (213.46.179.18) 25.403 ms 25.047 ms 36.500 ms 7 213.46.179.22 (213.46.179.22) 33.775 ms 35.005 ms 36.236 ms 8 ge-3-3-0-0.fftcr4.Frankfurt.opentransit.net (193.251.241.201) 37.075 ms 33.543 ms 35.063 ms 9 so-0-1-0-0.loncr4.London.opentransit.net (193.251.154.89) 46.025 ms 43.696 ms so-0-2-0-0.loncr4.London.opentransit.net (193.251.242.138) 41.868 ms 10 po3-0.loncr3.London.opentransit.net (193.251.242.217) 41.941 ms po2-0.loncr3.London.opentransit.net (193.251.242.21) 41.801 ms 42.328 ms 11 po10-0.ashcr1.Ashburn.opentransit.net (193.251.240.182) 114.678 ms 114.013 ms 140.397 ms 12 so-5-0-0-0.loacr2.LosAngeles.opentransit.net (193.251.240.250) 180.223 ms 175.206 ms 174.296 ms 13 ge2-23.fr1.lax.llnw.net (193.251.250.210) 191.550 ms 191.423 ms 195.842 ms 14 cenic.ge2-5.fr1.lax.llnw.net (69.28.144.154) 196.802 ms 192.148 ms 197.147 ms 15 dc-lax-dc1--lax-dc2-ge--1.cenic.net (137.164.22.2) 192.427 ms 191.576 ms 191.679 ms 16 dc-sac-dc1--lax-dc1-pos.cenic.net (137.164.22.127) 194.716 ms 192.703 ms 194.282 ms 17 dc-oak-dc1--csac-dc1-ge.cenic.net (137.164.22.110) 233.244 ms 323.978 ms 217.460 ms 18 dc-oak-dc2--oak-dc1-p2p-2.cenic.net (137.164.22.195) 195.045 ms 193.644 ms 194.056 ms 19 dc-csusanjose-egm--svl-dc1.cenic.net (137.164.40.74) 196.166 ms 204.107 ms 194.970 ms 20 130.65.11.158 (130.65.11.158) 194.320 ms 195.969 ms 199.912 ms 21 130.65.11.161 (130.65.11.161) 194.766 ms 194.577 ms 195.488 ms 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * 31 * * * 32 * * * 33 * * * 34 * * * 35 * * * 36 * * * 37 * * * 38 * * * 39 * * * 40 * * * -
Bozicku :-) Mozna se pohybujete v oblasti nejakych WiFi ci garazovych operatoru, kde skutecne k nejakym pretizenim okruhu ci zahazovani paketu dochazi, nicmene tady se bavime o velkych a rozumne spravovanych sitich. Kdysi v davnych internetovych dobach byly podnikany ruzne kroky se selmostroji pod spolecnym vzyvanim modly jmenem QoS, nicmene vyhral americky pristup (dostatecne tlusta trubka resi vse). Jednim z duvodu, proc QoS de facto chciplo, byla "drobna" prekazka v tom, ze se operatori nedokazali dohodnout na tom, odkud kam se vlastne QoS garantuje. QoS muzete vzyvat maximalne ve vlstni siti (ale i to je z velke casti powerpointove inzenyrstvi) :-) Mira zahazovani je nezavisla na poctu okruhu - tedy pokud pracujeme v profesionalnim prostredi. V pripade, ze pracujeme s vetsim mnozstvim okruhu, mame vetsi problemy se smerovacimi protokoly. Tyto problemy jsou technicke (rychlost konvergence, velikost smerovacich tabulek), ale i organizacni (nastavovani smerovaci politiky). Mate pravdu v tom, ze smerovac neni tak rychly jako opakovac. Nicmene, ve smerovaci obvykle konci vic nez dva datove okruhy, zatimco v opakovaci konci prave dva. Jejich funkce je proste rozdilna a je to podobne, jako byste chtel pracku nahradit lednici, protoze zere mene proudu. Ale jinak hezke teorie, vitejte ve svete skutecneho Internetu :-) Mimochodem, porad pisete o nejakych bodech A, B nebo C. Nicmene napriklad VoIP je z hodne velke casti o Peer-To-Peer sitovani. Budu ja mit z domova jedenmilionsestsetdevadesatdvatisictristadvacetpet (ci vice) ruznych datovych okruhu ke vsem SIP telefonum, ktere jsou pripojeny do site? Mimochodem, zkuste si traceroute z Vasi site nekam do San Jose. Zjistite, ze latence smerovacu nebude ten hlavni problem. Tedy pokud nevisite na nejake garazove siti.
-
Spojeni ma minimalni latenci v pripade, ze je realizovano dvoubodovym spojem s repeatery. Realna spojeni jsou pomalejsi protoze:
1) Nejsou vyhrazene. Cas od casu se neco zahodi a musi se poslat znova, coz samozrejme zvysi latenci. (A BTW, vyhrazenost kapacity je vec o kterou muzou mit VoIP sluzby jeste vetsi zajem nez o latenci, a jde zajistit proste prevedenim vyhrazeneho provozu na nove prikoupenou kapacitu - coz beru jako novy kabel a tedy HW).
2) Nejsou prime. Misto z A do B vedou nejdrive z A do C a pote z C do B. Lze resit natazenim noveho kabelu mezi A a B, tedy novym HW.
3) Na ceste jsou aktivni prvky pomalejsi nez repeatery. Samozrejme router nemuze byt nikdy tak rychly jako repeater, ale IMHO je mozne nakoupit novy, drazsi a rychlejsi router.
4) Aktivnich prvku na ceste je prilis mnoho. Krome reseni v bodu 2 myslim, ze jsou rezervy zpusobene tim, ze se nekolik kusu HW nahradi jednim drazsim. -
J (neregistrovaný)Nj, ale pak to nemuze byt prodejnim artiklem. Jak muzu prodavat neco, co nedokazu ani odmerit ?
Si predstavte, ze prijdete do uzenarstvi, v lepsim pripade siroko daleko neni zadne jine, vidite ceduly "1kg / 50Kc", ale ja vam to 1kg odvazim zpusobem, ze hodim sisku na stul a bywoko kus odriznu.
A protoze by ste si trebas nahodou moh stezovat, tak Vam jeste dam podepsat, ze vlastne vubec nerucim za to, ze vam navazim spravne, platit budete predem a kdyz obcas zaplatite a salam nebude, nemate narok na nic.
Presne takhle to dneska funguje s "internetem" v cechach. -
J (neregistrovaný)Pokud ja vim, ISP nakupuji vyhradne konektivitu z bodu A do bodu B, v nekterych pripadech ani to ne, pronajmou si vlakno(nebo vice vlaken) a co si na ne daji za koncove zarizeni, to tam maji.
Lokalni ISP to delaji spis tak, ze nakoupi konektivitu do NIXu a k ni byva pribalena v nejakem pomeru (trebas 1/10) konektivita do zahranici.
=> ano, datove limity jsou svym zpusobem vymluva, ISP je omezen vyhradne "tloustkou" kabelu (ktera samozrejme omezuje maximalni mnozstvi prenesenych dat). -
Crypto_work (neregistrovaný)Fakt si nedokazu predstavit jak tohle v praxi implementovat aby to bylo neprustrelny a flexibilni.
To by musela byt zapeceteny routery a databaze. A nesmelo by se do toho sahat. Nebo nejaky blackboxy pres ktery by to vsechno slo a ten by se pod lipnul nejakej podpis jako to maj luxusni meraky na kabelaz.
Porad ale nekde po ceste to muzu osulit. Fakt nevim. Vsechno co mi napada ma nejakou slabinu. -
Crypto_work (neregistrovaný)Nejste neprizpusobivej dedek. V jednoduchosti je sila. Jsem tehoz nazoru. Pocitani dat je zbytecnej technickej a administrativni overhead. Je tam spousta kritickych prvku, nadela se more chyb a stejne ani pak to nefunguje dobre. Proste bych akorat zavedl rozliseni priorit a prodaval bych agregovany pripojky o xmbitech
Delsi dobu mi jedno vrta hlavou. Provideri to nezavadej protoze si stezuji ze maji taky svy datovy limity. Do tohodle nevidim pac nejsem provider, ale pripada mi to jako blbost nebo hodne blbe uzavrena smlouva. Jak to teda je? Je to jenom vymluva? -
J (neregistrovaný)Velmi snadno, zakladem je stanovit, co chci vlastne merit, v nasem pripade dejme tomu pocet prenesenych bytu na IP vrstve (vcetne hlavicek). Pak muze kdokoli postavit takove zarizeni a nekdo, vetsinou nejaky zkusebni ustav, overi, ze to meridlo opravdu meri co ma a to i pri ruznych extremnich situacich.
No a dalsi podstatnou veci je, ze do meridla NELZE zadnym zpusobem zasahnout tak, aby to nebylo poznat - toto je zasadni problem soucasneho mereni a kdyby se nekdo soudil se svym ISP, tak ten nema v ruce zhola nic, jelikoz to co meri, casto ani nemeri, ale odhaduje ze vzorku a navic to muze kdykoli kdokoli jakkoli upravit, aniz by bylo mozne to zjistit.
Tudiz je v zajmu obou stran, aby mereni bylo overitelne. -
Vzhledem k tomu, jak funguji soucasne smerovace si dokazu jen tezko predstavit, ze byste dostal NIZSI latenci. Spis to bude tak, ze budete mit latenci vyssi a kdyz si priplatite, dostanete latenci takovou, jaka je dnes. Je samozrejme otazkou, KDO si priplati. U Google, Yahoo!, Seznamu ci dalsich klient/server aplikaci je jista sance na to, ze zaplati oni. Kdo ale zaruci, ze ze kdyz si priplatim, dostanu mensi latenci pro VoIP k nejakemu kamosi na Novem Zelande, kdyz data pobezi pres 10 operatoru? Pochopitelne je taky otazkou, podle ceho se bude merit. Napriklad v soucasne dobe nemaji ISP zadna certifikovana meridla na to, kolik dat uzivatele prenesli. Presto uplatnuji FUP ci platbu za data. Nepodeziram ISP, ze data falsuji, nicmene v CR maloobchodne na vahu nemuze prodavat nikdo, kdo tu vahu nema certifikovanou ...
-
Lubi (neregistrovaný)To co mě děsí je blokování "nevyhovujícího" provozu - jsem-li poskytovatel připojení, nebo nedej bože vlastník některého z vyhledavačů - budu samozřejmě chtít blokovat svou konkurenci, a to třeba i inzerenty, kteří jsou u konkurence a né u mě. Tím je přinutím utratit nějaký bakšiš i u mě.
Z hlediska uživatele je to ale hrůza. Budu muset prolézat všechny vyhledavače, abych našel to co hledám, a to se ještě budu bát, že mi obsah zakáže můj poskytovatel připojení. -
Kdyz tak mlati tim, ze pro nektere sluzby (jako VoIP) je zapotrebi nizsi latence, proc ne ? Kdo by si priplatil, dostane nizsi latenci. Dulezite ovsem je, aby ten kdo si nepriplati dostal ty same parametry co ma ted - ktere, jak je videt v praxi, jsou na VoIP pouzitelne. A rozhodne zakazat oblibene triky na tema uplneho blokovani "nevyhovujiciho" provozu.
ČLÁNKY DO MAILU