Posted by Scott Laird
Fri, 05 Sep 2008 14:46:00 GMT
So, here’s the thing: I’ve had Verizon DSL for years, and I’ve been waiting for FiOS almost the whole time.
Two years ago, they pulled fiber to within 3 blocks of my house. I was stuck waiting.
Six months ago, they tore up my front yard and put in fiber. I figured that the waiting was over. I called the phone number that they’d plastered all over the neighborhood and they told me that it’d be available for ordering around 4/15. So I waited a bit more tried to order. They told me that it’d be a couple more weeks, and they’d call me back around 4/28.
I’m still waiting. They never called back. Their online ordering system claims that it’s not available at my house, and I’ve checked every week since early April. When I call to see what’s up, I end up sitting on hold for 30 minutes and then someone rudely tells me to wait until they send someone around to hang “fiber’s available” fliers on my door and stop calling. Sometimes it takes extra time to get the office end of the circuit set up, and they won’t let me order until that’s done, you see.
Yeah, right–Like Verizon’s going to put fiber in the ground 6 months before they bother setting up all of their CO hardware if they have any choice in the matter. If I recall correctly, they’ve actually been grilled on that on their quarterly earnings calls before; putting fiber in the ground costs a lot of money, and they want to start recouping it as quickly as they can. The average that I’ve seen for other places is 4-6 weeks, not 6 months. So I strongly suspect that something’s wrong with their availablity database.
This morning I got fed up, so I entered my next-door neighbor’s phone number and address. Ten seconds later, Verizon’s ready to let me order fiber for him. It’s available next door, just not here. It’s the same cul-de-sac, there are no roads to cross. And I know that there’s fiber 30 feet from my current NTI, so it’s not even a tough run for them.
Ah ha! So I called the phone number listed on Verizon’s Business FiOS website (I need a static IP, so I need business FiOS). After 5 minutes on hold, an agent listened to my story and transfered me to the FiOS group. Which promptly announced “we’re not open, call back during business hours” and hang up on me. Without bothering to tell me what the business hours actually were.
You’d think that paying someone $100/month would be easier than this, right?
Update: Apparently waiting until after 8:00 PDT was good enough; the first person that I talked to on the second call has scheduled someone to come out and verify that I have fiber in the ground. Once that’s done, it should be orderable within 2-3 days.
Tags fios, networking, verizon | 1 comment
Posted by Scott Laird
Wed, 01 Mar 2006 06:59:00 GMT
I guess it’s officially spring cleaning time; after 6 years of open access, I finally turned on encryption for my home wireless network. For years, I had my wireless network on a different subnet then my wired network, and then used my Linux router/firewall to protect the two from each other. When I first set up the network, my access point was limited to 40-bit WEP. Since 40-bit WEP is effectively the same as an open network, I never bothered turning encryption on at all. I’ve swapped access points every few years since then, but I never had a pressing need for better security–everything that I use my laptop for uses either SSH or SSL, and the firewall between the two networks wasn’t really a problem for me.
Over the past year, though, a few new problems have cropped up. The biggest problem with a split network is that no Rendezvous/Bonjour-based services can cross between networks, and that’s become increasingly painful–I couldn’t print from my wireless network or access any shared iTunes songs. Also, my wife is now using my old PowerBook, and she didn’t really appreciate the technical reasons why sometimes things didn’t work right when the laptop wasn’t plugged into an Ethernet cable.
So, tonight I finally bit the bullet and redid things. I’m now using two access points on different channels, both sharing the same SSID and WAP pre-shared key. I can wander around the house transparently roaming between APs, so I finally have 100% coverage in my house. Both APs are Linksys WRT-54G series devices (one -54G, and one -54GL) running DD-WRT, which seems simple enough for what I need. I’m really just using the two boxes as simple access points; I don’t need (or want) them to route anything, but I *do* want working SSH and syslog.
I’m still recovering from The Big Drive, so I’ll have to finish the last bit of work (decommissioning the old wireless subnet and firewall and re-routing my office Ethernet cables) tomorrow. I’ll also have a few Typo roadmap updates ready soon.
Update: In order to work with my old PowerBook (handed down to my wife), I had to drop from WPA2 TKIP+AES to WPA2 TKIP. Apparently older Airport hardware can’t handle WPA2 AES. Other then that, everything seems to be working perfectly.
Tags networking, wireless, wrt54g | no comments
Posted by Scott Laird
Mon, 18 Apr 2005 18:25:32 GMT
It looks like Cisco is finally starting to push their new, modular IOS code down from their uber-expensive CRS-1 router into their merely amazingly expensive routers. Network World is reporting that they’re almost ready to release a version of IOS XR for Cisco 12000-series routers. So now you’ll be able to run a semi-modern operating system that implements things like memory protection between processes on routers that cost under $500k. When they get under $100k, this might start to be interesting.
Cisco’s also going to release a line of “shared port adapters” that can be used in routers from the 7300, 7600, 12000, and CRS-1 product families. You need a SPA Interface Processor card for your router type, and then you plus SPAs into the SIP card. According to their picture, the SIP for the 7600 family can hold 4 SPAs, which means that the SPAs themselves must be fairly small–almost certainly smaller then the PAs that 7200/7400/7500 routers use. There are a pile of different SPAs on their list, from 8x cT1 to 10x GigE to 1x 10GigE, to OC 192.
Of course, in typical Cisco fashion, the “shared port adapters” aren’t really all that shared. There are 3 different SPA carrier cards for the 7600 series; one model is only good with the VPN SPA, and the other two overlap a bit–both are good with 2x or 4x OC-3 SPAs, but one supports 1x OC-12 while the other supports T1 and T3 SPAs. None of the three models support the GigE SPAs. Ther 12000-series has 2 different SIP models; one is good for T1/T3 use, while the other one is good for GigE and OC-192s. The CRS-1 SIP is even more fun–it supports POS OC-3s, POS OC-192, and GigE. No OC-12 or OC-48 support, apparently.
So, even though the cards are called “shared port adapters,” there are some real limits on which chassis will work with which cards. The DS3 SPA will apparently only work on the 7600 and 12000, and not on the CRS-1 or 7304. I suspect that a lot of this is mostly a driver support problem, but it shows how screwed up and fractured Cisco’s product lineup is.
Posted in Computer Networking | Tags bfr, cisco, crs1, ios, networking, router | no comments
Posted by Scott Laird
Tue, 08 Mar 2005 07:23:21 GMT
It’s sort of an axiom of programming that features that aren’t continually used or tested won’t actually work. A similar rule holds for system administration–any feature that hasn’t been tested since the last upgrade is probably broken. An obvious corollary suggests that systems get more reliable as their user load increases–more users means more features are used more frequently, and broken features will be spotted sooner. And the corollary to that is that any server wedged under a desk in someone’s home office is probably flakier then hell because it’s probably just sitting there collecting dust and not getting used.
I’m not convinced that that applies to my home gateway box. It’s a busy little beaver:
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes prot opt in out source destination
234M 75G all -- dsl0 * 0.0.0.0/0 0.0.0.0/0
47M 1001G all -- eth0 * 0.0.0.0/0 0.0.0.0/0
In the 25.75 days since I last rebooted this system, it’s received over 75 GB via its DSL link and around 1 TB over its main Ethernet link. If my math is right, that’s an average of 3.6 Mbps on the Ethernet link and around 270 kbps over DSL. I wasn’t keeping outgoing traffic stats when I first booted this box, but more recent estimates make it look like there’s almost as much outgoing traffic on dsl0 as there is incoming.
CPU load is similarly heavy–the box has averaged 51.9% idle since it was rebooted. My rule of thumb for years was that any production box that was under 80% idle was due to be upgraded soon, because it was probably pegging the CPU during peak times during the day. If the box was under 70% idle, then it was time to start scrounging for an immediate upgrade. By those metrics, this box is way overdue for a major upgrade. Fortunately for my wallet, those metrics don’t really apply to this box–it’s spending a lot of its CPU time on tasks that aren’t particularly critical. Also, Linux 2.6 made some changes to /proc/stat that procinfo doesn’t seem to have picked up on; once you factor those into the equation, the box is really closer to 75% idle. Subtract off the non-critical usage, and the system is probably only 10% busy. I’ll probably upgrade it later this year if my virtual-server project works out, but that’s more for security and reliability then pure performance.
Posted in Computer System Administration | Tags dsl, home, linux, networking, router | no comments
Posted by Scott Laird
Wed, 23 Feb 2005 03:08:59 GMT
There’s an interesting thread going on right now on the Linux netdev mailing list, speculating about the network accelerator technology that Intel’s been talking about recently. No one’s quite sure what Intel is planning on adding, but for the past several years “network accelerator” has usually meant TCP offload engines (ToE), and Linux’s core networking guys are almost famously anti-ToE. Even though no one really knows what Intel’s up to, there’s a feeling that it’s not just ToE this time.
Several people have pointed out other technologies that can make a huge difference without requiring the sorts of compromises that ToE needs to work. For instance, this post by Lennert Buytenhek suggests that PCI and memory system latency is a big problem, but fixing it can have huge payoffs:
The reason a 1.4GHz IXP2800 processes 15Mpps while a high-end PC hardly
does 1Mpps is exactly because the PC spends all of its cycles stalling on
memory and PCI reads (i.e. ‘latency’), and the IXP2800 has various ways
of mitigating this cost that the PC doesn’t have. First of all, the IXP
has 16 cores which are 8-way ‘hyperthreaded’ each (128 threads total.)
I haven’t paid much attention to Intel’s IXP network processor family in the past, and that may be a mistake–from the description here, the IXP2800 sounds like a cross between Tera’s multithreaded CPU and IBM’s new Cell processor. Tera’s CPU, which was designed to support tons of threads, automatically switches between threads whenever one thread blocked due to I/O or memory access. The goal with Tera was to be able to remain efficient while the gap between CPU and memory speeds continued to grow. The IXP2800 isn’t as ambitious as the Tera, but the fundamental concept looks similar–support lots of threads in hardware, and switch when latency gets in the way. The IXP2800’s threaded CPUs aren’t full-blown processors, though–like the Cell, the IXP2800 contains one main CPU and a cluster of smaller domain-specific processors that are specialized for one specific task.
It’s unlikely that Intel will roll something like this into their Xeon CPUs anytime soon, though. It’s certainly not a quick fix–it’d require major changes in any OS that wanted to make use of it, and would probably take 3-6 years before it was really fully utilized.
Massively-multithreaded CPUs aren’t the only approach that has paid off for dedicated network processors, though. Some of FreeScale and Broadcom’s chips know how to pre-populate the CPU’s cache with headers from recently-received packets. This drastically cuts latency, but it seems to require that the CPU and network interface be very tightly coupled. Reducing the overhead needed to talk to the NIC can help, too–apparently some of Intel’s 865 and 875 motherboards use a version of their GigE chip that is connected directly to the north bridge, bypassing the PCI bus entirely, and some benchmarks show substantial improvements.
Reading the thread suggests that most of the effort going into Linux network optimization in the next few years will be happening on the receive end of things. Over the past several years, most higher-end NICs have added limited support for checksum generation and TCP segmentation offloading (TSO), where the CPU can hand the NIC a block of data and a TCP header template, and then have the NIC produce a stream of TCP packets without requiring the CPU to touch the data at all. Relatively little has happened on the receive side, but this seems to be changing. For example, Neterion’s newest card can separate headers from data, and is nearly able to re-assemble TCP streams on its own, sort of the inverse of transmit-time TSO. It’s not clear how many streams the card can handle at a time, though–even my little web server at home is currently maintaining 384 simultaneous TCP connections, and a busy system could easily have tens or hundreds of thousands of open streams. Odds are, throwing 100,000 steams at the card would run it out of RAM and completely negate any benefit that receive offloading would have. Unless it’s bright enough to be able to handle the 1,000 or so fastest streams and then let the main CPU handle the 99,000 that are dribbling data at 28k modem speeds.
This is a fascinating topic, and I can’t wait to see how this will turn out.
Posted in Linux, Computer Networking | Tags intel, linux, networking, sysadmin, toe | no comments
Posted by Scott Laird
Thu, 10 Feb 2005 05:08:58 GMT
I can’t believe it. After months and months of trying to upgrade my DSL, everything is finally up and running on my new DSL line. The line wasn’t supposed to go live until Friday evening, but Verizon sent me mail today with my IP address and claimed that it’s up and running. And, indeed, it is.
Unfortunately, I wasn’t quite as prepared as I thought I was; I’d forgotten to change the DNS TTL on scottstuff.net, so people may have a hard time getting through to this site for a couple days. Oops. Other then that, though, everything seems to be up and running perfectly. The sample size is still kind of small, but smokeping suggests that my average ping time has improved drastically–I was seeing numbers from 25 to 800 ms before. Right now, the line looks flat at 30 ms. That’ll probably break a bit once traffic picks back up on the website, but I should be able to keep it under 100 ms, easy.
I’ll post more details later tonight or tomorrow, along with a review of the Sangoma S518 PCI ADSL card. I have to put the kids to bed first, though.
Posted in Computer Networking | Tags dsl, home, networking, verizon | no comments
Posted by Scott Laird
Sun, 06 Feb 2005 00:43:01 GMT
I have a date now for my new DSL line: February 11th. My new DSL PCI card is in UPS’s hands, too. I’m starting to believe that my months-long DSL upgrade quest is nearly complete.
Posted in Computer Networking | Tags dsl, home, networking | no comments
Posted by Scott Laird
Wed, 25 Aug 2004 20:26:54 GMT
There are two local WiMAX stories going around right now. First, Intel has apparently invested an unspecified amount of cash in Speakeasy. Presumably Intel is working on WiMAX hardware and they want Speakeasy to deploy it.
Second, Adaptix has come out of stealth. They’re based a mile or two from my house, and they’re apparently doing software-defined WiMAX. Pity they’re a hardware company, not an ISP, or I’d be all over them looking for a test connection.
WiMAX, also known as 802.16, is one of two contenders for licensed fixed-wireless service. The other contender is 802.20, which Nextel is testing in North Carolina. As I understand it, 802.20 is designed to handle Doppler correction from the beginning, while 802.16 is planning on retrofitting it at some point in the future. That means that 802.20 is more suitable for cellphone-like use, although it lags about a year behind 802.16 in the market.
Posted in Computer Networking | Tags intel, networking, speakeasy, wimax | no comments
