World IPv6 Day....

Well maybe you've heard about IPv6, though you're less likely to have heard about World IPv6 Day (8 June 2011 not far now...) - A ruse from the guys at ISOC to get people talking about it. Well it is also that some of the world's biggest content providers (Google, Yahoo, Facebook, Akamai and others) will enable IPv6 on their main services that day - should be fun... (They mostly have IPv6 enabled offering already but you need to use special addresses ipv6.google.com).  On that day they will enable the lookup of the IPv6 addresses for their main addresses e.g. www.google.com will provide an IPv6 address (an AAAA record) from the normal DNS. Currently the only way to obtain IPv6 addresses for Google's main services is to use a whitelisted DNS server - such as those provided by he.net.

And talk about it people should! Given we really are (even the BBC are talking about it) about to run out of [old] IP [v4] addresses - (see my new gadget to the right) - the last bunch of IPv4 addresses were ceremoniously handed out and then everyone will be scurrying around trying to buy or sell addresses for while until they realise that IPv6 is the way forward.

Of course I've been IPv6 connected for ages....yeah yeah um - well it mostly just works, though since it's often via a tunnel it's not always the fastest option available... But all you Windows 7 users are already automatically connected to IPv6 via Teredo (which is available for other OSes - a free version is miredo).

Sorting out clock wierdness on dual boot Windows and OSX/Linux

I just installed Windows 7 on my MacBook and Windows STILL stores the local time in the hardware clock (as opposed to UTC) so when you reboot between the two OSes the time changes - dang! It turns out that there's a secret registry key that gets Windows to behave 'normally' in this respect. You just need to add a new DWORD key, called RealTimeIsUniversal (which should be set to 1), at the following place in the registry (and then reboot to make it take effect):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation

Here's all the details from a man who knows....

Google Chrome: SPDY (Speedy)

So Google have now deployed their 'go faster' SPDY (Speedy) web page delivery protocol - which is not only in Chrome but also running on various Google services including gmail.

Google's performance figures on SPDY look good - and I think their figures are impressive. So if you want speeded up Google services then run Chrome!

There's all the dirt on SPDY here and of course they have a 'magic' URI/URL you can tap into your Chrome browser to see the internal stats:

about:net-internals

So how radioactive is it in Tokyo?

Maybe you're wondering what the actual figures are - well you can watch them (uSv/hr) change (FYI I looked at it a week ago and it was 0.14uSv/hr - it is now 0.24uSv/hr) live on this live feed of a Geiger counter (a RADEX RD1503) located in Tokyo:

Live TV : Ustream
For the latest on the reactors check out daily updates from Japan's Atomic Industrial Forum.

OSX environment variables

Where are those pesky things kept - as usual Apple like to keep us guessing....Whilst the folks at Stackoverflow provide answers:

• ~/.profile, ~/.bashrc, (~/.cshrc, ~/.tcshrc) - depending on what shell you're running
• ~/.MacOSX/environment.plist - More for GUI stuff
• /etc/launchd.conf - used globally by launchd (can be set per process using launchctl setenv)
• /etc/paths - just for setting the PATH

Windows networking: interfaces

So have you ever wondered where Windows configures the some more obscure networking things like the length of its outgoing interface queue? (It's ok if you haven't ;) Anyway if you have then here's the dirt:

• The actual maximum size of the queue (cf Linux's txqueuelen) is set in the registry:
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{...your  GUUID here....}\ForwardBufferMemory which defaults to 50 packets (ok for 100Mbit Ethernet but not so good for Gigabit speeds...)
• For the above config to work you need to enable router mode:
  HKLM\SYSTEM\CurrentControlSet\Services\Parameters\IPEnableRouter=1
• In principle you can monitor the length of the output queue interface using this API

There's a various places that offer advice on improving performance like, Microsoft, and speedguide (win7). Windows 7 even provides special networking/scheduling support for multimedia apps.

Handy command line based Windows network tools: ipconfig, netsh

Hard disc full again?

Yeah even if you've got GigaBytes of it you still seem to run out! Here's a few free tools that are good for visualising used space - using a nice visualisation technique known as treemaps:

Windows: WinDirStat, SequoiaView (a bit old)
Mac OSX: Disk Inventory X, GrandPerspective. (Baobab is available thru darwinpaorts)
Linux: Disk Usage Analyzer (aka Baobab)

There's also plenty of others out there but I've not tried 'em.

Updated: 1jul15

Using the Linux tbf qdisc for rate limiting on local or loopback interfaces

If you have ever played with the Linux tbf (Token Bucket Filter) on either some local interfaces, or on the loopback interface (lo) then you may have run into problems - like the attained rate is only a few hundred kilobits/s or less (zero)....?

tc qdisc add dev lo root tbf rate 10Mbit burst 10kb latency 5ms 

Basically if your interface has TSO/GSO enabled (check using ethtool -k ethX), or you're using the loopback interface - then you'll probably hit a problem. It turns out that the loopback interface has GSO/TSO enabled as default, plus since it is a software interface its default mtu is 16384 (as compared to 1500 for normal Ethernet interface). This matters as the tbf queue checks the size of the incoming 'packets' - which in the case of GSO/TSO are much larger than a normal on-the-wire packet - instead they're up to 9 x iface's mtu. So for normal interfaces it's about 12K, but for loopback it is about 100k!

In which case you'll need to add the 'mtu' argument to the tc command and then it might work( but check update below in case not):

tc q a dev eth0 root tbf rate 10Mbit burst 10kb latency 5ms mtu 100000

Update [29jan20]: It is also important that the burst parameter is greater than the MTU (you will see warnings in dmesg to this effect if your burst size if too small) if running on an interface that has a large MTU like the loopback interface which is now commonly set to 65535 :

tc q a dev eth0 root tbf rate 10Mbit burst 70kb latency 5ms mtu 100000