How does Vmedia cable internet works?

[Khalietal]

Good day folks!

I'm a new customer to VMedia. I live in Trenton, Ontario, use their Cable internet service 55/10.
I am curious to understand how Internet works between ISP and Customers.
My service is pristine most of the time, running at peak performance most of the time according to speedtest.net with various server test.
I can download massive amount of data in short order but when it comes to online gaming, it falls short.

I am not sure to understand what makes gaming a tougher thing to achieve so I ask professional to help me understand the ins and outs of internet providing eheh!

can't wait to learn more about it!

[Khalietal]

My average ping is 15-25ms.. I run a private Minecraft server for couple of friends. Never had issue with it before. I also play Guildwars2, Defiance and Warframe. They used to run very smooth on 14mbps before with no lag from my side.. Minecraft, I see my friends lag by spikes of 3 seconds or more and then they catch up for a while, running extra smoothly. It repeats itself until they finally get timed out at which point they have to log back in after the spike lag. The internet never crashes for good, but it feels like it cant keep a solid flow for more than maybe 10 seconds.. As for the other games like defiance, its the same but I get to endure the spike lags.. I don't understand why it looses its speed momentarily like that all the time.. I don't feel that effect for downloading or watching streams that have buffers.

[synack]

15-25ms can be good or bad, depending on where the other end is.

Something local should be in the 1-10ms. Ontario to California would be around 30-40ms.

A tracert would give you hints on the path the traffic needs to take and the ping times to each hop (assuming that hop responds, not all do).

Also realize that internet traffic doesn't take the most sensible paths, it depends on who your isp has peering arrangements with. For instance from my Toronto office to my Toronto VoIP provider, the packets go through New York and back. I get lower ping times using my VoIP providers New York server!

I also run a private MC server and found that MC can get very laggy with lots of objects and not enough RAM. Try upping your xmax a bit and see if it helps.

Since you were wanting to learn...
Here is an example tracert from my house (vmedia via rogers cable) to www.yahoo.com:

hop    Address                                  round trip time (avg)
1      10.123.188.129                           10.6 ms
2      van58-6-240-57.dynamic.roger...          17.6 ms
3      69.63.249.193                            14.0 ms
4      204.197.190.137                          14.7 ms
5      10ge15-1.core1.tor1.he.net               14.9 ms
6      100ge13-1.core1.chi1.he.net              25.3 ms
7      exchange-cust1.ch1.equinix.NET           22.6 ms
8      ae-0.pat2.nez.yahoo.com                  41.2 ms
... (cut bouncing around yahoo)
13     bas2-7-prd.ne1.yahoo.com                 42.2 ms
14     98.138.253.109 (www.yahoo.com)           32.6 ms

This tells me that to get to yahoo.com my packets apparently go first to Vancouver on Rogers, back to HE in Toronto and Chicago, to Equinix in Chicago and then off to Yahoo in Sunnyvale California (according to geoip).
It also tells me that the round trip times are wonky probably due to either multiple paths or saturated links. Ideally hop 3 should never return faster than hop 2.
This trace route is actually quite ugly and indicative of a problem somewhere. My guess is that some major network link is down and BGP is still converging. I might try this again later and see if its the same.

That help at all?

[synack]

It appears I misspoke on the vancouver rogers. it is in fact rogers in Toronto... but oddly it's 17ms. and that's still not good.

[Trentelshark]

It appears I misspoke on the vancouver rogers. it is in fact rogers in Toronto... but oddly it's 17ms. and that's still not good.

I believe regardless of where you are located in Canada, if you are on Rogers network by CRTC regulations all traffic must route through the York Mills APOI so all IISPs have access to the interconnect using Rogers last mile.

[Khalietal]

That's very interesting.. I will test that on my side. As for minecraft, I run with a healthy 3GB of ram for the server and 2GB for my client, leaving a good 7GB for the system. It would be tough to optimize it more than that. Even on a fresh server I see the same "time out" problem so its not computing problems from my side.

If I'm not wrong, the Ping is the time for server/client to read each other's 32bit packet right?. Once the connection is made, shouldn't the connection be almost even accross the board? I mean, even though the high Ping will drop the functional bandwidth, the speed would feel even right? it lags to a degree and pretty much stays around that speed right?

So.. if the ping is the reason of my lag spikes, does it means that my Ping varies constantly? Its the first time I see that kind of lag in gaming. perfect flow for 7-10 seconds then stops for 7-10 seconds, back and forth.. Why would the ping vary so drastically so often all across the board?

[Trentelshark]

When running a server, you are dealing with two conditions, one being latency one being ping. This article should help explain the difference:

http://www.ehow.com/info_10064118_di...ency-ping.html

Ping times during a gaming session will always fluctuate due to the internet being unpredictable. A router somewhere could be processing more or less data depending on when your server "bursts" (upload is sent in bursts) than at other times. Keep in mind also that as upload saturates, download will fail especially if using TCP/IP based applications due to the recv/ack architecture. You could be looking at any number of things with the server:

1) CPU becomes temporarily overloaded as Windows offloads the CPU for other threads/tasks and not dedicated to Minecraft
2) Perhaps it's a router thing where QoS tries to prioritize something and puts the server link temporarily 'on hold'
3) Reasons I mentioned above (some other router, node, etc)

Does this happen around the same time every day, or is it random?

If the packet flow literally stalls for 7-10 seconds and spikes like crazy, you might want to monitor your router and see what occurs at that point in time. Example, the Asus based routers have a traffic monitor that shows incoming/outgoing from/to the WAN port, as well as traffic moving on the wireless/wired portions of the network. It can be helpful in tracking down local traffic to rule this out. I have no experience with a Minecraft server myself so can't be of much help there unfortunately. This could turn out to be a relatively long process of elimination unfortunately.

[synack]

Ping measures the time an ICMP type packet takes to get there and back. so your computer sends and icmp echo, the the other ends send back a reply.
Trace route kind of works the same way, except it sends an echo packet with a "TTL" (time to live) of 1 hop for the first hop and waits for an expiry back. Not all routers or servers reply, some just drop expired packets.
Then to glean hop 2, the ttl is set to 2 etc. The time it takes for the expiry to return is the round trip time for each hop.

No, a connection does not mean you are "good to go" every packet sent (via TCP, which is a majority of them) requires an acknowledgement back. (an ack... nudge nudge)
if a TCP packet does not get an "ack" then that packet, after a time is re-transmitted.
UDP is connectionless, it just sends and hopes the other end gets it.
There are other variables involved like transfer unit sizes and window sizes etc, but that's kind of beyond this conversation.

There are optimizations that allow a certain number of tcp packets to be sent without a reply, so yes, it's not exactly 1 to 1. but any network delays will present itself as lower bandwidth. congestion delays being the worse of them.

As far as ping being the "reason", I just want to clarify that ping is a tool to measure the round trip time or RTT. Your lags and spikes could be due to excessive RTT or simply lost packets. TCP is designed to re-transmit, which is the "catch up" you are seeing.

When you are experiencing the particular issues, running a tracert (trace route) will help isolate where the problem is along the path.

[Khalietal]

traceroute from sitka.triumf.ca to 38.129.15.144

1. to 38.129.15.144 (38.129.15.144), 30 hops max, 40 byte packets
2. rout01.triumf.ca (142.90.100.18) 4.881 ms 4.848 ms 4.831 ms
3. 142.90.1.9 (142.90.1.9) 5.264 ms 5.256 ms 5.527 ms
4. 207.23.240.14 (207.23.240.14) 5.489 ms 5.479 ms 5.466 ms
5. cr1-tx3927.srry1.BC.net (207.23.253.54) 1.560 ms 1.555 ms 1.542 ms
6. 204.101.4.177 (204.101.4.177) 1.816 ms 1.807 ms 1.794 ms
7. agg2-vancouverbg_5-2-0.net.bell.ca (64.230.122.250) 5.345 ms 5.322 ms agg1-vancouverbg_5-2-0.net.bell.ca (64.230.122.248) 5.305 ms
8. core3-vancouverbg_ge14-0-0.net.bell.ca (64.230.77.232) 8.509 ms 8.261 ms core3-vancouverbg_ge13-0-0.net.bell.ca (64.230.77.228) 6.343 ms
9. tcore3-seattle_hundredgige0-9-0-0.net.bell.ca (64.230.79.96) 9.269 ms tcore4-seattle_hundredgige0-9-0-0.net.bell.ca (64.230.79.98) 6.175 ms 6.065 ms
10. bx4-seattle_xe1-0-0.net.bell.ca (64.230.125.245) 5.285 ms 5.266 ms bx4-seattle_xe7-0-0_0.net.bell.ca (64.230.186.46) 5.252 ms
11. te0-0-0-30.ccr21.sea02.atlas.cogentco.com (154.54.10.253) 5.560 ms 5.824 ms 5.813 ms
12. be2085.ccr21.slc01.atlas.cogentco.com (154.54.2.198) 27.547 ms 26.728 ms 27.519 ms
13. be2126.ccr21.den01.atlas.cogentco.com (154.54.25.65) 63.350 ms 63.320 ms 63.313 ms
14. be2128.ccr21.mci01.atlas.cogentco.com (154.54.25.174) 66.108 ms 66.099 ms 66.323 ms
15. be2157.ccr42.ord01.atlas.cogentco.com (154.54.6.118) 63.242 ms be2156.ccr41.ord01.atlas.cogentco.com (154.54.6.86) 63.385 ms 63.458 ms
16. be2080.ccr22.yyz02.atlas.cogentco.com (154.54.42.6) 79.414 ms be2079.ccr21.yyz02.atlas.cogentco.com (154.54.27.182) 81.899 ms be2080.ccr22.yyz02.atlas.cogentco.com (154.54.42.6) 78.858 ms
17. te0-0-2-3.rcr11.b011027-3.yyz02.atlas.cogentco.com (154.54.6.242) 80.479 ms 81.244 ms 81.232 ms
18. 38.122.70.218 (38.122.70.218) 62.945 ms 62.920 ms 63.538 ms
19. 198.251.50.6 (198.251.50.6) 62.878 ms 63.508 ms 62.859 ms
20. 198.251.50.13 (198.251.50.13) 64.482 ms 64.154 ms 64.453 ms

[Khalietal]

===================
traceroute: Warning: Multiple interfaces found; using 134.117.14.35 @ hme0 traceroute to 38.129.15.144 (38.129.15.144), 30 hops max, 40 byte packets 1 unix-gate.physics.carleton.ca (134.117.14.1) 1.647 ms 4.505 ms 1.054 ms 2 10.50.254.3 (10.50.254.3) 1.026 ms 1.023 ms 0.980 ms 3 10.30.34.1 (10.30.34.1) 1.036 ms 1.046 ms 1.017 ms 4 10.30.53.1 (10.30.53.1) 109.183 ms 10.30.55.1 (10.30.55.1) 1.129 ms 1.108 ms 5 134.117.254.242 (134.117.254.242) 1.115 ms 1.168 ms 1.107 ms 6 134.117.254.243 (134.117.254.243) 89.355 ms 1.644 ms 1.408 ms 7 10.30.56.1 (10.30.56.1) 1.438 ms 1.476 ms 1.406 ms 8 gi1-8.mag02.yyz02.atlas.cogentco.com (38.104.158.201) 6.487 ms 6.593 ms 6.433 ms 9 te0-7-0-12.ccr21.yyz02.atlas.cogentco.com (154.54.40.137) 6.940 ms te0-7-0-12.ccr22.yyz02.atlas.cogentco.com (154.54.40.165) 6.920 ms 6.977 ms 10 te0-0-2-0.rcr11.b011027-3.yyz02.atlas.cogentco.com (154.54.6.238) 6.968 ms te0-0-2-3.rcr11.b011027-3.yyz02.atlas.cogentco.com (154.54.6.242) 7.116 ms te0-0-2-0.rcr11.b011027-3.yyz02.atlas.cogentco.com (154.54.6.238) 6.690 ms 11 38.122.70.218 (38.122.70.218) 6.593 ms 6.147 ms 6.505 ms 12 198.251.50.6 (198.251.50.6) 6.479 ms 6.508 ms 6.137 ms 13 198.251.50.13 (198.251.50.13) 7.304 ms 7.541 ms 7.494 ms 14 * * * 15 * * * 16 * *

[Khalietal]

I want to thank you guys so far for the useful info you gave me. As always, things are never simple in the tech world is it? That's what makes it all so interesting. I'm very eager to learn more on the internet architecture. So here I've put my first 2 traceroutes. I read on your link Trentelshark that my router could be bottlenecking the packet flow. It is an interesting thing I want to make sure of as it is quite a good router (Linksys EA3500) which I connect to by Ethernet Cat6 cables. I will try a little more diagnosis on my side and try again with direct Ethernet to the modem instead see if the same issues appears. I'm not too experienced to decode the traceroute reports I am getting so far. Do they look average or worse than expected? I'll check my latency in-game in direct modem connection in a moment.

[Khalietal]

Fascinating.. Direct Ethernet to Modem removes my latency spiking.. Anyway, on first sight this is. I will try many times over router then over modem to see if it is consistent. I guess if it is after all, I will need to properly configure my router. I never had more than 14mbps before and that could be why my router is having trouble digesting high demands I guess. More on that coming...

[synack]

That first traceroute shows you going through the dreaded cogent in the US. They have recently been having issues with their peers due to Netflix (one of their clients). and you can see the congestion with those ping times jumping.
The second came out in a jumbled mess, but from what I can see, it looks like excellent RTT.

[Trentelshark]

I agree with synack on the traceroute, basically the way you can read it is the name be2085.ccr21.slc01.atlas.cogentco.com is where the ping times are the highest and this carries through the rest of the hops. This means that's the source of the latency from your PC to the end point you are trying to reach. I'd have to look up what the multiple interfaces message means on the second, I have quite frankly never encountered that before. Just to be sure, you are only behind a single router right?

[synack]

Looks like the machine Khalietal ran the second trace route from is a sun solaris machine... its just complaining that it has multiple NICs and reporting which one it decided to use. I'm guessing a firewall device of some type. a *nix box would also explain the lack of CRLF in the paste.

I was a bit surprised myself to see that, most people on a *nix usually already know what a ping a traceroute is/does. but I won't judge!