Anue goes to the movies: My Fair Lady

Posted on Wednesday 16 May 2007

(or, Simulation vs. Emulation)

Sometimes you just have to use the right word. You know, like when people say, “I could care less,” when they really mean, “I couldn’t care less.” Cause if you could care less, that means you care some amount more than zero. But if you couldn’t care less, it means you care zero, cause you can’t care less than that.



Now, I’m not that guy who goes around at cocktail parties saying, “You know, it’s card sharp, not card shark.” Really, I’m not. OK, maybe I did that once. Or a few times. OK, I might be that guy. Not saying I am, just that it could be possible.

When it comes down to it, most people couldn’t care less if it’s sharp or shark, right? But when it comes to your enterprise application, it does matter that you get it right.

Of course, we know that testing under real-world conditions is important. Everybody knows that. We’ve seen what happens when you don‘t, and it’s not pretty. (See Network Impairments if you’re in doubt.)

You hear the terms “network emulation” and “network simulation” used a lot, sometimes interchangeably, but emulation and simulation are two different things. A network simulator uses software to imitate the behavior of a network. A network emulator uses hardware to imitate the behavior of a network. Hardware, software, who cares? You do.

The point of real-world testing is to precisely and repeatably reproduce network conditions in a controlled environment. So it stands to reason that you want a solution that can actually do that. Reproduce network conditions. Precisely. Repeatably.

A hardware-based emulation platform has the horsepower to do that. Pass all traffic through the impairment engine. All traffic. All speeds. All packet sizes. At line rate. Precisely and repeatably add delay in increments down to nanoseconds.

That’s what you need. You can’t afford to get in the middle of testing and discover your network simulator is creatively adding its own jitter or packet loss because it can’t keep up with the traffic. You need a solution that can dance all night.

So, now that you’re ready to bring real-world testing into your lab, make sure you get the right emulator – the one that can accurately reproduce the network in all its ugly reality. Because that’s the only way you’re going to know, instead of hope, that your solution really works out in the real world. Testing with network emulation means more stable solutions that perform as expected when the times (and the WAN) get tough. Wouldn’t it be loverly if everybody tested under real-world conditions with network emulation before release?

Things your mother told you

Posted on Wednesday 18 April 2007

Your mother always knows. The older you get, the more you realize how true it is.

You’re probably thinking your mother doesn’t know anything about networks. Telecommunications networks, that is. She probably had her own network that allowed her to know exactly what you had done before you even got home, so when you walked in the door she could say . . .

Is there something you want to tell me?
. . . and the next thing you know, you’re spilling your guts. You never knew how she does it, but it always seemed to work. She could give lessons to Homeland Security.



Sometimes maybe she would interfere and insist you do something you thought was totally unnecessary, like change your shirt or take a sweater with you or get a sandwich or something and you would roll your eyes and she would say . . .

You’ll thank me later
. . . and you’d realize later she was right, but you’d never admit it.

So, now somebody comes along and says you need to test your application under real-world conditions with a network emulator and you’re thinking that you already threw all kinds of traffic at it and stress-tested it and got all the kinks worked out and you really don’t need to bother with a network emulator because it’s going to mess up your schedule and besides, what could go wrong? Right?

Just remember what your mother said.

It’s for your own good
That’s right. What could go wrong? Plenty! The effect of delay across the WAN is multiplied when session-oriented protocols like TCP are involved. If your application is too chatty, dropped packets and retransmissions can bring it to a grinding halt faster than you can make up your bed. If buffer sizes aren’t big enough to handle reorder problems, they turn into dropped packet problems.

The truth is that if your solution hasn’t been tested under real-world network conditions, you have no idea how it’s really going to act, and that’s not a good thing. In fact, it’s a really, really bad thing. It can mean a failed launch, delayed schedules, productivity loss, finger pointing, loss of confidence in your department. Bad stuff, Maynard.

On the other hand, if you test under real-world conditions using network emulation, your application will be ready for prime time and anything the network can throw at it. Which is good, because when it comes time for the rollout, you don’t want it to crash and burn and then hear your manager say . . .
It looks like a tornado came through here

Listen to your mother. Even if she doesn’t know anything about networks.


Anue goes to the movies: The Perfect Storm

Posted on Tuesday 3 April 2007

AKA: Know what floats (and sinks) your boat

-Your test lab is like Lake Placid, a nice, calm spot that the most rickety boat can sail without a problem.
-The WAN is like the north Atlantic, a capricious, wild, treacherous monster that can sink the most rugged vessel.
-Your solution is the boat.

Wouldn’t you like to know if it will survive the storm before you put out to sea?



You’re building or launching a solution of some kind. It could be an enterprise application or a website or VoIP or video conferencing. One thing is certain – it will be used across a network, either the Internet or a corporate wide-area network. What isn’t certain is if it will work as expected once it’s launched.

Too often a test plan covers the expected traffic, but not the expected network conditions. PCs with scripts are set up in a test lab, or perhaps a traffic generator/analyzer is used to simulate hundreds of users hitting the server. But the test network is pristine 10/100/1000 Ethernet on CAT5. Nothing like the network it will be deployed on.
The WAN does bad things to applications. It adds delay in varying amounts. It drops packets or sends them down different routes so they arrive out of order. It flips bits when nobody is looking. The perfect storm of delay and impairments is out there, just waiting to sink your project when it goes live.

Kinda depressing, isn’t it? But you can change the story to have a happy ending. You can put your solution through the perfect storm before it ever leaves the test lab, find out what can sink it, and fix the problem before it even happens.

That’s what we do. We create the perfect network storm right in your test lab, without anybody getting hurt. How do we do it? We make a hardware-based platform that can accurately and precisely emulate real-world network conditions. Any speed, any traffic, any packet size. And we’re the only ones who can do that.

Just think. What if you could:
- Understand and predict the behavior of your solution under every possible network scenario before it goes live.
- Know if it will meet service level objectives.
- Identify the factors that will affect performance.
- Make changes based on data instead of guesswork.
- Be confident that your solution will support the performance, robustness and scalability your organization needs in the initial roll-out.

And think what your boss will say when you show him a plan that will:
- Reduce development schedules
- Reduce support costs
- Avoiding live troubleshooting and downtime
- Increase revenue and competitive advantage

He might even send you a thank you gift, like movie passes or something.
Bring the perfect storm into your lab, take the drama out of your job, and save it for the movies, where it belongs.


Network Impairments

Posted on Tuesday 27 February 2007

Call me what you want…just don’t call me late for dinner
You know how it is trying to do lunch. Half the battle is getting everyone to agree on a place. The other half is getting everyone to get to a stopping point at the same time so you can leave. Sumir says he’s almost done with the conference call, so Karen decides to respond to a few more emails. Sumir hangs up the phone and Karen says she has to type one more paragraph and Mark decides to go to the bathroom. Karen pops out of her cube, realizes everyone is waiting on Mark and has to be physically restrained from popping back in for one more email. It can take 15 minutes just to get everyone out the door.



If you do lunch with someone from another company it’s usually not as bad, since you just set a time and meet. Or so I thought. We picked a new deli close to her office where the Reubens were supposed to cause ecstatic visions. I was halfway through a transcendent encounter with my sandwich when Kim finally dropped into the other chair. I looked at her, munching in a serene but questioning way, at the cusp of enlightenment. She snagged a chip from my plate and said, “Rover.”

I took another bite and waited. She took another chip and continued. “ROVER is our new customer relationship management system. Stands for Remote Office something-or-other. It was supposed to streamline everything, order-tracking, support issues and all that while making it easier to work on the road or from home. Instead, it’s turned out to be a dog. It was painfully slow to start with, but last week they combined all the data centers into one facility in Denver and now it’s ridiculous. I got a call from our Portland sales team and tried to create a new incident record. It took two minutes just to log in, and an eternity to click through the screens. So, what’s good? Are the Reubens as wonderful as they say?”

Exuding an aura of pastrami-induced compassion, I gave her the other half of my sandwich and went to order another.
Her situation is not as unusual as it should be. Companies are developing and deploying distributed applications all the time without testing them against realistic WAN conditions. I’ve seen lots of reasons why this happens. The test plan overlooks the problems that can be caused by network impairments. Or they run a few test trials over their production network, usually after hours to prevent business disruptions, and have a false sense of confidence when they don’t see any problems.

Or they don’t realize that they can recreate actual network conditions in the test lab with an Anue Systems network emulator. It’s what we call network impairment testing or signal impairment testing. It lets you do to your application what the WAN is going to do to it, before you have hundreds of users like Kim complaining about your system. The cost of a network emulator is minor compared to what can happen when a system is deployed without network impairment testing. Productivity loss. Finger pointing between the network group and the applications group. Acrimonious meetings. Loss of confidence in your department. Morale issues among your staff.

It’s a shame, really, when, like karaoke, it’s completely preventable. It is possible to know in advance how your system works on a real network. To test during the relatively calm and rational time of development and testing instead of the high-visibility, company-wide exposure of a post-deployment crisis. To troubleshoot and identify performance and response-time issues early, when it is less expensive to find solutions and implement them.

That’s what we do. It’s nice working for a company that makes everyday life better for hundreds of thousands, if not millions of people. Spreading contentment and enlightenment. Kinda like buying a heavenly sandwich for everyone.





Since 1997, Gillaspy Associates has built a solid reputation for developing strong relationships with our customers by providing quality solutions and ongoing support.

Network Emulation Blog

Blog Home
Satellite Testing
Server Migration
VoIP
Circuit Emulation
Network Impairments
Network Emulation

GEM/XGEM Related Pages

Overview

GEM (10/100/1G Ethernet)

XGEM (10G Ethernet)

Ethernet Product Brief


Delay Emulation Products

GEM/XGME

SD Signal Delay

PD Path Delay

FC SAN Delay & Impairment

Combo Units


Delay Solutions

Networked Applications

Server/Data Center Migration

Video & Voice

Wireless/Mobile

Network QoS

Circuit Emulation

PON

Disaster Recovery/Business Continuity

Satellite Communications

Proof of Concept & Interoperability

Next Gen Sonet/SDH

iWARP

Network Planning & Readiness

SAN Extension

CPRI

TCP/WAN Acceleration

Anue Systems


Training Courses

Gillaspy currently offers the following training courses:

SAS

ML270 - Serial Attached SCSI Architecture & Instrumentation

Fibre Channel

ML250 - Fibre Channel Systems Architecture & Instrumentation

ML350 - In-depth Fibre Channel Analysis

iSCSI

ML280 - iSCSI Architecture and Instrumentation

FCIP

ML240 - Introduction to Fibre Channel Over IP (FCIP)

MCE: Medusa Certified Engineer

MC100 - Xgig Analyzer
MC125 - NetWisdom SAN Performance Monitoring System

SATA

Serial ATA Architecture

IO Bus

PCI™ Architecture
PCI™ Overview
PCI-X™ Architecture
PCI-X™ Overview
PCI Express ™ Architecture
PCI-Express™ Overview
Intel Pentium 4/m/Xeon
USB Architecture (Core Topics)
USB Architecture (LS/FS Only)
USB Architecture (HS Only)

Contact Gillaspy Assocates at 805-987-1959 to schedule an on-site class.