DiDiDi

Ano. A ty jsi majitel/akcionář nebo aspoň zaměstnanec Vodafone, že to cítíš potřebu opakovaně řešit? Nikdo tě nenutil to vlákno číst, bylo v offtopic sekci a týkalo se služby, která běžela na Vodafone infrastruktuře. Což ti bylo opakovaně vysvětleno, ale ty jsi jako (concern) troll, kterým jednoznačně jsi, spamoval a prudil stále dokola s tím samým. Nikdo nerozporuje, že to bylo na hraně (to mi bylo jasné již při zakládání vlákna), ale fascinuje mě, že admini/moderátoři to zvládli 2 roky tolerovat, ale tobě, ne jim, ale tobě to leželo natolik v žaludku, že jsi to musel furt dokola řešit a mořit tu virtuální prostor stále s tou samou stížností, místo toho, abys to dejme tomu napsal jednou a vlákno přestal číst. Tj. to co by udělal soudný člověk. Nechci moderovat nic (a do tvého příchodu to nebylo ani potřeba), ale pokud celé 2leté vlákno bylo smazáno kvůli příspěvku s odkazem na stránky TM + tvému nesnesitelnému opakovanému pruzení (na tom vlákně i jinde), byla by to možnost jak držet vlákno v patřičných mezích. Nauč se číst. Napsal jsem, že jsi pako s fůrou volného času. Pointa byla, že nikdo normální by takhle opakovaně neotravoval, pokud by neměl patřičnou (finanční nebo jinou) motivaci bít se za čistotu fóra telekomunikačního operátora - víc než samotní admini a moderátoři, kteří samozřejmě zainteresovaní jsou...

Ok... Já si nic nenárokuju, jen mi to přijde škoda. Budu se opakovat, ale mít možnost vlastní vlákno nějak moderovat, tak si to pohlídám. No nic, uřvaný troll vs. zbytek fóra 1:0.

A nestačilo prostě smazat daný příspěvek? Kdybych měl možnost moderovat vlastní vlákno, tak to klidně dělám sám (a mazal bych i příspěvky týkající se čehokoliv jiného než konkrétně TM Cable Internet, který jako jediná služba běží na VF infrastruktuře)... To vlákno fungovalo v rámci pravidel snad 2 roky(?). Tedy než přišel jeden konkrétní troll (s účtem o dost mladším než to vlákno) a začal opakovaně prudit (jako by ho za to někdo platil, ale pravděpodobně jen někdo, kdo má příliš mnoho času). Do té doby to zjevně nikomu nevadilo a bylo +- v rámci pravidel (a v offtopic sekci).

Já mám upload-only cake a v dobách 50mbit uploadu jsem si přesně měřil, od jakého uploadu (s Kbit přesností) to začne bufferbloatovat. Došel jsem k cake bandwidth 52480Kbit docsis. Teď, se 100mbit uploadem, mi to vyšlo přesně na dvojnásobek, tj. cake bandwidth 104960Kbit docsis, ale neměřil jsem to teda tak zevrubně jak tehdy. Je dost možné, že s násobkama rychlosti uploadu to budou násobky tady tohoto...

V první řadě bych se podíval, jestli je na adrese i TM Cable Internet (nebo jiná konkurence mimo DSL). Na retenčním na to (myslím) hodně slyšeli.

Ty nejvyšší (a nejdražší) rychlosti budou nejvíce zajímat power usery. Nemít zrovna u nich možnost bridge mode / vlastního routeru mi přijde až mimořádně debilní...

Dvougiga tarif mě zajímá a nově by měl být dostupný i na mé adrese. Chápu ale dobře (z vedlejšího vlákna), že kvůli modemu nebude fungovat bridge mode? To by pro mě byla nepřekonatelná překážka...

Jak končí happy endem? To ti ten Fritzbox VF prodal a používáš svůj vlastní modem (namísto pronájmu)?

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.

250 + 100

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.

https://www.epravo.cz/top/clanky/vecna-bremena-v-oblasti-telekomunikaci-117459.html

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.

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.

Už tam Vodafone na výpadcích něco (málo) má:

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.

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: 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... 🙂

Nebo i v bridge bez změny MAC stačí opravdu 11 minut, ale MUSÍ se na starou adresu zaslat DHCP Release. Bez toho se musí čekat dlouho.

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í).

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

Já mám 50mbit upload (shapuju si pouze upload) a používám linuxový router (Turris Omnia s OpenWrt) s cake qdisc: 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.

Tohle (na obrázku) je úplně normální a relativně v pohodě (taky máš A). Pokud chceš něco lepšího, tak jedině vlastní router a QoS / traffic shaping.

Z některých míst teoreticky ano, ale u vyložených podvodníků bych nesázel, že to pomůže. Mnoho těchto zmrdů používá např. hack Facebooku z roku 2021, s tím nenaděláte nic (budou vám tvrdit, že číslo našli "náhodným generováním" atd.). Zkuste zadat číslo v +420xxxxxxxxx formátu na https://haveibeenpwned.com

Já bych si přinejhorším vystačil s jednou (ideálně dynamickou, pevná zrovna pro mě znamená víc nevýhod než výhod), ale tu jednu veřejnou IPv4 opravdu potřebuji - tedy dokud IPv6 nebude naprosto všude na světě (10-20 let). Mám starý tarif "gigabit za polovinu natrvalo" (Pevný internet Kabel 1000 Mbps s 50% slevou) a doteď mám opravdu konstantní úroveň služby (v dobrém i zlém, např. mám pořád jen 50mbps upload). Jestli mi VF prostě zruší všechny veřejné IPv4 a nezbude mi ani jedna, s tím, že si mám připlatit za tu jednu pevnou, tak ragequituji a budu Vodafone hanit všude kam půjdu. I kdybych měl smrdět na *DSL...

Jestli pro mě nasazení dual-stacku/IPv6 má znamenat ztrátu VŠECH veřejných IPv4 adres (teď mám 3 bez jakéhokoliv příplatku), tj. že mi nezbude ani jedna, tak si rád počkám. Třeba i 10 let...