We accidentally upgraded our Verizon FIOS this week. I say accidentally because that wasn't our intention at all; actually we were investigating the possibility of dropping Verizon TV and just going pure Internet. That's almost possible, but unfortunately there are still a few shows we cannot get through Netflix streaming. That may change as Netflix bids for current shows, but right now we still need Verizon.
The upgrade happened because we called Verizon to find out how much we'd save if we dropped the TV portion. That was significant, but in the course of the conversation, we found out that we are actually paying $6 per month more for slower service. Ayup, we still had the old 5/2 (5 Mb down, 2 up) and could get 25/25 by paying $6.00 less.
Of course there's a catch: we had to lock in to a 2 year contract with a stiff ($300 plus) cancellation fee. Will strict Internet TV be possible within that time frame? It might be, but if it is, so be it: we'll either pay the fee or wait it out.
So now we have 25/25 and man, what a difference..
I'm kidding. My wife was all excited because the Verizon rep kept telling her "It's 5 times faster". Of course that's true: 25 Mbit is 5 times faster than 5 Mbit. But "it" is the important word here, because "it" is Internet download speed, not your computer speed, not your browser speed, not the speed of any given website you might visit and so on. I told my wife that she probably would not notice this "improvement" at all (and she didn't).
I notice it, because I download stuff. If nothing else, I download pages and logs from this website for local backup. That absolutely is faster, though there is usually a certain amount of overhead so it isn't really 5 times faster.
Overhead matters. Verizon really does deliver that 25 Mbit, but it is rare for me to be doing anything that can really take advantage of that. Most of the time I'm downloading a pile of relatively small files rather than one giant file.
Did you ever notice that "scp" has a "-l" limit option? You might use that when you have a slower internet connection and want to do some downloading without choking off your web browsing while you do it. You can also use it (up to the limits of your existing connection, of course) to see the effect of internet speed on a given download.
I chose a typical mix of 80 files with a combined size of just about 4 MB and timed an "scp" down to my computer. I tried with various limits on scp, starting at 1024 Kbits. I also glommed all those files into one big file and timed that separately. The results show how much overhead matters.
| scp limit | Multiple files | One file |
|---|---|---|
| 1024 | 0m32.644s | 0m30.940s |
| 2048 | 0m20.157s | 0m15.888s |
| 3072 | 0m16.317s | 0m10.920s |
| 4096 | 0m13.918s | 0m8.427s |
| 8192 | 0m10.872s | 0m4.713s |
| 16384 | 0m9.948s | 0m3.578s |
| (no limiting) | 0m9.908s | 0m3.560s |
But can this be improved? I checked Verizon's optimization page and they sent me to Apple's Broadband Tuner.
As this MacWorld article explains, that program simply changes three TCP/IP parameters by adding a /etc/sysctl.conf file that looks like this:
# # Tuning network for broadband # # START kern.ipc.maxsockbuf=512000 net.inet.tcp.sendspace=131072 net.inet.tcp.recvspace=358400 # END
We can do exactly the same thing (temporarily) from the command line with "sysctl". My Mac showed these values originally:
kern.ipc.maxsockbuf: 524288 net.inet.tcp.sendspace: 65536 net.inet.tcp.recvspace: 65536
Let's repeat the tests above after changing to the same values that Broadband Tuner would use:
sudo sysctl -w kern.ipc.maxsockbuf=512000 sudo sysctl -w net.inet.tcp.sendspace=131072 sudo sysctl -w net.inet.tcp.recvspace=358400
| scplimit | Multiple files | One file |
|---|---|---|
| 1024 (before) | 0m32.644s | 0m30.940s |
| 1024 | 0m36.701s | 0m30.989s |
| 2048 (before) | 0m20.157s | 0m15.888s |
| 2048 | 0m22.487s | 0m16.076s |
| 3072 (before) | 0m16.317s | 0m10.920s |
| 3072 | 0m16.990s | 0m11.191s |
| 4096 (before) | 0m13.918s | 0m8.427s |
| 4096 | 0m15.747s | 0m8.694s |
| 8192 (before) | 0m10.872s | 0m4.713s |
| 8192 | 0m11.426s | 0m4.926s |
| 16384 (before) | 0m9.948s | 0m3.578s |
| 16384 | 0m11.329s | 0m3.598s |
| (no limiting) (before) | 0m9.908s | 0m3.560s |
| (nolimiting) | 0m10.407s | 0m3.595s |
As you can see, this actually made things slightly slower!
Would it ever make anything faster? Sure - as that MacWorld article explains, this is all about latency. I'm only 16 hops (give or take) from the site I downloaded from and we are in the same country. If I tested tested a very big download from Japan, I might see a speed up.
I don't do many downloads from Japan. I'm not sure that I have EVER done a download from Japan. This "tune up" may be useless for me.
In the early days of broadband, MTU was a big deal. If you search "MTU" within this site, you'll find old articles recommending adjustments. Heck, if you Google the Internet today, you'll find articles about testing and setting MTU.
Many of them are wrong, both in their assertions and in the instructions they give for testing. See DSlreports "Tweaking FAQ "Max MTU: How do I find mine?" for a more accurate page.. but even that doesn't explain that you may not be able to use the typical ping tests. Wikipedia explains:
From Path MTU Discovery in Wikipedia MTU article:
Unfortunately, increasing numbers of networks drop ICMP traffic (e.g. to prevent denial-of-service attacks), which prevents path MTU discovery from working. One often detects such blocking in the cases where a connection works for low-volume data but hangs as soon as a host sends a large block of data at a time. For example, with IRC a connecting client might see the initial messages up to and including the initial ping (sent by the server as an anti spoofing measure), but get no response after that. This is because the large set of welcome messages are sent out in packets bigger than the real MTU. Also, in an IP network, the path from the source address to the destination address often gets modified dynamically, in response to various events (load-balancing, congestion, outages, etc.) - this could result in the path MTU changing (sometimes repeatedly) during a transmission, which may introduce further packet drops before the host finds the new safe MTU.
Those old problems came either because negotiated MTU values were wrong or because there was no negotiation and the default values were wrong. Today, neither of those are likely to be true. You probably don't need to worry about MTU at all.
Faster DNS can help Internet performance, but paradoxically, choosing a DNS other than that your local ISP recommends can slow you down in some circumstances. I picked up that tip from Joe Kissell's new Take Control of Speeding Up Your Mac; you can read the details at Think globally, route locally.
For most of us, maybe not. Of course specific cases might matter. For example, we use streaming Netflix through Roku.. I have no idea what that Roku box is tuned for - it's Linux, so in theory I could break into it and play around, but I'm not going to risk breaking it to see a movie a few seconds faster than I see it now. As to speeds on our computers, my testing says I should leave it as it is - Broadband Tuner will slow down my usual activities. That it might speed up some unusual activity is unimportant - it is the downloads I do every day that matter..
So, given all that, I'm not changing anything. I do use Google for DNS, and that might cause me problems in some obscure circumstances, but (again) it is the daily use that matters to me and for that, Google DNS is faster.
So how about that Verizon upgrade - It's five times faster! Ayup.. sort of, sometimes, maybe..
More Articles by Anthony Lawrence - Find me on Google+
Have you tried Searching this site?
Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.
Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.
Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.
We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.
Click here to add your comments
Don't miss responses! Subscribe to Comments by RSS or by Email
Click here to add your comments
If you want a picture to show with your comment, go get a Gravatar