In response to my previous articles about frustrations with my DSL modem, Sonic.net sent me a replacement modem to see if it would fare better. It had one specific improvement but for the most part duplicated the previous results; however I promised to post an update, and during the extra testing I learned one more useful fact, so this is that update with that one useful fact.

That useful fact: if you have two DSL lines in bonded mode, but the DSL lines sync at different speeds, the Comtrend 5361 modem cares a lot about which order you connect the lines (which of the fast/slow lines is master and which is slave).

In more detail: the testing I was doing involved different ways of connecting the modem to the DSL lines (one line at a time or both lines bonded, if bonded then testing both ways to pair the incoming lines with the modem, with and without DSL filters, with and without additional indoor wiring, and with both Annex A and Annex M spectrum allocation modes).

If the modem is configured for Annex A operation and is connected to the MPOE with no filter and minimal indoor wiring, I see it provide the good results you’d expect: on either line alone, it transfers real bits at about 85% of that line’s claimed sync speed, and connecting both lines together, I get the sum of the individual speeds (or 85% of the combined sync speed, which is the same thing), and it doesn’t matter which line is master and which line is slave.

That’s all as it should be. Where it gets weird is if I deviate from that exact configuration. If I add a DSL filter, or enable Annex M, then the modem may deliver only 1/3 of the claimed sync speed, depending on the way I connect the 2 lines for bonded operation. Single-line operation still yields data transfers at 85% of sync speed, and if I connect it for bonded operation with the fast line as the master and slow line as slave I get the expected combined rate, but if I connect the slow line as the master and the fast line as the slave, real-world performance drops drastically. This is extra weird because the line order doesn’t affect the sync speed; in the bad ordering, the modem still claims a nice fast sync speed and just can’t transfer data nearly as fast as it should. I’m still at a loss to know where the performance is going or why.

Now, if you know this is a problem and know how to fix it, you can route around it. And most people probably don’t end up with 2 DSL lines that sync at different speeds, and I presume that if they sync at the same speed the modem doesn’t care how you connect them. But this weird behavior sure caused me a lot of grief and lost time.

On the bright side, the newer modem did perform correctly for single-line operation on either line, which does address my initial complaint.

Previously:

• DSL Modem Annoyances
• DSL Disappointments: Annex M edition
• DSL Disappointments: Misleading sync speed edition

I’m giving up on DSL. There are really 3 separate reasons that it’s not performing as I’d hoped and expected:

• Reliance on AT&T’s wiring, and no incentives for AT&T to provide good enough wiring. There’s apparently no clear agreement between Sonic.net (and more importantly their DSL equipment) and AT&T as to what constitutes acceptable wiring. AT&T claims they’ve met their side of the bargain, but I have one line that syncs at 18mbps and one that syncs at 3-5mbps. Clearly, there’s an important difference between them, but it’s one that AT&T isn’t required to care about.
• Annex M doesn’t deliver, for me. Maybe it works in other cases, but for both my fast line and slow line, it caused a significant decrease in downstream performance and no increase whatsoever in upstream performance.
• The modem is finicky: depending on exactly how I connect it (which cabling, whether I use a filter, and what order I connect the two lines), it delivers as little as 30% of the sync speed as usable performance.

I was hoping to see Annex A speeds syncing at the expected 40mbps down/2mbps up, which using Annex M could be reallocated as something like 30mbps down/5mbps up. But instead I’m getting 22mbps/2mbps from the wires in Annex A, and Annex M reallocates that as 15mbps/2mbps, which there’s no reason to do. The highest real transfer speeds (not sync speeds) I’ve seen, sticking with the Annex A configuration, are 20mbps down, 1.8mbps up.

That 1.8mbps upstream is the clincher — that’s only a quarter of what I’m getting from Comcast. That might be fine for people who don’t want to run offsite backups across the WAN, but I’ve grown addicted to faster upload speeds.

I really like Sonic.net as a company — their policies and their attitude towards customers are preferable to any of the incumbents that own their own wires. But the wiring they’re able to rent from AT&T doesn’t cut it for me. If in the future they’re able to connect my house with something better than AT&T phone wiring, I’d certainly consider it.

Two keyboard shortcuts I use very frequently under Mac OS X are:

• Command-H: hide the current application
• Command-L: jump to the browser address bar (this isn’t a systemwide shortcut, but it’s the same for Safari, Chrome and Firefox, so it may as well be).

These, along with Command-Tab to switch between applications, and Command- curly brace to switch between tabs of the current application, are basically how I navigate the system from the keyboard, and I get very annoyed when something interferes with them and they don’t work as intended.

(A special note on Command-H, for hide: I’ve never liked the OS X minimize behavior. You just get a pile of tiny icons at the end of the dock, in addition to the app icon at the beginning of the dock. For a plethora of reasons intertwined with the dock/taskbar/task switching behavior, minimized windows are more useful under Windows and Linux than they are under Mac OS X. Now, you do want a “get out of my face until I need you again” action, and under Windows and Linux minimize is that action, but under OS X minimize is not that action. Hide is that action.)

Since Command-H is bound to an important systemwide command, no apps should override it, at least by default. It should be available for app use in special cases (remote control or virtual machine environment where you may need access to every possible key and there’s a predefined bypass mechanism; kiosk apps that are designed not to be hidden), but if apps get a way to turn this into an arms race, I wish the system gave me a way to escalate by removing that ability from naughty ones (Adobe CreativeSuite apps are the ones I remember being frustrating in this regard).

Likewise, for sites and plugins that are designed to be hosted inside a web browser, you do realize that that browser already has dibs on certain keystrokes, right? Again it’s Adobe that breaks conventions — Flash applets in particular often like to hook all keystrokes, including those with meaning to the browser like Command-L to jump to the address bar, Command-T to open a new tab, and Command-} to go to to the next tab. Again, I’m glad this is technically possible for those few special cases where the applet knows best, but I can’t see a good argument for acting this way by default, and again I wish the outer scope (in this case the browser) provided me a big hammer to say “always interpret your own keyboard shortcuts first”.

This is especially annoying because not only is behavior that I depend on and have committed to muscle memory getting blocked, but it’s not even for any good reason — the feature that Illustrator CS3 bound to Command-H wasn’t anything I ever used (at least it let me unmap the keyboard shortcut and return it to the OS). And most Flash applets that steal Command-L don’t do anything at all when I press it (nor is there, to the best of my knowledge, a way to tell them to stop hooking keystrokes I care about, at either the Flash Player or browser level — it’s up to the applet).

Another annoying behavior of the Comtrend modem I got from Sonic.net: it doesn’t always transfer real data at anywhere near the claimed “sync” speed.

As noted in my initial post about Sonic.net’s Fusion Broadband, I have 2 DSL lines from Sonic.net, which each in theory should support up to 20mbps downstream, but right now one of them syncs at 18mbps and one of them at only 4mbps, due to overly high attenuation in the wiring supplied by AT&T. Still, I should be able to get a combined 22mbps, right?

Well, with the modem deployed the way I intend to use it (in a back room near my other networking equipment and my UPS, connected to a DSL filter with a normal telephone patch cord), according to Sonic’s own speed test site, I get about 4mbps download and 1.83mbps upload. Whoa, that’s a lot lower.

To make things weirder, if I disconnect the slow line (the one that syncs at only 4mbps) and leave only the fast line (synced at 18mbps) connected, the same speed test result is 15.71mbps download, 0.95mbps upload. How is one line alone faster than the two lines together? At first I suspected a bug in the modem when bonding lines of different speeds, but then I repeated the test at the MPOE, and got the expected results: the two lines bonded together were slightly faster than the fast line alone.

Curious, and suspicious of everything at this point, I decided to run a bunch of tests: both at the MPOE (not depending on my own internal wiring) and in my network closet (adding ~50 feet of internal wiring), with and without the DSL filter supplied with the modem, and with different patch cables (the patch cable that came with the modem, the separate Y cable Sonic gave me, and an old patch cable I had lying around); for various combinations of each of these variables I tested both lines together, and where possible each line alone (that’s easy to do at the MPOE and hard to do at the server room, due to the way the modem is wired for single-line operation).

The results are pretty weird. I’ll list the results, one per line, with a description of the test configuration, the modem’s reported sync speed (down/up), the actual usable speed as reported by speedtest.sonic.net, and a % number which is the ratio of usable download speed to claimed downlink sync speed. First, testing one line at a time:

• At MPOE, fast line, no filter, Y cable:  sync 18.46/1.14, speed test 15.76/0.95 (85%)
• At network closet, fast line, with filter, Y cable: sync 18.49/1.14, speed test 15.71/0.95 (85%)
• At MPOE, slow line, no filter, Y cable: sync 4.93/1.08, speed test 4.02/0.90 (82%)
• At network closet, slow line, with filter, Y cable: sync 3.48/1.02, speed test won’t run (because modem has sync on slave line only)

The result of these single line tests shows that my internal wiring (between MPOE and network closet) and filter don’t seem to affect the speed at all — the modem syncs at the same speed, and tests at the same speed, in both locations.

But then, dual line tests (sorted by descending actual speed):

• At MPOE, both lines, no filter, Y cable: sync 23.60/2.23, speed test 20.06/1.83 (85%)
• At MPOE, both lines, no filter, Y cable + their patch cable: sync 22.99/2.23, speed test 18.94/1.83 (82%)
•  At network closet, both lines, no filter, my patch cable: sync 22.84/2.23, speed test 12.05/1.83 (53%)

• At network closet, both lines, no filter, their patch cable: sync 22.86/2.23, speed test 10.38/1.83 (45%) At MPOE,  both lines, with filter, Y cable + their patch cable: sync 22.09/2.23, speed test 6.12/1.83 (28%)

• At network closet, both lines, with filter, their patch cable: sync 21.83/2.23, speed test 4.23/1.83 (19%)

Note how the sync speed does not change appreciably across all these tests, but the actual speed changes hugely. Every single difference from the minimal MPOE configuration results in decreased speed!

Some additional notes: first, bonded upload speed is completely stable at 1.83mbps in every single test I’ve run. Second, I have tried various other speed test sites, and FTP of a large test file hosted by Sonic.net in case Flash/Java speed tests aren’t reliable indicators, but I got roughly equivalent results from all of them, so I stick with the speedtest.sonic.net numbers for comparison here.

First complaint: where are the bits going? Why is the sync speed not a reliable indicator of real speed? It’s annoying losing speed, and it’s annoying not being able to trust the sync speed, and this makes troubleshooting speed problems a lot harder (it takes longer to run a speed test than just check the sync speed, and Sonic.net’s support system shows them my sync speed but not, I presume, my actual transfer speeds). Presumably if the modem can’t actually transfer data at the sync rate, that’s due to errors and dropped frames at the ATM level, but the modem’s status page shows 0 for every ATM and DSL error category.

Second complaint: why do the filter, patch cable, and my internal wiring all result in a speed loss, but only in bonded operation, and not one line at a time, and without affecting the sync speed?

It’s looking increasingly unlikely that I’m going to get a fast and trouble- free connection via DSL. I mean, I could put the modem by the MPOE (with no UPS and no filter), but that wasn’t the intent, and I don’t understand why I should have to.

And one final note: in response to my earlier article about this modem, Sonic is already sending me a new one; I don’t really want to take time to repeat all of these experiments but I’ll at least see if the new modem or new filter does better in the cases that were worst here. (If nothing else, it should be easier to do apples-to-apples comparisons, using the same cables and getting all data points at both locations.)

Yet another disappointment with the DSL connection and/or modem from Sonic.net: Annex M doesn’t seem to do any good at all for upload speeds.

As I wrote in my introductory post on Sonic.net, the whole reason I was willing to consider them (or DSL technology at all) was the promise of decent upload speeds. The last DSL connection I had was only 768kbps upstream, and even ADSL2+ promises only about 1mbps upstream, but Sonic.net offers this Annex M configuration which trades some downstream bandwidth for upstream bandwidth, with upstream speeds theoretically as high as 3.3mbps (Sonic claims 2.5mbps is more typical real-world performance on a good line). Given that Sonic makes it easy to double these speeds by combining two lines together, now we’re talking — a combined 5mbps upstream would compare decently with what I’m getting from Comcast’s DOCSIS 3 technology.

(It’s hard to know exactly what real-world speeds to expect from Annex M. Sonic’s baseline for a single ADSL2+ line under good conditions, using the default Annex A configuration, is 20mbps/1mbps, or 40mbps/2mbps across 2 lines. Annex M should increase upload speeds to as much as 2.5mbps per line, but at at unknown cost to downstream speeds — I haven’t found anyone willing to predict that. It seems a reasonable estimate would be somewhere between the following hypothetical best case and worst case: best case, I added 1.5mbps of upstream, so it should cost me 1.5mbps of downstream; worst case, I multiplied upstreams speed by 2.5, so my downstream speed will be divided by 2.5. Using those as upper and lower bounds, I should expect something between 8mbps and 18mbps remaining downstream per line, or 16-36mbps/5mbps combined, with Annex M. That would compare favorably enough with the 32mbps/7.5mbps I’m getting from Comcast that, given the reliability problems and caps I’m also getting from Comcast, I’d be happy to switch.)

As described in my earlier posts, after two months of asking Sonic to ask AT&T to provide wiring that will sustain a good ADSL2+ signal, I have one line syncing at 18mbps and one line syncing at only 4mbps (downstream speeds, using Annex A). Still, I figured I might as well see the results of the Annex M spectrum reallocation, so last Friday I called Sonic and asked them to enable Annex M on both lines.

Then I went to the modem’s status page to see the effect on sync speeds. (If you followed my recent post on sync speeds vs actual transfer speeds, all tests here were done at the MPOE with no filter, that is, the best case from those earlier tests.)

First annoyance: the modem wouldn’t sync at all, on either line, until I enabled Annex M on both lines. Maybe this is how it’s designed to work, but from earlier reading of Sonic’s site (2 months ago when I first signed up, all excited by Annex M) that’s not the impression I got. Reading again now, the Annex M FAQ doesn’t say one way or the other, but Dane’s post introducing Annex M seems to imply it’s safe to leave it on on the network end and toggle it at will on your end. That would be more convenient, but for my Comtrend 5361 at least, the behavior is: if the network end is set to Annex A and the modem is set to Annex M, it syncs using Annex A (good), but if the network end is set to Annex M and the modem is set to Annex A, it doesn’t sync at all (bad).

Annoying, but not a deal-breaker. Let’s see how the speeds compare. I’ll give numbers even for the broken configurations that didn’t sync, since I did test those combinations and the results are interesting.

All of the following tests are with Annex M enabled for both lines on Sonic’s end, and at my end with the modem plugged directly into the MPOE with no filter. Speed test results are from speedtest.sonic.net.

Both master and slave lines set to Annex M:

• Master sync: 2.54/1.08
• Slave sync: 12.51/1.14
• Combined sync: 15.06/2.23
• Speed test: 5.92/1.83

Master on Annex M, slave on Annex A:

• Master sync: 2.54/1.08
• Slave sync: no sync
• Combined sync: 2.54/1.08
• Speed test: 2.17/0.88

Master on Annex A, slave on Annex M:

• Master sync: no sync
• Slave sync: 12.62/1.14
• Combined sync: 12.62/1.14
• Speed test: 10.82/0.96

Both master and slave set to Annex A:

• Master sync: no sync
• Slave sync: no sync
• Speed test: N/A

As a comparison point, here are my most recent numbers for a comparable test with Annex A on both ends:

• Master sync: 4.84/1.08
• Slave sync: 18.36/1.15
• Combined sync: 23.12/2.23
• Speed test: 19.72/1.83

So, two things to note here.

First, Annex M significantly decreases downstream speed without increasing upstream speed at all, for me. Compare the sync speeds above for Annex A and Annex M. The best sync speed I saw for the slow line was 53% of what it was without Annex M; the best sync speed I saw for the fast line was 69% of what it was without Annex M; the combined sync speed was 76% of what it was without Annex M.

Second, Annex M hurt my transfer speeds even more than the claimed sync speeds. Note the oddity that while bonded operation results in a faster sync speed than connecting the fast line only, when I measure the actual transfer speed, it actually got slower. (That’s reminiscent of the earlier bonding experiments I ran with Annex A.). The single-line Annex M tests both transferred data at the 85% of claimed sync speed that I’ve come to expect, but using both lines bonded together, this ratio drops to only 39%.

Again, I’m curious why bonding the lines results in slower operation than one line alone, without this effect being visible in sync speeds or ATM errors. And unless something is completely wrong here, it looks like Annex M does not, for me, bring DSL back into the realm of competitive upload speeds.

I recently wrote a post, On searching one’s own activity streams, lamenting the difficulty of finding stuff I myself had posted on Facebook and Twitter. In response to that post, a friend pointed out: “You may be looking for Greplin”.

Intrigued, I gave Greplin a try, and overall I’m impressed. It’s a new service that indexes data you create, on other sites and services like Facebook, Twitter, Gmail and associated Google services like Calendar, and Evernote. (Note that most of these involve indexing data that’s not publicly available, so Greplin needs access to your account data — it uses OAuth to request this access without needing to know your password.)

This goes well beyond what I was asking for in the stream-search post, and actually nicely answers something else I’d been wanting recently, and overall I’m impressed (and slightly jealous I didn’t get to it first).

But, back to the specific “find my own Facebook” posts case that led me to Greplin in the first place: I tried searching for a few of my own posts, and it didn’t find them. It seems pretty good about finding tweets, mail messages, appointments, and pretty much everything else it’s supposed to including Facebook messages, but not Facebook wall posts. I went looking for answers in Greplin’s help system. From the “which sites does Greplin index” article in their FAQ:

Please note that for news feed and wall posts, Facebook only allows us to collect data from a few days before you began your index on Greplin. However, we will collect all your data from that point forward. This means that you may not find Facebook news feed or wall post items that were created up to 4 days prior to your initial signup for Greplin.

Ouch. I don’t know whether that’s a policy or technical limitation. I don’t believe it’s a technical limitation, because I wrote my own little Python script to download my own status messages since the beginning of time, and comments on those status messages, and they’re all available via the API.

That seems to leave policy as the limitation. I sure hope that Facebook isn’t preventing 3rd party sites, with my permission, from looking at my own data. I can’t see any consistency in letting Greplin access my very recent posts and my future posts but not my past posts. Especially because if they’re not allowed to index old content, and they want to index content going forward (and the ability to rebuild the index as necessary), that pretty much requires them to keep a separate copy of my data, whereas if they had reasonable access to past data, they could rely on Facebook to store it and provide it as necessary and they would need only the index on their side.

Tumblr’s editor turned this post into 

between the time I pressed “Create Post” (at which time there was no CSS gunk visible) and the time it was actually published (where some CSS crept into the post body itself).

(This happened both on Tumblr itself and in the wall post that the Tumblrbot made on Facebook — I immediately went and fixed the damage in the original post, but the Facebook publish feature is basically instant and doesn’t allow after the fact edits, so the CSS gunk is forever baked into that post and that’s why the screenshot shows Facebook and not Tumblr. Also, Tumblr apparently bakes the RSS feed with enough delay that my subsequent edit to fix the post made it into the RSS version, unlike the Facebook version.)

This problem isn’t incredibly common, but common enough to be annoying — maybe something like 5% of the time.

One of the potential upsides to posting stuff on Twitter or Facebook ought to be that you can find it later when you want to know what you were doing/thinking/saying at a given time.

Too bad neither site has a good way of searching your own contributions.

Twitter does have a search feature and you can restrict it to your own tweets by adding your username but it only returns very recent tweets (like maybe the last week); Twitter is also indexed by the major web search engines and if you add “site:twitter.com username” to your queries you may or may not find what you’re looking for with minimal additional cruft; there’s also Snap Bird which is a 3rd party site designed to do this but it’s clunky and I’ve never seen it actually work (maybe the fault of Twitter’s API, who knows).

Facebook does have a search feature but it inexplicably doesn’t search your own updates (it finds people and pages and if you click the “See more results for…” link then a tantalizing “posts from friends” link appears which doesn’t seem to find content in posts by me or my friends); Facebook is a walled garden and its content is generally not indexable by external search engines; it does have a pretty good API and so somebody could probably go build this as a 3rd party app but I’m not aware of one, and arguably it would be better done as part of the core site anyway.

So, on those occasions I do want to go track down one of my own updates on either of these sites, I resort to viewing my own profile, then scrolling down, and clicking the “show older posts” link as necessary, and scrolling down, and repeating until I’ve gone back a couple months, and using my browser’s find-in-page feature to find what I’m looking for, eventually after way too much clicking and scrolling.

Not only is this ridiculous, it’s made even worse by an interaction with Google Chrome (and maybe other browsers, but Chrome’s what I’m using lately). Apparently the AJAXy way these sites use DOM writes or whatever they do to append content to the current page without reloading triggers this behavior in Chrome where “Find Again” (ctrl-G or Command-G) doesn’t find text in newly added parts of the page. So often, I’ll load the page and scroll back a month or so and then use the browser Find command to search for “widgets” and not find it, then scroll another month or so and then hit Command-G and not find it, then scroll back another month or so and so on… and after going back 6 or 7 months, I’ll remember that Command-G doesn’t work, and cancel the search and repeat the search with Command-F and then command-G and then it will find it halfway up the page, which I would have found a lot easier if Command-G had worked the first applicable time. (This was a pattern I learned with earlier versions of Chrome; using Chrome 10, it’s a little different — the first Command-G may actually scroll the search hit into view, but it won’t highlight it and you won’t notice it on a busy page, and it will keep reporting “0 of 0” in the search status pane; you still need to do the 3-step deselect, Find, Find Again dance to get it to highlight.)

(Side note on Facebook: there’s a metafilter question asking how to search your own Facebook profile; not only do the answers there not have a solution, but the overall feeling is highly negative on it even being possible. That’s not quite true; I’ve confirmed that using the Facebook API from a simple Python script I can get back anything I ever posted. They do keep it, and they or someone else could write an indexer and search tool.)

Update: Greplin does a pretty good job of this, though not as good a job as it could with Facebook posts.

For my dual-line Fusion setup, Sonic.net sent me a Comtrend Nexuslink 5361.

It’s an ADSL2+ modem that works with one line, or two lines bonded together, and also includes normal home wireless router functionality (NAT firewall, 4 ethernet ports, and Wi-Fi).

My specific complaint here is that the way they wired it to accept 2 DSL lines is annoying. It’s got a single RJ14 jack, so both lines enter it there, on the inner and outer pair of the same jack. The problem is that it considers the outer pair to be line 1 (primary/master) and the inner pair to be line 2 (slave). And if you connect only the slave line, it will establish ADSL sync but will not carry IP traffic (it looks like it never even acquires an IP address and gateway via DHCP).

If you connect only the master line, or both master and slave, then it works fine and carries IP traffic. But the way they wired it, it’s much easier to connect only the slave. (In fact, some Sonic.net support personnel told me they thought this modem doesn’t support single-line operation, which is probably because they’d tried plugging it in the straightforward way and found, indeed, it didn’t work.)

The reason this is a problem is that any single-line (RJ11) phone jack you have will only have the inner pair active. If you connect that to this modem with a standard phone cord (with either 1 or 2 pairs), you’ve connected the active pair to the inner pair on the modem, which is the slave line which will sync but will not alone carry traffic.

And the way AT&T’s wires terminate at the MPOE, each line goes to a separate test jack (an RJ11 jack, so on the inner pair), and a separate set of terminals, and it’s up to the customer how it’s wired from there. I connected an RJ14 jack to both lines, the inner pair connected to one phone line and the outer pair connected to the other phone line, which is the standard way of wiring a 2-line setup, and I can patch that jack directly to the modem with a standard 2-line phone cable to activate both lines. This setup is fine for actual use, but if I’m having problems, it’s unnecessarily difficult to troubleshoot.

The problem is that no standard phone cable gives you an easy way of connecting just the outer pair. A standard 1-line phone cable will connect the inner pair to the inner pair. A standard 2-line phone cable will connect both the inner and outer pairs to the matching pair on the other end. Sonic even gave me a fancy Y cable, which on one end has an RJ14 plug with both lines (inner and outer pair) active, and the other end has 2 separate RJ11 plugs each with only the inner pair. Using this Y cable, I can plug the modem directly into the MPOE, and connect both modem lines for bonded operation, or test single-line operation by connecting either single line to either the modem’s master or slave (in practice, since slave-only operation isn’t useful, it’s only useful to use the side of the Y cable that connects as the other end’s outer pair, thus goes to the modem’s master side). And also, I can hack the Y cable to work at my 2-line RJ14 jack to (in one direction) connect the inner pair on the line to either the inner or outer pair on the modem, or (in the other direction) connect the inner pair on the modem to either the inner or outer pair on the line (and if you’ve followed me so far, you’ll see that these 4 configurations are really just 3, and 2 of them connect only the slave line, so the only useful one is connecting the modem’s master line to the inner incoming pair, and there’s no way to test the modem’s master line on only the outer incoming pair, unless I build myself a cable that connects outer pair to outer pair while not connecting the inner pair).

The reason I’m complaining: this would all have been strictly better had Comtrend made the modem treat its inner pair as the master line. As it is now, you get the right result when connecting with a standard 2-pair phone cable to a 2-line jack, or using the fancy Y cable to connect to 2 separate 1-line jacks. But if you use a 1-line cable (to either a 1 or 2 line jack), or a 2-line cable to a 1-line jack, you’ll end up in the broken configuration, and this easily made mistake could have been easily avoided if they’d just configured the modem the more obvious way.

Why do I care so much about connecting this modem one line at a time, when it’s designed for bonded operation, you might ask? That’s a story for another time.

Update 4/16/2011: Sonic.net noticed this post, and called me to say that the various problems reported here have been fixed in updates by Comtrend to both the hardware and software. They were surprised I’d gotten one of the old modems, and are sending me a replacement (and even though most of the problems mentioned in this post only affect troubleshooting and won’t matter for real usage, I accepted the offer to see if the newer modem will help with any of the other problems I’m experiencing). +1 to Sonic.net for noticing this and being proactive.

This is why you need a Groklaw, to carefully gather all the pieces of true computer history, so when people talk like this, you have a place to send people to find what really happened.

http://www.groklaw.net/article.php?story=20110402143136766