UPC haldoklik?

Hálózatok egyéb

Elég érdekes dolgok történnek. Az imént próbáltam ssh-zni egy távoli gépre, nem tudok, csak vár, csak vár, csak vár. Mobilneten minden oké.
Az UPC oldala bejön, de a MyUPC ahol egyáltalán hibajelentést tudnék tenni nem, mobilneten sem jön be (5 perc alatt egy félig betöltött oldalt kaptam.
Egy másik vicces jelenség, speedtest.net-en a teszt fut, download teszt simán lefut, indulna az upload, de nem történik semmi.

Tapasztaltok ti valami hasonlót?

  • 14263 megtekintés

( sferi | 2016. 04. 16., szo – 02:20 )

Hali!

Legalább egy "környék" beírása segítene... mert így csak azt tudom válaszolni: Sopronban a Ferenczi János utcai nodban rendben lévőnek tűnik a dolog...

Üdv:
Feri

ugyanazon a kornyeken (89.133.135.254 az elso hop tracerouteban) nalam jo (cisco modem). Bar hasonlot meg nem tapasztaltam (es valoszinu nem relevans a problemahoz), de ezt a beallitast hasznalom mindenhol az /etc/ssh/sshd_config fajlban, enelkul gyakran eldobal (nemtudom ISP vagy router miatt): 


KeepAlive yes
ClientAliveInterval 60
ClientAliveCountMax 5

( thmir v | 2016. 04. 16., szo – 13:04 )

Nekem pár napja esett-kelt (bizonyos oldalak betöltődtek, mások nem), majd egyáltalán nem volt net, egy modem/router reboot megoldotta.
Tegnap is volt, hogy oldalak nem jöttek be, néhány stream media állandóan megszakadt, de már nem foglalkoztam vele.
BP XIII. ker.

( NCK | 2016. 04. 16., szo – 14:31 )

Tegnap Kelenföldön a Szerémi elején is szakadozott a net, UPC szerint fejállomás-hiba. Estére megjavulni látszódott.

( macko003 | 2016. 04. 16., szo – 16:58 )

csak az SSH-ddal van gond?
én pár hónapja szembesültem vele, hogy nem tudtam SSH-zni a munkahelyi szerverünk felé. Ha traceroute-olni próbáltam tcp 22-n, akkor ment, de normál ssh nem.
a furcsa az az, hogy én Diginél vagyok, a cég a GTS-nél. egyik partner is panaszkodott, ő telekom területről próbálta. mindhárom hely bp-en belüli. lehet hogy nem az upc-nél van gond, és nem az interneteléréseddel.

Nem csak az SSH problémás, bár el tudom képzelni, hogy az egy másik, vagy csak részben kapcsolódó probléma.

Minden más jelenség instabilitásra utal. Megszakadozó letöltések, sokáig tekerés, van hogy nem, vagy hiányosan tölt be egy oldal. Mindenféle dns lookup problémák, van empty response, mi szem szájnak ingere.

Jelentettem feléjük a hibát, azt mondták hogy úgy látják a jelszinttel van probléma, honlap javítják.
Nem lennék meglepve, ha kiderülne, hogy a router is elfáradt, ugyanis nem egyszer jártam már úgy, hogy a router felületébe akartam bejelentkezni, és az is nyögvenyelősen jött be.

Az SSH maga viszont nem instabilan működik, hanem stabilan NEM működik. Több, változatos helyen lévő szerverhez nem sikerült kapcsolódnom. A kapcsolat felépül, majd ez az a pont ahol csak vár, vár

debug1: kex: server->client aes128-ctr hmac-md5-etm@openssh.com none
debug1: kex: client->server aes128-ctr hmac-md5-etm@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

... majd:

Connection closed by ...

Nem hinném, hogy a klienssel vagy a szerverrel volna gond, mivel amint átmegyek mobilnetre minden oké. Ráadásul belső hálózaton gond nélkül sikerül kapcsolódnom az itteni gépekhez.

Játszottam olyasmikkel is, hogy engedélyezem/tiltom az ipv6-ot, nem segített. A router újraindítás a stabilitási gondokat néha megoldotta, néha nem, az SSH problémára nem nyújt megoldást.

Érdekesség, hogy az SSH teljesen jól működött mindeddig (tegnapig). Tegnap este már nem tudtam bejelentkezni a szerveremre, onnantól pedig kitartóan nem enged fel sehova az UPC-s kapcsolaton át.

Király vagy, köszi, megoldotta. 1500 volt alapból, automatikusan, az 1400 segített.

(kicsit bosszant, hogy hogy életemben nem kellett hozzányúlnom ehhez az értékhez, az átlag user meg amúgy se nyúlna hozzá. Telefonomon nem is tudom hogy tudok-e ilyet állítani... hmm... Azt hiszem beszélnem kell az UPC-s szakival holnap erről, mert nem állapot, hogy az alapértelmezésektől el kell térnem csak úgy hirtelen)

Ha ugy is kimennek holnap, en tuti visszaallitanam.
Ha a rutinos szervizes is ugyanerre jut, akkor ok. Ha szenved vele sokaig, akkor talan eljuttatja a kozpontnak hogy ez igy nem ok.
Ha meg tud valamit csinalni h menjen defaultbol tetszoleges MTUval, akkor meg mindenki nyer.
Ha nem jut eredmenyre, akkor mikor tavozott a bajszom alatt rohogve beallitanek alacsonyabb MTUt.

( oykawa | 2016. 04. 16., szo – 17:47 )

Milyen modem??

Újraindítani próbáltad?

Oykawa

+1
Bocsi, talán nem konstruktívnak tűnhet a hozzászólásom, de...
Több mint 15 éve vagyok UPC előfizető. Sokáig a Baross utcában laktam, tehát nem messze a tetthelytől ;), most meg a 7. kerületben.
Az ssh egyetlen esetben okozott problémát: reverz tunel nem ment, de annak is egy gagyi router volt az oka. Egyébként meg rendszeresen, nem ritkán napokig lógok ssh kapcsolaton minden probléma nélkül. Mindenki másnak meg nem működik?
Szerintem ilyen hibát a ügyfélszolgálat nem fog megoldani, még a kirendelt "szakember" sem.
Egyetlen ésszerű dolog a bridge. Az összes többi az én felelősségem, elvégre én akarok internetet használni. Ki hogyan magyarázza az nem érdekel, mert ez az olcsóbb és kényelmesebb, mint (nem) szakemberekkel vitatkozni.
Uff!

( PP v | 2016. 04. 16., szo – 22:55 )

Nálam is hasonló a helyzet. Csomó oldal nem jön be.

Nekem is ilyen gondom van egy-két oldal vagy nem tölt be, vagy csak gondolkozik! Pl. http://www.amazon.com/ egyeltalán nem az http://www.imdb.com/ viszont először timeout-ol utána betölt. Valaki lesse már meg nekem (szombathelyi), hogy ez most hálózati hiba vagy valami egyéb. Előre is köszi!

Oykawa

( szotsaki | 2016. 04. 17., v – 09:20 )

Az miért lehet, hogy a hazai oldalak bármekkora MTU-val bejönnek, míg a külföldiek csak max. 1472-es ICMP csomagmérettel (1500-as MTU-val)? Hálózatban nem igazán vagyok otthon, így csak tippelni tudok valamilyen BIX vagy UPC specifikus beállításra.

Linux alatt (a Don't Fragment bit alapból be van állítva):

ping ipon.hu -s 100000
PING ipon.hu (88.151.100.12) 10000(10028) bytes of data.
10008 bytes from ipon.hu (88.151.100.12): icmp_seq=1 ttl=55 time=25.6 ms
10008 bytes from ipon.hu (88.151.100.12): icmp_seq=2 ttl=55 time=24.3 ms


ping yahoo.com -s 1472
PING yahoo.com (98.139.183.24) 1472(1500) bytes of data.
1480 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=1 ttl=49 time=136 ms
1480 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=2 ttl=49 time=138 ms

--
The Elder Scrolls V: Skyrim

Nem tudom, nekem a routeremen 4074 van beállítva alapból, egy MikroTik RB951G-2HnD, de nem tapasztalok ilyet!

ping ipon.hu -s 100000
ping: packet size too large: 100000

ping yahoo.com -s 4074
PING yahoo.com (206.190.36.45) 4074(4102) bytes of data.
4082 bytes from ir1.fp.vip.gq1.yahoo.com (206.190.36.45): icmp_seq=1 ttl=49 time=201 ms
4082 bytes from ir1.fp.vip.gq1.yahoo.com (206.190.36.45): icmp_seq=2 ttl=49 time=200 ms

ping ipon.hu -s 4074
PING ipon.hu (88.151.100.12) 4074(4102) bytes of data.
4082 bytes from ipon.hu (88.151.100.12): icmp_seq=1 ttl=56 time=17.5 ms
4082 bytes from ipon.hu (88.151.100.12): icmp_seq=2 ttl=56 time=16.0 ms

ping yahoo.com -s 1472
PING yahoo.com (206.190.36.45) 1472(1500) bytes of data.
1480 bytes from ir1.fp.vip.gq1.yahoo.com (206.190.36.45): icmp_seq=1 ttl=49 time=194 ms
1480 bytes from ir1.fp.vip.gq1.yahoo.com (206.190.36.45): icmp_seq=2 ttl=49 time=194 ms

ping ipon.hu -s 1472
PING ipon.hu (88.151.100.12) 1472(1500) bytes of data.
1480 bytes from ipon.hu (88.151.100.12): icmp_seq=1 ttl=56 time=21.8 ms
1480 bytes from ipon.hu (88.151.100.12): icmp_seq=2 ttl=56 time=16.5 ms

Oykawa

Externeten dettó. Szerintem útválasztó-beállítás lehet:

$ ping ipon.hu -s 10000
PING ipon.hu (88.151.100.12) 10000(10028) bytes of data.
10008 bytes from ipon.hu (88.151.100.12): icmp_seq=1 ttl=56 time=18.7 ms
10008 bytes from ipon.hu (88.151.100.12): icmp_seq=2 ttl=56 time=19.3 ms

$ ping yahoo.com -s 10000
PING yahoo.com (206.190.36.45) 10000(10028) bytes of data.
^C
--- yahoo.com ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5038ms

$ ping google.com -s 1500
PING google.com (216.58.214.238) 1500(1528) bytes of data.
^C
--- google.com ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 8064ms

$ ping yahoo.com -s 1500
PING yahoo.com (98.139.183.24) 1500(1528) bytes of data.
^C
--- yahoo.com ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 2999ms

$ ping yahoo.com -s 1472
PING yahoo.com (98.139.183.24) 1472(1500) bytes of data.
1480 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=1 ttl=51 time=126 ms
1480 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=2 ttl=51 time=125 ms

$ ping google.com -s 1472
PING google.com (216.58.214.238) 1472(1500) bytes of data.
72 bytes from bud02s24-in-f14.1e100.net (216.58.214.238): icmp_seq=1 ttl=56 (truncated)
72 bytes from bud02s24-in-f14.1e100.net (216.58.214.238): icmp_seq=2 ttl=56 (truncated)

Útvonalak:
$ traceroute ipon.hu
traceroute to ipon.hu (88.151.100.12), 30 hops max, 60 byte packets
1 router (192.168.91.1) 0.304 ms 0.399 ms 0.512 ms
2 10.235.72.1 (10.235.72.1) 10.259 ms 10.272 ms 10.281 ms
3 pool-dsl-26-0004.externet.hu (217.173.38.4) 13.005 ms 13.033 ms 13.066 ms
4 pool-00e04.externet.hu (212.40.100.3) 11.397 ms 11.589 ms 11.460 ms
5 pool-00e03.externet.hu (212.40.100.2) 11.036 ms 11.099 ms 11.049 ms
6 bix2.deninet.hu (193.188.137.121) 11.157 ms 9.091 ms 8.958 ms
7 88.151.96.166 (88.151.96.166) 8.738 ms 11.698 ms 11.689 ms
8 88.151.96.160 (88.151.96.160) 15.866 ms 15.825 ms 15.856 ms
9 po25-225.c3560g-access-5.atw.hu (88.151.96.214) 12.570 ms 12.794 ms 12.570 ms
10 ipon.hu (88.151.100.12) 11.284 ms 11.296 ms 11.352 ms

$ traceroute yahoo.com
traceroute to yahoo.com (98.139.183.24), 30 hops max, 60 byte packets
1 router (192.168.91.1) 0.204 ms 0.313 ms 0.414 ms
2 10.235.72.1 (10.235.72.1) 9.089 ms 9.180 ms 9.200 ms
3 pool-dsl-26-0004.externet.hu (217.173.38.4) 10.383 ms 11.057 ms 11.125 ms
4 pool-00e04.externet.hu (212.40.100.3) 11.192 ms 11.016 ms 11.083 ms
5 pool-00e03.externet.hu (212.40.100.2) 10.234 ms 10.272 ms 10.844 ms
6 ae1-200.RT.DPX.BUD.HU.retn.net (87.245.242.200) 11.126 ms 11.097 ms 9.630 ms
7 ae0-8.RT.TLX.NYC.US.retn.net (87.245.233.114) 111.894 ms 111.833 ms 111.845 ms
8 de-cix.pat1.nyc.yahoo.com (206.130.10.49) 111.984 ms 111.930 ms 111.874 ms

$ traceroute google.com
traceroute to google.com (216.58.214.238), 30 hops max, 60 byte packets
1 router (192.168.91.1) 0.230 ms 0.301 ms 0.433 ms
2 10.235.72.1 (10.235.72.1) 6.859 ms 6.873 ms 6.864 ms
3 pool-dsl-26-0006.externet.hu (217.173.38.6) 11.771 ms 12.169 ms 12.209 ms
4 pool-00e04.externet.hu (212.40.100.3) 12.127 ms 12.129 ms 12.126 ms
5 pool-00e03.externet.hu (212.40.100.2) 11.559 ms 11.565 ms 11.592 ms
6 bix.google.com (193.188.137.163) 11.704 ms 9.495 ms 15.230 ms
7 209.85.243.121 (209.85.243.121) 18.751 ms 9.513 ms 9.440 ms
8 66.249.94.183 (66.249.94.183) 13.480 ms 9.910 ms 9.811 ms
9 bud02s24-in-f14.1e100.net (216.58.214.238) 7.685 ms 7.718 ms 7.756 ms

( manfreed (nem ellenőrzött) | 2016. 04. 17., v – 19:07 )

Sziasztok, vannak fejlemények az üggyel kapcsolatban.

Egyrészt jött a szerelő, rádugta az eszközét a kábelvégre, és megállapította, hogy nincs gond a jelszinttel. Meglepődött, amikor említettem neki, hogy amikor a hibabejelentést tettem ránéztek távolról a modememre, és akkor volt. Jobb híján kaptam egy új modemet/routert (ugyanolyat).

Elsőre látszólag minden oké. A cnet valamiért nem jött be nálam egyáltalán ma UPC-s neten, mobilneten gond nélkül böngésztem. Router csere előtt meggyőződtem róla, hogy továbbra is sikertelen a megnyitás, csere után minden jó volt, és SSH-zni is tudtam. Egy darabig. Most már megint nem :) Egyik gépen. Másikon megy. Amelyiken nem megy, azon az MTU lejjebb vétele se segít.

Szerencsére pont nem azon kell ssh-zgatnom.

( hendrick v | 2016. 07. 17., v – 09:25 )

Első kerület. Tegnap 14:30 óta nincs delej - kábelmodem nem tud felcsatlakozni a hálóra. (szokatlan, hogy ezalkalommal ezt az ügyfélszolgálat is elismeri telefonon, irányítószám alapján bejelentkezve is) Ma konkrét ügyfélszám alapján érdeklődve azt mondja be az automata, hogy talán holnap lesz civilizáció - nem csak gsm-en, hanem az ő hálózatukon is. Nagyon gyúrnak a 72 órára. Leesett egy kis eső és a civilizáció összeomlott... nesze neked "atombiztos" arpanet :)
Feliratkoztam a "van delej" sms értesítőre. Ez kellemes meglepetés. Kíváncsi leszek az sms latencyjére. A router úgyis logolja amikor úgyis lesz újra net. Rövid időkre egyébként néha visszajött éjszaka.
09:24 Up... ahh csak 19 óra off volt... ez elvileg bőven belefér a 98% éves rendelkezésreállásukba. Pedig már reménykedtem egy kis kötbérben... ugyanakkor az sms értesítő késik egyelőre.

IX. ker-ben áll a net. Ma már másodjára. Egy leállás délelőtt, egy délután. Modem nem tud felcsatlakozni. Állítólag tervezett karbantartás, de a leállás nincs a tervben. Mondhatni nincsenek a helyzet magaslatán :( Máshol van hasonló helyzet?

( wlaszi | 2017. 08. 31., cs – 15:50 )

A nemzetközi oldalak lassan/nem jönnek be (pl fb,google,bbc,cnn). A .hu-k gond nélkül.
Másvalaki tapasztal ilyesmit?
XI. ker.

--
"The only valid measurement of code quality: WTFs/min"

Egyéb problémák is voltak - index.hu, mint eklatáns példa, egyáltalán nem töltődött be, valamint a facebook CDN-jei sem voltak elérhetőek, ugyanakkor nagyjában-egészében minden működött. Miután megbizonyosodott, hogy csak tőlem nem jó semmi, egyesével kireszeltem az egyenletből minden ismeretlent a wireless-nél kezdve a névfeloldáson át felfelé, a végén az IPS maradt, ami valamiért minden átmenet nélkül úgy döntött, hogy ezeket utálja. :)
------------------------
{0} ok boto
boto ?

( flatline | 2017. 09. 06., sze – 09:47 )

UPC szinte az egész országban lehalt.
Az egy dolog, ha egy eseti hibáról lenne szó, de augusztusban is folyamatosan szolgáltatáskimaradások voltak, volt olyan is, hogy 3 napig se net, se TV, se telefon.
Már elnézést, de ez így nem szolgáltatás. Megvolt a hibabejelentés, visszahívás kérés, azóta is szorgalmasan hívnak. Ez így lóf@sz esti fénnyel.

Rohamosan zuhan a szolgáltatás minősége náluk ás az ügyfél támogatás is gyalázatos.
Ennyi problémám és szolgáltatás kimaradásom még egy szolgáltatóval sem volt, mint a UPC-vel az elmúlt 1 évben.
Pár évvel ezelőtt még a UPC is ennél jobb cég volt azért.

♲♻♲

2 éve kötötték be nálunk az üveget. Első évben nem volt semmi gond a szolgáltatással.
Viszont az elmúlt közel egy év az valami gyalázatos volt. Ha van is net szakadozik, szomszédban anyám nézi csak az ip tévét, de az is csak scarton keresztül megy, mert hdmi kábellel állandóan szaggat, kép be sem jön csak a hang szakadozik.
Hónapok óta bármikor pingelek kifelé a hálózatból 15-20% csomagvesztés. Szégyen gyalázat. Ha meg a hűségnyalatkozatot felbontom, fizethetem a kötbért...
Már ott tartok, hogy inkább telefonomról osztok mobilnetet a háztartásban, hogy lehessen netezni.

( uid_20269 | 2017. 09. 06., sze – 09:53 )

VIII.ker, kilenctől nagyjából oké
--
God bless you, Captain Hindsight..

Üdv,
a mai UPC elhalálozás nálunk (Erdőkürt) oka, hibás config fájl került az eszközre.
03:12 körül töltötte volna le a configfajlt, ez nem sikerült, így unknow.cfg-vel futott tovább az eszköz.

Se DHCP, se semmi nem volt, a mikrotikbe kézzel felvettem a 192.168.100.20 IP-t ezután a szokott 192.168.100.1 felületen fogadott az eszköz,

8:36-ig tartot ekkor ujra letöltötte a config fájlt (fiberpower500_v4-sip.cfg) és ismét ment minden a régiben.

Hogy TV kimaradás volt-e nem tudom, telefon nem volt ez tuti.

Környék: Csepel

Bár nem néztem meg, mi akasztotta meg a UPC dobozt, de a lehalás és feléledés időpontjai nagyon egybevágnak. Nálam 192.168.100.2-es IP kapott a házi router.

Az céges UPC internet (II. kerület) bár él, de degradált sebességgel megy.

UPDATE

Kb. dél fele az üvegkábeles szolgáltatás is visszatért a normális működési szintre. Előtte kb. 6/40 Mbites D/U sebességet produkált. Válaszolt mindenre, de mint az anyatetű, olyan tempóval.

--
Kinek nem inge, ne vegye gatyára

( asdPro | 2017. 09. 06., sze – 10:13 )

8. ker, én mostanában olyat tapasztalok, hogy 1-2 mp-re megy el a net. Utána vissza is jön, viszont elég ahhoz, hogy bármilyen aktív VPN, RDP, Online játék, stb. kidobjon arra az időre. Marhára idegesítő.

( Nyosigomboc v | 2017. 09. 06., sze – 16:29 )

Ma nalam sem volt net, XIII. ker., 3:37 es 8:41 kozott.

--
Worrying about killer AI and the superintelligent robots is like worrying about overcrowding on Mars. - Garry Kasparov

( ha5abe | 2017. 09. 07., cs – 10:51 )

Másfél hete Pomáz, Csobánka, Szentendre,,,," teljes kétnapos kiesés volt.
Tegnap is.
Küldtek, egy levelet, hogy:

*****************************************
"Kedves Ügyfelünk!
Augusztus 17-19. között a UPC szolgáltatásaiban hosszabb kimaradást tapasztalhatott.

Bár a szolgáltatás zavartalan igénybe vételét tőlünk független indokok befolyásolták, kérjük, engedje meg, hogy az Önt ért esetleges kellemetlenségekre tekintettel az alábbiakkal kedveskedjünk.

Önnek szeptember 4. napjától kezdődően 1 hónap időtartamon keresztül lehetősége nyílik arra, hogy az HBO GO szolgáltatást díjmentesen igénybe vegye a jelenlegi internet előfizetése mellett.

Tájékoztatjuk, hogy a szolgáltatás igénybevételéhez regisztráció szükséges, ehhez a regisztrációs útmutatót e-mailben küldjük meg az Ön részére. A tájékoztató tartalmazza az aktiváló kódot, valamint egy linket, amely a www.hbogo.hu oldalra irányítja.
Az HBO GO oldalán ügyfélszáma megadásával, illetve szolgáltatója (UPC) kiválasztásával tudja a regisztrációt elvégezni. A szolgáltatás elérhető asztali számítógépen és laptopon böngészők segítségével, valamint mobil eszközökön (táblagép, okostelefon) a HBO GO saját alkalmazásán keresztül.
További információkat a https://helpcenter.hbogo.eu/hu oldalon talál.

Köszönjük a megértését és bízunk benne, hogy szolgáltatásainkat a jövőben is örömmel használja majd!"
*****************************************

Nem tudom ki hogy van vele, én nem kérem a TV csomagot. inkább fizessenek kötbért.

Elég gusztustalan hasonlat. Nálam az HBO nem minősül banánnak. Persze való igaz, hogy egy valódi majom álmodozhat banánról. Nekem a folyamatos szolgáltatás a fontos. Ha fizetniük kellene - nem csak nekem, hanem sokaknak, nem kérésre, hanem automatikusan - az jobban fájna nekik és jobban bebiztosítanák magukat. Itt redundanciára gondolok, legalább a kritikus helyeken. Hogy egy nagy terület két napra kiessen, az durva. Hogy mennyit kellene fizessenek automatikusan? Ebben nem vagyok járatos. De annyit, hogy ne érje meg nekik nagyon spórolni a hálózatukon. Talán elég lenne, ha havonta egyszer is előfordul 2 órás kiesés, akkor a havi díjat ne számlázhassák ki arra a hónapra. Ez persze sokkal jobban ki kellene dolgozni, mert az sem jó, ha nagyon akadozik, ha túl sok a hibás csomag, lassú a válaszidő, stb...

Rossz oldaláról fogtad meg a dolgot. A kérdés az volt, hogy te mekkora rendelkezésre állást vársz el és mennyit fizetnél érte? Mint írtam, az üzleti csomagoknál is csak 99,5 százalék az éves rendelkezésre állás, nemhogy sima lakossági csomagnál... a szakértelmet, a redundanciát és a készenlétet meg kell fizetni... fizetnél-e tízszer ennyit 99 százalékos rendelkezésre állás helyett 99,9 százalékos rendelkezésre állásért?

Most akkor szűkítsük le a saját magamra? Nem fizetnék 10x annyit. Csak, ha valami rákényszerítene és behozná az árát. De én rossz példa vagyok, mert rám nem a tartalomfogyasztás a jellemző. Én elvagyok 28k sávszélességgel is, ha az stabil. Ezen elérek távoli citrix virtuális gépeket és más vasakat és megoldom rajtuk, amit szükséges. 30M sávszélesség nálam nagyon ritkán van kihasználva. Tudom, ez utóbbi másoknál is általános. Hogy engem mennyire bosszant egy kétnapos kiesés itthon? Nos én megoldom. Van kerülő utam. Több is. Így tehát hagyjuk, hogy én személyesen fizetnék-e 10x annyit.

Tudom, nem fog tetszeni a sok zsigerből anyádozonak, de miről is beszélünk?

5000/30=166

Tehát ha 2 napig nem megy, akkor 320 Ft-ról beszélünk! És ezért tartsanak nektek redundáns atomerőművet (csak a te kedvedért)...
Ezen habzik a szája mindenkinek... A szolgáltató helyében akkor mondanám, h tessék itt a 320 forintod!

Ahogy mások is írták, valamit valamiért, gondolkodjuk Béláim! :)

Nem értitek. Nem magamról beszélek. Engem a történet úgy érint, hogy az a fontos számomra, hogy másoknak (is) legyen rendben szolgáltatás. Vagy legyen nekik is lehetőleg azonnali és az adott feladatra alkalmas alternatív lehetőségük. Ha ők (pontosabban egy részük) izoláltá válnak egy időre, az nekem sem jó. E miatt tehát nehézkes az én igényemet kimatekozni. Összességében tehát annak örülnék, ha a szolgáltatók jobban érdekeltek lennének abban, hogy ne legyen sem gyakori, sem pedig hosszadalmas kiesés.

( bacsi2 | 2017. 09. 17., v – 17:12 )

XI. Kerület, Újbuda-központ: internet nem megy.

( uid_3194 | 2017. 11. 16., cs – 06:29 )

UPC-ről valaki tapasztalt ma reggel valamit?

2 ügyfél is UPC-s, egyiket el sem érem, másik elérhető, de kifelé 25-ös porton time out. Legalább hajnali 2 óta.

--
Tanya Csenöl az új csatorna

( royal v | 2018. 03. 27., k – 14:01 )

Az UPC a XIII. kerületben másnál sem működik úgy 12:40 óta?
Több ügyfél is jelezte, hogy porszem van a gépezetben...

--
http://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer

( fuligjimmy | 2018. 07. 17., k – 07:37 )

UPC külföldi webó'dalak, szolgáltatások BP XIII-ból csak nekem nem mennek (finoman szólva akadoznak), vagy mást is szórakoztat a upc?