Příspěvky

Pro představu, takto vypadá GPON od ÚVT na vlastním vlákně (Vestec u Prahy)

traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
1  gw-homelab (redacted)  0.475 ms  0.415 ms  0.528 ms
2  cust-178.17.0.2.uvt.cz (178.17.0.2)  2.294 ms  2.349 ms  2.297 ms
3  gw.uvt.cz (100.64.35.1)  2.265 ms  2.229 ms  2.274 ms // tohle mám v hosts souboru, aby reverz nezdržoval tracerouty
4  vl819.j2r.cec.net.uvtnet.cz (31.170.178.218)  2.202 ms  2.214 ms  2.190 ms
5  nix4.cloudflare.com (91.210.16.171)  3.106 ms  5.877 ms  3.110 ms
6  141.101.94.35 (141.101.94.35)  2.857 ms  3.354 ms  3.249 ms
7  one.one.one.one (1.1.1.1)  2.976 ms  2.786 ms  2.787 ms

Platite si vlastni ip? Nekteri zas rikaji ze si zaplatili ip a problemy s cgnat byly pryc

Potřebuju a nevím co abych to mohl vyřešit s nějakým technikem na T-Mobilu, ta moje latence se mi vůbec nelíbí.

Pre zaujímavosť, vieš nejak racionálne zhrnúť, prečo sa ti latencia x ms práve nepáči a y ms by bola tá pravá? Alebo ide len o pocitovú záležitosť?

Domnievam sa, že v realite ten rozdiel v 95% aplikácii vôbec nepoznáš (ak sa bavime povedzme o urovni x,y <20 ms).

Nejde mi o to, že bych při běžném používání internetu poznal rozdíl mezi 5 a 9 ms. To samozřejmě ne.

Jde mi o to, že jsem měl na stejné optické přípojce u Vodafonu odezvu kolem 4–5 ms, zatímco po přechodu na T-Mobile mám stabilně 9–10 ms. Zajímá mě tedy technická příčina tohoto rozdílu.

Internet využívám mimo jiné ke kompetitivnímu hraní, kde se snažím mít co nejnižší možnou latenci. Samozřejmě chápu, že samotné 4 ms navíc nejsou zásadní problém, ale pokud je možné mít nižší odezvu bez zbytečné transportní okliky, nevidím důvod, proč to neprověřit.

Navíc jsi sám zmiňoval plánovanou optimalizaci agregační sítě během 3–6 měsíců, takže předpokládám, že prostor pro zlepšení tam existuje. Právě to mě zajímá, nikoliv jestli poznám 4 ms při prohlížení webu.

Takhle to vypadá v Praze:

tracert 1.1.1.1
Tracing route to one.one.one.one [1.1.1.1]
over a maximum of 30 hops:

  1    2 ms    1 ms    1 ms  sagemcom [192.168.1.1]
  2    8 ms    3 ms    2 ms  62.141.11.119
  3    9 ms    3 ms    6 ms  10.92.6.149
  4    8 ms    3 ms    3 ms  141.101.94.16
  5    29 ms    3 ms    3 ms  141.101.94.37
  6    8 ms    2 ms    3 ms  one.one.one.one [1.1.1.1]

A takhle to vypadá jinde v Praze, s tarifem který se jmenuje Fiber Internet 250 bez závazku a routerem od T-Mobile (192.168.1.1) do kterého přímo vede optika a pro připojení vnitřní sítě má WiFi 6 a ethernet 4x1 Gbps a 1x2,5 Gbps:

traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)  0.421 ms  0.372 ms  0.328 ms
 2  62.141.5.8 (62.141.5.  1.095 ms  2.101 ms  2.061 ms
 3  10.92.6.149 (10.92.6.149)  2.419 ms  2.175 ms  2.783 ms
 4  141.101.94.16 (141.101.94.16)  35.396 ms  35.356 ms  12.763 ms
 5  141.101.94.35 (141.101.94.35)  3.208 ms  3.296 ms  3.255 ms
 6  one.one.one.one (1.1.1.1)  2.484 ms  1.966 ms  1.903 ms

Díky za traceroute, tohle je pro mě hodně zajímavé srovnání.

Moje první PPPoE brána je 62.141.5.9 s odezvou 8–9 ms, zatímco ty máš 62.141.5.8 s odezvou kolem 1–2 ms. Třetí hop 10.92.6.149 už máme stejný, stejně jako další trasu na Cloudflare.

Můžu se zeptat, jestli víš, zda jsi na vlastní infrastruktuře T-Mobilu, nebo přes CETIN? A případně alespoň přibližně z jaké části Prahy měříš?

Zajímá mě hlavně, jestli ten rozdíl vzniká na transportní trase od OLT k BNG, nebo jestli může mít jiné vysvětlení.
Potřebuju a nevím co abych to mohl vyřešit s nějakým technikem na T-Mobilu, ta moje latence se mi vůbec nelíbí.

Můžu se zeptat, z jaké přibližně oblasti měříš a jestli máš opravdu optiku přímo na infrastruktuře T-Mobilu, nebo přes jiného vlastníka sítě?

Oblast je to Praha 18 (Letňany) a jsem přesvědčený, že je to na infrastruktuře T-Mobile, ale úplně nevím jak to jednoduše spolehlivě ověřit, služba se při zřízení v 2/2022 jmenovala Můj optický internet S, teď je to Fiber Internet 250. Login do PPPoE i Můj T-Mobile začíná optin0027
A ještě tedy mám jejich ONT přepnutý do bridge čímž za něj nic neplatím a mám vlastní router

Díky za upřesnění! Takže máš v Letňanech optiku T-Mobilu s vlastním routerem za ONT v bridge režimu a stabilně kolem 2 ms na 1.1.1.1.

Zajímavé je, že od třetího hopu máme prakticky stejnou trasu, přestože u mě je odezva už na první PPPoE bránu 8–9 ms.

Ještě by mě zajímalo, jestli ti T-Mobile někdy výslovně potvrdil, že je OLT přímo jejich, nebo to předpokládáš podle původního názvu služby. Rád bych rozlišil přípojky na vlastní síti T-Mobilu a přes OLT CETINu.

nachomytnul sem se jen k reseni pripojeni TV k nove Wifi v ramci modemu ktery je na optice TM, ale zrejme take na infra Cetinu... zmohl sem se jen na overujici speedtest a tam byl ping 5ms. Jelikoz na VDSL mam 7-10ms tak bych cekal taky o fous mene na optice. 

To je zajímavé, díky za zkušenost. Můžu se zeptat, jestli bys mohl zkusit ping přímo na 1.1.1.1 a případně traceroute (tracert -d 1.1.1.1)? Zajímalo by mě, jakou máš odezvu na první bránu operátora a kudy vede trasa. Řešil bych to pak s Tmobilem s konkrétními podklady.

Pokud jsi také na infrastruktuře CETINu, bylo by to zajímavé srovnání, protože já mám už na první PPPoE bráně 8–9 ms.

Jen pro zajímavost a srovnání, T-Mobile optika na jejich vláknech, tady aspoň jsem o tom přesvědčen.

Kód [Vybrat] Rozbalit

Microsoft Windows [Version 10.0.26300.9711]
(c) Microsoft Corporation. All rights reserved.

C:\Windows\System32>ping 1.1.1.1

Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time=3ms TTL=59
Reply from 1.1.1.1: bytes=32 time=2ms TTL=59
Reply from 1.1.1.1: bytes=32 time=2ms TTL=59
Reply from 1.1.1.1: bytes=32 time=2ms TTL=59

Ping statistics for 1.1.1.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 3ms, Average = 2ms

C:\Windows\System32>ping 1.1.1.1

Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time=2ms TTL=59
Reply from 1.1.1.1: bytes=32 time=2ms TTL=59
Reply from 1.1.1.1: bytes=32 time=2ms TTL=59
Reply from 1.1.1.1: bytes=32 time=2ms TTL=59

Ping statistics for 1.1.1.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 2ms, Average = 2ms

C:\Windows\System32>tracert -d 1.1.1.1

Tracing route to 1.1.1.1 over a maximum of 30 hops

  1     1 ms    <1 ms     2 ms  192.168.10.7
  2     2 ms     2 ms     2 ms  62.141.11.116
  3     2 ms     2 ms     2 ms  10.92.6.149
  4     3 ms     3 ms     2 ms  141.101.94.16
  5     3 ms     2 ms     2 ms  141.101.94.35
  6     4 ms     2 ms     2 ms  1.1.1.1

Trace complete.

C:\Windows\System32>tracert -d 1.1.1.1

Tracing route to 1.1.1.1 over a maximum of 30 hops

  1     1 ms    <1 ms     1 ms  192.168.10.7
  2     2 ms     2 ms     2 ms  62.141.11.116
  3     2 ms     2 ms     2 ms  10.92.6.149
  4     3 ms     2 ms     3 ms  141.101.94.16
  5    12 ms    13 ms    13 ms  141.101.94.35
  6     3 ms     4 ms     2 ms  1.1.1.1

Trace complete.

Díky za porovnání, tohle je hodně zajímavé!

Všiml jsem si, že máme dokonce stejný třetí hop `10.92.6.149` a následně i `141.101.94.16`. Rozdíl je ale už na první bráně T-Mobilu, kde já mám 8–9 ms a ty pouze 2 ms.

To docela podporuje teorii o rozdílné přístupové/agregační trase, kterou tady zmiňoval dmr345.

Můžu se zeptat, z jaké přibližně oblasti měříš a jestli máš opravdu optiku přímo na infrastruktuře T-Mobilu, nebo přes jiného vlastníka sítě?

@Hedyyy Dobře , že do toho šťouráte. Ta odpověď zákazníkovi, že "vaše připojení je v normě" i když vy jasně vidíte velký rozdíl v latenci je ke vzteku.

Podobně jsem dopadl tady na P9 u jednoho lokálního providera. Ovšem to nebyl GPON.

Letos mám GPON Vodafonu a mají taky cca 5-6ms k "poslednímu bodu před Internetem". Takže bych těch 5-6ms považoval za standard pro gigabit+ GPONy.

Jenze netusim co s tim..

Jen pro zajímavost a srovnání, T-Mobile optika na jejich vláknech, tady aspoň jsem o tom přesvědčen.

Kód [Vybrat] Rozbalit

Microsoft Windows [Version 10.0.26300.9711]
(c) Microsoft Corporation. All rights reserved.

C:\Windows\System32>ping 1.1.1.1

Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time=3ms TTL=59
Reply from 1.1.1.1: bytes=32 time=2ms TTL=59
Reply from 1.1.1.1: bytes=32 time=2ms TTL=59
Reply from 1.1.1.1: bytes=32 time=2ms TTL=59

Ping statistics for 1.1.1.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 3ms, Average = 2ms

C:\Windows\System32>ping 1.1.1.1

Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time=2ms TTL=59
Reply from 1.1.1.1: bytes=32 time=2ms TTL=59
Reply from 1.1.1.1: bytes=32 time=2ms TTL=59
Reply from 1.1.1.1: bytes=32 time=2ms TTL=59

Ping statistics for 1.1.1.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 2ms, Average = 2ms

C:\Windows\System32>tracert -d 1.1.1.1

Tracing route to 1.1.1.1 over a maximum of 30 hops

  1     1 ms    <1 ms     2 ms  192.168.10.7
  2     2 ms     2 ms     2 ms  62.141.11.116
  3     2 ms     2 ms     2 ms  10.92.6.149
  4     3 ms     3 ms     2 ms  141.101.94.16
  5     3 ms     2 ms     2 ms  141.101.94.35
  6     4 ms     2 ms     2 ms  1.1.1.1

Trace complete.

C:\Windows\System32>tracert -d 1.1.1.1

Tracing route to 1.1.1.1 over a maximum of 30 hops

  1     1 ms    <1 ms     1 ms  192.168.10.7
  2     2 ms     2 ms     2 ms  62.141.11.116
  3     2 ms     2 ms     2 ms  10.92.6.149
  4     3 ms     2 ms     3 ms  141.101.94.16
  5    12 ms    13 ms    13 ms  141.101.94.35
  6     3 ms     4 ms     2 ms  1.1.1.1

Trace complete.

Jenze co s tim mam delat Takhle jak to mate vy si to predstavuju

Fiber Internet by mel byt postaven jako opticke vlakno mezi tebou a OLT TM (s pripadnym vlozenym splitterem, nebo vice splittery). Proto se mi nezda ta vymluva na "certifikaci v siti CETIN". Optiku v LTM IMO stavi CETIN a Amigonet.

Prihod nam sem traceroute a budeme vedet lip.

Jeste dotaz, ta puvodni pripojka od Vodafonu byla kabelovka nebo optika na siti CETINu?

Původně jsem měl u Vodafonu FTTH optiku 1000/1000 Mb/s, nikoliv kabelovku. Optické vlákno vedlo do samostatného aktivního převodníku CETIN (ONT) a z něj Ethernet do vlastního routeru. Nyní mám ze stejné optické zásuvky vlákno přímo do Sagemcomu 5670. Předpokládám tedy, že Vodafone využíval infrastrukturu CETINu, ale přesnou technologii původního ONT (GPON/XGS-PON) bohužel nevím.

Fiber Internet by mel byt postaven jako opticke vlakno mezi tebou a OLT TM (s pripadnym vlozenym splitterem, nebo vice splittery). Proto se mi nezda ta vymluva na "certifikaci v siti CETIN". Optiku v LTM IMO stavi CETIN a Amigonet.

Prihod nam sem traceroute a budeme vedet lip.

Jeste dotaz, ta puvodni pripojka od Vodafonu byla kabelovka nebo optika na siti CETINu?

Ahoj,
niekoľko poznámok:

Latencia - je to trochu viac ako obvykle, ale daná aktuálnou topológiou
aggregačnej siete. Ale vo všeobecnosti je tá latencia určite OK.
V dohľadnej dobe (3-6 mesiacov) by sa to malo zlepšit.

Zmena routra latencii nepomôže (vyplýva z predch. odseku).

MTU - TMCZ podporuje max 1492, viac nepôjde.

Zadanie Access Concentrator Name (AC-Name) v TMCZ sieti nepoužívaj,
môže sa ti stať, že sa v nejakom okamihu nepripojíš vôbec
(daný AC môže byť úplne ulitilizovaný a bude ťa odmietať),
ale vždy máš k dispozícii nejaký další voľný.

Pre tvoj región je úplne jedno, ktorý AC použiješ,
na latenciu to nemá vplyv. Nechaj to na automatiku (spojenie
sa naviaže na prvý ktorý odpovie, tj. najmenšia latencia).

PPPoE Passthrough - radšej nepouživať.
Technicky na Sagemcom 5670 PPPoE Passthrough normálne funguje,
speedtest dáva napr. 920/920 Mbps (na 1/1Gbps linke).

Všeobecne radšej PPPoE Passthrough nepoužívať, vytáča paralelne druhú/ďalšiu session,
môže spôsobiť problémy s routingom.
Ak chceš vytáčať zo svojho routra, radšej zavolaj na TMCZ Callcentrum
a požiadaj o prepnutie routra do bridge-modu.
(WAN Internet VLAN sa prebridguje na LAN port).

Ahoj, díky moc za podrobnou a věcnou odpověď!

Nejvíc mě zaujala informace o plánovaném zlepšení latence během 3–6 měsíců. Můžu se zeptat, jestli jde o nějaké konkrétní změny v agregační síti T-Mobilu, případně o optimalizaci předávacích bodů mezi CETINem a T-Mobilem?

Podle tech informaci to nevypada, ze by CETIN mel na uvedene parametry jakykoli vliv - vypada to na sdilenou fyzickou infrastrukturu, na ktere ale T-Mobile ma vlastni ONT a BRAS. To se nejlepe pozna podle nazvu tarifu.

OP, mate tarif FTTx Internet XXX (CETIN) nebo Fiber Internet XXX (T-Mobile)?

Kazda z techto siti ma vlastni topologii.

Díky za reakci. Ověřil jsem smlouvu a mám tam výslovně uvedený tarif **Fiber Internet 2000**, nikoliv FTTx Internet. Technická podpora T-Mobilu mi ale zároveň potvrdila, že vlastníkem optické infrastruktury na mé přípojce je CETIN, a právě kvůli chybějící certifikaci na síti CETIN zatím nelze aktivovat samostatný KAON PM1191.

Je tedy možné, že jde o infrastrukturu CETINu s vlastním optickým zakončením a PPPoE/BRAS T-Mobilu? Nebo označení Fiber Internet jednoznačně znamená jinou technologii?

Zdravím,

nedávno jsem přešel z internetu od Vodafonu na T-Mobile Fiber 2000/1000 Mb/s přes infrastrukturu CETIN v Litoměřicích a řeším především vyšší latenci oproti původnímu poskytovateli.

U Vodafonu jsem dlouhodobě dosahoval na Speedtestu odezvy přibližně 4–5 ms, zatímco nyní mám u T-Mobilu přibližně 9–10 ms. Chápu, že jde stále o dobré hodnoty, ale rád bych zjistil, zda je rozdíl způsoben přístupovou sítí CETINu, agregací, PPPoE koncentrátorem nebo směrováním T-Mobilu a jestli existuje nějaká možnost optimalizace.

Budu rád za zkušenosti ostatních, především těch, kteří používají T-Mobile přes CETIN na GPON.

1. Parametry přípojky

Lokalita: Litoměřice

Poskytovatel: T-Mobile

Infrastruktura: CETIN

Technologie: FTTH / GPON

Tarif: 2000/1000 Mb/s

ONT/router: Sagemcom F@st 5670

Hardware: 3.0

Firmware: SGFm100254

Protokol: PPPoE

MTU: 1492

IPv4: CGNAT

Optický signál RX: přibližně −17,1 dBm

PC: Intel I226-V, 2,5Gb/s Ethernet

Sagemcom hlásí optickou linku ve stavu OPERATIONAL a rychlost přípojky přes jeho 2,5Gb/s LAN port funguje správně.

2. Měření latence přímo přes Sagemcom

PC je připojené kabelem přes 2,5Gb/s Ethernet, nikoliv přes Wi-Fi.

Cíl

Naměřená odezva

Sagemcom (lokální síť)

pod 1 ms

PPPoE brána T-Mobilu

8–9 ms

Cloudflare (1.1.1.1)

9–10 ms

Google (8.8.8.

8–9 ms

Seznam.cz

10 ms

Ztrátovost paketů při testech byla 0 %.

Z traceroute je vidět, že většina latence vzniká už na trase k první bráně operátora. Další uzly přidávají jen minimální zpoždění.

Zajímalo by mě, zda je podobná latence na infrastruktuře CETIN → T-Mobile běžná, případně zda může souviset s regionálním předáváním provozu či topologií agregační sítě.

3. Komunikace s podporou T-Mobilu a změna BRAS

Kontaktoval jsem technickou podporu T-Mobilu kvůli vyšší latenci. Podpora ověřila připojení a potvrdila, že je z jejich pohledu vše v normě.

Požádal jsem také o informaci, na kterém BRAS/BNG koncentrátoru je moje PPPoE spojení ukončené.

Původně jsem byl připojený přes:

ph56921-bras-1

Na první PPPoE bránu jsem měl přibližně 8–9 ms.

Pracovník technické podpory následně provedl vzdálený restart portu a připojení se nově navázalo přes:

ph54483-bras-1

Výsledek byl prakticky totožný. Ping na první bránu zůstal 8–9 ms a na Cloudflare 9–10 ms.

Změna BRAS tedy nepřinesla žádné měřitelné zlepšení.

4. PPPoE Discovery a dostupné koncentrátory

Pomocí Wiresharku jsem při zapnutém PPPoE Passthrough na Sagemcomu provedl PPPoE Discovery.

Podařilo se mi zachytit odpovědi PADO od následujících koncentrátorů:

ph54483-bras-1
ph56921-bras-1
ph56921-bras-2
ph482-bras-1
ph482-bras-2

Zaujalo mě hlavně ph482-bras-1, protože ve starší diskusi z roku 2022 jsem narazil na zkušenosti s výrazně nižší odezvou oproti záložnímu bo3080-bras-1.

Je mi jasné, že jde o několik let staré informace a současné směrování může být jiné.

5. Test vlastního routeru TP-Link Archer BE3600

Vlastním také TP-Link Archer BE3600 s Wi-Fi 7 a 2,5Gb/s WAN/LAN porty.

Vyzkoušel jsem ho jako samostatného PPPoE klienta za Sagemcomem s povoleným PPPoE Passthrough.

Zapojení:

Optika
   |
Sagemcom F@st 5670
   | 2,5Gb/s LAN + PPPoE Passthrough
   |
TP-Link Archer BE3600
   | PPPoE klient
   | 2,5Gb/s LAN
   |
PC

Na Archeru jsem nastavil vlastní PPPoE přihlašovací údaje a MTU 1492.

Připojení se bez problémů navázalo a download dosahoval přibližně 2 000 Mb/s.

Objevil se však problém s uploadem, který nepřekročil přibližně 90 Mb/s, zatímco přes samotný Sagemcom dosahuji výrazně vyšších hodnot.

Současně byla přes Archer latence přibližně 10–11 ms, tedy zhruba o 1 ms vyšší než při přímém připojení přes Sagemcom.

Archer má v pokročilém nastavení PPPoE možnost ručně zadat Access Concentrator Name, takže jsem vyzkoušel také ph482-bras-1.

Ani tato změna však ping výrazně nezlepšila.

Zajímalo by mě, zda se někdo setkal s podobným omezením uploadu při PPPoE Passthrough na Sagemcomu 5670. Narazil jsem i na zkušenosti s nízkým uploadem v bridge režimu, ale nevím, zda jde o stejný problém.

Kvůli tomu jsem se nakonec vrátil k samotnému Sagemcomu.

6. Testování MTU

Zkoušel jsem také změnu MTU z výchozích 1492 na 1500.

Běžný internet fungoval i při MTU 1500, ale při ověřování přenosu větších IPv4 paketů bez fragmentace jsem získal následující výsledky:

ping 1.1.1.1 -f -l 1472

Pět požadavků skončilo timeoutem.

ping 1.1.1.1 -f -l 1464

Všech deset požadavků prošlo bez ztráty paketů s odezvou přibližně 9–10 ms.

Z toho důvodu jsem se vrátil k MTU 1492. Žádné zlepšení latence jsem při změnách MTU nezaznamenal.

Změnu DNS nepovažuji za řešení, protože obdobné hodnoty pingu naměřím i při přímém použití IP adres.

7. Bufferbloat

Provedl jsem také dva testy pomocí Waveform Bufferbloat Test.

Výsledky:

Parametr

Výsledek

Hodnocení

A

Základní latence

cca 10 ms

Nárůst při downloadu

+3 ms

Nárůst při uploadu

+18 až +26 ms

Jitter v prvním testu

0,8 ms

Ztrátovost v prvním testu

0 %

Při downloadu tedy dochází pouze k malému nárůstu latence. Při plném vytížení uploadu je nárůst vyšší a občas se objeví krátkodobá špička.

Celkově ale připojení působí stabilně a výrazný bufferbloat při downloadu se neprojevuje.

8. Možnost výměny Sagemcomu za KAON nebo Askey

Už při instalaci jsem s technikem řešil možnost využívat vlastní router.

Technik kontaktoval T-Mobile a zjišťoval dostupnost samostatného optického převodníku. Nabízené zařízení však mělo pouze gigabitový ethernetový výstup, což pro tarif 2000/1000 Mb/s nestačí.

Následně jsem narazil na KAON PM1191 s multigigabitovým Ethernetem, který T-Mobile uvádí v dokumentaci pro T Fiber.

Technická podpora mi však sdělila, že KAON zatím nemá potřebné schválení pro aktivaci na infrastruktuře CETIN a čeká se na certifikaci. Časový horizont mi nedokázali sdělit.

Další možností byla výměna Sagemcomu za novější Askey RTV7907VW s Wi-Fi 7, který podle dostupných specifikací podporuje GPON i XGS-PON.

Na prodejně T-Mobilu jsem ale zjistil, že tento model zatím nemají naskladněný a nedokážou ho ani objednat.

Aktuálně tedy zůstávám u Sagemcomu F@st 5670.

9. Na co bych se chtěl zeptat

Budu rád zejména za zkušenosti uživatelů T-Mobilu na infrastruktuře CETIN:

Jakou odezvu máte na první PPPoE bránu a na 1.1.1.1? Je v severních Čechách běžných 8–10 ms, nebo dosahujete nižších hodnot?

Může být rozdíl oproti Vodafonu způsoben způsobem agregace a předáváním provozu mezi CETINem a T-Mobilem?

Máte zkušenost s tím, že změna BRAS/BNG skutečně snížila základní latenci?

Setkal se někdo u Sagemcomu 5670 s omezením uploadu na přibližně 90–100 Mb/s při použití PPPoE Passthrough, přestože download funguje plnou rychlostí?

Podařilo se někomu na GPON infrastruktuře CETIN u T-Mobilu získat samostatné ONT s alespoň 2,5Gb/s ethernetovým portem, případně zprovoznit Askey RTV7907VW?

Neřeším nefunkční přípojku. Přes samotný Sagemcom dosahuji požadované rychlosti a připojení je stabilní. Spíš se snažím pochopit, proč mám oproti předchozímu poskytovateli vyšší základní latenci a jestli existuje nějaká technicky smysluplná možnost jejího snížení.

Budu rád za zkušenosti nebo vysvětlení od někoho, kdo zná topologii a agregaci CETIN/T-Mobile, případně fungování PPPoE koncentrátorů v této síti.

Díky všem.