• Guest, HEROCRAFT PUBLIC RELEASE IS HAPPENING AN HOUR EARLIER! TONIGHT @ 7PM CST GET READY FOR IT! play.hc.to
    Read up on the guides and new systems! Here.
    View the LIVE Map here @ hc.to/map
    Stuck or have a problem? use "/pe create" to to open a ticket with staff (There are some known issues and other hotfixes we will be pushing asap)
  • Guest, Make sure to use our LAUNCHER! Read more here!

Bug Packet Loss to server. Not in Server.

stamping

Glowing Redstone
Joined
Oct 16, 2012
Minecraft server. play.hc.to

Witnessed Packet loss effects, blocks not breaking as fast as they do on the client, IE they break, reform and need to be broken once to thrice more.
Also constant rubber banding, not rogue class /sneak problems as I'm a Wizard. Also have my partner experiencing it on her rangers with and without sneak active.

We know it's not likely our connection and the server TPS is always above the 17.5 threshold when servers usually give out lag.
So we did a simple tracert to find out the problem. The hop #11 is where the packet loss comes from. It's Registered to OVH Hosting Inc.
http://myip.ms/view/ip_addresses/3227750912/192.99.146.0_192.99.146.255

We've also tried using the VPN we have to bypass most of the latency issues we have from Australia. We still get caught at that node hop and rubber band.

Here is the wall of text our typical Tracert gives.

Code:
Tracing route to play.hc.to []
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192-168-1-1.tpgi.com.au [192.168.1.1]
  2    20 ms    19 ms    19 ms  bri-pow-que-bras2-lo-20.tpgi.com.au [10.20.23.79]
  3    21 ms    42 ms    19 ms  mail.rubin.com.au [203.219.166.130]
  4    33 ms    32 ms    34 ms  203-219-107-125.static.tpgi.com.au [203.219.107.125]
  5    31 ms    35 ms    31 ms  syd-gls-har-int1-be-20.tpgi.com.au [203.29.129.195]
  6   231 ms   231 ms   230 ms  ix-17-0.tcore2.SQN-San-Jose.as6453.net [64.86.21.53]
  7   298 ms   298 ms   300 ms  if-5-2.tcore2.PDI-Palo-Alto.as6453.net [64.86.21.2]
  8   298 ms   298 ms   298 ms  if-2-2.tcore1.PDI-Palo-Alto.as6453.net [66.198.127.1]
  9   299 ms   298 ms   298 ms  if-1-2.tcore1.NYY-New-York.as6453.net [66.198.127.6]
10   299 ms   298 ms   298 ms  if-3-2.thar1.NJY-Newark.as6453.net [66.198.70.21]
11   308 ms     *        *     192.99.146.48
12   309 ms   309 ms   309 ms  bhs-g2-6k.qc.ca [198.27.73.207]
13   309 ms   308 ms   309 ms  bhs-3a-a9.qc.ca [198.27.73.94]
14     *        *        *     Request timed out.
15     *        *        *     Request timed out.
16     *        *        *     Request timed out.
17     *        *        *     Request timed out.
18     *        *        *     Request timed out.
19     *        *        *     Request timed out.
20     *        *        *     Request timed out.
21     *        *        *     Request timed out.
22     *        *        *     Request timed out.
23     *        *        *     Request timed out.
24     *        *        *     Request timed out.
25     *        *        *     Request timed out.
26     *        *        *     Request timed out.
27     *        *        *     Request timed out.
28     *        *        *     Request timed out.
29     *        *        *     Request timed out.
30     *        *        *     Request timed out.

Trace complete.
So if others are suffering rubber banding packet loss issues. I'd suggest a tracert and post to the server admins to see where the common loss is and if it's at the same point, It's something Kainzo or the other founders can identify with.

Stamping and AlluraPhoenix.
 
Last edited by a moderator:

Kainzo

The Disposable Hero
Staff member
Founder
Adventure Team
Joined
Jan 7, 2011
Location
The 7th Circle of Heaven
You are unable to ping our servers directly. Ping / tracert tests have nothing to do with packetless in this case because they wont reach their destination. We aren't a public facing server, so we have the ability to drop requests that do nothing for the userbase.

If the above was actually true, you would never be able to connect.

We're behind a massive network/firewall at a Canadian data-center that handles LARGE amounts of traffic every day.
 
Last edited:

Naibsel00

Iron
Joined
Jan 17, 2014
Location
Valorium
@stamping To me this looks like latency between the paths your network takes to get to the server.
Although the delay isnt with your local connection or the hc server connection, the path your location takes is different than others.
If there was an actual issue with the server network everyone would have major issues, it would not be limited to a few individuals.
You could also be running into personal firewall issues between your personal router.

My suggestions:
1. Try a different model router and compare the results.
2. Try a few different network proxies and compare the results.

I hope this helps!
 

stamping

Glowing Redstone
Joined
Oct 16, 2012
Already tried that, Have experienced the same network packet loss at the same hop since I first joined Herocraft is 2012. Been through 4 routers, 3 isp's. As mentioned. I have also used a VPN right to chicago and it lost packets at the same node hop.

The actual servers are located after hop 13. I know I cant ping the actual servers, just show the route I used to get there. The OVH firewall is where I lose packets.
 

Kainzo

The Disposable Hero
Staff member
Founder
Adventure Team
Joined
Jan 7, 2011
Location
The 7th Circle of Heaven
Already tried that, Have experienced the same network packet loss at the same hop since I first joined Herocraft is 2012. Been through 4 routers, 3 isp's. As mentioned. I have also used a VPN right to chicago and it lost packets at the same node hop.

The actual servers are located after hop 13. I know I cant ping the actual servers, just show the route I used to get there. The OVH firewall is where I lose packets.
We've been on 3 different servers, under 4 or 5 different networks since 2012. It could be something local to our Debian config setup - but that's highly unlikely.

We actively block requests to Tracert / ping. That shows nothing of what our configuration is.

Your hops TO the datacenter mean virtually nothing because there's no way we can fix / resolve that. Report to your ISP.
 
Top