Saturday, November 29, 2014

"Why Does My Internet Connection Keep Dropping?" -- A Few Tips About IPv6, DSL, MTU, and Apple AirPort

We are told that IPv6 -- an updated and advanced system of network addressing -- is the future of the Internet. That may be true, but IPv6 is also an immature and treacherous technology.

For maximum reliability, my wife and I have two Internet connections, one cable and one DSL. Both are routed through wireless networks running on Apple's latest generation of AirPort base station. Generally, I use the cable Internet, while my wife uses the DSL, though we switch as needed.

For the past few months, my wife has switched to the cable more often than intended. With her DSL, she kept complaining that Web pages were slow to load or stopped partway. I tried a number of possible solutions and managed to make some improvements in network operation, but nothing fixed the original problem. And then she complained it was getting worse.

I began to wonder if our old DSL modem was at fault. So, I started researching modems and uncovered some interesting facts. One was that our DSL provider, CenturyLink, was in the process of switching its systems to IPv6. Another was that our old modem could only handle IPv4. Could that be the source of the problem?

I thought I should get CenturyLink to replace our modem, but their monthly rental charges were high, so instead I looked into buying. But when I checked the IPv6 models that CenturyLink recommended, I found they had bad customer ratings on Amazon because of poor reliability -- even though the previous-generation IPv4 modems from the same company had good ratings!

So, I changed course again and just bought a new IPv4 modem. But when I finally got it to work, I found that our connection was slower than with our old one! I wound up switching back and keeping the new modem as a backup.

In the course of trying to set up the new modem, though, I noticed something interesting about our AirPort settings. At some point I must have decided to "prepare" for IPv6 by setting up automatic configuration for it in our base stations. I must have figured that the stations' operations would be adjusted as appropriate for the connected modem.

But why, then, had the station on the DSL network been automatically set for "tunnel" mode? Was CenturyLink somehow bypassing the limitation of the IPv4 modem, or trying to? And was it botching the job and screwing up our connection -- or at the least, hitting an incompatibility with the base station?

Or was the base station itself screwing up? At about this time, I was reading about problems with dropped wireless connections in the first versions of Mac OS X 10.10, Yosemite. Why now? Was Apple having trouble with its own developing IPv6 technology?

Where the fault lay, I'll never be sure. Quite possibly with both CenturyLink and Apple. But the solution turned out to be simple: Completely turn off IPv6 from the Internet connection. I did this in the AirPort Utility by going to the Internet tab, choosing Internet Options, and on the Configure IPv6 drop-down menu, selecting "Link-local only." My wife's connection has been fine ever since.

Moral: Leave the future of the Internet to the future, and for now, reside safely and securely in the present.

Update: It turned out there was another piece to the puzzle. Because my wife's Internet connection was DSL with PPPoE, we needed to adjust the Maximum Transmission Unit -- "MTU" -- in the Mac's Network settings. This is something CenturyLink never bothers to tell you. (To check whether your DSL uses PPPoE, open AirPort Utility, select your base station, click on Edit, then on Internet, and look at Connect Using.)

Normally, the MTU for DSL with PPPoE is 1492. That's the largest packet of data your computer should send out if you want everything to run smoothly. But I noticed that part of CenturyLink's IPv6 setup called for an MTU of 1472. So, for future proofing, that's what I set.

To set the MTU in Yosemite, go to System Preferences > Network > Wi-Fi > Advanced > Hardware. Change Configure to "Manually" then lower the MTU from the standard 1500. To get the best number, you might want to talk to your DSL provider; or you can start at 1492 and go down in steps to maybe 1400, if needed. Don't worry about overshooting a bit. Though that does slow down the connection, it shouldn't be enough to notice.

Sunday, February 9, 2014

"Why Are My Time Machine Backups So Slow?"

I'm not sure I can tell you exactly why they're so slow, but I think I can tell you how to fix them.

Time Machine backups on my Mac Pro with Snow Leopard normally take just a few minutes at most. But recently, I found them taking about 15 minutes each. Reading the status messages in the Time Machine preference pane, I saw that over a million items were being scanned during each backup -- twice. And the actual copying took place at a snail's pace, sometimes a few kilobytes at a time, even though I was hearing a wild disk chattering for most of the backup.

Googling around, I discovered that Time Machine relies on a database called .fseventsd to tell it what files need backing up. When it can't read that database, is does the "deep scan" I was seeing reported in the status messages. But it should only have to do that once to get that database back on track. So, something else was obviously getting in the way.

I finally found one lone voice saying he had fixed his problem by deleting the Spotlight index on his Backup drive. Like me, he had indexing for that drive turned off, so it had taken him a while to realize that could be the problem. Apparently, some indexing gets done on backups even when it's turned off. This rang a bell for me, because I figured my disk chattering and slow copying were probably both due to indexing going on at the same time.

The solutions I came across were mostly Terminal commands to delete .fseventsd or .Spotlight-V100 on one disk or other. But I don't like flying blind with Terminal, so I fired up Marcel Bresink's Tinkertool, turned on "Show hidden and system files," and clicked "Relaunch Finder." Then I just dragged my backup's Spotlight index to the Trash, made sure that indexing was still turned off, and started Time Machine manually.

Only it didn't work. More double scanning, more slowpoke copying, more disk chatter.

I figured the next step would be the one most people recommended: Deleting .fseventsd on my startup drive. But while I waited for yet another 15-minute backup to complete, I took a look at my Finder windows. Let me explain that I have ten partitions on four disks. All but the boot partition have Spotlight turned off, and only the boot partition and two others get backed up. The others are for clone copies, experiments, temporary files, and so on.

What I noticed was that .fseventsd and .Spotlight-V100 folders showed up differently on different partitions. Some of the folders had on them a red circle with a minus sign inside. Others didn't. And some partitions were entirely missing one folder or both.

That kind of inconsistency didn't look right to me, and at this point, I figured the problem could be anywhere. I didn't want to keep making small changes with 15-minute interludes for testing. So, I took the sledgehammer approach: I dragged every single .fseventsd and .Spotlight-V100 folder to the Trash and rebooted.

Sure enough, when the computer restarted, every single partition had both folders, and each folder had the red circle with the minus sign.

Immediately going to the Privacy tab of my Spotlight preference pane, I made sure indexing was turned off for every partition but my startup -- beginning with my backup partition. Then I waited for indexing to complete on my startup partition -- something I could easily tell by ear! Then I did a Time Machine backup. And then a second.

As I'd been warned, the first backup took longer, as it did another thorough scan. But that was the last one. There was no second scan during that backup, and the second backup required none at all. Copying went at a more normal pace, and there was a whole lot less chatter. I did hear more indexing chatter following the second backup, but it stopped after about 45 minutes and I have not noticed any since.

Was I reckless to throw out all those system files? No. Despite the warnings I ran into online, the .fseventsd and Spotlight databases are merely catalogs of events and content on your disk. If they're missing, they're regenerated. No big deal. You do have to put up with all the reindexing, which can take some time, but you don't have to wait and wonder whether your particular problem is being fixed.

Chances are, it is!

Update, 9/29/2014 -- After writing the post above, the problem recurred, so I had the "opportunity" to study it a bit more.

What I discovered is that it recurred every time I booted into a more recent version of OS X on another hard drive partition and then returned to my usual Snow Leopard. All later Time Machine backups in Snow Leopard then needed to scan the boot partition twice.

My solution for now: Whenever I go into Mavericks, I use TinkerTool to reveal hidden files, and then -- while still in Mavericks -- I delete the .fseventsd file from my Snow Leopard partition. I hide the hidden files again, then reboot into Snow Leopard.

The first Time Machine backup after doing this includes scanning the partition, but after that, the backups are normal. There is no need to mess with the Spotlight files, and so no need for reindexing.