Biodiesel can't be stored underground?

No wonder BMW is having so much trouble selling the x5 xdrive35d and 335d (both are diesel models, which Europeans love and Americans don't.)

Local gas stations are not selling biodiesel anymore because the State Water Resources Control Board asked them not to store it underground.

More here.

Electricity prices up 5% YoY, also home-energy monitoring!

Just because you wanted to know: electricity prices are up 5% year-over-year in California, and about the same amount across the U.S. See this chart for more data.

Depending on the state, it's a mixed bag. But it is fun to read how much prices vary: people in Idaho pay 7c/kwh, whereas Connecticut and Hawaii pay >20c!

My household spends >3x as much on electricity as gas (natural and automobile combined). I wonder if this is common, because the ratio seems high. The computers amount to maybe 15% of the total, so having too many computers isn't skewing the numbers too much.

It's a good thing utilities and other companies are paying attention to this. If you want something to help understand your energy usage before your utility company and Google fix it, this article has two good alternatives, called Blue Line and TED (which weirdly is branded very much like the TED conference.)

Geoff Fowler at the WSJ seems to like the Blue Line/Black & Decker monitors slightly more than the TED thing. Maybe it's worth trying one, since they sound pretty easy to install.

Dropbox to add "LAN sync"

From an email today:

In addition to the iPhone app, we're also finishing up a new version of the Dropbox desktop software that features numerous performance improvements and our new "LAN sync" feature. LAN sync knows when Dropboxes are on the same network and will automatically exchange files directly between computers instead of downloading them from our servers - this makes sharing large files in an office environment much faster than was previously possible.

I hope there's an option to keep some files off the server, as well. Would be nice to be able to use Dropbox for everything!

MoCA bridges rock: the Netgear MCAB1001

We've had a terrible time getting a wireless network to reach our detached garage, where Lorna paints and uses her Mac. It has kind of worked, kind of not, and the latency has been awful.

Amazingly there is coax wired between the structures, and so there's a new variety of "MoCA" bridges that will use coax like ethernet, without disrupting your TV or internet connection. It's like powerline networking, except using coax, and also except it's actually fast.

We got the Netgear MCAB1001, and it works better than you could believe. 5 minutes to set up, and then it's on.

Since the ethernet side of the Netgear is 100mbps, it appears to bottleneck there, but I'm seeing 12MB/sec over HTTP, and less than 3ms everywhere. It really just works.

Mesh, a week later

Windows Live Mesh has been doing a good job for me. I have a 25,000-file folder sync'd across my laptop and desktop, and it all stays up to date, reasonably fast. I'm not syncing any data to the cloud, because I don't need it there and I don't want to pay for storage.

"Moe.exe" seems to be using a little more CPU than I'd expect (still context-switching away somewhere in the CLR), but overall it has much less system impact than I'd previously experienced. It seems to be keeping a lot of log files, and maybe (I'm hoping?) because this is a beta, some of them can be turned off in the future.

The only annoying thing is that Picasa keeps noticing changes in the Mesh folder. Files that were in sync days ago are showing up as changed, about once an hour. Odd.

Currently the major missing pieces for me are these:

1. Mesh is "PC and cloud" only. That seems to mean NTFS/HFS+, local filesystems only.

2. You can't sync to a network drive, and you can't install on Linux or Solaris. So this makes my investment in seriously awesome NAS kind of useless.

For installing on your server, the Linux/Solaris (inotify, FEM) equivalents to NTFS ReadDirectoryChanges are a little less mature, but it's certainly possible to code against them. (Wine supports inotify and dnotify for Picasa!) Crashplan supports Linux and Solaris, today.

PC against NAS sync is actually a harder problem. Even FindFirstChangeNotification/dnotify-level events over NAS turn out to be flaky in the implementation.

However, file locking does actually work (with at least 1-second-level precision), and it is possible on NAS to log all changes to particular files, and poll them from remote PCs.

So I really believe that a winning solution in this category will (a) support network filesystems (b) support UNIX/Linux hosts, and (c) use fewer resources on the desktop than Mesh does today.

But if you have a Desktop/Laptop combo, and you're not out of space yet, I can recommend Mesh for your basic sync p2p needs.

If you want a cloud backup or you're willing to pay for storage, and you don't mind the limitation of sync'ing from a particular folder, Dropbox is more efficient and tends to be faster to notice changes as well.

Mesh kinda worked!

[update: Despite its using an absurd quantity of resources, I'm letting Mesh finish syncing 13GB of stuff in a small folder. Moe.exe is using 170MB of RAM, but it's actually really working.]

[update 2: Mesh has copied 9GB in about 4 hours, for about 600kb/sec. That's about 10% utilization of my 802.11n network.]

I rebooted my laptop and Windows Live Mesh started syncing.

The amazing thing is that it's doing as many as 500,000 context switches/sec (no idea that was possible), and using most of my CPU (on a dual-core machine). So mostly the computer is running at "slow" speed while it's going.
This is on a 2.53GHz Core 2 Duo. I just had no idea copying files over a network took this many resources.

I guess you could do a context switch per packet, um, write the packet to a log file, um, write the packet to a database, maybe with a different thread for each task, and synchronize them somehow. But I think that might be more CPU-efficient than this.

And below is the graph of CPU...remember that's 80% of CPU on a dual-core box.

And finally, here's some more evidence of what's going on. This thing is actually writing data to disk 41 bytes at a time. That is just an insane amount of work for the kernel to do, and very unnecessary...

Social Network APIs for spam control?

I'm wondering if there's a way that we can use the proliferation of social networks to solve part of the email spam problem.

For instance, if you always sent mail and asked Facebook (or, hm, OpenSocial), "Hey, give me proof that so-and-so knows me?"

Then, if Facebook signed that request using some simple PKI system, you'd include the sig in your email header, and you could verify it's not spam using PKI. (Twitter, etc. could do the same thing.)

It could be possible to roll this kind of thing into an Outlook plugin, and webmail systems could follow fast with OAuth implementations of the same thing. You could deploy this widely within 12 months, and your mail would get through, very reliably.

Blatantly Latent: WiFi makes network filesystems pokey

I was just doing some benchmarking of my favorite photo app against a mounted NAS volume, on wireless 802.11n. Actually it doesn't take benchmarking to notice that things are a lot slower over wireless.

A lot.

Slower.

802.11n is not at all, even close, "ethernet without wires". In some cases it takes 20x longer to do things than 100Base-T. It's not clear by looking at the specs why this is true. But from what I've observed, the reason for this gap has a lot more to do with latency than throughput.

I'm sitting 12 feet from my WRT610N router with an Intel 802.11n chipset in my laptop, going through one wall, and this is mostly what you'd call a state of the art combo.

I can stream data at about 6MB/sec over this connection.

But my "average" ping to my router is nearly 10ms, about the same as my DSL ping to my ISP. For things like big HTTP streams, 802.11n does really nicely. It can stream video, and stuff like that.

Network filesystems were invented 20 years ago, when throughput and latency were balanced differently. The most data you can request at a time over these systems is maybe 64k, and that's not so much when latency is high.

This means if you issue 64kb reads in a tight loop, you can maybe use half of a typical 802.11n line. But just barely, and it depends on noise, and if your computer is doing anything else.

It's not nearly as good as an HTTP stream.

And still, the 64k at a time approach sounds close to reasonable, until you realize that the code everyone's using to read files (stdio and jpeglib and libpng) have embedded default buffer sizes of 4-8k! And that's when it gets really bad.

Yeah. Oh it's slow.

If you make software, you really have to change these 4-8k defaults, or even implement readahead if you don't want to be entirely gummed up by a normal wireless network. Because if you're only reading 8k at a time, you're reading at less than 25% of your network's capacity, maybe 10%.

No way around it. You are just slow.

People will notice that, and you'll be slow compared to the people who know this and code around it. They'll be 4x faster easily, and maybe more.

My advice: pretend you're reading streams 64k at a time. Don't seek a lot. Don't use a database that reads in 4k blocks.

I guess we should also think about when these 20-year-old filesystems are going to get updated. In the long term, we need network filesystems that can deal with latency in a smarter way. WebDAV tried to do that with HTTP, but with an XML fetish that doesn't look efficient over the wire. In general, a smarter approach to block sizes (intelligent read-ahead) and hints based on recent usage would help a lot. If I've just opened a dozen 30MB .CR2 files and read their full contents, software that adapts to that case would be very nice, rather than running at 10% of the network's speed because of a 20-year-old protocol.

The batchy, async "sync" protocols are all very proprietary right now, and they don't degrade nicely to "be like NFS or Samba". There's a big split in both openness and in "sometimes I need async speed and sometimes I need synchronous operation".

The cost of not updating this piece of the technology stack over time is that the 4x gap in throughput you can find today between "synchronous reading" and "streaming" widens further, until there are no "common" and high-performance network filesystems, and we all use custom or async protocols for high-performance situations.

We could do that, but I think there's potentially a middle ground, using some read-ahead, and some batching to avoid these issues. And if applications can usefully say "be totally async" then we get protocols like the ones we see in sync solutions today.

Finally, wireless standards could put some focus on latency as well as throughput. It's nice marketing to stream 3 HD video streams, but it's also nice when that doesn't come at the cost of increased latency for other common operations.

It's important to keep throughput and latency in balance. Already the big improvements made in the 802.11n standard show a trend towards putting them out of whack. Let's see if software or hardware makes the next step towards improving that.