Saturday, 10 May 2008

Edelweiss

Awoke this morning to the sound of "Edelweiss" (from The Sound of Music). What's particularly strange is that this is the second time I've heard this song here this week (we came across about 20 couples waltzing to it outside the Workers' Stadium last weekend). At first I thought it was our new neighbour upstairs who seems to practice the piano, the violin, the saxophone, and what someone more generous than I might call "singing" (even calling it karaoke would be gracious) throughout the day. Turns out it was a brass band playing for what looks to be a shop opening... how did this song get so popular over here?

Update:
Now I've got it stuck in my head again... gah!

Thursday, 8 May 2008

Olympic flame summits Mt. Qomolangma

I turned on the TV this morning just as the Olympic flame was being carried up the last 100m of Mt. Qomolangma (the Tibetan name for Mt. Everest), the world's highest peak. The media here has been anticipating this for weeks, probably since the torch relay began. While it seemed like a good gimmick I have to admit to a little bit of apprehension: it was hard to imagine the climbers calling of the summiting attempt, no matter how bad the weather was. How could you fail after building it up so much?

Luckily the weather looked good and they made great time to the top. And watching the footage I had to admit it was a fairly powerful image and pretty memorable achievement.

In looking into the torch relay, I discovered I had missed this leg of the Sydney torch relay: another unique gimmick.

Olympic Tickets

Looks like we've successfully obtained two tickets to see Beach Volleyball at the Olympics. I've been cursing myself for not getting on top of this earlier and picking through the scraggly tickets left at the various official national tickets sellers for which we could possibly qualify (Canada, Ireland, Germany). Not much left, let me assure you...

Then we caught wind on the news on Sunday that the 3rd round of Chinese sales would begin Monday morning, and as luck would have it Julia qualified on account of her visa type. The selection was still somewhat limited and I spent 5 hours or so Monday repeatedly clicking and waiting for the inevitable "Sorry, we are unable to process your request at this time" which was the result of the huge load hitting the servers. I finally got an offer of two beach volleyball tickets shortly after lunch. Because of a rather complex, bureaucratic payment process, I was unable to acquire any more but at least I'll get to see something (and the tickets were only $7.50 or so each!). Some people, having failed to get tickets in the first two rounds, apparently trekked across the country to line up for tickets at Bank of China branches in Beijing the night before. Olympic fever is building...

Wednesday, 7 May 2008

A Beijing Expat Wife

People here often ask what I'm doing here. I used to say I was looking for work or that I was doing contract work or thinking of taking some classes. Or I'd give the long spiel about how my girlfriend was doing an internship, blah, blah, blah. Now I just say "I'm an expat wife" and pause for the double take. Hence the new title for the blog: "A Beijing Expat Wife: Excuse the facial hair..."

Friday, 25 April 2008

Asterisk on VMWare

Many people have reported problems with Asterisk running on VMWare and having just decided to play with Asterisk I ran into them myself. First, here's what worked for me (using CentOS 4.6):

  • On the VMWare host machine, edit the .vmx config file for your image and add:
host.noTSC = "TRUE"
ptsc.noTSC = "TRUE"

  • In your CentOS image, disable the cpuspeed process:
chkconfig cpuspeed off

It actually worked fine for me without the extra kernel parameters but the CPU usage seemed to be slightly lower at idle with them added so I left them. The issue seems to be the default clock rate (1000Hz) used by most 2.6 kernels which can't be adequately serviced in the VM guests. The kernel-vm kernel is built with the clock rate at 100Hz.

Apparently CentOS 5 has a new kernel that allows you to specify divider=10 clocksource=acpi_pm to the kernel which tells it to run at 1/10 the clock rate it was compiled with.

Some links:
http://communities.vmware.com/message/762010#762010
http://bugs.centos.org/view.php?id=2189
http://communities.vmware.com/thread/101492?start=0&tstart=0
http://communities.vmware.com/thread/101406

Wednesday, 23 April 2008

Adjusting MTU to improve ADSL performance

So here I am in China, being driven mad by the number of dropped packets I'm seeing. Mostly it's not too bad until I make a VPN connection and then I'm seeing somewhere in the neighbourhood of 10% packet loss on a ping.

Well, after much, much debugging and internet searching I think I've finally found my problem: the MTU setting. MTU is the Maximum Transmission Unit or maximum size of an individual frame being sent on a network. Ethernet has an MTU of 1500, which is usually set as the default value for connections (at least in MS Windows). But other network equipment along your route may not be using Ethernet and may have a lower value. This is ok in theory; the equipment will break up larger frames into smaller ones and combine smaller frames into larger ones as the data is transferred between different networks.

The problem usually comes when your ISP's equipment is using an MTU slightly lower than your value. Apparently PPPoE connections always have a lower MTU than Ethernet (usually 1492) but Windows XP already accounts for that by reducing the MTU for PPPoE connections to 1480. In my case, though, China Telecom seems to be using equipment with an MTU of 1398.

What happens is that I send out 1480 bytes of data and China Telecom sends the first 1398 bytes and then holds onto the remaining 82 bytes until it gets some more data from me. Let's say I send another 1480 bytes. Now the first 1316 bytes of that frame are added to the 82 bytes from my first frame and sent and the remaining 164 bytes are held onto. This is slightly inefficient and can make the connection seem "bursty" because data is being held up before being sent. It also tends to get a lot worse if your connection is flaky (which mine is); I think this is because a lost frame along the way may hold part of the data for 2 or more of my original frames, all of which now need to be retransmitted. VPNs (because of the way TCP packets are being embedded into TCP packets) apparently amplify these effects further.

So how do we solve it?

Finding the Correct MTU

First, you need to find out what MTU setting your ISP is using. This MS KnowledgeBase article describes how to do this. Basically, you pick a host as close as possible to you on your routing path and run the following command:

ping -f -l size

The -f marks the packet as non-fragmentable and the -l size parameter specifies the number of bytes to include in the ping packet.

Start with a value of 1472 for size. If the ping is successful, your ISP's MTU is 1500. If you get the error Packet needs to be fragmented but DF set then decrease the value of size and try again. Once you find the highest value that allows a successful ping, that value plus 28 (20 bytes for the IP header and 8 for the ICMP header) is the correct MTU value.


Adjusting the MTU Value in Windows XP

Follow this KnowledgeBase article to set the MTU value for PPPoE (also seems to affect all VPN connections - not sure if there's a way to avoid that). Basically you want to set the following registry keys (all values are DWORD type):

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NdisWan\Parameters\Protocols\0]
ProtocolType = 0x00000800
PPPProtocolType = 0x00000021
ProtocolMTU = 1480

Obviously you would adjust the MTU value as desired and make sure to choose "decimal" when inputting the value. You probably have to reboot.

You may alternatively be ale to specify the MTU for the PPPoE interface here:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{Adapter-id/GUID}]
MTU = 1500

but I haven't tested it yet (again, adjust the MTU as desired and choose "decimal" when entering the value).

UPDATE: I tested setting the MTU for just the one PPPoE interface as above and it seems to work fine. I set the MTU value for NdisWan back to 1480 and will probably test removing that section from the registry altogether to see if it still works.

Other possibly helpful links:
http://www.speedguide.net/read_articles.php?id=157
http://www.speedguide.net/analyzer.php