Rychlost.cz → Fórum → Všeobecná diskuze o různých typech připojení → T-Mobile FTTH 2000/1000 přes CETIN (GPON) – vyšší ping oproti Vodafonu

T-Mobile FTTH 2000/1000 přes CETIN (GPON) – vyšší ping oproti Vodafonu

T-Mobile FTTH 2000/1000 přes CETIN (GPON) – vyšší ping oproti Vodafonu

Všeobecná diskuze o různých typech připojení
od hedyyy
IP: (zobrazit)

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)
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 z

 

Vyzkoušejte náš speedtest. Fungující i bez Flashe, čistě na Javascriptu.