Monthly Archives: March 2005

Photoshop image rotation made easy

If you use Photoshop for scanning images, you often need to rotate the scanned image by a degree or two to get it lined up straight (placing it straight on the scanner bed can be almost impossible).

I used to use the trial & error method of guessing a rotation amount, trying it out, then adjusting it up or down until I got something that looked right. Eventually, I figured there must be an easier way.

And of course there is: use Photoshop’s Measure tool, which is a sub-menu option on the Eyedropper tool. Measure a horizontal or vertical line using this (the longer the better), then open the Rotate Canvas / Arbitary dialog and you’ll find Photoshop has automatically filled in exactly the right angle for you.

This handy tip courtesy of Pixel-Techs where you can also find a detailed example, with screenshots.

Eircom’s new DSL packages

After several weeks of rumours, Eircom officially announced their new DSL packages today.

It’s not a bad deal. All existing customers will see improvements of between 2x and 4x in total downstream bandwidth, depending on the monthly subscription. The best improvement is for Home+ users, who jump from 512 Kb/s to 2 MB/s. Smart Telecom’s equivalent deal is still significantly cheaper, but offers only 128 Kb/s instead of 256 Kb/s upstream.

There was an opportunity for Eircom to also increase upstream bandwidth, but they appear not to have done so. Several people are speculating that this is to discourage business users from switching to VoIP, thus undermining Eircom’s voice revenue; this could well be the case.

No discussion at all of bandwidth caps – in light of Smart Telecom’s cap-free policy, Eircom may have decided to leave it be for now, privately targetting only those users that are blatantly abusing it.

Interesting times…

Pesky ATA/66 disk caddies

In an earlier entry, I mentioned the problems I had when upgrading an old ATA66 drive to a shiny new ATA133 drive. The old drive had been in an ATA66 removable disk caddy, and it didn’t behave too well at ATA133.

I resolved that problem by simply uninstalling the drive caddy and connecting the new drive directly to the motherboard via a decent ATA133 cable. (HDTach still shows the performance as a little choppy, but it’s not bad, averaging around 50 MBps transfer rate and peaking at 78 MBps.)

Well, I had a 120 GB drive die a few days ago, also in a caddy. Maxtor sent me a replacement, and once again, it was ATA133. Exactly the same problem as before – really bad performance, making the PC close to unusable.

I didn’t want to give up another caddy, so I buckled down and did a bit of research. It’s been well documented that Windows XP will drop down to PIO mode for hard disk transfers after six DMA timeouts have occurred. However, my problem was different – I suspected transfer errors (which result in a retry) rather than timeouts.

You can check which mode Windows is currently using for a drive by going into System / Hardware / Device Manager, then opening IDE / ATAPI controllers and double-clicking the Primary or Secondary IDE controller. Under Advanced Settings, you’ll see the current transfer mode used for each drive.

I knew from the PIO/DMA discussions that the registry key HKEY_LOCAL_MACHINE \ SYSTEM \ ControlSet001 \ Control \ Class \ {4D36E96A-E325-11CE-BFC1-08002BE10318} was responsible for configuring the ATA IDE driver. However, documentation of the various fields was hard to come by. I eventually figured it out by trial and error.

This key has a Default value of “IDE ATA/ATAPI controllers”, which is a handy way to check you’re in the right place. If you’re searching for it manually, it’s usually about the 10th class down in the (gigantic) list of classes from the top, so it’s easy enough to locate.

Inside the key are several numbered sub-keys: 0000, 0001, 0002, etc. 0000 is for the IDE controller, 0001 and 0002 are the primary and secondary interfaces. If you have multiple IDE controllers (e.g. SATA and PATA), then there will be more than three keys here – be careful to modify the correct one! The SATA controller is usually listed before the PATA controller, but you may just need to use trial and error.

Anyway, once you have identified the correct subkey, corresponding to the interface the problematic drive is attached to, you’ll see a few sub-keys:

  • MasterDeviceTimingMode – set to the fastest supported transfer mode when the drive initialises.
  • MasterDeviceTimingModeAllowed – defines what modes are supported by Windows; usually set to 0xFFFFFFFF, but we can tweak it to stop certain modes being used.
  • MasterIdDataCheckSum – I believe Windows uses this to detect when a new drive has been attached to the cable. If you delete this key, it forces Windows to treat the drive as new next time it boots up, and restore full DMA access. This is one way to force a drive that Windows has reduced to PIO mode back to UDMA mode again.

(The same settings also exist with a Slave prefix; which set you modify depends on whether your drive is the master or slave.)

Let’s look at the MasterDeviceTimingModeAllowed value in more detail. This defines a 32-bit mask, allowing up to 32 options to be individually permitted or prohibited. The default value of 0xFFFFFFFF means all supported operations are permitted. By selectively turning off certain bits, we can make Windows avoid using those features. These same bits are reflected in MasterDeviceTimingMode, so that’s a good place to start.

On my UDMA6 drives, MasterDeviceTimingMode was set to 0x20010, which is 0x00020010 in 8-digit hex. I also knew that 0x00002010 was UDMA2. It seemed logical that the in-between positions corresponded to UDMA3 (0x4010), UDMA4 (0x8010) and UDMA5 (0x10010). The 0x10 at the end is probably multi-word transfer, though I haven’t confirmed this.

Right so. To disable, for example, UDMA5 and UDMA6 (ATA100 and ATA133 support respectively), we just need to turn off the appropriate bits in the Allowed mask. Instead of 0xFFFFFFFF, we can use 0xFFFCFFFF. All the other modes up to and including UDMA4 (ATA66) will still be allowed.

My problematic drive was attached to the secondary master IDE interface, so I went ahead and set MasterDeviceTimingModeAllowed for that interface to 0xFFFCFFFF, then rebooted. Sure enough, Device Manager now shows that the drive is running UltraDMA 4 instead of UltraDMA 6. Better, the performance is now usable again, averaging around 20 MB/s transfer rate. I suspect the caddy is still introducing errors (HDTach is a bit choppy still) but it’s hugely better than it was before.

This is crying out for a little applet to let you tweak the individual bits in this mask from a nice GUI. Perhaps I’ll write one if I get some spare time…

Host fingerprinting

The technique of OS fingerprinting has been well documented. It lets you identify the operating system used by a remote host with a fair degree of certainty. Indeed, OpenBSD even supports this in its filter engine; for example, you can write a rule that assigns mail traffic from Windows machines to a lower-priority bandwidth queue than that from other machines (since such traffic is usually the result of a virus).

However, researcher Tadayoshi Kohno has come up with a much more sophisticated approach, based on measuring clock skew across TCP packets. The idea is that every machine has a slightly different skew to their internal clock, and almost all TCP stacks timestamp packets using their internal clock as a reference point. By identifying the clock skew used for a particular PC, e.g. a laptop, you can track that machine’s movement as it moves around the Internet, perhaps connecting from several different countries or via different dial-up nodes.

All very ingenious, and with no end of big brother implications. Read more in this article at ZDNet Australia, or for the full technical details, check out his original research paper.