t-home fiber, milyen technologia

Hálózatok egyéb

Minap kozoltek velem, hogy van t-home fiber elerhetoseg a lakasban es hogy valtsak UPC-rol, mert jobb, olcsobb es megbizhatobb.

Hat eddig az rezerparos ADSL szolgaltatasomban kevesebb hiba volt mint a UPC-vel coax kabellel (helyesiras nazik oldjak meg, hogy coax-szal vagy coax-al, vagy esetleg coaxal). Mivel ez a ketto kicsit mas tech ezert lehet, hogy abbol ered a kulonbseg.

Kicsit hosszas bevezeto utan akkor a kerdes, hogy ki, mit tud arrol, hogy a t-homenal meddig er el a dedikalt fiber, es mennyire dedikalt az. Nekem azt ecsetelgettek, hogy milyen jo, hogy optikan erkezik es nem coaxon, hogy akkor nekem dedikatl az optikai szalam. Na persze, sot rogton a bixre kotnek ra es ha van BGP kepes routerem akkor kaphatok full BGP tablat is:D. Szoval tud valaki arrol valamit, hogy ezt a T-home hogy oldja meg? PON, mert akkor nem sok kulobseg van a caox meg az optika kozott vagy esetleg van itt valami aktiv olcso switch vagy megis hogy van ez?

  • 16203 megtekintés

( andrej_ v | 2012. 06. 01., p – 14:09 )

Tudomásom szerint FTTB a legjobb esetben ez, tehát te egy FE/GE porton kapod a netet, pl. lehet hogy maga a csatlakozás PPPoE lesz ezen is. Nekem egyébként pont azt mutatta a tapasztalatom, hogy a DSL-nél stabilabb a UPC-s kábelnet, pedig sok helyen láttam működni. Sebesség ügyben meg a DOCSIS-al nem egy kategória a DSL már.

Valoban, a modem is CPE de ha egy switchet raknak be neked akkor az is CPE-nek minosul. Ha PPPoE vszinu azert kell, hogy az L3 halozatba kozponti helyen lepjel be. Tulajdonkeppen annyit akarok megtudni, hogy a t-home fibernet is olyan-e mint a UPC, hogy szomszed elszar valamit es az netemet is kiuti/rontja stb.

A technológia miatt nem olyan. :) A koax hátránya, hogy ha nincs rendes vissz irányú zajszűrő (ami a levehető ajtós ndk robotgépet és a junoszty tévé zaját leszedi) akkor a beszórt frekvenciákkal szétvágják a DOCSIS-ra használtakat is. (Legalább 8 évet voltam UPC-és a megfelelő HWSW fórumban megfelelő igyekeztem tájékozódni).

Az optikának biztos lesz más baja, pl. marhára érzékeny az üvegszál a hajlításra.

A PPPoE ne tévesszen meg, mert azt alapvetően sávszél korlátozó és azonosító funkcióra használják az FTTH vagy FTTB opciókkal, illetve a hálózati topológiát is elrejti a juzer elől. Egy olyan előnye is van, hogy nem szórják tele (nagyon) szeméttel a switchet kliensek. A kábelmodemes rendszereknél MAC cím hegyek alapján (kábelmodem és rákötött hálókártya) alapján működnek és a sávszél korlátot is a kábelmodem konfigból oldják meg.

" Mi van akkor, ha én gonosz vagyok és valamivel belevilágítok a kábelbe?"
Semmi ,mert az osztók visszirányú elnyomása , két előre irány között kb -70dB.
A lineáris erősítő komparátorának a bontás határa -30dB.
Ezek szerint egy 1310nm-es fényforrás kéne +45dB teljesítménnyel.
Ilyet csak ipari fém megmunkáló lézerek tudnak 40-50KW felvett teljesítménnyel ,és azt sem ezen a hulláhosszon.

"Vagy csak simán megbolondul a nálam lévő ONT?"
Megint csak semmi , az OLT lekapcsolja az idegen időrésbe renitens módon beledumáló ONT-t.

"Bár ettől a felfele irányt még ugyanúgy tönkre lehet tenni"
Nem , nem tudod tönkretenni.
Ahhoz ,hogy a szomszédjaidnak gondot okozz , az osztó bemenetét kellene eltörnöd.
Az pedig védett helyen van , és mindennemű idegen beavatkozás az rongálás.
Az ONT otthoni optikai buherálása , veszélyes játék.
A kimenő jelszintje +2,5dB , az meg már a bőven szem kiégetős kategória.
Van benne védelem , ha széthúzod az optikát és nem érzékeli az OLT 1490nm-es jelét , akkor lekapcsol.

Alapjaban veve az, hogy az upstream az TDM azert ad nemi aggodalomra okot. Ha egy OTN valamit csinal es rosszul akkor ott meg tud olni eleg sok mindenkit. Bar nemtudom, hogy hogy viszonyul az egy OTN max upstream teljesitmenye a GPON interface-hez kepest de mar csak az is eleg ha kicsit elcsuszik egy par idoegyseggel az OTN es mar is leutott egy embert teljesen.

Az időrés hiba esetén sincs gond.
Ha elcsúszik , akkor az OLT a hibás egység számára nem válaszol.
Így elindúl a feltétel nélküli lézer lekapcsolás.
Te ki és bekapcsolod akkor kezdődik előlről a szinkronizációs folyamat.
Az ONT az eszköz idő keretben elküldi az azonosítóját , és az OLT válaszol.
Ha ez nem történik meg akkor újra lekapcsol az ONT lézere.
Némi vonali zajt a 40-50s-es ki-bekapcsolgatással tudsz elérni egy hibás egységgel.
Az pár csomag ismétlését jelenti csak a szomszédos ONT-k számára.
Ez zaj nagyságrendekkel jobb mint a rézhálózatok esetén.

A GPON nem csak egy egyszerű ethernet kihosszabbító.
Egy HUAWEI-t nem feltétlen tudsz egy THOMSON-nal kombinálni.
A T-HOME hálózatába csak az adott ONT-vel tudsz bejelentkezni , és csak a saját OLT-dre.
A kliens adminisztrálásra,felügyeletre mindenki más rendszert használ , mint ahogy a hardware hiba kezelésre is.
Lehet 1550nm-en analóg TV-t is szolgáltatni, más kérdés ,hogy ilyet a T-Home nem ad.
Az IPTV-t favorizálják ,ilyen megoldást inkább kis KTV-s cégek nyújtanak.
Jelen pillanatban a rendszer egy OLT portra maximum 128 klienst tud fogadni 2.5Gbit vagy 10 Gbit sávszélességgel.
Ebben bene van az IPTV és a IPtelefonok által elfoglalt sávszélesség is.

Kicsit túlhaladott de alapvetően igaz.
http://en.wikipedia.org/wiki/Passive_optical_network

Így van.
A validáció gátolja meg az idegen eszköz feljelentkezését.
A jogosultság kezelés , HW hiba kezelés , szolgáltatás biztonság követeli meg.
Ezek rendszerenként , eszközökként és szolgáltatónként különböznek.
Egy szó mint száz mára a pont pont optika után ez a legüzembiztosabb széles sávú polgári vezetékes kommunikációs technológia.

Nem akarok en minden aron szolgaltatot valtani, csak ha kulonosen megeri. Jelenleg megvagyok ezzel a UPC primary, adsl backupal, azt a par napot kibirum 512k uploaddal is.

Mert ha mondjuk arrol lett volna szo, hogy a t-nek a fiberen mar itt a pinceben csatlakozik a metro optikara, ami jobb esetben redundans es L3 akkor azt mondom, hogy megeri, de igy, hogy a minosegi valtozas az annyi, hogy nem coaxot hanem optikat furnak be ami raadasul kenyesebb is... Hat nem is tudom. Talan az egyetlen pozitivum amit latok, hogy az elso aktiv eszkoz ami a lakason kivul van egy ertelmes helyen van, ahol van generator + UPS stb es nem a szomszed haz pincejeben. De errol linelord esetleg majd nyilatkozik:)

< troll mode on> Marmint az 1 CLP bit vs a Priority|DSCP < /troll mode off>

Eloszor is a 53/5 kicsit szarabbul hangzik mint az 1500/(50 + 8 a pppoe-re) es amikor ~10gigabitnel szetnezel nem szivesen dobsz a kukaba 1gigabitet csak azert, hogy jo legyen.

De ha mar igy elkezdted kivancsi lennek arra a configra amit az IP nem tud:).

Szia!

Lehet, hogy rosszul fogalmaztam,sem ATM-ben, sem IP-ben nem vagyok, expert. :)

A CBR/rt VBR/nrt VBR/UBR/ABR vs. DSCP-re gondoltam (AF/EF/NF...)
ATM halozatoknal sosem volt olyan gondunk, hogy a control planet kiszoritotta volna a user plane.
Amiota IP backbone van mindenhol, azota tobbszor is belefutottunk (plane ha tobb diffserv-es domainen ativelo kapcsolatrol volt szo), hogy ha valahol beszukult a cso, akkor a user plane traffic siman kiszoritotta a signallingot... Persze lehet, hogy ez nem a protokoll hibája, hanem megfelelő traffic engineeringgel megoldható lenne, de több emberrel is találkoztam, aki már szívott ugyanígy az E2E QoS miatt. Az ATM-es traffic contract-ok nekem jobban tetszettek, de ez lehet, hogy egyéni preferencia kérdése. Sok szolgáltató úgy áll a diffservhez, hogy minek az, inkább dimenzionáljuk túl a hálózatot, de szerintem ez strucc politika.

"hogy ha valahol beszukult a cso"
Hálózat méretezési problémákat ritkán lehet orvosolni protokol cserével.:)

"Sok szolgáltató úgy áll a diffservhez, hogy minek az, inkább dimenzionáljuk túl a hálózatot "
Valószínüleg azért mert a jól méretezett és megépített hálózat nem szorít korlátok közé.
Több féle szolgáltatás adható ,jövő állóbb , hisz technológiák , protokolok , berendezések ,jönnek mennek.


Amiota IP backbone van mindenhol, azota tobbszor is belefutottunk (plane ha tobb diffserv-es domainen ativelo kapcsolatrol volt szo), hogy ha valahol beszukult a cso, akkor a user plane traffic siman kiszoritotta a signallingot... Persze lehet, hogy ez nem a protokoll hibája, hanem megfelelő traffic engineeringgel megoldható lenne, de több emberrel is találkoztam, aki már szívott ugyanígy az E2E QoS miatt.

Hat ha tobb diffserv-es domain van, akkor gyanitom, hogy a sima internet+ipsec meg talan jobb is lehet, mert az legalabb konstans szar es nem szoksz hozza a johoz amikor minden jol mukodik:D

Hat a tobb diffserv domainnel ugye van a remark aztan ha szerencsed van jol jarsz, ha nincs akkor nem. Eddigi tapasztalataim alapjan akik ezeket a "vonalakat" confoljak altalaban nem a halozatmernokok kremje szoval elofordulhat igen csunya felreconfolas. Mondjuk azt nem tudom, hogy a fentebb emlitett szituacioban a te control planedrol van szo vagy a szolgaltatoerol de lehet, hogy ez mellekes is:).


Sok szolgáltató úgy áll a diffservhez, hogy minek az, inkább dimenzionáljuk túl a hálózatot, de szerintem ez strucc politika.

Hat en veluk ertek egyet. berakni meg 1-2-4 linket egy etherchannel/LAG-ba konyebb, egyszerubb es kiszamithatobb mint egy QoS policy.

Ha troubleshootolni kell hajnal kettokor akkor nem biztos, hogy eszedbe fog jutni, hogy akkor hogy is keressuk vissza, hogy ez a nagymennyisegu EF csomag honnan jon. QoSt konnyu felreconfolni amivel jobb esetben egesz halozatokat tudsz megfekteteni. Ahol dolgoztam ISP-nel ott a vegeszkozok kezzel lettek felconfolva es egy csapatba (nem ugy mint egy adott emberben) nem lehet megbizni, hogy nem fogja valaki felreconfolni (mert jon az uj gyerek, masnaposan configol, gyorsan kell csinalni stb stb. Ilyen elofordul, emberbol vagyunk nem fabol).

Nekem egy okos ember azt mondta, hogy csak azert nem kell featureoket hasznalni, hogy hasznaljuk a featuroket:) Eddig meg ahol jartam minel kevesebb controll protokollt kellett hasznalni annal jobb volt. Ennek van meg egy olyan resze is a dolognak, hogy akkor az interjun nem eleg megnezni, hogy a jelolt ismeri-e az (ospf|isis)/bgp/mpls szentharomsagot meg kell a QoS is, tapasztalataim szerint nem konnyu leakasztani ilyen embert sehonnan.

Aztan van meg az, hogy nem eleg egy hw platformot ismerni, 6500/7600 es az juniper MX sorozataban is eleg bonyolult egy csomag elete amikor athalad ugy, hogy nincs megkulonboztetes koztuk, nem kell meg ezt is bonyolitani azzal, hogy a buffereket szetosztjuk a kulonbozo traffic classok kozott.

Es nem utolso sorban nehez utolag is bevezetni, mivel minden vegpontot konfolni kell annak megfeleloen. egy t-nel vagy egy invitelnel nem annyira egyszeru egy core router konfigjanak a valtoztatasa, es ha tapasztalataimbol indulok ki el kell telnie legalabb 4 hetnek az "ezt meg akarom csinalni, jolvan" es a "tessek konfigolhatsz" kozott.

hmmm... kicsit hoszabb lett mint terveztem:)

Ez a válasz neked, és a feletted válaszolónak is szól :)
Átlagos használatnál lehet, hogy nincs létjogosultsága, hogy az ember ezzel sz*rakodjon, hanem egyszerűen felül kell dimenzionálni a hálózatot.

De pl. egy telco szolgáltatásnál elvárod azt is, hogy mondjuk egy földrengés után, amikor mindenki telefonálni akar, és 10x-es traffic van, és emellett még a backbone fele kiesett, akkor ne a control plane essen ki amiatt, mert hirtelen mindenki át akar férni a szűk csövön. IP-n egy ilyet működőképesre belőni elég nagy kihívás, ha nem te uralod a teljes backbone-t.

Tudod atom háburúra nem méretezünk semmit.(nem éri meg gazdaságilag , meg kinek) :)
Az általad felvázolt katasztrófa helyzeteken többet segít , egy hibatűrőre méretezett hálózat mint a protokol.
A hálózat felsőbb síkjait úgy méretezik , hogy tartalmazzanak redundanciát ilyen esetekre.(földrengés,árviz,stb..)
Ez az álláspont azért is jó mert nem kell évente cserélgetni a drága felsőszintű berendezéseket.
Nem kell mindig a HIGH TECH platina árában , majd megvesszük jövőre a tizedéért.
Nyilván nem segít azokon , akik egy szem elszakadó köldökzsinóron lógnak a hálózaton.

A hibatűrő hálózat és a redundancia nem segít, ha a forgalomad sokszorosára nő egy rendkívüli esemény (pl. árvíz, földrengés) miatt. (és nyilván a normális forgalom tízszeresére sem fogsz méretezni egy hálózatot)

Ismétlem, itt most telco hálózatról van elsősorban szó, tehát nem arról beszélek, hogy a torrent miatt laggol a WoW. A user plane mondjuk legyen a sokezer RTP folyam, a control plane pedig a signalling (SIP,H248,SIGTRAN,MxUA, akarmi) egy 1+1 Gb-es linken. Ha a Diffserv nincs mindenhol ugy beallitva, hogy a control plane AFxx legyen, a user plane pedig EF, akkor itt egy 10x-es növekedésnél a control plane simán megdöglik.

Hat alap allapotban ha van 2x1 gigabit redundans linked akkor minden linket ugy kell meretezni, hogy kulonleges esemeny kivetelevel ne fusson egyik se 50% (de inkabb 40%) felett. Nagyjabol ennyi a meretezes alapja. Ha N+1-es redundancia modellel mesz az 1+1 helyett akkor ezek a szamok persze valtoznak. Manapsag ez mar nem "annyira" draga mulatsag.

Az megint mas kerdes, hogy google mit csinal par szaz gigabittel ha megszakad az egyik backbone linkjuk, de erre lett kitalalva az RSVP meg az autobw.

Hala istennek en meg nem lattam olyan szolgaltatot aki ne kezdett volna upgradebe amikor a redundans link kihasznaltsaga rendszeresen atlepte a 45%-ot.

Telcoban is így méreteznek, azért tudsz karácsonykor és szilveszterkor is telefonálni, de pont ez a lényeg, hogy ez még nem az extrém kategória. Egy földrengés után pl. a szilveszteri forgalom sokszorosára nő a hívások száma (a normál forgalomhoz képest akár 2 nagyságrendet is ugrik), és erre viszont nincs méretezve a hálózat.

(Ráadásul ezek jellemzően rövid hívások, tehát arányosan sokkal több a signalling is.)
Egy telco hálózattól elvárom, hogy ezekben az extrém esetekben is működjön a control plane, akár a user plane kárára is, és pont ezért nem jó válasz a standard válasz, hogy méretezd nagyobbra a hálózatot.

hat vegulis epithettek volna japan kore is 8 metere magas 4 meter vastag betonfalat.

A karacsonyi forgalomra soha nem is lesz meretezve egy halozat, mert az eloforulasi gyakorsiag/valoszinuseg nem indokolja. Csak azert mert lehet, hogy egyszer mennel 300-al nem fogsz venni egy bugatti Veyront es mindennap azzal bejarni pestre hatvanbol.

"a normál forgalomhoz képest akár 2 nagyságrendet is ugrik"
Ugye egy méretezett hálózatnak az is része , hogy a szolgáltatásokat nem viszik együtt a "csak internettel".
Lehet ,hogy a Skype-od nem fog menni de a fizetett IP telefon szolgáltatásod vagy analóg/ISDN telefonod igen.
A 70-es évek elmúltak amikor a tárcsa hangra várni kellett.
A központoknak , egyéb kapcsoló elemeknek sokszorosa a kapacitása az előfizetői létszámnak.
A telefóniának ráadásul csak töredék sávszélesség igénye van a "csak internet"-hez képest.
Egy kisebb régióban a mobil lehet cinkes a katasztrófa turizmus miatt.
Az Olasz szolgáltatók hálózatai is így épülnek fel.
A nemrég történt földrengés kapcsán , nem a telefonokra panaszkodtak szegények.

japanban X ido feletti szolgaltataskiesnel jelentest kell irni a kormanynak, Y folott elveszik a frekvenciat (es itt X es Y eleg alacsony idoegyseg)
valamint az osszes szolgaltato kenyes ugynek tekinti a segelyhivasokat, mivel faszkorbacs jar erte, ha nem mukodnek :-)

szerk.: necroposting rulz :)

--
NetBSD - Simplicity is prerequisite for reliability

Nekem az ADSL nagyon jó volt vagy 7 évig, aztán egyszer csak megbízhatatlanná vált (akkoriban kezdték el olcsón osztogatni az 5MBit-es csomagokat), annyira, h át kellett térnem UPC kábelnetre. Rá egy évre ide is behúzott vmit a T (szerintem csak sima kábelt), de akkor már késő volt. Lehet szívni ADSL-lel is sokat..
--
Direp

Köszi, érdekes. Nekem azt mondták régebben, én is gondolkoztam fiberen, hogy az optika nem jön a lakásig, hanem csak egy közelebbi elosztóig és onnan már telefonkábelen jön a lakásba. A sebességnövekedést meg az adja, hogy nem a központtól, hanem közelebbről jön rézen. De a leírások alapján nem mondtak igazat.

( N_and_Y | 2012. 06. 01., p – 15:56 )

"off"

coax-szal a jó, de coaxszal, koax-szal és koaxszal alak is elfogadható

( koax + val, -val -vel rag, teljes hasonulás, hasonul a kettős mássalhangzó [ká-esz] második tagjához, az esz-hez)

((nem elég, hogy anyám magyar-töri szakos, de az osztályába is jártam négy évig, és nem akarok róla beszélni.))

:D

"/off"

( mauzi v | 2012. 06. 01., p – 21:23 )

Szia!

Hozzám a falu szélére tavaly októberben jutott el az optika. Korábban "Alap" csomagú T-Home ADSL-em volt, ezt migráltattam át üvegre. A T-nél a csomagok ugyanannyiba kerülnek, függetlenül attól, hogy milyen platformon (DSL, Kábelnet, GPON) veszed igénybe.

Nos, és mi az, amit változatlan áron kapok?

Üvegszál egészen a Salgó polcom sarkáig. A végberendezés egy "Huawei Echolife" típusú doboz, ami eddig tökéletesnek látszik: bombabiztos, és még langyos sem lesz. Az eszközön gigabit ethernet port van. Az eszköz ethernet bridge-ként működik, amin PPPoE-vel lehet csatlakozni. (Az ADSL-ről váltás után csak a felhasználónév/jelszó párost kellett átállítani)

Papíron az "Alap" csomagban most 5/2,5 megabitet kellene kapnom. Azt mondta a szerelő, hogy az üveget nem szokták a legkisebb csomagra állítani, így - külön kérés nélkül - a következő, "Családi" csomagot kapom, ami 15/7,5 megabit, gyakorlatban majdnem 20/10 megabit. Ehhez 4-6ms pingek tartoznak. "Kicsit" jobb, mint az ADSL volt ugyanennyiért. (az papíron 5/0,5 megabit volt, ténylegesen kb. 1,5/0,25 megabit ment át rajta, 24ms körüli pingekkel, néha jelentős packetlossal)

A GPON szolgáltatás béreltvonal-minőségű!

Ja, és natív IPv6-ot adnak (tesztüzemben), /56-os tartománnyal.

Most már csak az a gáz, hogy a cégem két telephelyén ennek a töredékét kapjuk, sokkal drágábban. Üveget akarok mindenhová! :)

( vtechun | 2012. 06. 01., p – 22:45 )

be a lakasba megy az optikai szal, es ott jo esellyel egy Huawei Echolife 850 ONT-ba csatlakozik. Szoval FTTH

( csilee | 2012. 06. 04., h – 17:02 )

esetleg nem tudjátok a bővítési menetrendet? hol melyik teleülésen akarnak ilyet?

( kisg v | 2012. 06. 06., sze – 12:49 )

Dunakeszin (a Fót felé eső részen) mikor lesz végre optika? Nem ragaszkodom a T-hez sem, bár most náluk vagyunk. Már végigpróbálgattam a T-t, UPC-t meg Invitelt is, de semmi.

( sibike | 2012. 09. 04., k – 15:20 )

Sziasztok!

Valakinek van tapasztalata az INVITEL féle FTTH technológiával? Nemrég kerestek meg, hogy a jelenlegi ADSL-t leváltsák.

Jelenlegi felállás, hogy az internet ADSL-en jön, a tévé meg T-home (kábeltv). Mind a tv-t, mind az invitelt kiváltanám vele, mert úgy látom, hogy anyagilag így éri meg a legjobban...

Az invitel milyen CPE-t ad?
A bekötésnél milyen költségeket áll a szolgáltató és mit kell nekem fizetni? (esetemben kb 30 métert kell kábelcsatornában húzni az udvaron, és legalább 5-öt házon belül)
A TV-khez milyen kábelezés szükséges? Jelenleg van kiépített cat5 kábelezés, amit telefonvonalnak használunk, az megfelelő lehet?

hali,

En egy huawei -t kaptam, 2 fxs + 4 ethernettel + 1 settopboxal ( asbis vagy mi az isten nyila :))
Internet: PPPoE -vel megy, egy rossz szavam nincs ra. Stabil, gyors es kivancsisagbol neztem tcpdump -ot a switchporton es nagyon ugy tunik, hogy igenyesen megcsinaltak -> nem latszik semmi 'szemet' a halozaton.

Telefon: sima FXS nincs benne semmi csoda, megy szepen.

Settopbox: UTALOM! :) Leven elotte THome volt, ami nem igazan torodott a jogokkal ( vagy fizetve volt ) es fel lehetett venni barmi csatornat. Invitel valami csoda rendszert, ami kozpontilag rogzit / donti el, hogy mit lehet visszatekerni / felvenni.

Viszont, az internet zsir :) gyors es megy. Raadasul az elmult egy honapban ( bekotes ota ) nem volt olyan perc, hogy barmi lassult / megallt volna.

( kalebris | 2012. 10. 09., k – 16:26 )

Hat akkor tapasztalatok. Tegnap bekotottek a t-home FTTH megoldasat., lecserelve az 5megas backup dsl vonalamat 25megas optikara. Ami erdekes szamomra:
t-home ping a def. gw-hez:


100 packets transmitted, 100 received, 0% packet loss, time 99149ms
 rtt min/avg/max/mdev = 1.506/1.932/2.343/0.138 ms

UPC ping a def gw-hez:


100 packets transmitted, 100 received, 0% packet loss, time 99144ms
rtt min/avg/max/mdev = 4.068/9.102/20.866/2.220 ms

Ami ertheto ugyan de azert kicsit meglepodtem. Nem gondoltam volna, hogy 7ms-el alacsonyabb lesz a first-hop latency. Ugy tunik, hogy engem meggyoztek, szova tv-t valt t-hez, megjegyez k*va ugyfelbiztonsagi jelszo, aztan upc downgrade secondary vonalra:)

Gpon lévén ugyanazon a szálon halad az adás és vétel.
A G652 szálak tipikus törésmutatója 1,4768 .
Ha eltekíntünk az OLT egyébként erősen változó késleltetésétől akkor 110Km az 1ms.
Természetesen ennek semmi értelme , mert a passzív osztók miatt az áthidalható távolság csak a töredéke.

( Gragra | 2015. 06. 16., k – 19:08 )

Sziasztok, bocs, hogy ezt az ezer éves topikot hozm fel de nem akartam újat nyitni. Igazából keresnék valakit a HUP-os brigádból aki a T-Home/Telekom hálózatáról tud infót Szigetszentmiklós és környékén.

A T-Home elkezdett vadul hirdetni, hogy itt az optika. Ehhez képest az egy utcában csak a harmadik telektől hozza a bekötés lehetőségét a rendszer a másikban (sarokház) pedig s szomszédtól. Konkrétan a kocsibeálló mellett 5 méterre van az oszlop amin ott virít az optika...

Ez csak az ügyintéző lustasága vagy tényleg létezik, hogy a szolgáltatási terüleből kivágnak két telket? Nekem ez meseszerű. Előre is köszönöm a hasznos infókat.

( gergov | 2015. 12. 08., k – 23:53 )

Akkor én most újra felélesztem a témát egy kérdés erejéig.

Úgy tűnik, hogy nemsokára érkezik hozzánk is a t-home FTTH. Talán érdemes lenne váltani rá ADSL-ről, de nem tudom, hogy a szolgáltató részéről biztosított HGW képes-e bridge módban működni. Ugyanis jó lenne, ha a saját routerem továbbra is publikus IP címet kapna, nem szeretnék dupla NAT-ot.
Akinek van telekomos FTTH net előfizetése, meg tudná nekem mondani, hogy hogy is működik ez?

Köszi!

Működik bridge módban, ugyanolyan PPPoE megy felette, mint az ADSL-nél. Gyakorlatilag neked semmit sem kell állítanod, csak átdugod a routered WAN portján a kábelt az ADSL modemből a GPON eszközbe, még a felhasználónév/jelszó is ugyanaz maradhat.

Cserébe lesz bombabiztos 2.5/1.2 gigabites linked 1-2 ms válaszidővel. Ami persze le van korlátozva az általad igénybevett csomagra + pár %-ra... vagy sokkal többre, mert a díjcsomagokat ADSL/VDSL/DOCSIS/GPON fronton pár éve egységesítették, viszont a profilokhoz nem feltétlenül nyúltak hozzá.

Régen emlékeim szerint 15/7.5, 25/12.5, 50/25 és 120/50 csomagok voltak GPON platformon, ma viszont papíron a legnagyobb csomag is csak 120/10-es. A régi ügyfeleknek megmaradt az eredeti (nagyobb) sávszéljük, de hogy az új ügyfelek mit kapnak??

( szollosiimre | 2015. 12. 09., sze – 07:14 )

Gpon, vagy gepon. Attol ffüggően,vhogy melyik technológiàt vâsàroltâk fel èpp olcsóbban,

Fttb esetèben az onu valahol a hàzban vagy, ahol ethernet swizchenkre terelik a forgalmat ès kapsz egy tyúkbelet.
Fth esetében nálad van az onu, és lehetőség szerint ne told rá az optikai kábelre a stelázsit. Amugy ahogy láttam, elég masszív.

Az onuban levő inteligencia az már nagyon készülékspecifikus, meg szolgáltató specifikus, de az alapok ezek.

Anno mi pppoe--t raktunk ki az ügyfél elé. A szerződéskötès elött kötelessègük megfelelően tàjékoztatni.