Ovidiu Predescu's Weblog

Bad Comcast Internet service

Comcast's Internet service has been pretty bad in the past few weeks. It started about 6 weeks ago when they apparently screwed up my modem registration. As a result of this hiccup, for more than a week I had a download speed of about 128kb/sec instead of the 3Mb/sec that I pay for. After repeated calls to the customer service over many days, they finally fixed it. According to one of their customer reps, the problem was caused by an update of their registration server. Duh, all this time they were instead blaming my modem!

Some days ago, their DNS servers were not available for about an hour. As I write this, their DNS servers are down again. I got so fed up with this situation, I setup a caching nameserver on two of my always running machines at home - I should have done this long time ago.

According to CNET's internet connection speed meter, the connection speed I get is about 256kb/sec, nowhere close to 3Mb/sec!

It's time to switch, but unfortunately the alternatives are limited in Bay Area. There are no other cable providers, and with SBC DSL I seem to be limited to 1.5Mb/sec. I'll give it a try though.

Update (April 13, 2005): I did some checks on my setup, and it turns out both my modem and my router/firewall were having problems. I setup a different cable modem and a computer connected directly to it got 4Mb/sec download speed. Through my old firewall the computer with the new modem got only about 1Mb/sec instead. I ran again to Fry's and got a replacement firewall box.

With these new two components and my two home caching DNS servers, things are now running much faster. As Suraj suggested in the comments, I setup an additional DNS server to backup my home ones, should they both fail.

java.nio.channels.FileChannel is not selectable?

Maybe I'm missing something, but I just can't figure this out. With the Java NIO it appears there is no way you can use selectors to asynchronously listen for new data to read on stdin, or any other files for that matter!

I want to write a simple program that opens a serial device file (/dev/ttyS0 for example) on Unix (Linux or MacOS X), and listens to events on the associated file descriptor. These events are bytes written by a physical device connected on serial port. I also want the application to listen on stdin, for characters I may type to change the internal state of the application.

With the Unix select() you can do this easily by passing the two file descriptors to the system call. The Java API however chose to hide this ability, and you can only do selects on sockets. This is really stupid and plain wrong if you ask me, as it basically means I need to write the multithreaded code to handle this simple application.

How could the bunch of Unix heads at Sun that designed the NIO API allow such a thing to happen? Somebody tell me I'm wrong, please!

Update (April 5, 2005): Java is just the wrong language for my application. I've ported everything to Python, and implemented the above functionality in just few lines. Sometimes too many abstractions are just wrong, as in this case. Python exposes everything I need, including device characteristics (serial line speed, parity etc.). The perfect tool for the job!

iPod Photo Connector is slow

About a month ago I bought the latest iPod photo with the hope it will be able to act as a backup for the pictures I take with my digital camera. I just got the new Photo Connector and connected it to my EOS 20D camera to see how fast the downloads happen.

Downloading 47 pictures occupying 345Mb takes 12 minutes, eating a lot of iPod's battery in the process. Based on the battery level, I estimate it uses about 1/6th of the battery.

By contrast, downloading the same pictures directly from the camera into the computer takes 2 minutes (the camera has USB 2.0), 6 times faster!

Another comparison I did was to transfer the pictures from the iPod to the computer directly. I mounted the iPod as a disk and copyied the pictures on the computer using cp in Terminal. This process takes about 40 seconds using a dock connected via Firewire to the computer!

This is really disappointing, I was hoping for a much higher transfer rate between camera and iPod. Judging by the difference in speed, 6 times slower camera <-> iPod than the camera <-> computer connection, it appears the Photo Connector uses USB 1.1 instead of USB 2.0.

Hopefully Apple will improve this connector in a future release. As it is, the current version is fairly unusable. If you just want to carry the camera and iPod with you, downloading a 1Gb memory card would take about 35 minutes, in which time you cannot take any shots.