[Jiri]

dovod je jednoduchy. traffic ide znova cez TATA

1 rbx-30-m1.fr.eu (91.121.98.253) 0.856 ms 1.097 ms 1.291 ms
2 rbx-1-6k.fr.eu (213.251.191.1) 0.445 ms * *
3 rbx-g2-a9.fr.eu (91.121.131.14) 1.744 ms 1.738 ms 1.910 ms
4 * * fra-5-6k.fr.eu (91.121.131.129) 7.894 ms
5 tata.as6453.de.eu (213.251.130.106) 8.381 ms 8.271 ms 8.241 ms
6 if-4-1108.tcore1.FNM-Frankfurt.as6453.net (195.219.156.133) 8.149 ms 8.076 ms 8.299 ms
7 if-5-2.tcore1.AV2-Amsterdam.as6453.net (195.219.194.13) 10.229 ms 10.406 ms if-6-3.tcore1.AV2-Amsterdam.as6453.net (195.219.194.77) 10.391 ms
8 if-2-2.tcore2.AV2-Amsterdam.as6453.net (195.219.194.6) 10.196 ms 10.172 ms 10.138 ms
9 80.231.152.22 (80.231.152.22) 14.873 ms 14.910 ms 15.192 ms
10 84.116.136.82 (84.116.136.82) 30.503 ms 30.579 ms nl-ams05a-rd2-xe-4-2-2.aorta.net (84.116.130.21) 30.730 ms
11 at-vie01a-rd1-xe-0-2-0.aorta.net (84.116.130.82) 33.899 ms 33.287 ms 29.591 ms
12 sk-bts01a-sd1-v11.aorta.net (213.46.160.18) 33.037 ms 213.46.160.26-vl12.aorta.net (213.46.160.26) 30.434 ms 213-46-160-166.aorta.net (213.46.160.166) 30.582 ms
.
.
.

[fjosty]

Děkuji za reakci!

Lžimetr teď ukazuje

Last Result:
Download Speed: 94881 kbps (11860.1 KB/sec transfer rate)
Upload Speed: 8728 kbps (1091 KB/sec transfer rate)
Latency: 89 ms

realita 3MB/s down 180 kB/s up čili o něco málo radostnější než stav cca celý minulý rok. Změna k lepšímu to ale bezpochyby je.

[lubos]

Dobrý den, toto je nejnovější informace k tématu:

"Náš link do UPC je momentálně plně vytížen. Včera došlo k drobným úpravám nastavení, takže by se mělo objevit dílčí zlepšení, ale výrazná změna se chystá až v horizontu cca dvou měsíců, kdy vejdou v platnost nové peeringové smlouvy."

Obávám se tedy, že za naši stranu (OVH.CZ) jsme momentálně dosáhli maxima možného. Situaci budeme společně s vámi monitorovat a průběžně se připomínat.

Zatím díky za všechny komentáře a... mějte s námi prosím ještě trpělivost...

[fjosty]

bump for justice. Spoj v 8 ráno na 78%

[Liquid]

Můžeš to zkusit, třeba budeš mít větší štěstí a podaří se ti to protlačit dál a někdo s tím něco udělá.

Rozhodně to bude mít ten efekt, že se načte číslo zákazníků, co reportují, že s tím mají problém. Pokud se na to každej vykašle, nemá se podpora o co opřít. Pokud to nikdo nenahlásí, neprobublá tento problém vejš, a nikdo se tím nebude zabejvat.

V podstatě je potřeba aby co nejvíce lidí reportovalo oficiální cestou tento problém.

[MCleaner]

Nemá k tomu někdo již nějaké informace?

Před nedávným 3-týdenním vylepšením to bylo s rychlostmi špatné, ale řekl bych že ne tak špatné, jaké je to nyní. S uploadem se nedostanu nad 80kbs, download se drží pod 150kbs (což při tarifu 80/15 je k vzteku). Pochopím dočasné přetížení, ale tohle trvá již několik dnů a mám obavy, že se to spíš zhoršuje.

Má kvůli tomu cenu bombardovat podporu UPC nebo OVH? Nebo obojí?

[Liquid]

Koukám, že na propoji UPC - OVH ve Vídni byl nějakej problém.

http://status.ovh.cz/?do=details&id=3664

[Liquid]

Prosím, OVH, dejte nám k Vánocům změnu v síti..... :-)

[Liquid]

Aha, no jasně, koukal jsem na opačný směr. :-)

Tak to je jasný. Proboha...

Fra - Prg - Vie tam hop do UPC a zase hurá do Prahy. Proboha, proč to dělat jednoduše, když to jde složitě?

Jak ušetřit min. 3 hopy a stovky km = jedna routa :-)

[quakerox]

Je zbytecny nad necim badat. Podivej se sem http://weathermap.ovh.net/backbone dolu doprava a je snad jasno.

Viz.
2: rbx-2-6k.fr.eu 2.444ms
3: rbx-g2-a9.fr.eu 8.681ms
4: fra-5-6k.fr.eu 52.009ms
5: pra-1-6k.cz.eu 16.441ms
6: vie-1-6k.at.eu 21.243ms
7: upc.as6830.at.eu 22.111ms asymm 10
8: at-vie01a-ra3-ge-0-1-0.aorta.net 27.597ms asymm 10
9: 213-46-160-178.aorta.net 29.014ms
10: ip-81-27-202-35.net.upcbroadband.cz 27.413ms
11: ip-81-27-204-125.net.upcbroadband.cz 27.546ms reached

Napadlo mne to sem hodit primo, at to mame pekne zvecneny:

[Liquid]

Podle posledního traceroute mi to přijde, že to leze přes Telia až do Frankfurtu a teprve tam se to předává do sítě OVH. U OVH ve Frankfurtu to vypadá v pohodě, takže odhaduji problém na spojnici Telia Víděň - Frankfurt.

Tracing route to ipv4.proof.ovh.net [188.165.12.106]
over a maximum of 30 hops:

1 5 ms 1 ms <1 ms butters [192.168.200.1]
2 * * * Request timed out.
3 18 ms 10 ms 13 ms ip-86-49-52-65.net.upcbroadband.cz [86.49.52.65]

4 17 ms 9 ms 12 ms ip-81-27-202-33.net.upcbroadband.cz [81.27.202.3
3]
5 16 ms 11 ms 12 ms cz-prg01a-ra1-ge-0-0-0-v50.aorta.net [213.46.172
.18]
6 40 ms 18 ms 16 ms win-bb2-link.telia.net [213.155.131.66]
7 24 ms 24 ms 115 ms ffm-bb2-link.telia.net [80.91.246.28]
8 28 ms 105 ms 25 ms ffm-b10-link.telia.net [80.91.247.189]
9 34 ms 109 ms 29 ms fra-5-6k.fr.eu [213.186.32.225]
10 56 ms 38 ms 157 ms rbx-g2-a9.fr.eu [91.121.131.201]
11 45 ms 38 ms 79 ms rbx-s3-6k.fr.eu [213.251.128.2]
12 39 ms 41 ms 44 ms proof.ovh.net [188.165.12.106]

Trace complete.

[quakerox]

Musim se k vam pridat panove.

Veskutecnosti jsem zil v dojmu, ze konektivta upc/ovh byla v tom spoji par tejdnu dozadu navysena (weathermap ukazoval vytizeni z 80-90% -> 1-5%) coz by tak odpovidalo.
Dle zakazniku markantni zmena zejmena ve smeru ovh->upc, z nejakejch upocenejch 300kB/s to najednou jelo cca 8-9MB/s na jedno vlakno.
Nicmene to trvalo 2-3 tejdny a uz sme zase na svejch 300kB/s; momentalne na weathermape 89% vytizeni spoje. Co se tyce peeringu pres transit telii a ne lokalni peering pres nix, bylo tady receno, ze zejmena upc povazuje spoj za adekvatni a nepocituje zadne problemy.

Zajimalo by mne, co se delo, ze to jelo ty 2-3 tejdny normalne. Jestli to bylo v dusledku uzpusobeni ovh site na novou politiku, nebo nakej kix?

Dejte nam vedet pane Cehaku. Nepochybuju o tom, ze... pravda je nekde tam venku.

[Liquid]

Ano, situaci jsem nechal chvilku spát a koukám, že se lautr nic nezměnilo. V době kdy jsem do toho šťoural mi obě strany argumentovaly dostatečnou kapacitou sítě peeringu ve Vídni.

Jak je vidět, dostatečná kapacita to není. Což si takhle ušetřit zahraniční konektivitu, zlepšit spokojenost zákazníků z ČR a předávat si trafik UPC.cz - OVH na úrovni 10G portů zapojených v NIXu? Oba subjekty mají přípojky v NIXu 4, OVH NIX4-acc2, UPC je vedle NIX4-acc4.

[fjosty]

Tak díky za demoverzi minulý měsíc kdy vytíženost UPC>OVH padala pod 5% a 120Mbit i s 10Mbit uploadem od UPC jel téměř na plno. Dnes už je vše při starém a spoj je vytížen skoro na 100% a zase to jede do kopru.

Ani ten vaš optimistický lžimetr neukáže víc než

Download Speed: 1543 kbps (192.9 KB/sec transfer rate)
Upload Speed: 6820 kbps (852.5 KB/sec transfer rate)

Můžete dát vědět co se testovalo? A proč to zase jede nahovno jako celý minulý rok

[Jan Cehák]

Zatím žádné novinky co se týče peeringu OVH a UPC nejsou.

Vaši připomínku předáme řediteli OVH. Ten jediný s tím může něco dělat.

[Jiri]

nejake novinky sa nechystaju ? vytazenost .at portov neklesne pod 60 a drzi sa okolo 80-90% , tecie tade traffic ku .cz .sk .hu .ro upc a vysledok je momentalny 150KB/s-200KB/s na spojenie

route https://pastee.org/mgxsg

edit: dalsi relevantny thread http://forum.ovh.de/showthread.php?t=11404

[lubos]

Mrzí mě to a omlouvám se. Z naší strany (česká pobočka) jsme udělali, co šlo.

[Liquid]

Takže to vzdávám, tohle je na politické vyjednávání a rozhodnutí mezi OVH a UPC. Tohle za tyto společnosti dělat opravdu nebudu.

Výsledkem je to, že prostě s dedikovanými servery k OVH od konkurence nepřejdu. Je mi jasné, že to citelná rána pro OVH nebude, ale když takto budete přistupovat i k jiným problémům, asi se Vám příliš dobře dařit nebude.

[Liquid]

A po druhém pruzení.......

Vážený kliente,


podle vyjídření správy sítě by mělo být z naší strany všechno v pořádku, žádné omezení mezi námi a Vámi udaným serverem není. Tudíž bych doporučil obrátit se na správce serveru popř. poslat nám výpis z trasy od Vás k serveru abychom se mohli dále tímto problémem zabývat.

S pozdravem a přáním příjemného dne

XXXXXX

[Liquid]

Od UPC jsem obdržel:

Vážený pane,


dovolte, prosím, abychom touto formou reagovali na Váš e-mail ze dne 28.02.2012, týkající se technického problému.

Současné řešení peeringu se sítí OVH.cz za pomocí zahraničních linek je kapacitně dostatečné, o přímém peeringu lze uvařovat v době, kdy dosavadní připojení nebude kapacitně stačit a spojení bude příliš vytížené, což se v současné době neděje. Váš problém s rychlostí spojení do sítě OVH.cz, by mohl sice být vyřešený přímým peeringem do této sítě, ale také nemusel, je tu také možnost, že společnost spravující síť OVH.cz si nastaví v přímém peeringu stejná omezení, jaká jsou na současném spojení. Každopádně vzhledem k výše uvedeným důvodům se neuvažuje u zavedení přímého peeringu se sítí OVH.cz.

Nicméně musím zdůraznit, že Vám poskytovaná rychlost připojení na internet je dle smluvních podmínek garantována pouze po síti UPC, jakmile komunikace opustí naší síť, nelze garantovat rychlost připojení. Garantujeme pouze routování po naší síti.

S pozdravem a přáním příjemného dne

XXXXXXXX

[Liquid]

Dostal jsem informace od supportu UPC, že peering zatím neudělají, protože údajně jejich zahraniční linky dostačují. Poukázali na fakt, že oni žádná omezení nedělají, a přímej peering by to nemusel vyřešit, protože i potom OVH může nastavit omezování na peering spojení.

Dnes jsem zkoušel svá data z jiných serverů protokolem RSYNC přes SSH dostat na kimsufi server. Bohužel peklo, pomalé, rozpadající se spojení. A to jsem to tahal z různých sítí, ne jen z UPC.

Takže můj závěr? Omezování se nejspíš děje na straně OVH.

Udělá s tím někdo něco? Copak zákaznící mají dál sprostředkovávat spojení mezi techniky OVH a techniky UPC a pomáhat jim s řešením situace?

[Liquid]

Tak ráno to byla vyjímka. Zbytek dne je to zoufalost.

wget -4 http://proof.ovh.net/files/1Gb.dat
--2012-02-29 18:22:31-- http://proof.ovh.net/files/1Gb.dat
Resolving proof.ovh.net... 188.165.12.106
Connecting to proof.ovh.net|188.165.12.106|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 125000000 (119M) [application/octet-stream]
Saving to: `1Gb.dat.1'

100%[================================================>] 125,000,000 385K/s in 5m 8s

2012-02-29 18:27:39 (397 KB/s) - `1Gb.dat.1' saved [125000000/125000000]

[Liquid]

Budu testovat průběžně jak si na to vzpomenu, min 1x za hodinu.

[quakerox]

Momentalne nemam po ruce nekoho s konektivitou upc. Na o2 mi to jede lip nez vcera. Ale jak rikam, tyhle vykyvy nejsou vyjimkou.
Pres noc, po ranu to jede vzdycky lip.

[Liquid]

Pochybuju. Pockej jak to pojede pres den.

Jak jsi na tom ty? Jede ti to lépe z UPC?

[quakerox]

Pochybuju. Pockej jak to pojede pres den.

[Liquid]

Dnes ráno změna. Takto to jede na mém domácím UPC 10/1:

wget -4 http://proof.ovh.net/files/1Gb.dat
--2012-02-29 07:28:17-- http://proof.ovh.net/files/1Gb.dat
Resolving proof.ovh.net... 188.165.12.106
Connecting to proof.ovh.net|188.165.12.106|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 125000000 (119M) [application/octet-stream]
Saving to: `1Gb.dat'

100%[================================================>] 125,000,000 1.22M/s in 98s

2012-02-29 07:29:54 (1.22 MB/s) - `1Gb.dat' saved [125000000/125000000]

wget -6 http://proof.ovh.net/files/1Gb.dat
--2012-02-29 07:30:36-- http://proof.ovh.net/files/1Gb.dat
Resolving proof.ovh.net... 2001:41d0:2:876a::1
Connecting to proof.ovh.net|2001:41d0:2:876a::1|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 125000000 (119M) [application/octet-stream]
Saving to: `1Gb.dat.1'

100%[================================================>] 125,000,000 1.19M/s in 2m 6s

2012-02-29 07:32:42 (971 KB/s) - `1Gb.dat.1' saved [125000000/125000000]

Routing stále přes zahraničí:
3 ip-86-49-52-65.net.upcbroadband.cz (86.49.52.65) 11.494 ms 11.626 ms 11.741 ms
4 ip-81-27-202-33.net.upcbroadband.cz (81.27.202.33) 11.378 ms 11.479 ms 11.506 ms
5 cz-prg01a-ra1-ge-0-0-0-v50.aorta.net (213.46.172.18) 37.747 ms 37.814 ms 37.853 ms
6 win-bb2-link.telia.net (213.155.131.66) 24.013 ms 19.741 ms 19.736 ms
7 ffm-bb2-link.telia.net (213.155.131.108) 28.849 ms 27.453 ms 27.505 ms
8 prs-bb2-link.telia.net (80.91.246.183) 47.244 ms prs-bb2-link.telia.net (80.91.246.185) 44.530 ms 44.560 ms
9 prs-b4-link.telia.net (80.91.251.114) 47.154 ms 47.325 ms 47.376 ms
10 gsw-1-6k.fr.eu (213.251.130.81) 40.658 ms * 39.811 ms
11 gsw-g1-a9.fr.eu (213.186.32.157) 42.795 ms 42.823 ms 42.087 ms
12 rbx-g1-a9.fr.eu (91.121.215.151) 40.668 ms 39.197 ms 45.412 ms
13 rbx-s3-6k.fr.eu (178.33.100.10) 45.015 ms * *
14 proof.ovh.net (188.165.12.106) 42.338 ms 42.294 ms 42.554 ms

Doufám, že to není vyjímka nevytíženosti nějaké části zahraničních linek, ale někdo hrábnul do konfigurace a odstranil ten QOS.

[Liquid]

Tak mám opravdu podezření na konektivitu u OVH. Nastavil jsem si tunelované IPV6, vlastní VPN server a vlastní nativní IPV6, test downloadu z proof.ovh.net, a opět rychlost pouze max 502K/s. S touto konektivitou nemá UPC co dělat.

[Liquid]

Jo, mám stejné poznatky. Mě to připadá, že je tam nějaký QOS na download jednotlivých souborů, ftp, wget..... Jakmile to jede klasicky jako web, třeba ten speedtest, tak je to v pohodě. Nevím koho přesně prudit, špatně se to popisuje, špatně detekuje, a špatně prosazuje.

Ale bohužel pro OVH, tohle je důvod, proč svoje testovací dedikované servery neprodloužit, tohle mi opravdu vadí a nasazení pro české projekty nevyhovující.

[quakerox]

Treba ten jejich "flash speedtest" na linku http://proof.ovh.net/ mi jede plnou rychlosti. Ale jednovlaknovy stahovani momentalne 400kB/s.
Kazdopadne pamatuju ze cca pred rokem, nebyl problem i pres upc stahovat jednim vlaknem 7+MB/s.

Tezko soudit, kde je chyba. Doufam ze se k tomu vyjadri podpora, ta by mohla vedet vic.

Leccos se da vycist taky z http://weathermap.ovh.net/backbone

[Liquid]

Co s tím? Prudit helpdesky telefonátama a mailama.

[Liquid]

Těžko říct, kde je to úzké hrdlo, kde dochází k ořezání. První problém je určitě peering UPC, peering v NIX jako jakovej vůbec IPV4/IPV4, druhá věc je že poskytovatelé ta spojení můžou ořezávat.

[quakerox]

Jinak co se tyce cesnetu a centria - jede bez problemu i 6+MB/s v jednom vlaknu.

[quakerox]

S tim upc je to hodne spatny uz delsi dobu.
Kazdopadne jako koncovej zakaznik o2 musim rict, ze uz je to spatny taky. Minimalne par poslednich mesicu. Neni vyjimkou ze to pres den jede 200-300kB/s. Pres noc jak kdy.

[Liquid]

Žádnej IPV6 peering z O2 = zoufalost
wget -6 http://proof.ovh.net/files/100Mb.dat
--2012-02-28 16:20:59-- http://proof.ovh.net/files/100Mb.dat
Resolving proof.ovh.net... 2001:41d0:2:876a::1
Connecting to proof.ovh.net|2001:41d0:2:876a::1|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 12500000 (12M) [application/octet-stream]
Saving to: `100Mb.dat.3'

100%[================================================>] 12,500,000 1.41M/s in 9.1s

2012-02-28 16:21:09 (1.31 MB/s) - `100Mb.dat.3' saved [12500000/12500000]

[Liquid]

Testy z jejich test serveru:

O2:
wget -4 http://proof.ovh.net/files/100Mb.dat
--2012-02-28 16:15:14-- http://proof.ovh.net/files/100Mb.dat
Resolving proof.ovh.net... 188.165.12.106
Connecting to proof.ovh.net|188.165.12.106|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 12500000 (12M) [application/octet-stream]
Saving to: `100Mb.dat.2'

100%[================================================>] 12,500,000 14.6M/s in 0.8s

2012-02-28 16:15:15 (14.6 MB/s) - `100Mb.dat.2' saved [12500000/12500000]

UPC 10/1:
wget -4 http://proof.ovh.net/files/100Mb.dat
--2012-02-28 16:12:45-- http://proof.ovh.net/files/100Mb.dat
Resolving proof.ovh.net... 188.165.12.106
Connecting to proof.ovh.net|188.165.12.106|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 12500000 (12M) [application/octet-stream]
Saving to: `100Mb.dat'

100%[================================================>] 12,500,000 332K/s in 25s

2012-02-28 16:13:10 (483 KB/s) - `100Mb.dat' saved [12500000/12500000]

[Liquid]

3: 194.228.243.74 (194.228.243.74) 1.403ms
4: 194.228.243.117 (194.228.243.117) 1.281ms
5: 194.228.190.245 (194.228.190.245) 5.764ms
6: nix.routers.ovh.net (91.210.16.129) 2.831ms asymm 7
7: fra-5-6k.de.eu (213.251.128.110) 10.806ms asymm 8
8: rbx-g2-a9.fr.eu (94.23.122.117) 19.122ms asymm 9
9: rbx-s3-6k.fr.eu (178.33.100.98) 41.484ms asymm 10
10: no reply
11: no reply
12: no reply
13: no reply

[quakerox]

Liquide hod sem tracepath/traceroute vypis z toho o2 serveru.
thx

[quakerox]

Pres nix to routuje snad uz hodne dlouho.

Pro testovani rychlosti ovh poskytuje vlastni soubory na adrese http://proof.ovh.net/files/

--2012-02-28 11:16:23-- http://proof.ovh.net/files/100Mb.dat
Resolving proof.ovh.net (proof.ovh.net)... 188.165.12.106, 2001:41d0:2:876a::1
Connecting to proof.ovh.net (proof.ovh.net)|188.165.12.106|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 12500000 (12M) [application/octet-stream]
Saving to: `100Mb.dat'

100%[================================================== ================================================>] 12,500,000 433K/s in 27s

2012-02-28 11:16:50 (448 KB/s) - `100Mb.dat' saved [12500000/12500000]


Testovano na o2 14Mbit. Jelo to cca 250-440kB/s, coz je dost malo. Kor kdyz vice vlaknama to jede klidne maximalkou (1500kB/s).

[Liquid]

Test ze serveru na síti O2.

HTTP request sent, awaiting response... 200 OK
Length: 100000000 (95M) [application/x-iso9660-image]
Saving to: `test100.iso'

100%[================================================>] 100,000,000 11.2M/s in 8.6s

2012-02-28 11:21:59 (11.1 MB/s) - `test100.iso' saved [100000000/100000000]


To je rozdíl v tom když se peeruje. :-) Donuťte už UPC udělat peering.

[Liquid]

Mám UPC 10/1 + kimsufi server. Download jsem právě otestoval jedním threadem, rychlost hodně kolísá, pohybuje se v rozmezí 400KB/s - 1,2 MB/s. Testováno wgetem. Při testu jsem ostatní provoz na UPC lince eliminoval.

HTTP request sent, awaiting response... 200 OK
Length: 100000000 (95M) [application/x-iso9660-image]
Saving to: `test100.iso'

100%[================================================>] 100,000,000 884K/s in 2m 10s

2012-02-28 11:13:00 (753 KB/s) - `test100.iso' saved [100000000/100000000]

[Liquid]

Koukám, že ze sítí O2 se už routuje přes NIX. Kdy se konečně pohne i s dalším peeringem? Hlavně také IPV6, to jede vždy všechno přes zahraniční linky.

[quakerox]

mesic utek jako voda a reakce zadna

[quakerox]

Uvodni post updatovan, ocekavam reakci od OVH.cz teamu. Diky.

[fjosty]

Stoji to samodrejme za prd,ale uz je to lepsi nez to bylo :-)

Download Speed: 28148 kbps (3518.5 KB/sec transfer rate)
Upload Speed: 2508 kbps (313.5 KB/sec transfer rate)
Latency: 70 ms

Download Speed: 21039 kbps (2629.9 KB/sec transfer rate)
Upload Speed: 1526 kbps (190.8 KB/sec transfer rate)
Latency: 139 ms

zhoršuje se to, směrem upc > ovh je to zřejmě problém i na straně upc. Směr ovh > upc je ale
nedostatečný ze strany ovh

Testováno na UPC FIBER 100/10

[Jan Cehák]

Koukněte se sem
http://forum.ovh.cz/showthread.php?p=2218#post2218
a proveďte si test rychlosti.

Když tam potom hodíte výsledky, bude to dokonalé.

[Jan Cehák]

Musíte brát v potaz, že server je skutečně připojen do naší sítě 100 Mb/s. Budete-li tedy mít na serveru v jednu chvíli třeba 1000 zákazníků a každej z něho bude něco stahovat, pak bude rychlost stahování ze serveru těch cca 12 MB/s..... Toto je primární účel serveru...obsluhovat velké množství lidí.

Další, co je potřeba si uvědomi je to, že s giganty jako je UPC se špatně jedná a když už se s nimi jedná, tak je to vždy na dlouho.

Nezbývá nic jiného, než čekat.

[PrimS]

Nevybodlo Alespoň tedy ne tady na CZ pobočce. Řešíme to s vedením, upomínáme na to atd. Navíc stále platí to, co již dříve zmínil kolega: čím víc mailů na podporu nám napíšete, tím větší je šance, že se tomu budou ve FR věnovat.

Jde o to že i jeden klient který má daný problém by měl stačit aby k jeho spokojenosti byl problém vyřešen. Já jsem k vůli toho že mi data ze serveru nešli stahovat mou rychlostí zrušil a jsem momentálně bez seedboxu. Abych tahal data takovou rychlostí je server k ničenu.

[lubos]

No dle me se na to ovh uplne vybodlo.....

Nevybodlo Alespoň tedy ne tady na CZ pobočce. Řešíme to s vedením, upomínáme na to atd. Navíc stále platí to, co již dříve zmínil kolega: čím víc mailů na podporu nám napíšete, tím větší je šance, že se tomu budou ve FR věnovat.

[PrimS]

zacinam mit neblahy dojem ze posileni peeringu ve Vidni (OVH - UPC) dopadne asi jako slovenska pobocka OVH :/

No dle me se na to ovh uplne vybodlo.....

[Limoto]

zacinam mit neblahy dojem ze posileni peeringu ve Vidni (OVH - UPC) dopadne asi jako slovenska pobocka OVH :/

Nebo třeba IPv6 peering v NIXu :-)

[quakerox]

zacinam mit neblahy dojem ze posileni peeringu ve Vidni (OVH - UPC) dopadne asi jako slovenska pobocka OVH :/

[PrimS]

Nanestesti mam opacnou zkusenost - testovano dnes navecer dvema clienty - kazdy v jinem regionu - ani jeden z nich se nedostal pres hranici cca 550-600kB/s.

Tak jsem se unahlil. To co jsem psal vyse plati, ale od dneska rana jsem taky zpet na +- 600kB/s

[quakerox]

Tak jsem od nedele vecera postrehl ze uz je vse o.k. V prumeru mi dowload frci 7-10MB/s

Nanestesti mam opacnou zkusenost - testovano dnes navecer dvema clienty - kazdy v jinem regionu - ani jeden z nich se nedostal pres hranici cca 550-600kB/s.

[PrimS]

Skvela zprava. Dekuji.

Tak jsem od nedele vecera postrehl ze uz je vse o.k. V prumeru mi dowload frci 7-10MB/s

[quakerox]

Mám tu pro Vás čerstvou novinku:
Již se plánuje posílení peering pointu ve Vídni (UPC - OVH), takže by se všem zákazníkům, kteří mají UPC jako svého ISP brzy navýšit rychlost přenosu dat.

Bohužel zatím neznáme podrobnosti jako:
- kdy přesně
- o kolik se kapacita zvýší
- atd.

Jakmile seženu další informace, napíšu je sem.

Skvela zprava. Dekuji.

[Jan Cehák]

Mám tu pro Vás čerstvou novinku:
Již se plánuje posílení peering pointu ve Vídni (UPC - OVH), takže by se všem zákazníkům, kteří mají UPC jako svého ISP brzy navýšit rychlost přenosu dat.

Bohužel zatím neznáme podrobnosti jako:
- kdy přesně
- o kolik se kapacita zvýší
- atd.

Jakmile seženu další informace, napíšu je sem.

[Jan Cehák]

Pochopitelně se snažíme tento problém vyřešit i bez Vašeho oficiálního oznámení, ale čím více zákazníků se nám s tímto problémem ozve, tím rychleji by se měl problém vyřešit.

Počítejte také s tím, že jestliže je problém v routingu či peeringu v NIXu, tak jeho řešení nebude ze dne na den

[quakerox]

Je potřeba, abyste se s konkrétními problémy, které máte, obrátili na naši podporu: podpora@ovh.cz
nebo
jestliže dokážete přiložit veškeré potřebné informace (ping, traceroute, printscreen weathermapy, kde je přetížený peering s UPC a ke všemu i datum a přesný čas + mít na svém serveru nainstalovaný OVH ssh key, aby se na to mohli administrátoři podívat přímo), tak si ze svého Manažeru můžete vytvořit ticket, který budou řešit přímo technici a administrátoři ve Francii (tím se řešení urychlí).

Zatím jsme tu na podpoře měli pouze jediné "oficiální" nahlášení tohoto problému a bohužel se nakonec ukázalo, že tazatel nebyl majitelem serveru, o kterém jsme se bavili, takže jsme problém ani nemohli dořešit (ten musel dořešit polský vlastník, takže to ani nešlo přes OVH.CZ).

Jakmile budu vědět další informace, tak je sem dám, ale určitě se nepohneme z místa, jestliže nám problém nikdo oficiálně nenahlásí či nevytvoří ticket.

Nu dobra tedy, napisu asap s timto problemem na podporu.

Cekal jsem totiz na:

Problém by mohl být s peeringem.
Předám tento podnět přímo řediteli OVH a bude-li to možné, určitě se to z naší strany vyřeší.

Jakmile budu mít další informace, objeví se pod tímto vláknem.

[Jan Cehák]

Je potřeba, abyste se s konkrétními problémy, které máte, obrátili na naši podporu: podpora@ovh.cz
nebo
jestliže dokážete přiložit veškeré potřebné informace (ping, traceroute, printscreen weathermapy, kde je přetížený peering s UPC a ke všemu i datum a přesný čas + mít na svém serveru nainstalovaný OVH ssh key, aby se na to mohli administrátoři podívat přímo), tak si ze svého Manažeru můžete vytvořit ticket, který budou řešit přímo technici a administrátoři ve Francii (tím se řešení urychlí).

Zatím jsme tu na podpoře měli pouze jediné "oficiální" nahlášení tohoto problému a bohužel se nakonec ukázalo, že tazatel nebyl majitelem serveru, o kterém jsme se bavili, takže jsme problém ani nemohli dořešit (ten musel dořešit polský vlastník, takže to ani nešlo přes OVH.CZ).

Jakmile budu vědět další informace, tak je sem dám, ale určitě se nepohneme z místa, jestliže nám problém nikdo oficiálně nenahlásí či nevytvoří ticket.

[quakerox]

Jiri: Diky za info, to znacne objasnuje situaci.

Jan Cehák: Muzete nam k tomu dat nejake blizsi info? Kdo? Proc? Na jak dlouho? Soucasny stav je pro nas samozrejme neprijatelny, precijen UPC uz neni na ceskem trhu az takova minorita. Diky.

[Jiri]

menil sa routing a teraz vsetok traffic ovh -> upc .sk/at/cz/hun/ro ide cez 2gbit vo viedni ktory je nonstop vytazeny na 95-99% http://weathermap.ovh.net/wien . predtym to islo cez gblx/teliu

[fjosty]

Mám stejný problém už tak týden. Dříve jsem dosahoval rychlostí OVH > UPC na více vláken takřka 5MB/s, dnes to není více jak 150-250kB/s. Zřejmě se jedná o omezení ze strany UPC, ačkoliv se kasají že nikdy nic neomezují.

[Jan Cehák]

Problém by mohl být s peeringem.
Předám tento podnět přímo řediteli OVH a bude-li to možné, určitě se to z naší strany vyřeší.

Jakmile budu mít další informace, objeví se pod tímto vláknem.

[quakerox]

Dobry den,

cca posledni tejden se potykam s problemem - zakaznici ceske frakce UPC maj seriznutou rychlost downsteamu z OVH na cca 100-500kB/s - jak na ftp tak webu.
Vyzkouseno na mem a kolegove kimsufi serveru a cca 3 clientech s UPC.
Chci se zeptat, je nejaky problem u Vas - s peeringem? Sam jsem na siti o2 a problem nepocituji.

Diky.
_________________________________
UPDATE ~ 24.1. 2012:

Tak od posledniho mesice (mesice a pul) uz je tento problem zrejmy i u zakazniku ceskeho o2.
Zda se, ze stahovani jednim vlaknem (jak z UPC tak o2) je omezeno na cca 100-500kB/s, zejmena pres den. Zkouseno nekolik protokolu, ruznymi uzivateli napric CR. Jakmile se stahuje vice vlakny uvedene rychlosti se scitaji. To ovsem neni mozne vzdy.