Cloud Concerns

Are We Going to Look Back and Say..."What Were We Smoking?"

You've got a blazin' fast gig network running like Usain Bolt on Jolt. You've tweaked every inch of the network and spent hours explaining that you "don't control the Internet" when their web browsing sessions slow to a crawl because some blowhard ISP decided to cap your bandwidth. The winds have turned cold and a chill is in the air as management performs rain dances that bring ominous cloud computing towards the horizon. Now you need to watch for latency along the ISPs path to your servers... your data. What about packet loss dragging your throughput rates through the mud? Oh... don't even get me started about rate throttling! Makes me want to throttle someone! Let's ponder this case study... A customer of mine complained that communications between their offices seemed rather slow lately. They asked me to take a look at the traffic and evaluation the throughput rates. There seemed to be a consensus that some device was dropping packets along the path.

The IO graph screamed a story.The graph above is my rendition of what I'd seen that day - the trace files were to remain at the client.Do you see how that line seems to hit a ceiling? Oh yeah... a ceiling by the name of ***** (name hidden to avoid lawsuits). The ISP had promised them (and charged them)the world. In reality, however, they had put a cap on my customer's traffic that was way below what my customer paid for. Now... imagine that this is your corporate network and your service response times are dependent upon some ISP! Do you love your ISP that much?

Cloud computing brings up so many issues - the idea of putting the network health in the hands of the ISPs triggers my gag reflexes. Have you ever tried to work with an ISP to find out why your round trip latency times are so high? What are the bandwidth requirements of your apps? What will the end-to-end (client to cloud-based server) throughput be? Where will your data really be? What path will it take... today...? Who will pick up the phone when you call to say "the cloud is slow?"

Perhaps Lena Horne said it best... "Don't know why... there's no sun up in the sky... stormy weather... when my SERVER and I ain't together...". Lena knew networking! The Analyze and Improve Network Throughput and Top 10 Reasons Your Network is Slow seminars explain throughput testing and the most common causes of poor performance.

Enjoy life - one bit at a time...
aura

Do You Know Where Your Throughput is Today?

iPerf Might Scream "This Stinks!"

Last night I was laughing and crying at the same time while reading a local small town newspaper and the dissertation on bandwidth problems at the local library. They actually shut off half the computers to aleviate the problem. One quote really grabbed me - "We don't notice the bandwidth problem when no one is using the computers." Hunh?

There were a few puzzling comments in the article such as the comment that the bandwidth problem "started 3 weeks ago." That sudden onset of the problem feels like something else to me. It feels like a device along the path that is causing the problems. A quick look at the traffic would validate that.

The article tied in nicely to the iPerf Throughput Testing materials I am finishing up. The reaction to the live iPerf testing done during the Analyze and Improve Throughput course and numerous requests for more information on iPerf prompted me to start developing a course that shows how to perform a series of throughput tests for UDP and TCP traffic.

iPerf is simple and complex at the same time. The one application can be run either in client mode or server mode.

Tests can be run in one direction (from the client to the server, which is the default) or bi-directionally. Here is one of my favorite tests for iPerf:

Client: -c 10.1.1.1 -u -t 60 -i 5
Server: iperf -s -u -i 5

This test enables me to locate jitter and packet loss along a path using a UDP stream sent over a 60 second time with results displayed every five seconds at both the server and the client.As you can see from the screenshot above, the path suffers packet loss reaching 39%. We were sending a steady stream at 1.05 Mbit/second specifically to identify packet loss. Well... we found it. Running the test for a full 24 hours would help us identify specific times of the day when packet loss is at its highest.

I hope to get into the local library and run Wireshark and iPerf on the network soon. I have no idea if the systems are locked down - a slight problem that might require some workaround. Meanwhile I'll peruse the shelves for those network troubleshooting books.

The "iPerf Throughput Testing" modules will be included in the Summit 09 course in December (www.chappellseminars.com/summit09.html) - the "Analyze and Improve Throughput" course is available now at www.chappellseminars.com.

Enjoy life one bit at a time.
Laura