In “Good Math, Bad Math,” Ph.D. carrying, Google-employed, shmartypants Mark Chu-Carroll talks about how math can be used, incorrectly, to mislead people into having expectations that do not match up to reality.

His latest post points out a particularly interesting one – the bad math used to calculate the mileage on the Chevy Volt.

The Volt, if you’re not familiar with it, is a type of vehicle called a “plug-in” hybrid. In a normal hybrid, the internal combustion engine powers a generator which charges batteries, and the car runs off of the electric juice in those batteries. This generally produces better gas mileage than standard internal combustion engines – basically because the batteries in hybrids can store energy that is normally “lost” in internal combustion engines – specifically, in braking and idling.

So anyway, the Chevy Volt simply takes the next step; it not only takes electric power from the onboard internal combustion engine, but also allows you to draw electricity in off-peak hours from the municipal grid. You literally plug this sucker into an outlet outside your house.

Now this isn’t particularly new technology either. Hobbyists and car enthusiasts have been creating “PHEVs” (Plug-in Hybrid Electric Vehicles) since 2004. This is the first car, however, that has plug-in as a default, off the factory rack, no voiding the warranty needed.

But because of the technology needed, it was always hard to figure out exactly how fuel-efficient plug-in-hybrids were. Hybrid cars – those cars that get all of their electricity from the internal combustion engine – had rather simpler metrics. But plug-in hybrids use zero gallons of gas for the first few dozen miles – for the Chevy Volt, that’s about 40 miles without a need for gas. But once you get over that limit and start burning gas, the volt is no more fuel efficient than a normal hybrid – say, 50 miles per gallon.

So depending how far you drive between 8kwh charge cycles, you’re looking at anywhere from slightly above 50 mpg to “infinity” Mpg. Where’d this 230 number come from?

Well, the U.S. Environmental Protection Agency drafted some guidelines for coming up with an MPG figure – with, of course, some “guidance” from the auto industry. Of course, this is a literal case of “Your Mileage May Vary.” Chevy is claiming the 230 mpg number based on its own internal tests, however, as the EPA has not yet tested a Volt.

You may argue that a more accurate nomenclature, say “50mpg + 40” is confusing to consumers who are used to thinking in cars in terms of “miles per gallon” – but you know what’s going to be even more confusing? When they find out that their 230 mpg car might get as little as 50 mpg.

One of the big problems with trying to figure out something that’s “per” anything else – is that essentially, our brains aren’t wired for division. They’re wired for addition, subtraction, and multiplication. It’s counterintuitive, but true, that a hummer that improves its mileage from 10mpg to 15mpg saves more gas (about 3.33gal/100 miles) than a hybrid going from 40mpg to 50mpg. (about 0.5gal/100 miles). I mean, I’d still get the hybrid over the hummer, but you see where I’m going with this.

Of course, we’re no strangers to bad math ourselves in IT. Bad math is one of the reasons that you need to independently confirm service level agreements with various bandwidth providers. They may promise something like “100ms” latency, but there’s a big difference between a maximum of 100ms latency and an average of 100ms latency. Network visibility isn’t just looking at the numbers, but knowing what the numbers mean.

We’ve produced a follow-up to our earlier “The Network Company” video, this time looking at LAN vs. WAN application coding, TCP Slow Start, and WAN Optimization. Instead of giving you a detailed run-down, I’m just going to go ahead and embed it right here.

I love any day when I get to smash citrus with a large blunt object at work...

An interesting post over at Slashdot pointed me over to a Network World story by Mitchell Ashley about how Windows 7 wouldn’t be a compelling upgrade from Windows XP. The interesting aspect is that Ashley goes on to suggest that perhaps the idea of OSes might become irrelevant if you move to thin clients connected to virtualized computers over the LAN.

The future Simon paints is one where these personal and business computing environments are virtualized onto the same computer, rather than intermingled as they are today. Businesses will deliver virtualized full OS plus apps, and stand-alone virtualized apps, to computers that users own. This maintains the security of corporate data and applications, and allows the business to viably deliver a computing environment they manage on computers they don't. Obviously this vision is in line where Citrix is going with XenServer, XenApp and their newly announced Project Independence, and given my own views about desktop and application virtualization I can see merit in a lot of Citrix's vision.

While we haven't seen much of this yet, I believe it would be wise for Microsoft to continue to improve Windows 7 as an easily virtualized OS and a platform for delivering virtualized applications. Microsoft has partially move Live Essential apps into the cloud. As they move Office and other apps online, the OS becomes thinner and thinner, less bloated with applications that entangle themselves into the registry and Windows folder of Windows 7.

You know what, I might be wrong on this – but I don’t see it happening.

This is not to say that thin clients and virtual desktops don’t have their place, but the problem with virtualizing the desktop is that offloading processing to a datacenter means, necessarily, more traffic on the LAN. Individual applications may be run remotely, sure, but operating systems – or specifically the graphical user interfaces of those operating systems – carry a lot of overheard. (If we were all using command line interfaces, the overhead would, of course, not be nearly as great.)

Additionally, companies have been moving more towards having consolidated servers connected to the end-user via the WAN – by bringing the servers closer to the datacenter, you’re also, in effect, moving the users further away. You can have virtualized desktops saturating your LAN, or virtualized servers saturating a WAN, but it would be extremely unlikely that you could have both on the same WAN.

What seems more likely is the use of virtual servers to serve up specific applications – applications that can be optimized to reduce overhead on the network. I just don’t see that happening with XP, nor Windows 7 – perhaps only the next generation – the Microsoft Cloud OS, perhaps – might be light enough to handle virtualized desktops. Then again, a computer’s what, $300 from Dell nowadays? And are you saving that much if you have to get a thin-client appliance for each user instead of buying a general purpose PC?

There have been some worthwhile attempts to do the WAN equivalent of having a cake and eating it too - a number of WAN Optimization vendors are putting in Windows services on the WAN Optimization blades themselves.  That is, one of the ways they optimize the WAN is to keep traffic off of it – and one of the ways to keep traffic off the WAN is to take care of Windows services on the branch LAN, before it even reaches the WAN.  In a way, it’s sort of the opposite of server consolidation – but since you have to run the blade for WAN optimization purposes anyway, you’re not adding additional hardware or sucking up much more power. 

This is pretty much speculation at this point – but speculation is fun, isn’t it? I’d love to hear your comments on this.

My car, a Ford Taurus from 2000, with 120k miles on it, is dying. The check engine light went from a manageable steady golden hue, indicating need of expensive repair, to intermittent blinks which indicate that death is imminent.

Coincidentally, this is also the general state of the American automobile manufacturing industry.

The trade-in value is less than what it would cost to repair, so I’ve decided to buy a new car.

It’s my first time buying a new car, as all the other cars were given to me by relatives as hand-me downs. I’m running up against a familiar nemesis, however, and that is information asymmetry.

That is, the dealers know a hell of a lot more than I do about how this works. For example, I couldn’t figure out why all the local dealers were charging $15k for a car that has an MSRP of $14k. (Turns out that all the cars of that brand go through a wholesaler who adds options.) Also, it’s either an urban legend (or inapplicable with my insurance company) that red cars cost more to ensure than blue ones. But I was misinformed about it until just recently and that artificially limited my options.

Stephen Dubner and Steven Levitt wrote extensively about this in Freakonomics and I’d be happy to quote the relevant passages. I can’t, however, because I don’t trust my current car to make it all the way to Barnes & Noble and back.

What I can take comfort in is that compared to a few years ago, I am at least more informed than I once was, being able to look up MSRP, Invoice price, and average sale price on the Internet. In fact, between Edmunds.com, KBB.com, Caranddriver.com, Yahoo Autos and various auto blogs, I’m probably in a better shape, information wise, than my father when he bought his first car – and Dad was a mechanic as a teenager.

Similarly, enterprise customers who use network service providers need to have visibility into how the services are actually performing.  Are they living up to SLAs?  Is the service provider having performance problems that are affecting your applications?  Without the transparency, there is an information asymmetry and the service provider has an advantage over the customer. 

There are several different ways to address this. One, you can keep some amount of network performance monitoring in-house to validate contracted performance. Another route, which is gaining popularity with service providers that are differentiating their services and adding more granular, performance-oriented offerings, is to provide their clients with their own view of network performance.

Either way, sharing data and context between client and service provider removes the asymmetry, building trust for the client and potential new streams of revenue for the provider.

My day job is covering networking innovations and trends, but I moonlight as a video editor, director, and producer, so I was personally really excited to hear what Cisco was doing with the Cisco regarding the new Cisco Media Experience Engine (MXE) 3000, and my question lists includes questions about bitrate, framerate, dynamic re-encoding, and “can I borrow one for the weekend, pretty pretty please?”

Network World has a picture of it, which looks like a 1U blade with a DVD-ROM drive. According to the Cisco FAQ, it’s designed to be used in the data center.

But what does it do, exactly, and how will it impact network performance?

Ultimately, the MXE is a transcoding device that resides in the Data Center. For non-video geeks, transcoding is what happens when you take a video that is in one computer format, and want to turn it into another video format. For example, when you take your digital camcorder’s DV tape and burn it to a DVD, part of that process is your computer converting from the DV format to the format used in DVDs – MPEG2. That conversion is called transcoding – moving from one codec to another.

The question, of course, I would have really liked to ask Cisco: What is the advantage of putting the transcoding software and appliances in the data center, compared to, say, buying a Mac XServe, putting it in a closet somewhere, enabling a remote desktop, and using a program like Final Cut Studio’s Compressor to accomplish many of the same pre-processing and encoding tasks that the MXE can accomplish?

This is an especially important question because while one of the key goals of the MXE is to limit traffic congestion on the WAN by reducing large videos into smaller ones. For example, videos may be recorded using an HD camera in HDV, which records at 25 mbits/s in the MPEG2 codec. However, you could save on bandwidth by reducing the movie from the original 25Mbits/s to around 3Mbits/s in the H.264 codec, which preserves video quality at lower file sizes with the tradeoff being the extra processing power needed to both encode and decode the image. You could cut that down even further if you don’t need HD detail.

So, yes, if having an MXE means that raw video travels on the high-bandwidth, low-latency LAN down to the MXE, where it is converted to a smaller file for travel on the low-bandwidth, high-latency WAN, it could be huge.

What seems to be strange, though, is that Cisco suggests, in the online promotional video for the product, sending the large source video through the WAN to be transcoded. I’m not sure that that would work out as well as Cisco thinks it will. Even with a device like the MXE, keeping track of your network’s capacity and monitoring your traffic flows and response times end-to-end remains important for the simple reason that not all video is optimized for the network. We were unable to, as of press time; hear back from Cisco directly, and that was a little disappointing.

So what is the advantage of the design decision to put this in the data center? I’m sure there is one – I just wasn’t able to get with Cisco – yet- to find out exactly what it is.

Additionally, the MXE transcodes files, not streams. This means that video-over-IP won’t be affected by the device. What I’d really like to see is a device that can transcode streaming video on the fly – using higher resolutions and bitrates when the link is relatively uncongested, and reducing it when there is other traffic on the network with higher QoS priority. That would be a killer app for videoconferencing, and this might be a good first step towards that goal.

Ken Church, Albert Greenberg and James Hamilton of Microsoft recently put out a paper on “Delivering Embarrassingly Distributed Cloud Services.”[PDF] Like most papers of this type, it’s a dry read, but informative. It looks at the tradeoff between mega-data center size and micro-data center diversity from the both the viewpoints of total cost of ownership and of performance.

The most important line in the entire report, of course, is “The trade-offs vary by application.” However, they make the argument that applications with little need for server-to-server communications will show benefits in cost, scale, reliability and performance through geo-diversification – in other words, lots of little datacenters as opposed to one big datacenter.

This seems to fly in the face of the trend in data consolidation, but there is a point to it: For any data center, there needs to be redundancy, but in a centralized data center, there needs to be more redundancy than having multiple small data centers. As Church, Greenberg, and Hamilton put it, “the more geo-diversity, the better. N+1 redundancy becomes more attractive for large N.”

The part that really interested me, though, was the networking section. (Section 3, in case you want to skip right to it.) Church, Greenberg, and Hamilton point out that in a large, centralized datacenter, you can have end-to-end control and assure a particular level of performance through supported service level agreements. On the other hand, they argue:

“[with distributed data centers] the cloud service provider has ceded control of quality to its Internet access providers, and so cannot support (or even fully monitor) SLAs on flows that cross out multiple provider networks, as the bulk of the traffic will do. However, by artfully exploiting the diversity in choice of network providers and using performance sensitive global load balancing techniques, performance may not appreciably suffer. Moreover, by exploiting geo-diversity in design, there may be attendant gains in reducing latency…”

“Many large analysis applications are best run centrally in mega data centers… Interactive applications are best run near users… [they] can be delivered with better QoS (e.g., smaller TCP round trip times…) via micro data centers.”

The argument’s sound, especially when you consider that interactive applications are probably the most latency sensitive because they need to make multiple trips to and from the client and server with every interaction.

But reducing the propagation delay (or distance delay) is merely one part of the performance equation. By ceding control over router performance and transmission, you have no way of diagnosing network round trip time problems if they occur, and wouldn’t be able to fix them – short of the messy step of changing service providers – even if you did. If something goes wrong, it could negate the speed increases by diversifying servers, so moving to this model more of a gamble than a guarantee of improvement. Granted, it’s a gamble that might make sense for some apps and some organizations – some apps, apparently, can get away with less than 100% uptime.

Reprinted from TheDailyWTF.com:

At my company, there's a bit of a wall between Application Development and Network Operations. All "network and network-service related issues" must be reported through the porthole, a.k.a. Helpdesk. Quite often, this leads to interesting results.

"Helpdesk, Jerry speaking."

"Hey Jerry," I said, "this is Paul over in app dev. Our TerraTrade system has a defective ForEx feed that needs to be fixed right away. It's causing a bit of an outage, so if possible, can we open the ticket as 'Urgent'?"

"Not a problem," Jerry responded, "let me just have your name and number, and we'll take care of it."

I gave him a few more details and felt pretty happy that helpdesk was actually helpful. Five minutes after I hung up, an email message came in:

[URGENT] TICKET #71248 HAS BEEN ASSIGNED TO YOU

Not a moment later, my phone rang. I hesitantly picked it up.

"Hello is this Paul," the caller asked before I could even say Hello. I affirmed that it was me.

"Paul," he said, "this is Steve over at help desk. We've got an Urgent trouble ticket that just came in. It's for a, uh, Fortix feed defect. We just wanted to make sure you're on it?"

It took me a few minutes to explain to Steve that he was, in fact, assigning me the defect I had just reported.

Before you laugh too hard at the above story – it’s not that far removed from what many IT departments do daily – play the blame game. The user calls a problem into the help desk, then assigns it to the network. The network calls the helpdesk to tell them that it’s a problem with the server, and the server team calls the help desk to tell them it’s the application. If you’re lucky, someone along that chain will know how to fix the problem, but even if you are lucky, it’s still a lot of wasted time and energy.

This line from Manish Chacko’s article, “God Help the Help Desk” sums it up:

Imagine a man walking into a hospital, saying that he doesn't feel good, and doctors around the country are immediately called in, starting with the cardiologist, who rules out heart trouble. The man is next wheeled to a podiatrist, who rules out any problems with his feet. He's then wheeled to a gynecologist (But I'm a man... Ma'am, I'm a doctor. I think I should make that determination - and only after the tests come back.) If your diagnostic process is trial by error, you're not, technically, diagnosing.

This is why Dr. Jim Metzler recommended time and time again that application development and network operations merge into a single “application delivery” team. The primary job of IT is to deliver an application. Focusing on the performance your single group misses the point – it’s how the applications perform that is most important, and hardware, software, and networking are all part of that performance equation.

By Kevin Davis
Adapted from “Sources of Latency” Whitepaper

When network users call the Help Desk to report poor application performance, you don’t typically hear things like “The router’s CPU is too busy!,” “The network utilization is above 70%!,” or “The carrier path has failed-over to a sub-optimal path.” Instead, what you’re likely to hear is “The network is slow” or “The calls on my IP phone sound terrible.”

Complaints that end-users lodge are nearly always based their quality of experience using the application. And their quality of experience is almost always reliant on time.

Anytime a significant delay occurs in the delivery of network data, application performance suffers. Depending on the type of application and how it works, variances in network delay can have a severe impact on application performance thereby degrading end-user’s experiences.

Two important measurements of time intervals in network transmission systems are referred to as “latency” and “jitter”. Understanding latency and jitter sources and how their values vary in network architectures is critical to engineering application performance and optimizing information resources. For many regular readers, this will be old-hat, but we’ll go over it again.

Network latency is the amount of time it takes for a packet to be transmitted end-to-end across a network and is composed of five variables:

Network Latency = (Distance Delay) + (Serialization Delay) + (Queue Delay) + (Forwarding Delay) + (Protocol Delay)

Serialization Delay refers to the amount of time it takes for a network interface (such as a router’s interface or computer’s NIC) to perform bitwise transmission of a frame unto the outbound media, Forwarding Delay is the amount of time it takes a network device to process a frame/packet by performing a destination address lookup and forwarding the frame/packet to the outbound interface, and Protocol Delay is the amount of time that access or transmission algorithms may contribute to the delay of a network frame, and is typically introduced at the endpoints of the data transmission system.

Serialization delay, on a per-packet basis, becomes insignificant at data rates above 1.544 Mbits/s – or a T1. Forwarding delay is typically insignificant in modern routers and switches (when appropriately configured – significant delay can occur in misconfigured routers.) And Protocol delay typically occurs at the access layer or the end points. So the two major variables that have the most effect on network latency are Distance Delay and Queue Delay.

Distance Delay is simply the minimum amount of time that it takes the electrical signals that represent bits to travel down the physical wire. Optical cable sends bits at about ~5.5 µs/km, copper cable sends it at ~5.606 µs/km, and satellite sends bits at ~3.3 µs/km. (There are a few additional microseconds of delay from amplifying repeaters in optical cable, but compared to distance, the delay is negligible.)

Distance delay can have a significant impact on application performance for applications that require a large number of network round trips in order to complete a transaction – for example, custom transactional based applications, database queries, and VoIP, which begins do degrade when one-way end-to-end latency exceeds 200-220 milliseconds.

One of the biggest sources of end-user ire are database queries designed to run over a LAN ported to the WAN. For example if a user executes a SQL database query that requests 100 rows of a database table, one row at a time, over a link with a latency due to distance of 60 ms, it would take approximately 6 seconds (60 ms * 100 turns) to complete the transaction. The same query executed by a user on a LAN connected to the same database server would take less than 2-3 ms to be completed, as the latency due to distance across the LAN is insignificant.

Queue Delay is the amount of time a packet must spend in a network buffer waiting its turn to be transmitted. Network interfaces transmit one frame at a time, typically one bit at a time. As such, when two or more packets are forwarded to a network interface at the same time, or close to the same time – one packet is transmitted while the others are put in a queue on the interface buffer to await their turn at the interface. Packets that are put into the queue must wait until they can be transmitted, adding milliseconds of delay.

Increases in Queue Delay can be measured and detected by monitoring traffic along a given network path. Typically, most intermittent increases in latency above the baseline distance latency can be attributed to network congestion. (In order to reduce the possibility of excessive queue delay, application servers that are members of the same application architecture should be placed on the same Ethernet switch and on the same VLAN to ensure they do not have to compete for uplink bandwidth when problems like the one pictured above occur.)

Worse still, if the problem gets worse and packets wait in increasingly longer lines within the queue, the buffer may become full and the packets may be dropped. Packet drop, in turn, causes TCP connections to throttle back on the rate of transmission.

Those are some of the main causes of latency – but what about jitter?

Jitter is a term that refers to the variance in the arrival rate of packets from the same data flow, and abnormal jitter values can negatively impact real-time applications like VoIP and video. Jitter is typically created by three different mechanisms in a network: variance in Serialization Delays due to variance in packet sizes, variance in per-packet Queue Delay due to packet spacing from multiple sources at a common outbound interface, or packets taking different routes from source to destination – perhaps due to per-packet load sharing or routing issues.

The most effective way to deal with jitter is by using low-latency queuing for VoIP and video traffic on network interfaces with large serialization and/or queue delays. In addition, endpoints (such as IP phones) can use jitter buffers or playout delay buffers in order to deliver received packets at a constant rate to the end consumer. These buffers are typically 30-50 ms in depth, and thus they attempt to manage jitter values within these values on any single one-way path. While these buffers technically add 30-50ms in latency, they significantly reduce jitter. Since human beings don’t start to notice latency in VoIP or VideoIP applications till it hits about 200ms, if latency can be kept to under 150 milliseconds, then jitter can be significantly reduced using this method.

By Ben Erwin

Even the WAN optimization vendors are starting to realize that WAN optimization’s utility is diminished without visibility into the network.

Riverbed’s recent announcement shows that they, (and other WAN optimization and acceleration vendors), are recognizing the dependency between better network management and successful WAN optimization projects. The partner vendors mentioned in the announcement all provide some level of network management capabilities, from network configuration to application delivery monitoring. These partnerships are part of a growing trend since network management capabilities are critical to understanding WAN optimization’s ROI and impact on network performance.

In addition to third-party partnerships, WAN optimization vendors have also developed their own technology to improve integration with network management vendors. Riverbed, Juniper, Cisco, and Blue Coat (Packeteer) have all developed traffic flow export capabilities within their WAN optimization appliances to help customers better understand WAN optimization’s impact on application flows. For example, a large insurance brokerage company exports traffic flow records from Riverbed appliances to NetQoS ReporterAnalyzer to help visualize changes to volume, rate, and bandwidth utilization for every application on the optimized link. This flow export alongside ReporterAnalyzer provides the customer with continued visibility across the link for future troubleshooting, traffic analysis, or capacity planning efforts.

While traffic flow and per application bandwidth utilization information is critical to managing application delivery, it’s only part of the story. The other part is measuring latency of mission critical applications between remote sites and the data center – a more tangible metric of WAN optimization’s ROI and impact on the end-user experience. This measurement can be nearly impossible to obtain since WAN optimization appliances obfuscate application transactions between clients and servers, breaking up the TCP stream.

In order to get around the broken TCP stream problem, we at NetQoS entered into a partnership with Cisco to provide unique technology which measures end-to-end latency over Cisco Wide Area Application Services (WAAS) optimized WAN connections. By integrating our NetQoS SuperAgent technology, WAAS users can get client and server-side data collection and reporting capabilities.

To our knowledge, Cisco and NetQoS currently provide the market’s only solution for accurate latency measurements for client and server communication over optimized links.

WAN optimization is all about improving application delivery. Collecting volume, rate, and bandwidth utilization on optimized applications is only part of the solution. Truly understanding ROI on WAN optimization requires accurately measuring network latency and the end-user experience.

Ben Erwin is technical marketing manager at NetQoS and on Tuesday, May 27, 2008, he will be presenting a Webinar on Building Performance-first Application Delivery Networks with Cisco and NetQoS.

Kevin Davis, a senior consultant at NetQoS, will be presenting a few training sessions at Symposium about SuperAgent, the end-to-end response time module of the NetQoS Performance Center. This will include a training session about how to use time-based network metrics in troubleshooting.  He talks about his upcoming training session below.

In the session, I’m going to be covering the importance of using a time-based metric in troubleshooting, because end-users complain foremost about time.  For example, they’ll say “the application is running slow,” or they believe “the network is slow.”  To users, everything is based on time, that’s what they’re complaining about.  And they’re correct.

It’s very new to many people to think of performance in “time” although that may seem counterintuitive - because most people are used to reading utilization graphs.  With utilization graphs, however, we don’t know if 70 or 80 or 90 percent utilization is necessarily impacting the user experience.  I mean, we buy networking equipment, routers, switches, firewalls, servers, and we want them to be highly – or efficiently - utilized.  Seeing high utilization could indicate a problem – or it could just indicate that you haven’t over-purchased.  So you can have a link at 90% utilization or a router at ninety percent CPU utilization but you won’t know if that’s impacting the end-user without a time based metric.

It’s time-based data that tells you how the users are being impacted.  Sure, the utilization data – the interface utilization, memory utilization, I/O utilization, can often tell what is doing the impact.  But the time base shows you the degree of the impact – the real-world effect on end-users.  With a time-based instrument, such as NetQoS SuperAgent, you can find out where the delay increase is occurring, and whether it’s based in the network, server, or application. 

In fact, you can take a look at time-based data and make a determination very quickly as to which entity is creating the performance issue – the beautiful thing about SuperAgent, in particular, is that it trends by time 24/7, so not only can you determine how your important business applications are being impacted today, but you can go back and look at recurring patterns in performance issues.  You can see if today is worse than yesterday or last week or last month.

In the session, I’ll also be going over how to architect the data center for performance.  Placement of servers that participate in inter-architectures is critical for the health and performance of the application and indeed the data center.  We also talk about how different protocols, for example, Microsoft’s TCP/IP stack, can impact application performance by enhancing or degrading it. 

It’s important for servers that are serving the same application.  For example, a front-end Web server and a back-end Oracle database really should be on the same switch on the same VLAN.  That way they receive optimum service from the network.  If they do leave the switch, they’ll have to contend with bandwidth going up and down the switch links, and they’ll be switched and routed multiple times. 

Based on measurements from customer environments and from our own laboratories, when two servers are on different switches they can have up to 18 milliseconds delay between them.  If we think of that in the terms of network engineers of one millisecond per 100 miles, what in effect we’re doing when we put two different servers on different switches, or two different VLANs on the same switch, we’re making it look like those servers are 1800 miles apart – like one server is in Los Angeles and the other is in Memphis.