Make the Internet faster.
Fast is definitely NOT the issue. I have a very stable, low latency and fast connection (22Mbps/5Mbps down/up TCP/IP ... not ATM or DOCSIS frames which would imply a slight lower effective speed]. Testing against most any site in the United States or Canada results in nearly perfect results, at least through the Comcast network. However, there is an international route in play here.
You are in part correct that it is an Internet issue, but the issue isn't speed (throughput). See the results below. The issue is occasional packet loss along the route.
100 ping packet testPing statistics for 46.4.99.204:
Packets: Sent = 100, Received = 91, Lost = 9 (9% loss),
Approximate round trip times in milli-seconds:
Minimum = 144ms, Maximum = 188ms, Average = 155msWHOIS shows I am being routed to German from the USrole: Hetzner Online AG - Contact Role
address: Hetzner Online AG
address: Stuttgarter Straße 1
address: D-91710 Gunzenhausen
address: Germany
Traceroute shows a backbone issue between deepbit.net in Germany and my hostTracing route to deepbit.net [46.4.99.204]
over a maximum of 30 hops:
1 14 ms 8 ms 10 ms 73.115.174.1
2 9 ms 14 ms 12 ms ge-9-1-ur02.hamlake.mn.minn.comcast.net [68.85.165.229]
3 12 ms 9 ms 13 ms te-0-3-0-2-ar01.roseville.mn.minn.comcast.net [68.87.174.70]
4 22 ms 21 ms 19 ms te-0-4-0-0-cr01.chicago.il.ibone.comcast.net [68.86.91.137]
5 90 ms 57 ms 54 ms pos-2-10-0-0-cr01.newyork.ny.ibone.comcast.net [68.86.86.113] 6 54 ms 56 ms 54 ms pos-0-4-0-0-pe01.111eighthave.ny.ibone.comcast.net [68.86.85.22]
7 54 ms 54 ms 59 ms nyk-s2-rou-1001.us.eurorings.net [75.149.228.126]
8 135 ms 167 ms 136 ms nntr-s1-rou-1021.FR.eurorings.net [134.222.226.166]
9 135 ms 136 ms * nntr-s1-rou-1022.FR.eurorings.net [134.222.231.154]
10 141 ms 142 ms 140 ms ffm-s1-rou-1022.DE.eurorings.net [134.222.229.30]
11 144 ms 155 ms 156 ms ffm-s1-rou-1021.DE.eurorings.net [134.222.231.141]
12 147 ms 149 ms 148 ms nbg-s1-rou-1001.DE.eurorings.net [134.222.225.26]
13 147 ms 143 ms 143 ms kpn-gw.hetzner.de [134.222.107.21]
14 159 ms 150 ms 162 ms hos-bb2.juniper1.fs.hetzner.de [213.239.240.146]
15 150 ms * * hos-tr1.ex3k7.rz14.hetzner.de [213.239.224.136]
16 149 ms 152 ms 147 ms j2.deepbit.net [46.4.99.204]
Trace complete.
Looking at the obvious points on the route, hops 5, 8, 9 and 10 are candidates due to large jumps and variationHop 5 - the largest variation and most likely candidatePing statistics for 68.86.86.113:
Packets: Sent = 100, Received = 90, Lost = 10 (10% loss),Approximate round trip times in milli-seconds:
Minimum = 52ms, Maximum = 92ms, Average = 58msI checked for packet loss to hop 4 and it was clean [well, I lost 1 packet in 250 hops]. I would rather see this was at hop 5, since then it would arguably be an issue between Comcast and the connection crossing the Atlantic, but alas, it is a Comcast issue.
So, in this case, outbound communications from my miners to deepbit.net seem to be caused by a bad or overloaded Comcast backbone router in New York.
NOTICE to Comcast users; it is most likely that nearly all connections to deepbit.net are going through this same router in New York and thus ALL Comcast customers are likely suffering the same issue. This is not necessarily the cause however, but most likely the connection is maintained on the same route in both directions in this particular case.
To there you have it, the issue does not seem to be deepbit as far as outbound goes. I have no idea what inbound traffic from deepbit.net looks like since a reverse traceroute would be required along with ping results from each hop originating from deepbit.net. Having said that; there is one hop that looks a little troubling and that would be 15 which looks to be one hop upstream of data center used by deepbit.net.
netname: HETZNER-RZ14
descr: Hetzner Online AG
descr: Datacenter 14
So, any Euro customers, especially Germany or France, if you could do something similar, we can at least see if there is loss on your side of the pond
Looking through the hosting company's site,
http://www.hetzner.de, I don't see any tools for doing a reverse traceroute ... so I have to leave that task to Tycho if he cares to do it. A good example of a such a tool in the US that is connected very well as far as the US and Canada are concerned is from Giganews at
http://www.giganews.com/performance.html#traceroute, but doesn't do the ping tests in either direction looking for packet loss. Perhaps one of the better tools out there, again to one of two sites, is from DSL Reports at
http://www.dslreports.com/pingtest.
So, perhaps a little overkill, but I did it to find out why the issue and it solidly points to a single network backbone router in New York owned by Comcast (arguably the largest single network entity in the world and one of the best maintained, especially considering their size). They seem to have blown it on this one.