Andy
14-07-2009, 12:11
Me neither, lets hope they do something!
Routing: Virginmedia scotland to Quake3 servers ovh.net
freshwire
14-07-2009, 11:14
I didn't even get a response so congrats
Myatu
14-07-2009, 09:58
Originally Posted by monkey56657
Edit: Well, the response thus far is "Thanks for that flag - and glad that includes some traceroutes! Will get networks on the case, thanks. AB" -- we'll see where this will be taken, if anywhere at all.
freshwire
14-07-2009, 02:44
Ye virgin prefer to route the traffic via germany before back to france.
They did use amsix at one point.
If you use twitter send them a message to use amsix or linx to get to ovh/roubaix. @virginmedia
They did use amsix at one point.
If you use twitter send them a message to use amsix or linx to get to ovh/roubaix. @virginmedia
Myatu
13-07-2009, 23:40
Right, most routers deprioritise ICMP. But if it's so busy it can't find time to respond, and the next hop is spiking over 100 ms, I'll raise an eyebrow.
Andy
13-07-2009, 22:52
ICMP is deprioritised. OVH routers don't always respond. It doesn't mean there is packet loss.
The reason the routing is so crappy is because VM refuse to peer with LINX or use AMSIX for connection to OVH. They insist on using DTAG transit in Franfurt. No amount of pleading with VM has changed this, and we've been trying for over a year.
The reason the routing is so crappy is because VM refuse to peer with LINX or use AMSIX for connection to OVH. They insist on using DTAG transit in Franfurt. No amount of pleading with VM has changed this, and we've been trying for over a year.
Myatu
13-07-2009, 22:21
Interesting, when I tried to do a traceroute to your 5th hope, rbx-2-6k.routers.chtix.eu was giving me trouble. So I tried to only your 9th hop...
Attempt 1 (2 lost packets):
Attempt 2 (2 lost packets, th2-1-6k > 100 ms):
Attempt 3 (no ping response from th2-1-6k):
I'm getting the same results from Goscomb (UK) with a 100+ ms spike at rbx-2-6k:
And Ireland is suffering as well:
Now, my reverse route from my server at OVH to VirginMedia in Edinburgh (62.253.0.1) shows that VirginMedia isn't exactly the king of speed either but at least consistent with 26~34 ms:
Attempt 1 (2 lost packets):
Code:
# tracert 213.251.130.13 traceroute to 213.251.130.13 (213.251.130.13), 30 hops max, 40 byte packets 1 rbx-16-m2.routers.ovh.net (91.121.67.252) 1.116 ms 1.397 ms 1.885 ms 2 rbx-2-6k.routers.chtix.eu (213.251.191.130) 8.208 ms * * 3 th2-1-6k.routers.chtix.eu (213.251.130.13) 5.044 ms 5.041 ms 5.242 ms
Code:
# tracert 213.251.130.13 traceroute to 213.251.130.13 (213.251.130.13), 30 hops max, 40 byte packets 1 rbx-16-m2.routers.ovh.net (91.121.67.252) 0.873 ms 1.180 ms 1.462 ms 2 rbx-2-6k.routers.chtix.eu (213.251.191.130) 0.640 ms * * 3 th2-1-6k.routers.chtix.eu (213.251.130.13) 149.303 ms 149.300 ms 149.419 ms
Code:
# tracert 213.251.130.13 traceroute to 213.251.130.13 (213.251.130.13), 30 hops max, 40 byte packets 1 rbx-16-m2.routers.ovh.net (91.121.67.252) 0.913 ms 1.260 ms 1.644 ms 2 * * * 3 th2-1-6k.routers.chtix.eu (213.251.130.13) 4.658 ms 4.656 ms 4.773 ms
Code:
Hop Node Loss% Sent Last Avg Best Worst StDev
1. 77.75.104.121 0.0% 5 0.4 0.5 0.4 0.6 0.1
ae0-1235.rt2.the.uk.goscomb.net.
2. ??? 100.0 5 0.0 0.0 0.0 0.0 0.0
3. 213.251.130.57 20.0% 5 141.8 49.2 8.5 141.8 63.3
rbx-2-6k.routers.chtix.eu.
4. 213.251.130.13 0.0% 5 12.4 15.3 12.0 20.7 3.9
th2-1-6k.routers.chtix.eu.
Code:
Hop Node Loss% Sent Last Avg Best Worst StDev
1. 91.189.70.129 0.0% 5 0.3 0.4 0.3 0.5 0.1
rr6.mve.gal.core.airwire.ie.
2. 195.222.111.251 0.0% 5 0.5 0.4 0.3 0.6 0.1
qp1.mve.gal.core.airwire.ie.
3. 195.222.111.203 0.0% 5 4.3 4.4 4.1 4.9 0.3
qp2.tcy.dub.edge.airwire.ie.
4. 84.203.155.21 0.0% 5 4.6 4.8 4.5 5.3 0.4
ge0-0-0-106.edge2.tcy.dub.stisp.net.
5. 84.203.130.165 0.0% 5 5.6 5.4 4.7 5.8 0.4
ge1-3-0-111.core1.tcy.dub.stisp.net.
6. 195.66.224.220 0.0% 5 15.7 16.0 15.5 17.2 0.7
sw1.tc.lon.ovh.net.
7. 213.251.130.57 20.0% 5 188.6 134.9 23.0 234.3 94.8
rbx-2-6k.routers.chtix.eu.
8. 213.251.130.13 0.0% 5 22.8 26.5 22.8 30.7 2.9
th2-1-6k.routers.chtix.eu.
Code:
# tracert 62.253.0.1 traceroute to 62.253.1 (62.253.0.1), 30 hops max, 40 byte packets 1 rbx-16-m2.routers.ovh.net (91.121.67.252) 1.496 ms 1.701 ms 1.800 ms 2 rbx-1-6k.routers.ovh.net (213.251.191.1) 3.291 ms * * 3 40g.ams-1-6k.routers.ovh.net (213.251.130.66) 5.903 ms * * 4 mpr1.ams1.nl.above.net (195.69.144.122) 6.200 ms 6.198 ms 6.196 ms 5 so-2-1-0.mpr2.ams5.nl.above.net (64.125.31.254) 6.538 ms 6.536 ms 6.534 ms 6 xe-3-2-0.mpr1.lhr2.uk.above.net (64.125.31.246) 9.272 ms 9.007 ms 8.995 ms 7 * * * 8 man-bb-b-so-010-0.network.virginmedia.net (62.253.185.134) 24.961 ms 24.954 ms 24.949 ms 9 edin-core-1a-v2.network.virginmedia.net (62.253.0.1) 32.640 ms 32.633 ms 32.627 ms
rickyday
13-07-2009, 21:30
I get pings of 28ms/27ms/27ms on Virginmedia 50Mb service if that helps?
morbid
22-06-2009, 22:50
Hi all,
I have been in and out of this forum looking for some answers to the routing issues that virginmedia and ovh.net seem to have.
I have access to a Q3 server box running inside the ovh.net network, since summer of 2008.
In the beginning all was ok with the routing, most clients getting connected with ease and good rate, even my connection was pinging at around 40ms from Scotland.
For the last few months the connection in and out of this network is variable, mostly very bad but late at night it improves.
connection speeds range from :
60ms [best] to around 260ms
ping was 33ms on day 1 of launching this public server.
It is now quite normal for the connection to drop several times per night.
what is curious about this is the client data does not seem to reach the server but I can still get data coming back from the server.
1 way lag: rebooting the client router will resolve this for a time.
server is located at : 213.251.160.63: port 29968
there are 4 server's all behaving in the same manner as described above., each running on an unique port with the same ip.
the q3 server uses udp packets to send and receive data, only tcp/ip is used to find and connect the client to the server, after the client has established the connection udp is used from there on in. These are simple datagrams packets.
I get the feeling that the problem is partly VM related.. "oversubscribed and under managed", However I would be interested in any feedback relating to this problem from ovh.net.
I have tracert data going back months.
here is a trace to the above server ip : 22 june 2009 @ 22.38uk time.
4 31 ms 29 ms 41 ms man-bb-a-ae1-0.network.virginmedia.net
[195.182.178.90]
5 19 ms 34 ms 24 ms man-bb-b-ae0-0.network.virginmedia.net [62.253.1
87.178]
6 24 ms 29 ms 29 ms nth-bb-a-as3-0.network.virginmedia.net [213.105.64.21]
7 50 ms 40 ms 56 ms fran-ic-1-as0-0.network.virginmedia.net [62.253.185.81]
8 * * * Request timed out.
9 191 ms 212 ms 187 ms th2-1-6k.routers.chtix.eu [213.251.130.13]
10 54 ms * 53 ms 80g.p19-2-6k.routers.chtix.eu [213.186.32.150]
11 60 ms 56 ms 59 ms p19-17-m1.routers.chtix.eu [213.251.130.181]
12 51 ms 61 ms 60 ms ns32242.ovh.net [213.251.160.63]
packet loss and rate is throttled always..?
udp packets need no queuing on a router as they do not require any responce ..?
There are several clients connecting to the above server from Virginmedia network and all have this problem, and some clients on other isp's seem to have similar issues..
Maybe this story is getting old .. but it is still very much an ongoing problem, it would be nice to get some answers and maybe even fixed.
Thanks a lot for reading this post.. and I hope its in the right place.
best
morb! [scotland]
I have been in and out of this forum looking for some answers to the routing issues that virginmedia and ovh.net seem to have.
I have access to a Q3 server box running inside the ovh.net network, since summer of 2008.
In the beginning all was ok with the routing, most clients getting connected with ease and good rate, even my connection was pinging at around 40ms from Scotland.
For the last few months the connection in and out of this network is variable, mostly very bad but late at night it improves.
connection speeds range from :
60ms [best] to around 260ms
ping was 33ms on day 1 of launching this public server.
It is now quite normal for the connection to drop several times per night.
what is curious about this is the client data does not seem to reach the server but I can still get data coming back from the server.
1 way lag: rebooting the client router will resolve this for a time.
server is located at : 213.251.160.63: port 29968
there are 4 server's all behaving in the same manner as described above., each running on an unique port with the same ip.
the q3 server uses udp packets to send and receive data, only tcp/ip is used to find and connect the client to the server, after the client has established the connection udp is used from there on in. These are simple datagrams packets.
I get the feeling that the problem is partly VM related.. "oversubscribed and under managed", However I would be interested in any feedback relating to this problem from ovh.net.
I have tracert data going back months.
here is a trace to the above server ip : 22 june 2009 @ 22.38uk time.
4 31 ms 29 ms 41 ms man-bb-a-ae1-0.network.virginmedia.net
[195.182.178.90]
5 19 ms 34 ms 24 ms man-bb-b-ae0-0.network.virginmedia.net [62.253.1
87.178]
6 24 ms 29 ms 29 ms nth-bb-a-as3-0.network.virginmedia.net [213.105.64.21]
7 50 ms 40 ms 56 ms fran-ic-1-as0-0.network.virginmedia.net [62.253.185.81]
8 * * * Request timed out.
9 191 ms 212 ms 187 ms th2-1-6k.routers.chtix.eu [213.251.130.13]
10 54 ms * 53 ms 80g.p19-2-6k.routers.chtix.eu [213.186.32.150]
11 60 ms 56 ms 59 ms p19-17-m1.routers.chtix.eu [213.251.130.181]
12 51 ms 61 ms 60 ms ns32242.ovh.net [213.251.160.63]
packet loss and rate is throttled always..?
udp packets need no queuing on a router as they do not require any responce ..?
There are several clients connecting to the above server from Virginmedia network and all have this problem, and some clients on other isp's seem to have similar issues..
Maybe this story is getting old .. but it is still very much an ongoing problem, it would be nice to get some answers and maybe even fixed.
Thanks a lot for reading this post.. and I hope its in the right place.
best
morb! [scotland]