You are currently browsing articles tagged upstream.

If you want to get the most out of your Verizon FiOS (fiber to the home) Internet connection, here are your top two tiers:

FiOS tiers

I have the one on the left, and that’s what I’m paying for it. The service is rock-solid and reliable. So is support, as rarely as I’ve needed it.

But when I go to work, my upstream speeds are higher — up to 100 Mbps. I get more done. And I’m not the only techie who appreciates high upstream speeds. Boston is the world’s biggest college town, and full of other industries (pharma, big science, finance) that are staffed by professionals that could use the speed too.

But Verizon does this weird thing with the next tier up: they cut back the upstream speed from 25 Mbps to 20 Mbps. At double the price. WTF is that all about? When I ordered the 25 Mbps tier several months ago, the guy on the phone told me the reason was “just marketing.” He also said “We could give you 100Mbps tomorrow and blow everybody else out of the water.”

So why not?

Oddly, all of FiOS’ “Triple Play” (Internet + TV + phone) bundles here have relatively low Internet speeds, compared to the two tiers above. If the Net is your main interest, you might be better off without the TV and the phone. (In fact, we had the other two “plays” we got FiOS originally, and dumped them later, mostly because  we hardly used them.) If you view more bundles, your best speeds are still just 25/25Mbps.

My request (and advice — and companies do pay me for this stuff) to Verizon is to do two things:

  1. Come up with a sensible offering — one that doesn’t subtract upstream value at twice the price.
  2. Try localizing a bit. Boston isn’t Red Bank. (And no offense to that town or other FiOS service areas.) See what happens when you super-serve a region with an offering that makes sense for it.

Maybe Verizon is doing that, sort of, with its business offerings. But getting to the actual offerings requires many clicks and filling out forms. Where I finally arrived in my latest hunt was a page with this set of choices:

First, this is much better than what I remember about my last look at FiOS business deals.

Second, that 35/35 offering is attractive.

Third, once again, we have an upstream speed drop when you go to the highest tier.

Fourth, the “static” offering is poorly explained. What this means is a real IP address, rather than one dynamically assigned by the router. This is real Internet stuff, so the customer can, say, run a server. (The copy does say “host websites.”) But, unless I’m missing it, nowhere does it say how many IP addresses the customer gets. For customers who care about this stuff, that’s the first question that will come up.

Fifth, the examples are poor. Here are some of the things that serious professional customers might care about:

  1. Offsite storage or backup
  2. Virtual computing in the cloud, such as with Amazon’s EC2
  3. Running servers in a co-lo or some other heavy-lifting environment
  4. Remote rendering, such as RenderCore

Verizon (or any ISP) could offer any of those services locally themselves, taking advantage of low latencies. In fact, in some cases that can be a huge advantage, and therefore a selling point.

Again, the service I’ve had all along with FiOS (going on three years now) has been solid and good — so good, in fact, that I miss it a lot when I’m gone. (Such as with this example here.) I just want it to be better. Hope this helps.

Tags: , , ,

Major props to Cox for cranking up my speeds to 18Mb/s downstream and 4Mb/s upstream. That totally rocks.

I’m getting that speed now. Here’s what Cox’s local diagnostic tool says:

TCP/Web100 Network Diagnostic Tool v5.4.12
click START to begin
Connected to:  –  Using IPv4 address
Checking for Middleboxes . . . . . . . . . . . . . . . . . .  Done
checking for firewalls . . . . . . . . . . . . . . . . . . .  Done
running 10s outbound test (client-to-server [C2S]) . . . . . 3.79Mb/s
running 10s inbound test (server-to-client [S2C]) . . . . . . 18.04Mb/s
The slowest link in the end-to-end path is a 10 Mbps Ethernet subnet
Information: Other network traffic is congesting the link

That won’t last. The connection will degrade again, or go down completely. Here we go:

Connected to:  –  Using IPv4 address
Checking for Middleboxes . . . . . . . . . . . . . . . . . .  Done
checking for firewalls . . . . . . . . . . . . . . . . . . .  Done
running 10s outbound test (client-to-server [C2S]) . . . . . 738.0kb/s
running 10s inbound test (server-to-client [S2C]) . . . . . . 15.09Mb/s
Your Workstation is connected to a Cable/DSL modem
Information: Other network traffic is congesting the link
[C2S]: Packet queuing detected

Here’s a ping test to

PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=246 time=368.432 ms
64 bytes from icmp_seq=1 ttl=246 time=77.353 ms
64 bytes from icmp_seq=2 ttl=247 time=323.272 ms
64 bytes from icmp_seq=3 ttl=246 time=343.178 ms
64 bytes from icmp_seq=4 ttl=247 time=366.341 ms
64 bytes from icmp_seq=5 ttl=246 time=385.083 ms
64 bytes from icmp_seq=6 ttl=246 time=406.209 ms
64 bytes from icmp_seq=7 ttl=246 time=434.731 ms
64 bytes from icmp_seq=8 ttl=246 time=444.653 ms
64 bytes from icmp_seq=9 ttl=247 time=474.976 ms
64 bytes from icmp_seq=10 ttl=247 time=472.244 ms
64 bytes from icmp_seq=11 ttl=246 time=488.023 ms

No packet loss on that one. Not so on the next, to UCSB, which is so close I can see it from here:

PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=52 time=407.920 ms
64 bytes from icmp_seq=1 ttl=52 time=427.506 ms
64 bytes from icmp_seq=2 ttl=52 time=441.176 ms
64 bytes from icmp_seq=3 ttl=52 time=456.073 ms
64 bytes from icmp_seq=4 ttl=52 time=237.366 ms
64 bytes from icmp_seq=5 ttl=52 time=262.868 ms
64 bytes from icmp_seq=6 ttl=52 time=287.270 ms
64 bytes from icmp_seq=7 ttl=52 time=307.931 ms
64 bytes from icmp_seq=8 ttl=52 time=327.951 ms
64 bytes from icmp_seq=9 ttl=52 time=352.974 ms
64 bytes from icmp_seq=10 ttl=52 time=376.636 ms
ç64 bytes from icmp_seq=11 ttl=52 time=395.893 ms
— ping statistics —
13 packets transmitted, 12 packets received, 7% packet loss
round-trip min/avg/max/stddev = 237.366/356.797/456.073/69.322 ms

That’s low to UCSB, by the way. I just checked again, and got 9% and 25% packet loss. At one point (when the guy was here this afternoon), it hit 57%.

Here’s a traceroute to UCSB:

traceroute to (, 64 hops max, 40 byte packets
1 (  0.687 ms  0.282 ms  0.250 ms
2 (  349.599 ms  379.786 ms  387.580 ms
3 (  387.466 ms  400.991 ms  404.500 ms
4 (  415.578 ms  153.695 ms  9.473 ms
5 (  16.965 ms  18.286 ms  15.639 ms
6  te4-1–… (  19.936 ms  24.520 ms  20.952 ms
7 (  26.700 ms  24.166 ms  30.651 ms
8  dc-lax-core2– (  44.268 ms  98.114 ms  200.339 ms
9  dc-lax-agg2– (  254.442 ms  277.958 ms  273.309 ms
10  dc-ucsb– (  281.735 ms  313.441 ms  306.825 ms
11  r2–r1– (  315.500 ms  327.080 ms  344.177 ms
12 (  346.396 ms  367.244 ms  357.468 ms
13  * * *

As for modem function, I see this for upstream:

Cable Modem Upstream
Upstream Lock : Locked
Upstream Channel ID : 11
Upstream Frequency : 23600000 Hz
Upstream Modulation : QAM16
Upstream Symbol Rate : 2560 Ksym/sec
Upstream transmit Power Level : 38.5 dBmV
Upstream Mini-Slot Size : 2

… and this for downstream:

Cable Modem Downstream
Downstream Lock : Locked
Downstream Channel Id : 1
Downstream Frequency : 651000000 Hz
Downstream Modulation : QAM256
Downstream Symbol Rate : 5360.537 Ksym/sec
Downstream Interleave Depth : taps32Increment4
Downstream Receive Power Level : 5.4 dBmV
Downstream SNR : 38.7 dB

The symptoms are what they were when I first blogged the problem on June 21, and again when I posted a follow-up on June 24. That was when the Cox service guy tightened everything up and all seemed well … until he left. When I called to report the problem not solved Cox said they would send a “senior technician” on Friday. A guy came today. The problems were exactly as we see above. He said he would have to come back with a “senior technician” (or whatever they call them — I might be a bit off on the title), which this dude clearly wasn’t. He wanted the two of them to come a week from next Wednesday. We’re gone next week anyway, but I got him to commit to a week from Monday. That’s July 6, in the morning. The problem has been with us at least since the 18th, when I arrived here from Boston.

This evening we got a call from a Cox survey robot, following up on the failed service visit this afternoon. My wife took the call. After she indicated our dissatisfaction with the visit (by pressing the appropriate numbers in answer to a series of questions), the robot said we should hold to talk to a human. Then it wanted our ten-digit Cox account number. My wife didn’t know it, so the robot said the call couldn’t be completed. And that was that.

I doubt another visit from anybody will solve the problem, because I don’t think the problem is here. I think it’s in Cox’s system. I think that’s what the traceroute shows.

But I don’t know.

I do know that this is inexcusably bad customer service.

For Cox, in case they’re reading this…

  • I am connected directly to the cable modem. No routers, firewalls or other things between my laptop and the modem.
  • I have rebooted the modem about a hundred times. I have re-started my computers. In fact I have tested the link with three different laptops. Same results. Re-booting sometimes helps, sometimes not.
  • Please quit trying to fix this only at my end of the network. The network includes far more than me and my cable modem.
  • Please make it easier to reach technically knowledgeable human beings.
  • Make your chat system useful. At one point the chat person gave me Linksys’ number to call.
  • Thanks for your time and attention.

Tags: , , , , , , ,