DEFINITIVNÍ FUP - DŮVOD KE ZMĚNĚ ISP - PODVOD TISÍCILETÍ

[_-0-_]

...streamované rádio (128kbps) na portu 80...začne kolabovat......Restart nepomáhá (pro to rádio)...podivné...na dsl.cz i v těch 20 minutách ukazuje 600-900kbps...0/quote]

To, že je někdy limitovaný i port 80 jsem už několikrát pozoroval, se streamem rádia mě napadá jedna věc, kterou si nejsem jistý. Může to souviset s krátkodobě se zvyšující latencí a výpadky v řádu zlomek sekundy, které podle mého odhadu mohou být používány pro ztrátu spojení v download streamech v rámci jednoho z možných (a volitelných) projevů FUP_2. Od jejího zavedení jsou krátkodobé a velmi četné výpadky pozorovatelné např. na grafu z NetLimiteru (nespojitost). To by odpovídalo tomu, že měření proběhne, ale audio stream se "zasekne" a potom se musí opět naplnit buffer.

K žalobě se dá přidat - resp. se dá podílet na její přípravě - viz http://mobilforum.mobilmania.cz/viewtopic.php?t=161

[czechian]

Nové FUP je velice podivné. Poslouchám streamované rádio (128kbps) na portu 80 (HTTP, di.fm) a po 40 minutách to začne kolabovat, hraje 2 sekundy a pak 10 sekund bufferuje.. Přesně za dalších 20 minut se dá ale zase poslouchat.

Lokace: Praha 1, BTS nad Krone.

Restart nepomáhá (pro to rádio).

Co je na tom podivné je ale fakt, že měření rychlosti na dsl.cz i v těch 20 minutách ukazuje 600-900kbps.

Každopádně nemožnost stabilně mít více než 64kbps, to NENÍ rychlý internet, ale PODLAD pro žalobu..n/quote]

Pokud jsem FUP v nové formě pozoroval v rámci toku ve firewallu, tak se k 50(+-)MB na všech portech dohromady kromě http ještě při dlouhém streamu (např i stahování) po několika MB začíná rozpadat spojení. Prostě a jednoduše se dlouhé načítání snaží utnout.

[Marek Lutonský]

Pokud jsem FUP v nové formě pozoroval v rámci toku ve firewallu, tak se k 50(+-)MB na všech portech dohromady kromě http ještě při dlouhém streamu (např i stahování) po několika MB začíná rozpadat spojení. Prostě a jednoduše se dlouhé načítání snaží utnout.

[_-0-_]

Používám DC a k tomu trvale stahuji ze soukromého (trvale funkčního a přístupného) FTP (download z něj limituji na 3 kBps, samotný Strong "si bere" trvale 1-2, i když neběží žádný download). Celkový pokles datového toku tedy není daný např. nedostatkem slotů v dané chvíli, ale limitací.

Další zajímavá věc je, že zjevně dochází k nasazení FUP_1 a FUP_2 kdykoliv, ne tedy od 09:00 do 01:00 v noci.

Podle mé osobní zkušenosti se to neprojeví příliš na četnosti nutných restartů, ale na celkovém downloadu v daných dobách ano. Zásadní změna je v tom, že se dá aktuálně lépe stahovat ve dne, než ve noci (v mém případě).

Dobře to bylo vidět na grafu NIXu z 31.3.

NIX aktuálně:
http://www.nix.cz/graf2/switch_14_8_9-day.png


Na výpisu dávky je dobře vidět, že se (alespoň v mém případě) nedá jednoduše vysledovat periodicita a že je FUP aktuálně nasazeno dnem i nocí:

*************************************
************************************
DOWNLOAD SPEED AND CONNECTION MONITORING
Wed, Mar 30, 2005 12:24 *** BATCH STARTED ***
*************************************
************************************
Wed, Mar 30, 2005 12:35 LOWER THAN LIMIT 4 kBps - RESTARTING CONNECTION
Wed, Mar 30, 2005 13:20 LOWER THAN LIMIT 4 kBps - RESTARTING CONNECTION
Wed, Mar 30, 2005 14:15 LOWER THAN LIMIT 4 kBps - RESTARTING CONNECTION
Wed, Mar 30, 2005 14:34 LOWER THAN LIMIT 4 kBps - RESTARTING CONNECTION
Wed, Mar 30, 2005 14:55 LOWER THAN LIMIT 4 kBps - RESTARTING CONNECTION
Wed, Mar 30, 2005 15:53 LOWER THAN LIMIT 4 kBps - RESTARTING CONNECTION
Wed, Mar 30, 2005 16:41 LOWER THAN LIMIT 4 kBps - RESTARTING CONNECTION
Wed, Mar 30, 2005 18:01 LOWER THAN LIMIT 4 kBps - RESTARTING CONNECTION
Wed, Mar 30, 2005 18:40 LOWER THAN LIMIT 4 kBps - RESTARTING CONNECTION
Wed, Mar 30, 2005 18:59 LOWER THAN LIMIT 4 kBps - RESTARTING CONNECTION
Wed, Mar 30, 2005 19:18 LOWER THAN LIMIT 4 kBps - RESTARTING CONNECTION
Wed, Mar 30, 2005 19:37 LOWER THAN LIMIT 4 kBps - RESTARTING CONNECTION
Wed, Mar 30, 2005 20:21 LOWER THAN LIMIT 4 kBps - RESTARTING CONNECTION
Wed, Mar 30, 2005 21:31 LOWER THAN LIMIT 4 kBps - RESTARTING CONNECTION
Wed, Mar 30, 2005 21:49 LOWER THAN LIMIT 4 kBps - RESTARTING CONNECTION
Wed, Mar 30, 2005 22:26 LOWER THAN LIMIT 4 kBps - RESTARTING CONNECTION
Wed, Mar 30, 2005 22:49 LOWER THAN LIMIT 4 kBps - RESTARTING CONNECTION
Wed, Mar 30, 2005 23:10 LOWER THAN LIMIT 4 kBps - RESTARTING CONNECTION
Wed, Mar 30, 2005 23:35 LOWER THAN LIMIT 4 kBps - RESTARTING CONNECTION
Wed, Mar 30, 2005 23:59 LOWER THAN LIMIT 4 kBps - RESTARTING CONNECTION
Thu, Mar 31, 2005 00:20 LOWER THAN LIMIT 4 kBps - RESTARTING CONNECTION
Thu, Mar 31, 2005 00:41 LOWER THAN LIMIT 4 kBps - RESTARTING CONNECTION
Thu, Mar 31, 2005 01:11 LOWER THAN LIMIT 4 kBps - RESTARTING CONNECTION
Thu, Mar 31, 2005 01:20 PING_1 ERROR - GO TO NEXT TRY
Thu, Mar 31, 2005 01:20 PING_2 ERROR - RESTARTING
Thu, Mar 31, 2005 01:45 LOWER THAN LIMIT 4 kBps - RESTARTING CONNECTION
Thu, Mar 31, 2005 07:37 LOWER THAN LIMIT 4 kBps - RESTARTING CONNECTION
Thu, Mar 31, 2005 08:43 LOWER THAN LIMIT 4 kBps - RESTARTING CONNECTION
Thu, Mar 31, 2005 09:15 LOWER THAN LIMIT 4 kBps - RESTARTING CONNECTION
Thu, Mar 31, 2005 09:36 LOWER THAN LIMIT 4 kBps - RESTARTING CONNECTION
Thu, Mar 31, 2005 10:01 LOWER THAN LIMIT 4 kBps - RESTARTING CONNECTION
Thu, Mar 31, 2005 10:43 LOWER THAN LIMIT 4 kBps - RESTARTING CONNECTION
Thu, Mar 31, 2005 11:29 LOWER THAN LIMIT 4 kBps - RESTARTING CONNECTION
Thu, Mar 31, 2005 12:33 LOWER THAN LIMIT 4 kBps - RESTARTING CONNECTION
Thu, Mar 31, 2005 12:51 LOWER THAN LIMIT 4 kBps - RESTARTING CONNECTION
Thu, Mar 31, 2005 13:10 LOWER THAN LIMIT 4 kBps - RESTARTING CONNECTION

[_-0-_]

Odpověď na dotaz Esera z poprávu zamčaného vlákna http://mobilforum.mobilmania.cz/viewtopic.php?t=384

kolik MB dat se dá s novým FUP stáhnout za den ?n/quote]

Záleží na rychlosti připojení a mnoha dalších faktorech (strategii downloadu, clientu, protokolu, síti...), ale protože jsem nezměnil chování před, ani po, tak se dá něco usoudit z mého případu (z poměru downloadu).

Čísla uvádím velmi řibližně, jsou zaokrouhleným průměrem z týdenních výpisů DU meteru (s trochou historie). V samých počátcích, kdy mi připojení umělo chodit rychlostí až 1 mbps jsem měl denní průměr do 5 GB (tedy cca 50% teoreticky možného), potom mi rychlost spadla na 400-500 kbps a download se analogicky snížil opět na 50%, tedy na denních 2,5 GB. FUP_1 nečinila žádný problém, když ji zavedli, tak stačilo dvakrát clicknout krysou ve Strongu. Nicméně rychlost mi klesala nadále a ustálila se někdy v lednu, tehdy jsem se dostal na denní download přes 1 GB denně (průměr 1,2 Gb). Po zavedení FUP_2 následoval další pokles, a to na 0,6 GB denně a dnes, s použitím batch, restartující při poklesu datového toku, jsem na cca 1,1 GB denně. (Pokud mi zrovna nelimitují VEŠKERÝ datový tok všech portů na 10-12 kBps, ty dny neuvažuji.)

Obecně si nemyslím, že jsou FUP_1, a FUP_2 při vhodně zvolené strategii zásadním problémem, větším problémem je podle mě klesající rychlost připojení, nestabilita sítě, její latence atd.

[citron(smazano)]

Zdravim,

dneska pozoruju zajimavou vec - po stazeni urciteho mnozstvi dat se rychlost nemezi na 10KB/s, ale postupne a plynule klesa smerem dolu. Instaloval jsem dnes netbsd a balicky tahal z internetu. Po stazeni nejakych 30MB mi postupne zacala rychlost klesat.

Drive se ovsem rychlost snizila na cca 10KB/s a tuto hranici "drzela". Ze by nejaka nova uprava?

Nestalo se mi to pri stahovani jen z jednoho serveru. Zkusil jsem si ted stahnout neco uplne z jineho serveru a chovalo se to stejne.

[_-0-_]

...stazeni urciteho mnozstvi dat...rychlost...postupne a plynule klesa...

Také zdravím.

To je zjevně novinka. Dosud jsem se setkal jenom se skokovitým poklesem rychlosti a několikrát (nejen já, ale vzácně) znám pokles rychlosti ve dvou skocích (pozorováno při stahování z různých FTP).

Vypadá to, jako by stále hledali optimální variantu, ale stále je to jen o tom, že vyhodnotí nějaká kriteria a následně snižují datový tok. Ani tato varianta není tragická

[BooT]

no nixem bych se tu moc neohanel.....et ma jiste i nejake linky do zahranici ze? Nebo to sichni sosate jen z CR? navic jde o AGREGOVANE statistiky IP traficu ET....a kdo vi, jestli jsou ty public grafy vubec kompletni suma provozu do nixu.

PS: mame u nasich zakazniku desitky CDMA po celem Brne a okoli a nikdo si zatim na nejake problemy nestezoval...zdrejme idealni uzivatele

[_-0-_]

Dnes, v dopoledních hodinách se stala jakásí ohyzdná změna - DC je zcela k nepoužití. Nevím, jestli je to náhodný jev, nebo trvalý, ale je to další rozčarování, jakého jsem se dočkal na CDMA.

Co se stalo? Po připojení na HUBy se nespustí téměř žádné streamy (upload, ani download). Když se výjimečně nějaký spustí, tak v rychlostech okolo stovek Bps (!), file listy nejdou "ručně" stáhnout.

Ostatní: FTP a HTTP (HTTPS, POP, SMTP...) stejně jako před tím, t.j. jsou zaFUPovány pomocí již popsaného "algoritmu"...

Zlepšení: Dramaticky se snížila latence, 120 - 200 ms ping na NIX, Seznam, nasa.gov je z řádu sekund na stovkách ms...

Jestli Vás někoho napadne příčina, nebo způsob, jakým toho docílily (tvrdé y záměrně, naznačuje nenapsané slůvko), nebo jestli naopak nepozorujete stejné projevy, dejte prosím vědět. Doufejme, že to není filtrace podle packetů...

[_-0-_]

PROČ SE MŮJ PŘEDCHOZÍ PŘÍSPĚVEK OBJEVIL S DATEM 2.4., KDYŽ JSEM JEJ NAPSAL DNES, T.J. 12.4.? Prosím admina, aby tento příspěvek po opravě smazal. Děkuji.

[_-0-_]

DC je od dopolednich hodin zcela nefunkcni. Upload i download streamy jsou limitovany na mene nez 1 kBps celkem (!), navic je omezena komunikace s HUBy. Prosim, napiste jestli je to plosny, nebo lokálni jev.

Od 01:00 limitace částečně mizí, při vypnutém "send garbage" se zpomaluje download (byl to opakovaný pokus, takže nějakou váhu snad má). Nějaká forma omezení je patrně aplikovaná i v noční době, protože rychlé streamy po krátké chvíli "uhynou". Tato vlastnost, která se objevila s FUP_2 a která vždy zmizela v ranních hodinách se nezměnila.

Rád bych zjistil, jestli je limitovaná skupina zákazníků "nadměrně zatěžujících síť" (jde-li to technicky), nebo je-li to experiment v rámci některých sektorů/BTS/oblastí, nebo plošně nasazená FUP_3.

Jiné clienty už se mi ani nechce zkoušet, bylo by zajímavé, kdyby někdo napsal zkušenost s Aresem, torrenty, clienty pro IRC (Bottler a pod.)... Zkusil jsem rychlé proxy, které nejsou na blacklistu HUBů. Výsledek byl žalostný.

Pokud jsou stále "jen" limitované porty (krajně nepravděpodobné), pošlete mi prosím někdo na PM, nebo mail číslo volného portu...

FTP mi funguje stejně, jako před tím (tedy s nutností restartů), z HTTP prakticky nestahuji a POP (SMTP) funguje beze změny (tím nevyjadřuji nadšení).

Pohodlné vyhledávání na DC, vykoupené relativně malým objemem stažených dat bude vystřídáno nepohodlným vyhledáváním na FTP, odměněné relativně velkým objemem stažených dat. Sosač je naštvaný kvůli nepohodlí a současně se zvýší traffic. Tak tedy proč? Kde zůstala logika?

[_-0-_]

řešení bylo tak primitivní, až mi to vyrazilo dech. Tvůrci SW nezahálejí, stejně, jako nezahálejí "naši kamarádi" od ET. Stačí trochu hledat...

Fascinující je, že nasazením FUP_3 se provoz P2P dramaticky zrychlil, mám download na více než DVOJNÁSOBKU (někdy až trojnásobku!) předchozího.

Stal se ze mě spokojený uživatel (otázka je, jak dlouho to vydrží) ))

[Techchch]

Mám stejné výsledky, dnes je CDMA neporovnatelně lepší službou.
Nevím přesně co se stalo, ale pokud by to takto vydrželo, namám problém.
Že by dostali rozum?

[Marek Lutonský]

Mohli byste prosím popsat, co se přesně stalo? Díval jsem se i na cdma.cz, kde si rychlost také pochvalují.

[_-0-_]

Pane Marku Lutonský,

poslední dny byly nabité změnami. Napřed zavedl Eurotel regulérní FUP_3, která využívá jiný algoritmus a je účinná na většinu užívaných DC clientů. Následně (ale nikoliv jako důsledek, protože se to stalo s mnohahodinovým zpožděním) prudce klesla latence sítě (na 150-200 ms).

Dnes během dopoledne začala narůstat rychlost na HTTP a FTP, z obvyklých 150 - 300 kbps mi vzrostla na obdivuhodných 400 kbps - 1 mbps. Současně s tím opět vzrostla latence, na průměrných 300 ms (stále zázrak oproti minulosti, kdy nebyly neobvyklé hodnoty v řádu sekund).

FUP_3 sice částečně snížil traffic, ale nic takového jsem nebyl schopný vyčíst z NIXu (nevidím tam ani změny, které by odůvodnily nárust rychlosti, ani jsem nenašel očekávanou závislost mezi latencí a trafficem).

Kromě toho jsem zjistil, že jen má tupost mi zabránila v posledních dnech používání P2P přes den (nebudu uvádět "jak na to", je to tak jednoduché, že si připadám jako blb). Po oživení denního provozu DC jsem s úžasem zjistil, že stahuji několikanásobkem obvyklých nočních rychlostí a že se vše načítá mnohem rychleji se zlomkem timeoutů. (To ale není ani náhodou zásluha změn, provedených Eurotelem.) Jednoznačně se tím ale potvrdilo mé silné podezření, že je i noční provoz limitován nějakou variantou FUP_1.

Abych shrnul celkový dojem (doufám, že ne předčasně): CDMA se chová v současnosti tak, jak se chovalo v srpnu (pravda, s mnohými úpravami včetně hlídání downloadu a automatických restartů). Předběžně odhaduji, že mi opět vzroste denní download na řádově více než 3 GB - což samozřejmě neodpovídá zvýšení rychlosti, protože pomocí DC se Vám většinou nepodaří využít přenosovou kapacitu naplno.

Osobně v této chvíli nemám CDMA co vytknout (streamovaná audia ani videa mě nelákají, a služby, které provozuji fungují tak, jak mají). Doufám, že se neraduji předčasně.

Berte to vše ale prosím se značnou reservou, protože se samozřejmě nejedná o žádná seriósní měření a navíc je to empirie jednoho člověka. K mé lítosti jsem nenalezl žádnou odezvu na zavedení FUP_3 a následných změn, takže vůbec netuším, jestli popisuji plošný jev, nebo něco, co se týká nějaké oblasti, nebo snad jen dokonce sektoru.

Podíval jsem se na cdma.cz, ale na rozdíl od Vás jsem tam nenalezl potvrzení zrychlení, ale navzájem protichůdná prohlášení typu "mně to jede" a "mně to nejede". Ani z těch z těch příspěvků nelze soudit na to, zdali se nejedná jen o lokální experiment Eurotelu.

*******************************************

Frekvence restartů (úměrně vyšší k rychlosti):

Thu, Apr 14, 2005 17:14 LOWER THAN LIMIT 10 kBps
Thu, Apr 14, 2005 17:36 LOWER THAN LIMIT 10 kBps
Thu, Apr 14, 2005 17:57 LOWER THAN LIMIT 10 kBps
Thu, Apr 14, 2005 18:16 LOWER THAN LIMIT 10 kBps
Thu, Apr 14, 2005 18:34 LOWER THAN LIMIT 10 kBps
Thu, Apr 14, 2005 18:51 LOWER THAN LIMIT 10 kBps
Thu, Apr 14, 2005 19:20 LOWER THAN LIMIT 10 kBps
Thu, Apr 14, 2005 19:37 LOWER THAN LIMIT 10 kBps
Thu, Apr 14, 2005 19:55 LOWER THAN LIMIT 10 kBps
Thu, Apr 14, 2005 20:13 LOWER THAN LIMIT 10 kBps
Thu, Apr 14, 2005 20:30 LOWER THAN LIMIT 10 kBps
Thu, Apr 14, 2005 20:49 LOWER THAN LIMIT 10 kBps
Thu, Apr 14, 2005 21:10 LOWER THAN LIMIT 10 kBps
Thu, Apr 14, 2005 21:33 LOWER THAN LIMIT 10 kBps
Thu, Apr 14, 2005 21:51 LOWER THAN LIMIT 10 kBps
Thu, Apr 14, 2005 22:20 LOWER THAN LIMIT 10 kBps
Thu, Apr 14, 2005 22:38 LOWER THAN LIMIT 10 kBps
Thu, Apr 14, 2005 22:56 LOWER THAN LIMIT 10 kBps
Thu, Apr 14, 2005 23:14 LOWER THAN LIMIT 10 kBps
Thu, Apr 14, 2005 23:32 LOWER THAN LIMIT 10 kBps
Thu, Apr 14, 2005 23:41 PING_1 ERROR - GO TO NEXT TRY
Thu, Apr 14, 2005 23:42 PING_2 ERROR - RESTARTING
Thu, Apr 14, 2005 23:59 LOWER THAN LIMIT 10 kBps
Fri, Apr 15, 2005 00:33 LOWER THAN LIMIT 10 kBps
Fri, Apr 15, 2005 03:51 PING_1 ERROR - GO TO NEXT TRY
Fri, Apr 15, 2005 03:51 PING_2 ERROR - RESTARTING
********************************************
VÝPADEK (pozorovatelný na NIXu) AŽ DO:
Fri, Apr 15, 2005 04:30
********************************************
Fri, Apr 15, 2005 04:43 LOWER THAN LIMIT 10 kBps
Fri, Apr 15, 2005 05:03 LOWER THAN LIMIT 10 kBps
Fri, Apr 15, 2005 05:19 LOWER THAN LIMIT 10 kBps

Ve 3:59 spuštěna opět FUP_3 v nějaké své podobě (krátký interval mezi restarty úměrný rychlosti), od 5:19 do 8:28 bez FUP_3 Potom byla s půlhodinovým předstihem nastartována FUP_3 v podobě, známé ze včerejška (předcházející "zub" na grafu se u mě neprojevil).

Fri, Apr 15, 2005 08:28 PING_1 ERROR - GO TO NEXT TRY
Fri, Apr 15, 2005 08:29 PING_2 ERROR - RESTARTING
Fri, Apr 15, 2005 08:47 LOWER THAN LIMIT 10 kBps
Fri, Apr 15, 2005 09:24 LOWER THAN LIMIT 10 kBps
Fri, Apr 15, 2005 09:45 LOWER THAN LIMIT 10 kBps
Fri, Apr 15, 2005 10:16 LOWER THAN LIMIT 10 kBps (98 MB za 31 min !)
Fri, Apr 15, 2005 10:32 LOWER THAN LIMIT 10 kBps
Fri, Apr 15, 2005 10:56 LOWER THAN LIMIT 10 kBps
Fri, Apr 15, 2005 11:24 LOWER THAN LIMIT 10 kBps
atd...

Vyšší frekvence restartů připojení přes den není na závadu, protože se načítají data z hubů mnohen rychleji (nečeká se přes 10 minut na začátku relace - zásluha Eurotelu i změny u mě současně).

Trochu jsem to přechválil, download mezi restarty byl večer 30 stazenych MB (přes den to bylo do 50), ale stejně je to skvělé a mohu potvrdit odhad denního downloadu (průměr do limitace 40 MB) na více než 3 GB [(15,5x40x3)/1000+1,63]=3,49 GB

Naměřené hodnoty:

Noční download od 00:00 do 08:30 1,63 GB
Za půl dne - 00:00 až 12:00 2,14 GB
Za 3/4 dne - 00:00 až 18:00 2,81 GB

Limita pro snížení datového toku u FUP_3 byla včera večer i dnes ráno 30 MB (resp. 28 MB opakovaně). Během dopoledne se změnila limita na 100 MB (!), nebo se stal rozhodujícím parametrem čas připojení při velkém datovém toku. FUP_3 je tedy v poslední době tvořena souběhem limitace datového toku po 30-50 MB (někdy po uplytutí definovaného času) a stálou dramatickou limitací provozu P2P na 1 kBps.

Z intervalu mezi restarty a znalosti konkrátního objemu dat staženého mezi nimi nelze přímo odhadovat možný průměrný datový tok (je vyšší než takto konstruovaný odhad), protože v prvních minutách dochází ke komunikaci s HUBy a vyhledávání volných slotů. V tu dobu je datový tok pouze v řádu jednotek kBps.

_______________________________________________________________________

Poznámka:

Nechci razit teorii spiknutí, ale noční výpadky sítě, které se objevují velmi četně mezi 2. a 4. hodinou ranní mohou (kromě předpokládatelných "servisních operací" - ale proč by byly téměř denně a proč by byl předem ohlašován pouhý zlomek z nich) mít za cíl snižovat traffic, protože se dá předpokládat, že ne všichni používají softwarová udělátka na obnovení spojení, takže výpadek a následná krátká aplikace "násilných vytuhnutí spojení" (tento jev jsem několikrát po nocích pozoroval, následoval po výpadcích sítě) zajistí odpojení nikoliv nepodstatné části stahovačů. Pro ilustraci se stačí podívat na stránky pana Alexe - http://www.efs.wz.cz/ - sekce download na počet stažení nejkvalitnějšího dostupného redialeru, hlídajícího vše možné, od času, přes objem dat a rychlost... Ze 40 000 lidí si jej dosud stáhlo méně než 500 (1,25%) uživatelů.