Friday, January 25, 2008

Brussels putback

This post discusses the 2nd flag-day putback yesterday, which is Brussels (phase I). Brussels also changes the way NIC drivers are administered, but it is focused on simplifying and centralizing the administration of network driver tunables -- these are the values used to tune the device itself, or in some cases, the link layer properties. The most common of these tunables are the values associated with duplex and link speed settings.

Historically these values have been configured with ndd(1M) or driver.conf(4). Many people know how I feel about those methods, but let me just reiterate: "ndd must die!" (And driver.conf, as well.)

The Brussels putback represents another opportunity for community members interested in kernel programming though. A lot of these NIC drivers need to be converted to use the property access methods that Brussels offers, and have the ndd support ioctls removed. (And yes, I strongly desire to see the ndd(1M) ioctl support removed from drivers. A follow-on phase for Brussels will offer ndd compatibility at the Brussels layer.)

Brussels provided a conversion of bge(7d), but many other NIC drivers remain. I plan on converting my two drivers, afe(7d) and mxfe(7d), as well as a few drivers that are still closed source (iprb(7d) and rtls(7d)). But there remain many others. And conversion of a driver to support Brussels is just the sort of bite-sized task that is great for learning how to develop in the kernel. Some possible drivers to convert are sfe(7d), rge(7d), and nge(7d). If you're interested in working on one of those, let me know (you need the hardware, though!)

Clearview/UV putback

Folks watching Nevada putbacks will have noticed at least 3 flag days in the past 24 hours. I want to take a second to talk about the first of them. (I'll talk about the second in a follow up post.)

The first, Clearview/UV, is about providing GLDv3-like features to legacy NIC drivers, and about providing friendlier names to device drivers. I will confess that I've not had a chance to play with any of these features yet, but I think that they are likely to be one of the more important putbacks to OpenSolaris this year. This putback fundamentally changes network administration by offering the ability to use "logical naming" for network device drivers.

The other important thing here is that some folks may believe that the Nemo Unification offered by Clearview/UV means that those legacy drivers don't need to be converted. This is not true. Conversion to GLDv3 still offers significant and tangible benefits to network device drivers:
  1. Performance. The translation layer that Clearview provides adds a performance hit for legacy drivers. Its also the case that legacy NIC drivers are unable to benefit from several of the performance benefits that GLDv3 offered (direct function calls, mblk chaining, etc.)
  2. Full VLAN support. Legacy drivers that don't support the undocumented VLAN features aren't able to offer full size VLAN frames. VLANs still work, but you have to shrink your MTU by 4 bytes.
  3. Certain upcoming GLDv3/Crossbow features. Legacy drivers won't be able to take advantage of upcoming features in GLDv3 from Crossbow. These include various interrupt mitigation techniques and multiple hardware ring support.
The upshot is that the Nemo Unification represents a band-aid for legacy NIC drivers. If you own the code for one or more of these, you really should still have a plan for GLDv3 conversion, unless your willing to accept that your driver is a second class citizen in OpenSolaris. (Note that GLDv3 is still Consolidation Private. Figuring out that Corollary to that fact is left as an exercise to the readers.)

Folks that want help with such a conversion should contact me.

Wednesday, January 9, 2008

making good on a promise (Velocity Networks == bad)

My former Internet service provider, OChosting, was recently purchased by a much larger company, Velocity Networks.

As part of that acquisition, they moved my e-mail to some more central server. However, they screwed it up really really badly. The DNS MX records for my domain pointed to an old server, but the CNAME I was using for IMAP was pointing to the old one. The helpdesk was completely useless/powerless to fix the DNS records. (As part of this they were transitioning the old systems to a new management system, ala CPanel, as well. The helpdesk people were only able to deal with accounts that had been transitioned.

Finally I told them they'd not only lose my business, but I'd post my negative experiences here if they didn't get someone to help me quickly. That much they did. But ultimately, the promise that DNS records would clear up when caches flushed never materialized. Two weeks later their servers are still giving out incorrect DNS information. I've been able to access my e-mail by manually editing my /etc/hosts file, supplying a workaround IP address. (I have noticed that their IMAP server has gotten significantly slower since the transition as well. It can take up to 2-3 seconds to delete a message sometimes. Typically it takes about 1 second for the IMAP delete to occur. On my other servers IMAP deletes appear to be "instantaneous".) This doesn't work well for my wife though, and I'm fed up with trying to force feed these guys a clue.

I will point out that I was paying these bozos over $20/month for very modest hosting needs, which is 2-3x the typical market rate. And I'd been doing this for about the last 5 years, with nary a service call in the interim.

Anyway, now I'm making good on my original promise to them.

Anyway, I've been able to recover all my old e-mails (at least the ones that didn't bounce, and who knows how many of those occured!), and I've given my business to Bluehost as of about two days ago. So far, it seems to be going quite well. My e-mail performance seems to be good, and the software they have deployed for CPanel is a bit more sensible as well. (For one, they seem to understand the problem of matching TLS/SSL certificates to hostnames when used for IMAP or SMTP.) I'm also paying $7.95 a month (full year paid in advance) instead of $19.95, and my disk and throughput quotas are much much higher (not that I need them).

I would strongly urge folks considering ISPs to avoid Velocity Networks or any of their affiliates if at all possible. My experience is that they are clueless, and their helpdesk staff are completely hobbled by a combination of restrictions on what they can perform and their own lack of ability.

A big kudos to Bluehost, as well.