Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now


Those Pesky Network Speed Issues

Use ‘divide and conquer’ technique to troubleshoot problems

This edition of “things the average broadcast engineer needs to know” is going to focus on common complaints about network speed. I’m sure you’ve heard them: It takes forever for a Web browser to load a page, or printing something is really slow. Maybe your audio streams are intermittent.

As I write this, my assistant Todd and I have been troubleshooting issues like these, so they’re fresh on my mind. In one case, we eventually determined that the ISP was having problems. In another, we had a Telos Z/IP link that kept dropping between two of our stations in New York State. We determined that one of the Z/IPs needed a firmware update.

I’m going to assume that you’ve isolated high-traffic networks into separate subnets. If you’re trying to run your audio automation, audio-over-IP, office, traffic and everything else on One Giant Network, well … that’s your problem right there! But assuming that you’ve intelligently subnetted everything, let’s focus on complaints within a given subnet.

There are no quick and easy answers in every case. But by carefully considering your network topology and using the old “divide and conquer” troubleshooting approach (and by not overlooking factory upgrades!), you can run these down with a little patience.

As usual, I’m going to focus on 100-megabit Ethernet, since that’s what most of us use. If you have something else, the principles are the same, but the numbers may differ.

There’s no need for every PC on the network to see every packet that is sent by everyone. This is where a good network switch comes in. It doesn’t just act like a patch panel with blinky lights. It intelligently routes the packets between ports, only sending data to ports that need to “see” it.

Fig. 1: Simple Networking Example In Fig. 1, PC#1 is “talking” to PC#2. The switch has “learned” where these PCs are (i.e., it knows or has learned their MAC addresses) and automatically routes the data directly between port 1 and port 2. The other ports (and thus, all of the other connected hosts) never see that data.

In a sense, a smart switch does “sub-netting” on a moment-to-moment basis. This dramatically reduces congestion at the local, host-to-host level. PC #1 and PC #2 might be transferring gigabytes of data, but it doesn’t cause congestion to computers on other ports. They are isolated from that high data flow by the switch.

“Smart” 16-, 24- and 48-port switches can be had for a few hundred dollars nowadays, so there’s little excuse not to buy a good one. To do per-port packet routing on the fly, a switch needs fast processing and RAM to store data during brief overloads. That adds to the cost and it almost certainly won’t be included in a $20 unit from Walmart!

Speaking from experience, cheap switches are notorious for dropping into what’s called “promiscuous mode” if they become confused. At the least provocation, they’ll essentially become wide-open hubs: all data passing through the switch is visible to every connected host. At this point the switch is no longer “smart.” Using Fig. 1 as an example, if PC#1 and PC#2 are transferring gigabytes of data, now they’re bogging down everyone on the network, because that transferred data is appearing at every port. Yes, the other hosts will ignore that data because it’s not addressed to them, but bandwidth is still required at each port to give each host the chance to ignore it.

I’d recommend a smart switch with a built-in Web interface. You’ll have to assign an IP address to the switch itself, but in return, you can check the status of each port, looking for problems. Here’s a common thing to watch: you want those ports to run in full-duplex, full-speed mode. I can’t tell you how many times we’ve had a sluggish computer, only to discover that (for whatever reason) the connection had dropped to half-duplex, or even to 10 megabits.

The next step is to use one large switch, rather than a bunch of small ones. In particular, you should avoid daisy-chaining switches. If a smart switch sees more than one network address using the same port, it will essentially have to “divide” that bandwidth between all of those hosts. While it doesn’t work out this neatly in practice, you can imagine that four people daisy-chained on a single 100 megabit port will each enjoy the equivalent of a 25 megabit connection.

Fig. 2: More Detailed Networking Example Fig. 2 shows a typical arrangement. The top section is fine; if someone in the “Other PC” group wants to print, the smart switch makes a “direct connection” between that PC and the printer. Just as important for network performance, those packets won’t appear at the other ports. That’s what we want.

Now let’s say that someone else in the “Other PC” group browses the Internet. The smart switch will again arrange a virtual “direct connection” between that PC and the firewall (and thus, to the Internet).

As a switch “learns” the addresses that are connected to each port, it will attempt to make these “direct connections” between ports whenever possible. Our job is to arrange the network so that it is possible in most cases.

By preference, you should use a single switch that’s large enough for the network. Don’t try to use a bunch of little 4- and 8-port cheapos in a daisy-chain arrangement. Performance will (to put it mildly) be suboptimal.

(Super tip: watch for switches that have been added by co-workers without your knowledge! I’ve seen it happen. Someone wants Internet access — especially at night or on a weekend — and just grabs a little cheapo switch and “splits” the connection in the control room!)

But sometimes “chaining” is unavoidable. In Fig. 2, some folks wanted wireless access, so we added a wireless access point. That’s fine, but keep this in mind: it doesn’t matter if you have the latest, greatest, ultra-fast wireless hardware. Since everyone on wireless will be sharing the same port on the main network switch, things can (and will) bog down. The people using wireless will just have to deal with it.

Here’s another recommendation: Printers, scanners and other hardware often come with wireless capability built in now, but don’t use that on a busy network. Run a separate, hard-wired connection between that hardware and your main network switch (as we’ve done with “Printer #1” in Fig. 2).

Don’t succumb to the temptation to use the built-in switch on the wireless unit. I’ve shown 4 ports in Fig. 2, which is typical. But leave them be. In the illustration, the folks in the “Yet Still More PCs” group are not going to happy, especially when the network is busy. And anyone who tries to use Printer #2 will definitely be unhappy because it’s going to be bottlenecked as well.

One other piece of advice: don’t put the wireless unit at the “head” of the network. In Fig. 2, you might wonder why we didn’t just use a wireless router on the Internet access. Many of them have a built in firewall, wouldn’t that work? The truth is these little wireless router boxes are intended for very small networks. They’re not enterprise quality. Putting that switch at the head of your network installs a splendid bottleneck right at the git-go!

Let’s say that someone complains of slow Internet access. I showed a separate firewall machine in Fig. 2 because I’ve learned (the hard way) that this is the best way to do it. Once you’ve ruled out the obvious (a bad cable, for example), the next thing to check is network congestion.

We use ClearOS (see Todd Dixon’s article in the Aug. 28, 2012 RWEE, “ClearOS Is a Firewall Winner,” for more info;, keyword ClearOS). With a few added modules, it is marvelous for tracking down stuff like this. Think someone is “hogging” all of your Internet bandwidth? You can pull up each user and see, in real time, precisely how much they’re using. This makes it easy to run down the offender.

Now let’s go in the other direction. Suppose you use a streaming service: Your station transmits an audio stream to a remote server, which then distributes it to the public at large. The problem is, your stream has become intermittent — the audio is dropping in and out.

First, confirm that your internal network path is good. As mentioned above, ideally, you’d have this “streamer” on a separate Internet connection entirely. But for this illustration and for better or worse, let’s just assume that it’s in the “Other PCs” group in Fig. 2. (It goes without saying that the worst possible connection would be that little wireless router!)

Next, disconnect the internal network from the Web. I would suggest doing it at point “A” in Fig. 2. Connect a laptop to point “A,” set it to your public IP address and ping the remote streaming service. Look at the response times. You want them to be well under 100 mSec.

Better yet, connect the streaming PC itself directly to the Internet at point “A,” with nothing else in the way. If the stream issue clears up, something on your network is bogging things down. If you suspect a firewall issue, try the streaming PC again at point “B” in Fig. 2. If point “A” is remarkably better than point “B,” you need to spend some time tweaking your firewall.

If the stream is still intermittent at either point “A” or “B”, browse to one of those “speed test” pages. I like the one at Now, these will only detect gross problems with your Internet service. You will rarely (if ever) get the speeds advertised for your connection. But if it’s really low (e.g., you’re paying for 1 megabit of upload but you’re only getting 156k!), you should open a trouble ticket with your Telco and/or Internet Service Provider.

Many Telcos and ISPs oversell their bandwidth. If they have many users on the Internet at the same time, their network is going to bog down. This is pretty obvious and a speed test may uncover it.

But if you read your service agreement, you’ll probably discover that they reserve the right to do this. If you absolutely must have a reliable, unthrottled connection, you may have to pay the higher price for a bonded T1 or Metro Ethernet connection. These are guaranteed bandwidth services but they cost a lot more.

“Slow” network issues can be aggravating. Step one is to set up the network as logically as possible, with one smart switch in a “star” network. If you have problems internally, look for a switch or network card that has dropped to half-duplex or speed. The better switches will allow you to examine the throughput and will even tell you if one or more ports have dropped into promiscuous mode.

Look for an Internet bandwidth hog; a firewall/gateway like ClearOS is ideal for this.

For Internet issues, divide and conquer. Do a speed test. Be aware that your connection may be throttled during peak hours. But with patience and a little work, you can find the problem.

Until next time!

Stephen M. Poole, CBRE-AMD, CBNT is market chief engineer is Crawford Broadcasting in Birmingham, Ala.