To all who have noticed slower downloads on network2, it is almost a mistake that I’m using an old P4 for network2 downloads and a dual opteron server grade NICs for network1 tests. I’ll try to get unused servers with equivalent H/w configuration for both networks and that should eliminate the download speed differences.
Re: Feedback from Amsterdam/NL/Europe
Right. I’ll also probably start serving the contents from memory, instead of disk, to make downloads faster.
Now in Fairbanks Alaska. Results are:
Network1
Microsoft Windows [Version 6.0.6000]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.
C:\Users\George Marchewa>ping -n 25 64.71.235.167
Pinging 64.71.235.167 with 32 bytes of data:
Reply from 64.71.235.167: bytes=32 time=136ms TTL=42
Reply from 64.71.235.167: bytes=32 time=150ms TTL=42
Reply from 64.71.235.167: bytes=32 time=153ms TTL=42
Reply from 64.71.235.167: bytes=32 time=146ms TTL=42
Reply from 64.71.235.167: bytes=32 time=138ms TTL=42
Reply from 64.71.235.167: bytes=32 time=139ms TTL=42
Reply from 64.71.235.167: bytes=32 time=141ms TTL=42
Reply from 64.71.235.167: bytes=32 time=248ms TTL=42
Reply from 64.71.235.167: bytes=32 time=141ms TTL=42
Reply from 64.71.235.167: bytes=32 time=142ms TTL=42
Reply from 64.71.235.167: bytes=32 time=137ms TTL=42
Reply from 64.71.235.167: bytes=32 time=136ms TTL=42
Reply from 64.71.235.167: bytes=32 time=138ms TTL=42
Reply from 64.71.235.167: bytes=32 time=140ms TTL=42
Reply from 64.71.235.167: bytes=32 time=153ms TTL=42
Reply from 64.71.235.167: bytes=32 time=184ms TTL=42
Reply from 64.71.235.167: bytes=32 time=199ms TTL=42
Reply from 64.71.235.167: bytes=32 time=140ms TTL=42
Reply from 64.71.235.167: bytes=32 time=138ms TTL=42
Reply from 64.71.235.167: bytes=32 time=138ms TTL=42
Reply from 64.71.235.167: bytes=32 time=137ms TTL=42
Reply from 64.71.235.167: bytes=32 time=139ms TTL=42
Reply from 64.71.235.167: bytes=32 time=144ms TTL=42
Reply from 64.71.235.167: bytes=32 time=139ms TTL=42
Reply from 64.71.235.167: bytes=32 time=136ms TTL=42
Ping statistics for 64.71.235.167:
Packets: Sent = 25, Received = 25, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 136ms, Maximum = 248ms, Average = 149ms
C:\Users\George Marchewa>tracert 64.71.235.167
Tracing route to smtp1.hr2p.m****here.biz [64.71.235.167]
over a maximum of 30 hops:
1 1 ms 1 ms 1 ms 172.16.48.1
2 * * * Request timed out.
3 14 ms 11 ms 12 ms 77-252-223-66.gci.net [66.223.252.77]
4 62 ms 60 ms 59 ms 34-251-223-66.gci.net [66.223.251.34]
5 66 ms 62 ms 64 ms InetSeaSDCDist-1.gci.net [209.165.129.65]
6 67 ms 65 ms 62 ms 217-129-165-209.gci.net [209.165.129.217]
7 61 ms 61 ms 62 ms 500.POS1-1.GW5.SEA1.ALTER.NET [157.130.191.1]
8 79 ms 81 ms 71 ms 107.ATM7-0.XR2.SEA1.ALTER.NET [152.63.105.206]
9 61 ms 63 ms 62 ms 0.so-0-0-0.XT2.SEA1.ALTER.NET [152.63.106.233]
10 62 ms 62 ms 67 ms POS7-0.BR2.SEA1.ALTER.NET [152.63.106.5]
11 86 ms 85 ms 85 ms so6-1-0-2488M.ar4.SEA1.gblx.net [64.215.195.221]
12 143 ms 149 ms 141 ms te1-1-10G.ar1.MIA2.gblx.net [67.17.108.62]
13 158 ms 148 ms 144 ms te1-1-10G.ar1.MIA2.gblx.net [67.17.108.62]
14 142 ms 137 ms 138 ms INTERNAP.Tengigabitethernet2-2.ar1.MIA2.gblx.net
[64.212.16.166]
15 140 ms 141 ms 139 ms border5.pc2.bbnet2.mia003.pnap.net [69.25.0.77]
16 137 ms 136 ms 137 ms webhosting-9.border5.mia003.pnap.net [216.52.162
.66]
17 138 ms 138 ms 136 ms 64.71.225.26
18 148 ms 150 ms 148 ms smtp1.hr2p.m****here.biz [64.71.235.167]
Trace complete.
Download ~300KB/Sec
Network2
Microsoft Windows [Version 6.0.6000]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.
C:\Users\George Marchewa>ping -n 25 64.59.88.66
Pinging 64.59.88.66 with 32 bytes of data:
Reply from 64.59.88.66: bytes=32 time=135ms TTL=45
Reply from 64.59.88.66: bytes=32 time=134ms TTL=45
Reply from 64.59.88.66: bytes=32 time=138ms TTL=45
Reply from 64.59.88.66: bytes=32 time=136ms TTL=45
Reply from 64.59.88.66: bytes=32 time=136ms TTL=45
Reply from 64.59.88.66: bytes=32 time=133ms TTL=45
Reply from 64.59.88.66: bytes=32 time=135ms TTL=45
Reply from 64.59.88.66: bytes=32 time=136ms TTL=45
Reply from 64.59.88.66: bytes=32 time=137ms TTL=45
Reply from 64.59.88.66: bytes=32 time=131ms TTL=45
Reply from 64.59.88.66: bytes=32 time=144ms TTL=45
Reply from 64.59.88.66: bytes=32 time=135ms TTL=45
Reply from 64.59.88.66: bytes=32 time=132ms TTL=45
Reply from 64.59.88.66: bytes=32 time=135ms TTL=45
Reply from 64.59.88.66: bytes=32 time=141ms TTL=45
Reply from 64.59.88.66: bytes=32 time=168ms TTL=45
Reply from 64.59.88.66: bytes=32 time=191ms TTL=45
Reply from 64.59.88.66: bytes=32 time=213ms TTL=45
Reply from 64.59.88.66: bytes=32 time=136ms TTL=45
Reply from 64.59.88.66: bytes=32 time=136ms TTL=45
Reply from 64.59.88.66: bytes=32 time=141ms TTL=45
Reply from 64.59.88.66: bytes=32 time=141ms TTL=45
Reply from 64.59.88.66: bytes=32 time=149ms TTL=45
Reply from 64.59.88.66: bytes=32 time=137ms TTL=45
Reply from 64.59.88.66: bytes=32 time=138ms TTL=45
Ping statistics for 64.59.88.66:
Packets: Sent = 25, Received = 25, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 131ms, Maximum = 213ms, Average = 143ms
C:\Users\George Marchewa>tracert 64.59.88.66
Tracing route to 64.59.88.66 over a maximum of 30 hops
1 1 ms 1 ms 1 ms 172.16.48.1
2 * * * Request timed out.
3 11 ms 11 ms 12 ms 77-252-223-66.gci.net [66.223.252.77]
4 62 ms 66 ms 64 ms 34-251-223-66.gci.net [66.223.251.34]
5 62 ms 60 ms 60 ms InetSeaSDCDist-1.gci.net [209.165.129.65]
6 75 ms 60 ms 62 ms 221-129-165-209.gci.net [209.165.129.221]
7 58 ms 60 ms 60 ms ge-6-12.car3.Seattle1.Level3.net [4.71.152.9]
8 70 ms 71 ms 71 ms ae-31-55.ebr1.Seattle1.Level3.net [4.68.105.158]
9 73 ms 79 ms 63 ms ae-1-100.ebr2.Seattle1.Level3.net [4.69.132.18]
10 99 ms 90 ms 92 ms ae-2.ebr2.Denver1.Level3.net [4.69.132.54]
11 94 ms 89 ms 91 ms ae-1-100.ebr1.Denver1.Level3.net [4.69.132.37]
12 107 ms 107 ms 106 ms ae-2.ebr2.Dallas1.Level3.net [4.69.132.106]
13 111 ms 107 ms 113 ms ae-72-72.csw2.Dallas1.Level3.net [4.69.136.142]
14 108 ms 108 ms 122 ms ae-71-71.ebr1.Dallas1.Level3.net [4.69.136.125]
15 133 ms 155 ms 145 ms ae-6-6.car1.Miami1.Level3.net [4.69.133.1]
16 133 ms 145 ms 136 ms ae-14-14.car4.Miami1.Level3.net [4.69.133.18]
17 149 ms 138 ms 169 ms EASY-ONLINE.car4.Miami1.Level3.net [4.71.208.6]
18 134 ms 192 ms 196 ms 64.59.88.66
Trace complete.
Download speed ~229KB/s
Here are updated URLs for network2:
47 MB file - http://64.59.88.67/linux-2.6.25.4.tar.bz2
20 MB file - http://64.59.88.67/tetex-fonts-2.0.2-22.0.1.EL4.8.i386.rpm
4.8 MB file - http://64.59.88.67/tora-1.3.14.1-2.i386.rpm
464M file - http://64.59.88.67/big.tar
Will be great if the users who have tested in the past, re-test the download speed with this new set of URLs.
Thank you all for your feedback so far!
20 MB: I got over 700 KB a sec
464M file: It ranged from 500 to 702 KB a sec
107 KB/s, regardless of file size, from the Northern Marianas
47 MB file - http://64.59.88.67/linux-2.6.25.4.tar.bz2
54.3 KB/s, 234.6 KB/s, 184.6 KB/s, 28.1 KB/s
The downloads were started at random intervals between 9:30 PM and 11:15 PM (NZ time). Fastest result is markedly higher than in the first set of tests :)) while the slowest is considerably slower ![]()
So, once again, the results are inconsistent.
I would say, try using a download accelerator and see if it changes anything.
There is no reason for results to be inconsistent from our end as both network have loads of spare capacity and even more burstable capacity beyond that.
Most common reason for such inconsistency can be shared bandwidth pool at your ISP or in their international transit.
Using a download accelerator will not provide real-world results, as they generally use multiple connections to get high speeds. Downloading with a web browser is the only thing that matters here.
My results downloading http://64.59.88.67/linux-2.6.25.4.tar.bz2 to Perth Australia is ~190KBytes/sec. My previous result (which was from 64.59.88.66 - I assume it’s the same network) was 46KBytes/sec, so this time is a drastic improvement. Excellent!
I want to express my thanks to Tanmaya, Stephen and everyone else working on improving throughput for all of us, even down here in the backwaters. ![]()
Existing Cluster 1 servers are still at ~28KB/s for me… when is the new setup expected to go live?
Agreed. I specifically meant for nzkiwi as the results posted by him vary quite a lot that is not even the case with my mere 512kbps circuit.
Quite soon. We will post an official announcement about it. We also plan to introduce more redundancy in our network to overcome the fiber problems we have seen in the past. Both will be clubbed to ensure smoothest possible migration.
network2 big.tar starts at 500kbyte/sec, but then slows down to around 300kbyte/sec.
This is from Amsterdam/NL/Europe.
No need to club anyone, I’m sure they’re doing the best they can. ![]()
I didn’t mean to imply that the inconsistent results were due to JH or its connections. I’m quite aware of the limitations we in NZ face being so far of the main routes (and that doesn’t apply just to the Internet). I know many local ISPs actively shape their international traffic, and I suspect that is why my results vary so much.
Fortunately most of my file transfers are via FTP, which seems to be less prone to such manipulation.
As an aside, even local downloads can be very slow due to peering disputes between some NZ telcos/ISPs. The ISP subsidiaries of our two major telcos peer via a third party in the U.S. Between them they would account for half of NZ’s Internet subscribers. Currently I am downloading Ubuntu Hardy Heron from two different NZ sources. One is downloading at 34 KB/s and according to a traceroute is crossing the pacific twice before it reaches me, while the other is downloading at 397 KB/s and never leaves our shores.
Damn, there goes my dream of moving to New Zealand one day.. ![]()
Internet isn’t everything
I am on some ‘slow’ 1.5mb dsl here at my home in TX ![]()
It has been down twice this week already, but I love living here…it is mine
Don’t give up just yet. Disputes do get resolved from time to time. This one must be costing both parties a tidy sum. Sooner or later, they’ll see sense and make up ![]()
Network2 will this month have some impressive additions, 10gig link to SAVVIS, 10gig link to Tata Communications(VNSL is common name), and 10gig link to WV Fiber.
SAVVIS will be quite nice for US and Europe
Tata will excel at both South America and all Asia
WV Fiber is a local US company that is a prime provider for the likes of cox, charter, and comcast so that will be quite a good link for people on cable internet in the US.
By Network 2 do you mean Cluster 2? When will Cluster 1 get its upgrade?
No I mean network2 as listed in the first post ![]()
It is not cluster1 or cluster2 network.