[Hands0n]

Ben and I were having a natter recently about 3G network latency and how it is so much better with HSDPA (coined 3G+ by some) than with the standard offering. For sure, the latency with 3G is quite high, and that may disrupt some applications. But for general purpose Internet use it is so much better at 3G speeds than 2G.

The purpose of this thread is for to allow you to share your own 3G and HSDPA experiences and, if you can, the technical details.

Below I have some information relating to my particular set up. Please share :)

Device: Nokia 6280 on T-Mobile Web N Walk Plus, receiving full 3G signal, using Nokia PC Suite to create the Dial-Up connection

When connected to the 3G network the ipconfig details are as follows:
PPP adapter Nokia 6280 USB Modem (OTA):

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : WAN (PPP/SLIP) Interface
Physical Address. . . . . . . . . : 00-53-45-00-00-00
Dhcp Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 10.35.3.153
Subnet Mask . . . . . . . . . . . : 255.255.255.255
Default Gateway . . . . . . . . . : 10.35.3.153
DNS Servers . . . . . . . . . . . : 149.254.192.126
149.254.201.126
NetBIOS over Tcpip. . . . . . . . : Disabled

NB: Before making any connection please make sure you have Windows Firewall enabled on the dial-up connector or a 3rd party firewall running.

Latency measurements.
The simplest way of doing this is to perform a Traceroute - in XP the command is tracert - where hostname is any DNS name you want. I chose an easily reachable domainname, that being google in the UK and Hong Kong (see why in a mo). For consistency of comparison it would be best to replicate this test exactly.

My connection speeds are:
3G: 460.8Kbps (claimed by Windows)
Landline: 10Mbps asymetric (speedtested to over 9Mbps)


Test 1: Traceroute to google.co.uk using 3G connection
C:\> tracert google.co.uk

Tracing route to google.co.uk [216.239.59.104]
over a maximum of 30 hops:

1 631 ms 309 ms 310 ms 172.18.51.98
2 249 ms 279 ms 309 ms 10.64.74.113
3 278 ms 329 ms 319 ms 172.18.14.60
4 268 ms 289 ms 279 ms 149.254.195.194
5 267 ms 299 ms 279 ms 172.18.238.230
6 268 ms 309 ms 309 ms 193.159.224.1
7 * 261 ms 289 ms ldn-b2-pos1-1.telia.net [213.248.75.105]
8 269 ms 289 ms 289 ms google-118150-ldn-b3.c.telia.net [213.248.104.58
]
9 301 ms 299 ms 340 ms 66.249.95.107
10 279 ms 309 ms 329 ms 64.233.174.185
11 287 ms 309 ms 299 ms 216.239.49.114
12 319 ms 349 ms 350 ms gv-in-f104.google.com [216.239.59.104]

Trace complete.

It is the first hop that is significant - this is the time it takes to "ping" from the mobile handset to the first routing device. This should be a routing device at the 3G mobile transmitter mast that you are currently connected to.

The results are quite surprising when considering that you are likely to be no more than half a mile away from a mast, and that radio signals typically transmit at near the speed of light (186,000 miles per second in a vacuum). So what is making this huge 300ms delay across the air interface?

Test 2: Traceroute to google.co.uk using cable ISP link.
For comparison I performed the same tracert using my cable Internet connection - this runs at 10Mbps.

C:\>tracert google.co.uk

Tracing route to google.co.uk [216.239.59.104]
over a maximum of 30 hops:

1 1 ms 2 12 ms 8 ms 10 ms 10.40.0.1
3 9 ms 9 ms 14 ms 80.195.192.67
4 16 ms 19 ms 24 ms pc-62-30-243-69-bn.blueyonder.co.uk [62.30.243.6
9]
5 16 ms 11 ms 11 ms pc-62-30-243-90-bn.blueyonder.co.uk [62.30.243.9
0]
6 14 ms 13 ms 10 ms tele2-gw4.telewest.net [194.117.136.197]
7 10 ms 10 ms 12 ms 194.117.148.251
8 17 ms 14 ms 15 ms 72.14.238.244
9 24 ms 24 ms 22 ms 66.249.95.107
10 24 ms 23 ms 23 ms 72.14.232.241
11 29 ms 26 ms 31 ms 216.239.49.114
12 26 ms 22 ms 26 ms gv-in-f104.google.com [216.239.59.104]

Trace complete.

Ignore the first hop, that is to my internal router, it is the second hop that is significant. That is the time taken to hit the first routing device in my ISP's network. The difference in landline speed and 3G air interface speed is not highly significant to the latency times. The test data packets are tiny so any differences would be marginal.


Test 3: Traceroute to google.hk using the cable ISP link
Hong Kong is pretty much the other side of the world.

C:\>tracert google.hk

Tracing route to google.hk [72.14.235.104]
over a maximum of 30 hops:

1 2 35 ms 23 ms 15 ms 10.40.0.1
3 9 ms 10 ms 11 ms 80.195.192.67
4 15 ms 17 ms 15 ms pc-62-30-243-69-bn.blueyonder.co.uk [62.30.243.6
9]
5 11 ms 11 ms 15 ms pc-62-30-243-90-bn.blueyonder.co.uk [62.30.243.9
0]
6 10 ms 14 ms 12 ms tele2-gw4.telewest.net [194.117.136.197]
7 10 ms 12 ms 12 ms 194.117.148.251
8 21 ms 21 ms 19 ms 72.14.238.255
9 84 ms 97 ms 86 ms 72.14.236.216
10 101 ms 103 ms 103 ms 216.239.46.227
11 151 ms 153 ms 148 ms 72.14.233.116
12 285 ms 282 ms 298 ms 209.85.248.130
13 280 ms 282 ms 281 ms 216.239.47.232
14 313 ms 312 ms 312 ms 64.233.174.42
15 313 ms 313 ms 315 ms 72.14.232.167
16 313 ms 315 ms 312 ms 72.14.232.166
17 326 ms 314 ms 312 ms 72.14.232.154
18 313 ms 315 ms 314 ms tw-in-f104.google.com [72.14.235.104]

Trace complete.

So, in summary, the latency to Hong Kong, around the other side of the planet, is somewhat less the latency from my desk to the nearest 3G transmitter mast less than a mile away. :cool:

Anyone know whats going on here? :D


NB: Just for interest, I set my Nokia 6280 to GSM only and ran the same traceroute to google.co.uk with the following result


Test 4: GSM connect at a reported 56Kbps
C:\>tracert google.co.uk

Tracing route to google.co.uk [72.14.221.104]
over a maximum of 30 hops:

1 595 ms 396 ms 420 ms 172.18.51.97
2 338 ms 419 ms 419 ms 10.64.74.113
3 416 ms 419 ms 419 ms 172.18.14.60
4 355 ms 419 ms 419 ms 149.254.195.194
5 396 ms 419 ms 438 ms 172.18.238.250
6 355 ms 420 ms 419 ms 62.159.199.173
7 378 ms 401 ms 419 ms so-4-2.core2.London1.Level3.net [212.187.131.81]

8 388 ms 419 ms 419 ms ae-29-56.ebr2.London1.Level3.net [4.68.116.190]

9 439 ms 401 ms 420 ms ae-2.ebr2.Amsterdam1.Level3.net [4.69.132.134]
10 368 ms 419 ms 396 ms ae-21-52.car1.Amsterdam1.Level3.net [4.68.120.47
]
11 422 ms 419 ms 419 ms GOOGLE-INC.car1.Amsterdam1.Level3.net [212.72.46
.230]
12 396 ms 438 ms 443 ms 209.85.248.86
13 461 ms 419 ms 438 ms 209.85.248.183
14 433 ms 521 ms 420 ms 72.14.232.207
15 417 ms 399 ms 419 ms 209.85.250.46
16 420 ms 400 ms 420 ms fg-in-f104.google.com [72.14.221.104]

Trace complete.

Latency is worse over 2G as anticipated but not so much so in relation to the stark connection speed differences. However, in actual use the connection speed difference is very noticeable, and coupled with the increased latency make for a very poor quality experience.

[bsrjl1]

It is the first hop that is significant - this is the time it takes to "ping" from the mobile handset to the first routing device. This should be a routing device at the 3G mobile transmitter mast that you are currently connected to.

The results are quite surprising when considering that you are likely to be no more than half a mile away from a mast, and that radio signals typically transmit at near the speed of light (186,000 miles per second in a vacuum). So what is making this huge 300ms delay across the air interface?

No the first hop should be the response from the GGSN, you cannot ping the NodeB (or AXC/RNC/SGSN) as the traffic is tunneled through.

[Ben]

No the first hop should be the response from the GGSN, you cannot ping the NodeB (or AXC/RNC/SGSN) as the traffic is tunneled through.
Any idea why that first hop is the one with all the latency? I'll post up my stats from the office, but I can tell you right now that HSDPA significantly reduces the latency at the first hop. There's still an unacceptable amount, however.

[Hands0n]

No the first hop should be the response from the GGSN, you cannot ping the NodeB (or AXC/RNC/SGSN) as the traffic is tunneled through.

Ah, thanks. So the GGSN is somewhere at the perimiter of the actual IP network but back at the central site/s rather than in the transmitter cabinet? Do public viewable network diagrams exist for how these networks are constructed in the UK?

[bsrjl1]

Any idea why that first hop is the one with all the latency? I'll post up my stats from the office, but I can tell you right now that HSDPA significantly reduces the latency at the first hop. There's still an unacceptable amount, however.

Because the handset has to modulate the ping to send over the air in the right frame, the NodeB has to decode it then the RNC forwards it onto the SGSN & onto the GGSN. Then backwards for the response. HSDPA moves a lot of the buffering & retransmission into the NodeB hence the reduced latency instead of the RNC doing it.

http://www.artesyncp.com/resources/teledata/ is quite a good diagram.

[Hands0n]

Yes, a nice diagram, I just love the activeness of it. Whoever put that together certainly had their head in the right place on that day.

Perhaps as the mobiles themselves get more powerful processors or the job of encoding the data is done in silicon we can expect some increase in performance. But I don't suppose that will happen much until Data becomes more generally used and hence the demand for better performance becomes tangible. Up until recently, or now even, mobile Data users are simply grateful to be able to get at their data when in the field. I think the Data user of the not too distant future will be more demanding of better performance.

[getti]

You guys have totally lost me on this 1 lol.

All i know is compared to 3G, HSDPA is bloody fast! :D

[Ben]

Yes, a nice diagram
Even has the SS7 connections on it, awesome :D

[Ben]

Here we go!

Vodafone '3G Broadband' HSDPA via the Hauwei card and Linksys WRT54G3G router.

My connection speed from ADSLGuide.org.uk/whatever it's called now:
Speed Down 1220.48 Kbps ( 1.2 Mbps )
Speed Up 336.54 Kbps ( 0.3 Mbps )
I've had faster, but that's fine.

traceroute: Warning: google.co.uk has multiple addresses; using 72.14.221.104
traceroute to google.co.uk (72.14.221.104), 64 hops max, 40 byte packets
1 *.*.*.* (Linksys WRT54G3G on my network) 0.968 ms 0.691 ms 0.698 ms
2 212.183.136.241 (212.183.136.241) 97.841 ms 99.289 ms 99.979 ms
3 10.240.0.26 (10.240.0.26) 99.985 ms 10.240.4.2 (10.240.4.2) 89.306 ms 10.240.4.14 (10.240.4.14) 99.233 ms
4 10.206.64.4 (10.206.64.4) 99.337 ms 89.263 ms 90.010 ms
5 10.206.65.1 (10.206.65.1) 89.980 ms 79.193 ms 99.981 ms
6 10.206.65.135 (10.206.65.135) 90.005 ms 89.301 ms 99.969 ms
7 10.206.66.71 (10.206.66.71) 99.994 ms 89.226 ms 89.979 ms
8 10.206.66.193 (10.206.66.193) 89.967 ms 89.299 ms 89.992 ms
9 10.206.66.212 (10.206.66.212) 89.985 ms 99.282 ms 99.976 ms
10 10.206.70.157 (10.206.70.157) 100.070 ms 99.345 ms 99.986 ms
11 172.17.100.1 (172.17.100.1) 110.066 ms 109.210 ms 109.983 ms
12 so-2-2-3-iar1.tsd.cw.net (166.63.214.141) 120.066 ms 109.641 ms 119.979 ms
13 bcr3.tsd.cw.net (195.2.1.15) 120.078 ms 129.706 ms 119.978 ms
14 so-1-1-0-dcr1.tsd.cw.net (195.2.10.98) 130.056 ms 119.686 ms 120.092 ms
15 72.14.198.41 (72.14.198.41) 119.990 ms 129.103 ms 129.974 ms
16 72.14.238.244 (72.14.238.244) 120.069 ms 119.324 ms 119.980 ms
17 209.85.248.80 (209.85.248.80) 140.151 ms 139.356 ms 139.970 ms
18 209.85.248.183 (209.85.248.183) 129.972 ms 129.302 ms 129.993 ms
19 72.14.232.207 (72.14.232.207) 140.051 ms 139.155 ms 72.14.232.205 (72.14.232.205) 140.080 ms
20 209.85.250.42 (209.85.250.42) 129.376 ms 129.255 ms 209.85.250.46 (209.85.250.46) 140.064 ms
21 fg-in-f104.google.com (72.14.221.104) 149.277 ms 129.703 ms 139.985 ms

PING google.co.uk (72.14.221.104): 56 data bytes
64 bytes from 72.14.221.104: icmp_seq=0 ttl=234 time=133.227 ms
64 bytes from 72.14.221.104: icmp_seq=1 ttl=234 time=133.164 ms
64 bytes from 72.14.221.104: icmp_seq=2 ttl=234 time=123.066 ms
64 bytes from 72.14.221.104: icmp_seq=3 ttl=234 time=132.975 ms
64 bytes from 72.14.221.104: icmp_seq=4 ttl=234 time=142.914 ms
64 bytes from 72.14.221.104: icmp_seq=5 ttl=234 time=132.822 ms
64 bytes from 72.14.221.104: icmp_seq=6 ttl=234 time=142.738 ms
64 bytes from 72.14.221.104: icmp_seq=7 ttl=234 time=142.666 ms
64 bytes from 72.14.221.104: icmp_seq=8 ttl=234 time=142.597 ms
64 bytes from 72.14.221.104: icmp_seq=9 ttl=234 time=142.487 ms
^C
--- google.co.uk ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 123.066/136.866/142.914/6.465 ms

So, as you can see, vastly improved latency over Hands0n's vanilla 3G on T-Mobile. It'd be interesting to see T-Mobile's HSDPA results. Note, though, the crazy number of hops through Vodafone compared to T-Mobile...

[Hands0n]

I'm round a friends on Friday who has T-Mobile HSDPA data carded laptop. Will run the tests there and post them up pronto-like :)

Unless, of course, we have a Talk3G'er who can do this sooner :D

[bsrjl1]

Unless, of course, we have a Talk3G'er who can do this sooner :D

Here you go:
C:\>tracert google.co.uk

Tracing route to google.co.uk [216.239.59.104]
over a maximum of 30 hops:

1 123 ms 119 ms 119 ms 172.18.51.100
2 97 ms 112 ms 107 ms 10.64.72.113
3 154 ms 150 ms 120 ms 172.18.247.145
4 119 ms 99 ms 109 ms 149.254.212.24
5 111 ms 109 ms 139 ms 172.18.238.198
6 108 ms 119 ms 119 ms 217.6.51.97
7 114 ms 110 ms 109 ms lon-sa1.LON.GB.net.DTAG.DE [62.154.5.37]
8 145 ms * 128 ms ldn-b2-pos1-1.telia.net [213.248.75.105]
9 156 ms 159 ms 139 ms google-118150-ldn-b3.c.telia.net [213.248.104.58]
10 147 ms 141 ms * 66.249.95.107
11 234 ms 239 ms 230 ms 64.233.174.185
12 209 ms 219 ms 260 ms 216.239.49.126
13 199 ms * 246 ms gv-in-f104.google.com [216.239.59.104]

Trace complete.

[Ben]

Crikey, that's rather flattering to Vodafone, million-hops-and-all!

[Hands0n]

Thats a nice result from T-Mobile's HSDPA - a sane 13 hops to the destination without rattling around endlessly within their own intranet. They seem to leave their own network around hop 5 or 6 vs at least hop 10 for Vodafone! You just gotta love corporate network design!

[Ben]

Not very nice in terms of latency, though!