Sean's blog

DiGi and Streamyx: The tortoise and the hare

I still can’t be bothered phoning this one in, it is after all just bad and not actually completely broken. It is also Sunday, so the weekend-workers at TM would probably rather tackle something really major. I mentioned a couple of nights ago that Streamyx was bad to some international sites, well it still is – here’s a ping to news.bbc.co.uk:

sean@taiguima:~$ ping -n bbcnews.com
PING bbcnews.com (212.58.224.138) 56(84) bytes of data.
64 bytes from 212.58.224.138: icmp_seq=1 ttl=112 time=529 ms
64 bytes from 212.58.224.138: icmp_seq=2 ttl=112 time=514 ms
64 bytes from 212.58.224.138: icmp_seq=3 ttl=112 time=252 ms
64 bytes from 212.58.224.138: icmp_seq=5 ttl=112 time=507 ms
64 bytes from 212.58.224.138: icmp_seq=6 ttl=112 time=255 ms
64 bytes from 212.58.224.138: icmp_seq=7 ttl=112 time=284 ms
64 bytes from 212.58.224.138: icmp_seq=8 ttl=112 time=256 ms
64 bytes from 212.58.224.138: icmp_seq=9 ttl=112 time=267 ms
64 bytes from 212.58.224.138: icmp_seq=10 ttl=112 time=264 ms
64 bytes from 212.58.224.138: icmp_seq=13 ttl=112 time=521 ms
64 bytes from 212.58.224.138: icmp_seq=15 ttl=112 time=523 ms
64 bytes from 212.58.224.138: icmp_seq=17 ttl=112 time=529 ms
64 bytes from 212.58.224.138: icmp_seq=18 ttl=112 time=255 ms
64 bytes from 212.58.224.138: icmp_seq=20 ttl=112 time=529 ms
64 bytes from 212.58.224.138: icmp_seq=21 ttl=112 time=256 ms
64 bytes from 212.58.224.138: icmp_seq=22 ttl=112 time=540 ms
64 bytes from 212.58.224.138: icmp_seq=23 ttl=112 time=259 ms
64 bytes from 212.58.224.138: icmp_seq=24 ttl=112 time=256 ms
64 bytes from 212.58.224.138: icmp_seq=25 ttl=112 time=538 ms
64 bytes from 212.58.224.138: icmp_seq=26 ttl=112 time=249 ms
64 bytes from 212.58.224.138: icmp_seq=27 ttl=112 time=249 ms
64 bytes from 212.58.224.138: icmp_seq=29 ttl=112 time=535 ms
64 bytes from 212.58.224.138: icmp_seq=30 ttl=112 time=245 ms
64 bytes from 212.58.224.138: icmp_seq=31 ttl=112 time=537 ms
64 bytes from 212.58.224.138: icmp_seq=32 ttl=112 time=521 ms
^C
— bbcnews.com ping statistics —
33 packets transmitted, 25 received, 24% packet loss, time 32100ms
rtt min/avg/max/mdev = 245.494/387.271/540.330/135.008 ms

This is actually quite a good one! I forgot the -n switch (so the lines aren’t too long to fit nicely in the blog!) the first time, and that was 50% packet loss. You can see the massive variation between times. Here’s a DiGi ping, taken about the same time:

root@box0045:/home/sean# ping -n bbcnews.com
PING bbcnews.com (212.58.224.138) 56(84) bytes of data.
64 bytes from 212.58.224.138: icmp_seq=1 ttl=114 time=957 ms
64 bytes from 212.58.224.138: icmp_seq=2 ttl=114 time=1456 ms
64 bytes from 212.58.224.138: icmp_seq=3 ttl=114 time=736 ms
64 bytes from 212.58.224.138: icmp_seq=4 ttl=114 time=698 ms
64 bytes from 212.58.224.138: icmp_seq=5 ttl=114 time=736 ms
64 bytes from 212.58.224.138: icmp_seq=6 ttl=114 time=574 ms
64 bytes from 212.58.224.138: icmp_seq=7 ttl=114 time=536 ms
64 bytes from 212.58.224.138: icmp_seq=8 ttl=114 time=690 ms
64 bytes from 212.58.224.138: icmp_seq=9 ttl=114 time=632 ms
64 bytes from 212.58.224.138: icmp_seq=10 ttl=114 time=549 ms
64 bytes from 212.58.224.138: icmp_seq=11 ttl=114 time=671 ms
64 bytes from 212.58.224.138: icmp_seq=12 ttl=114 time=633 ms
64 bytes from 212.58.224.138: icmp_seq=13 ttl=114 time=592 ms
64 bytes from 212.58.224.138: icmp_seq=14 ttl=114 time=672 ms
64 bytes from 212.58.224.138: icmp_seq=15 ttl=114 time=692 ms
64 bytes from 212.58.224.138: icmp_seq=16 ttl=114 time=551 ms
64 bytes from 212.58.224.138: icmp_seq=17 ttl=114 time=692 ms
64 bytes from 212.58.224.138: icmp_seq=18 ttl=114 time=694 ms
64 bytes from 212.58.224.138: icmp_seq=19 ttl=114 time=573 ms
64 bytes from 212.58.224.138: icmp_seq=20 ttl=114 time=714 ms

— bbcnews.com ping statistics —
20 packets transmitted, 20 received, 0% packet loss, time 19005ms
rtt min/avg/max/mdev = 536.086/702.613/1456.054/195.820 ms, pipe 2

See? No packet loss! The times are large and there’s large variation between times because this is a cellular modem. Ping times and packet loss may not be of much interest to you, but if you want to read the news at http://news.bbc.co.uk/ and you have a choice of these two Internet connections, you’ll get a counter-intuitive result.

My Streamyx connection is specified as 512Kbit/s, EDGE is about 200Kbit/s (I think). Using Streamyx, the BBC page ‘half’ appeared after a minute and 5 seconds. That half never completed. I gave up at 4 minutes. Using DiGi, the whole page appeared around 1 minute, with the pictures slowly appearing over the next 2 minutes. The page was fully loaded around 3 minutes.

Those times sound appalling, and they are – I suspect the international links may be unusually slow today. the BBC News front page is also very, very ‘fat’, with lots of images to load – nearly half a Megabyte in total. I cleared my cache in between loads of the BBC News front page, so every little icon had to be loaded each time. If you visit the page a second time, it loads in under 20 seconds on DiGi and fails to load again on Streamyx.

It is just like the old story of the tortoise and the hare. Streamyx is fast – when it works. It occasionally impresses me with its performance. You couldn’t ever say the same for DiGi EDGE – it’s physically a slow way to transfer data, there’s no getting away from that. But it never fails to deliver the goods. Eventually.

– Update –

It did cheer up for a bit, and was quite fast, up until lunchtime 2 days later. And then it was unusable.