Přejít na obsah

DiDiDi

Uživatel

  • Registrace

  • Přítomen

Prohlédnout profil Všechny aktivity

Příspěvky od uživatele DiDiDi

    Odesláno ·

    Upraveno uživatelem DiDiDi

    Už jsem Vám to vysvětloval já i jiní, ale tak ještě jednou: T-Mobile Cable Internet funguje na infrastruktuře Vodafone, takže tato konkrétní služba TM s Vodafonem úzce souvisí. Lidi, co tady řeší optiku/DSL od TM, se snažím upozorňovat, že jsou mimo téma.

    Taky jsme v kategorii "o všem ostatním" (kam patří offtopic), kde najdete mnoho témat, které s VF souvisí ještě mnohem míň než toto.

    • Souhlasím 1

    Odesláno ·

    Upraveno uživatelem DiDiDi

    Já bych jen (opět) upozornil, že toto vlákno je o T-Mobile Cable Internet, tj. o internetu na (koax.) kabelové infrastruktuře Vodafone.

    Kdyby mi domů vedla optika (v podstatě od kohokoliv), byl bych taky na optice... 😉

    • Souhlasím 2

    Odesláno ·

    Upraveno uživatelem DiDiDi

    Co tak koukám, tak např. naši severouhorskí bratia mají běžně asymetrii i na optice, tj. mít symetrický up/download rozhodně není samozřejmost, i když to z hlediska koncové infrastruktury jde.

    U DOCSISu (kterékoliv verze) je upload problematický vždy a o symetrii si můžeme nechat zdát, zejména když se kvůli legacy DVB-C televizi koaxiální kabeláž nevyužívá 100% na internet. 

    Odesláno ·

    Upraveno uživatelem DiDiDi

    V 12. 12. 2024 v 22:10, DiDiDi napsal:

    Já tam volal a nabídli mi zvýšení uploadu za... 150 Kč měsíčně navíc. Navíc jsem zjistil, že mi účtují 100 Kč za pronájem Vodafone Station, který nepodporuje Wifi 6.

    Bum! A najednou mám 100Mbit upload a navíc platím o 200 Kč měsíčně míň. Tzv. retenční kouzlení. 😄 Měl jsem to udělat už před rokem... Jen mi teda paní z retenčního volala V NEDĚLI PŘED OSMOU RÁNO (WTF?😴). To bolelo, ale stálo to za to.

    • Haha 2

    Odesláno ·

    Upraveno uživatelem DiDiDi

    Jo takhle! Tak to je pak jiná! Pak v podstatě TM dělá to, po čem se tu kdysi volalo (možná ve vlákně "Vlastní modem"?) - možnost hloupého modem-only zařízení za nižší cenu než standardní modem+wifi+router. Jen je to v této podobě bez nutnosti podporovat / řešit kompatibilitu více zařízení. To je hodně zajímavé, zajímalo by mě, co je k tomu vede, PR si na této velmi skryté slevě pro pokročilejší uživatele s vlastním routerem asi nenahrabou...

    • Souhlasím 1

    Odesláno ·

    Upraveno uživatelem DiDiDi

    Bridge je jenom režim/nastavení modemu (resp. modemo-wifi-routeru - čisté modemy VF ani TM nenabízí, kdysi je pronajímalo/prodávalo UPC a ty v principu nic jiného než bridge dělat ani nemohly), které vypne funkcionalitu routeru/wifi a nechá jen základní funkcionalitu kabelového modemu - s tím, že router zákazník použije vlastní.

    Tak ještě aby si ISP za vypnutí části/funkcionality pronajímaného zařízení chtěl účtovat prachy... To bych je hnal! 😄

    Odesláno

    před 16 hodinami, tomus napsal:

    Já mám v mobilu přímo na ploše ikonu, na kterou když kliknu tak se dostanu přímo na webovou stránku s výpadky kde už je vyplněna moje adresa

    Zrovna tohle bylo při tom brněnském výpadku k ničemu, protože dali ten banner (co jsem citoval ve svém předchozím příspěvku) POUZE na /vypadky, ale když jsem vyplnil adresu, tak banner zmizel a bylo tam jen klasické "Ve vaší lokalitě neevidujeme žádný výpadek služeb." 😄

    Jinak co si pamatuju nějaký výpadek v minulosti, tak Vodafone (nebo to bylo ještě UPC?) uměl při volání na infolinku na výpadky upozornit, než přepojil na operátora.

    Je rozhodně fakt, že tohle fórum by nemělo být hlavní (a už vůbec ne jediný) zdroj informací o výpadku.

    Odesláno ·

    Upraveno uživatelem DiDiDi

    Tak typický SOHO router, tj. ten, který má víc než jeden LAN port, má uvnitř switch - v principu úplně stejný jako samostatný switch. Když se správně nastaví a vše (včetně modemu) se zapojí přes LAN (nikoliv WAN) sloty, může i router fungovat jako klasický switch. Takže pokud se někomu někde válí starý nepoužívaný router, určitě si nemusí pořizovat switch (za předpokladu, že LAN porty podporují adekvátní rychlost).

    U některých routerů je i WAN port součástí interního hardwarového switche, jen oddělen od zbytku pomocí VLAN. V těchto případech pak jde i WAN port zkonvertovat na LAN a získat port navíc.

    • Souhlasím 1

    Odesláno ·

    Upraveno uživatelem DiDiDi

    Záleží na routeru a jeho DHCP klientu. Já mám router s OpenWrt, který (pro IPv4) používá udhcpc/busybox. Tam stačí poslat signal, viz readme:

    Citovat

     udhcpc also responds to SIGUSR1 and SIGUSR2. SIGUSR1 will force a renew state, and SIGUSR2 will force a release of the current lease, and cause udhcpc to go into an inactive state (until it is killed, or receives a SIGUSR1). You do not need to sleep between sending signals, as signals received are processed sequencially in the order they are received.


    Můj skript na výměnu IP: 

    #!/bin/sh
set -e

if [ $# -ne 1 ]; then
        echo "specify (only) network device" >&2
        exit 13
fi

OLDIP=$(ip -br address show $1 | awk '{print $3}')
echo "old IP address: ${OLDIP:-(none)}"

PID=$(ps o pid,cmd -C 'udhcpc' | grep -Fe "-i $1 " | awk '{print $1}')

kill -USR2 $PID

echo "waiting 11 minutes after releasing DHCP lease"
sleep 11m

kill -USR1 $PID
sleep 10s

NEWIP=$(ip -br address show $1 | awk '{print $3}')

if [ -z "$NEWIP" ]; then
        echo "failed to get new IP address" >&2
        exit 14
fi

echo "new IP address: $NEWIP"

if [ "$OLDIP" = "$NEWIP" ]; then
        echo "received same IP address" >&2
fi

    A ano, stále to funguje, stále mám až tři veřejné (dynamické) IPv4 zároveň (na 4. WAN MAC adresu už se nedostane) - záleží (asi) na tarifu. Pro lidi s bridge + dynamickými IPv4 se zatím nic nezměnilo. Doufám, že to tak zůstane co nejdéle... 🙂

    Odesláno

    Pak stačí poslat DHCP Release, počkat >10 minut a požádat o novou DHCP lease (nebo prostě odpojit na víc než deset minut router/zařízení). Bez DHCP Release je třeba počkat o dost déle, nebo změnit MAC adresu WAN rozhraní routeru (ale bez restartu modemu to má svá úskalí).

    Odesláno ·

    Upraveno uživatelem DiDiDi

    @zajdee 

    --- a/net/sched/sch_cake.c
+++ b/net/sched/sch_cake.c
@@ -2462,18 +2462,18 @@ static int cake_config_diffserv4(struct Qdisc *sch)
 	/* class characteristics */
 	cake_set_rate(&q->tins[0], rate, mtu,
 		      us_to_ns(q->target), us_to_ns(q->interval));
-	cake_set_rate(&q->tins[1], rate >> 4, mtu,
+	cake_set_rate(&q->tins[1], rate >> 6, mtu,
 		      us_to_ns(q->target), us_to_ns(q->interval));
-	cake_set_rate(&q->tins[2], rate >> 1, mtu,
+	cake_set_rate(&q->tins[2], rate * 29 / 32, mtu,
 		      us_to_ns(q->target), us_to_ns(q->interval));
-	cake_set_rate(&q->tins[3], rate >> 2, mtu,
+	cake_set_rate(&q->tins[3], rate >> 4, mtu,
 		      us_to_ns(q->target), us_to_ns(q->interval));
 
 	/* bandwidth-sharing weights */
 	q->tins[0].tin_quantum = quantum;
-	q->tins[1].tin_quantum = quantum >> 4;
-	q->tins[2].tin_quantum = quantum >> 1;
-	q->tins[3].tin_quantum = quantum >> 2;
+	q->tins[1].tin_quantum = quantum >> 6;
+	q->tins[2].tin_quantum = quantum * 29 / 32;
+	q->tins[3].tin_quantum = quantum >> 4;
 
 	return 0;
 }
@@ -2713,7 +2713,7 @@ static int cake_init(struct Qdisc *sch, struct nlattr *opt,
 	q->rate_bps = 0; /* unlimited by default */
 
 	q->interval = 100000; /* 100ms default */
-	q->target   =   5000; /* 5ms: codel RFC argues
+	q->target   =  10000; /* 5ms: codel RFC argues
 			       * for 5 to 10% of interval
 			       */
 	q->rate_flags |= CAKE_FLAG_SPLIT_GSO;
-- 
2.43.0

    Nedělám žádné zásadní úpravy, jen měním poměry jednotlivých front tak, aby Voice měl 1/16, Video 29/32 a Bulk 1/64 celkového bandwidth uploadu - změna se projeví, jen pokud se použije diffserv4 (default je diffserv3, tj. jen 3 fronty, na tom tento patch nemění nic). Můj usecase je zejména streamování her přes Moonlight/Sunshine a PS Remote Play, proto to nafouknutí Video fronty. Taky jsem zdvojnásobil target, už si moc nepamatuji proč, tahle část možná není potřeba. Další část skládačky je samozřejmě správně prioritizovat packety pomocí DSCP - některé aplikace to umí přímo samy (např. VoWiFi na mém Samsungu se samo označuje a automaticky padá do Voice fronty, jak by mělo), jde to dělat na úrovni routeru ve firewallu/Xtables (např. podle použitých portů nebo IP) nebo i přímo na počítači (pak to lze vztáhnout na konkrétní aplikace) - např. u Woken viz https://learn.microsoft.com/en-us/powershell/module/netqos/new-netqospolicy?view=windowsserver2022-ps

     

    @r2d2S downloadem v principu vždy bude problém, protože nad tím, co přichází z internetu do routeru, nemáš jako klient téměř žádnou kontrolu. To nejlepší, co se dá dělat, je začít zahazovat konkétních flows, co překračují nějakou rychlost - u TCP to relativně spolehlivě zpomalí přenos, ale UDP se může dít všechno možné a co bude záviset na infrastruktuře VF a co/kdy ti VF pošle. Se shapováním downloadu jsem si tedy skoro nehrál. Jinak ale ano, jitter je problém i u mě, kabel se prostě s dobře udělanou optikou nedá srovnávat. Pingování defaultní brány (tj. nic blíž asi neexistuje): rtt min/avg/max/mdev = 5.522/7.413/14.094/1.529 ms


    Jinak pro OpenWrt jsou přímo připravené packages jako SQM a qos-scripts ( https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm a https://openwrt.org/docs/guide-user/network/traffic-shaping/traffic_shaping )

    • To se mi líbí 1

    Odesláno

    Já mám 50mbit upload (shapuju si pouze upload) a používám linuxový router (Turris Omnia s OpenWrt) s cake qdisc:

    Citovat

    tc qdisc replace dev eth2 root cake bandwidth 52480kbit diffserv4 docsis

    K těm 52480 kbit jsem došel pečivou detekcí bufferbloatu (zahltil jsem pomocí traffic generatoru z jedné veřejné IP na druhou upload a následně se pingoval s vyšší DSCP prioritou - s bufferbloatem by latence postupně stoupala).

    Bufferbloat samotný JE na straně klienta řešitelný problém, je-li stabilní rychlost uploadu (což u kabelového VF je, aspoň u mě). Všechno ostatní, zejména jitter, ne.

    Download neshapuju, tj. zahlcení downloadu je možné, ale to se mi při poměru DL:UL 20:1 skoro neděje...

    S nějakou prioritizací (používám modifikaci cake, která mění poměr jednotlivých front voice/video/standard/bulk, bohužel cake je v tomto nekonfigurovatelný, tj. musím patchovat přímo linuxový kernel) packetů je pak v pohodě možné mít plně vytížený upload uploadem do cloudu / torrentem a u toho bez vlivu na latenci hrát hry.

    • Souhlasím 1

Vodafone Czech Republic a.s.,
nám. Junkových 2808/2, 155 00 - Praha 5,
IČO 25788001, sp. zn. B 6064 vedená u Městského soudu v Praze

Vodafone Czech Republic a.s.,
Junkových sq. 2808/2, 155 00 - Prague 5,
CRN 25788001, file number B 6064 kept at the Municipal Court in Prague

Powered by Invision Community