Jump to content, skipping navigation

Spirent Logo

Support

  • What are you Testing?

    Networks

    • 40/100 GbE
    • Cloud Computing
    • Data Centers and Enterprise Networks
    • In-Home Networks
    • IPv6
    • Multiplay
    • Network Impairments
    • Infrastructure Test Optimization


    • CDMA EV/DO
    • LTE
    • Mobile Backhaul
    • Mobile Packet Core
    • UMTS

    Applications

    • Ethernet Services on Live Networks
    • Security
    • Triple Play Services on Live Networks
    • Video and IPTV
    • Voice and IMS
  • What are you Testing?

    Mobile devices

    1
    A-GNSS/A-GPS/A-GLONASS
    CDMA/EV-DO Devices
    Certification/Conformance
    Hybrid GNSS/Wi-Fi/Cellular Location Technology
    LTE & Multi-Mode Device Development
    LTE Devices
    MIMO
    2
    Mobility inter-RAT
    MIMO OTA Testing
    GPS/A-GPS OTA Testing
    Radio Access Performance
    UMTS Devices
    Wireless Receiver

    Network equipment

    • Access
    • Basestation Receivers
    • Firewall
    • Automation
    • Router/Switch
    • Router/Switch (Service Provider)
    • Server
  • What are you interested in?

    Technologies

    • Multi-GNSS Simulation
    • GNSS Simulators
    • GPS Simulation
    • GPS Modernization
    • Galileo Simulators
    • GLONASS Simulators
    • GPS/GNSS Augmentation
    • Beidou/Compass
    • Wi-Fi Positioning
    • Record & Playback

    Solutions for

    • R&D
    • Integration
    • Verification
    • Production Line

    Sectors

    • Military & Defense
    • GPS SAASM
    • GPS Vulnerability
    • GPS Inertial Navigation
    • Transport
    • Automotive
    • Telematics
    • Road Tolling
    • Rail
    • Civil Aviation
    • Space
    • Mobile Devices
    • Telecom & Wireless
    • Chipset & Technology
  • Spirent Products

    Networks & Applications

    • 8100 Location Technology
    • 8100 LTE
    • Abacus
    • Avalanche
    • C2K-ATS
    • DLS
    • GEM
    • Landslide
    • SmartSight Central
    • Spirent Anue 3500
    • Spirent INE
    • Spirent iTest
    • Spirent TestCenter
    • Spirent TestCenter Live
    • SR5500
    • Tech-X Flex
    • Spirent NoCode
    • VR5

    Mobile Devices & Network Equipment

    • 8100 Location Technology
    • 8100 LTE
    • 8100 UMTS
    • Abacus
    • AirAccess
    • Avalanche
    • AX/4000
    • C2K-ATS
    • CS8 Wireless Device Design Tester
    • DLS
    • GEM
    • GSS5700
    • Landslide
    • Spirent Anue 3500
    • Spirent iTest
    • Spirent TestCenter
    • Spirent TestCenter Live
    • SR5500
    • Spirent NoCode
    • VR5

    Positioning & Navigation

    • GSS4200
    • GSS5700
    • GSS6300
    • GSS6400
    • GSS6700
    • GSS7735
    • GSS7765
    • GSS7790
    • GSS8000
    • SimAUTO
    • SimINERTIAL
    • SimPLEX45

    Spirent Global Services

    Support, Education and Professional Services
    • About Spirent
    • Lab Links
    • Tested with Spirent
    • Contact us
    • News Room
    • Spirent Social Hub
    • Events
    • Spirent Webinars
    • Spirent Blog
    • RSS Feeds
    • Partnerships & Alliances
    • Investors
    • Board Committees
    • Careers
    • Corporate Governance
    • Ethics Policy
    • PG Drives Technology

Networks blog

Spirent Blogs

  • Networks blog   RSS Feed
  • Wireless blog   RSS Feed
  • Positioning blog   RSS Feed

Latest Posts

  • Manage Upcoming Leap Seconds Insertion

    Stuart Smith

  • Creating an Industry-First Performance Test: Validating a “super-class” platform

    Chris Chapman

  • Mobile Device Designers: You Can Relax Now – Part 1

    Mike McKernan

  • View all latest posts

Most Popular Posts

  • Creating an Industry-First Performance Test: Validating a “super-class” platform

    Chris Chapman

  • Metrics for Network Performance

    Ankur Chadda, Spirent

  • Top Five Test Issues of the Mobile Internet Revolution

    Ross Cassan

You are here:
Home >
Tested with Spirent Blog >
Networks blog >
Testing 10G Data Center Switches: Scaling 10 Times Higher
<Back to Networks blog

Testing 10G Data Center Switches: Scaling 10 Times Higher

If there’s one overarching conclusion I’ve drawn from three months of testing 10-gigabit top-of-rack data center switches, it’s that “switch” and “data center switch” are very different beasts.

Understanding the latter means testing new features like virtualization support and storage/data network convergence, while also driving unicast and multicast scalability benchmarking to new heights.

In a project recently published in Network World, we compared switches from six vendors, each with at least 24 10-gigabit Ethernet ports. We compared products in 10 areas: features; usability; power consumption; MAC address capacity; forward pressure; multicast group capacity; multicast group join/leave delay; link aggregation hashing fairness; and, of course, basic unicast and multicast performance.

Performance testing remains as important as ever, if not more so, when it comes to data center switching. That’s an important point: Buyers are interested in these new features, to be sure, but only in addition to switches’ long-time role as fast packet pushers.

In other words, the same industry-standard methods of benchmarking switching and routing performance (as defined in RFCs 2544, 2889 and 3918) remain vitally important in the context of data center switching. In fact, line-rate performance and low latency and jitter are even more important for many data center applications than for general-purpose enterprise networking.

Data center switches tend to have much longer features lists than their wiring-closet counterparts. We paid special attention to three areas. First is redundancy protocols. Some data center switches offer new methods to connect multiple servers and/or switches. Some methods even eliminate slower redundancy protocols, such as spanning tree. Others offer “active/active” connectivity across multiple links until a failure occurs, boosting bandwidth in a way that “active/standby” protocols such as spanning tree cannot. While new protocols are intriguing, it’s a good idea to test their resiliency and benchmark failover times before deploying them in your network.

Second, some switches allow the convergence of previously separate storage and data networks using technologies such as Fibre Channel or Fibre Channel over Ethernet (FCoE) on the same switch. The IEEE has defined several new protocols to accommodate the FCoE’s stringent delay and loss requirements. We didn’t test these protocols this time, since only one switch tested supported all these new mechanisms, but look forward to comparing data/storage performance in upcoming tests.

Finally, data center switches support virtualization in a variety of ways. Since virtual machines (VMs) often move between physical hosts in the data center, some switches offer the ability to have the VMs’ access control policies move with them. Other switches can carve up physical interfaces to appear as multiple logical links to different sets of VMs. And some support end-to-end management of physical and virtual switches, offering the same set of capabilities for both.

I’m looking forward to future tests comparing Fibre Channel and FCoE performance as well as even larger-scale tests of large modular data center systems. We’re still in the early days of data center switch testing, and things will only get bigger from here.

Newman is president of Network Test, an independent test lab and engineering services consultancy. He can be reached at dnewman@networktest.com.

Posted: Jan 18, 2010. Author: David Newman, Network Test (comments 5)

Next post

Previous Post

Comments

  1. Hi,

    In this test, you tested 108 byte frames. Just out of curiousity, why 108 byte? I'm thinking it has something to do with TCP acks, but I can't make the math work.

    Chris McCoy
    Posted: 21 Jan 2010 2:55 PM

  2. Given more space and time I would have run a sweep test to measure throughput, latency and jitter for *every* frame size between 64 and 9216 bytes. A switch should handle any frame thrown at it.

    Since we didn't have infinite resources, I included only a couple more sizes beyond the seven standard lengths from RFC 2544+jumbos.

    A major stock exchange runs an application that makes heavy use of 108-byte frames. That's why I chose that particular length.

    I've seen issues with 65-byte frames multiple times with multiple vendors' switches.

    As it turned out results for both 65- and 108-byte frames were unremarkable for all switches, so much so that we only printed numbers for 64-, 256-, 1518- and 9216-byte frames.

    Hope this answers your question. I really would have liked to have run the sweep test, as it sometimes turns up "tuning for benchmarks" problems where switches do great with the standard lengths but not at all great with a few other sizes.

    David Newman
    Posted: 21 Jan 2010 4:00 PM

  3. Given more space and time I would have run a sweep test to measure throughput, latency and jitter for *every* frame size between 64 and 9216 bytes. A switch should handle any frame thrown at it.

    Since we didn't have infinite resources, I included only a couple more sizes beyond the seven standard lengths from RFC 2544+jumbos.

    A major stock exchange runs an application that makes heavy use of 108-byte frames. That's why I chose that particular length.

    I've seen issues with 65-byte frames multiple times with multiple vendors' switches.

    As it turned out results for both 65- and 108-byte frames were unremarkable for all switches, so much so that we only printed numbers for 64-, 256-, 1518- and 9216-byte frames.

    Hope this answers your question. I really would have liked to have run the sweep test, as it sometimes turns up "tuning for benchmarks" problems where switches do great with the standard lengths but not at all great with a few other sizes.

    David Newman
    Posted: 22 Jan 2010 1:20 PM

  4. Given more space and time I would have run a sweep test to measure throughput, latency and jitter for *every* frame size between 64 and 9216 bytes. A switch should handle any frame thrown at it.

    Since we didn't have infinite resources, I included only a couple more sizes beyond the seven standard lengths from RFC 2544+jumbos.

    A major stock exchange runs an application that makes heavy use of 108-byte frames. That's why I chose that particular length.

    I've seen issues with 65-byte frames multiple times with multiple vendors' switches.

    As it turned out results for both 65- and 108-byte frames were unremarkable for all switches, so much so that we only printed numbers for 64-, 256-, 1518- and 9216-byte frames.

    Hope this answers your question. I really would have liked to have run the sweep test, as it sometimes turns up "tuning for benchmarks" problems where switches do great with the standard lengths but not at all great with a few other sizes.

    David Newman
    Posted: 22 Jan 2010 1:26 PM

  5. Thanks For You're Input It Is Much Appreciated. Iam glad to help.

    Bryan
    Posted: 28 Mar 2010 7:28 PM

Post a Comment

* Indicates required field

Share this:
    • Tweet
  • Email to Friend
  • Create PDF

 

Register to talk with David Newman:

10 Things About 10Gig in the Data Center

Presenters:
David Newman from Network Test

Dates and Times:
Wednesday, March 10, 2010
10:30AM IST / 1:00PM CST

Thursday, March 11, 2010
11:00 AM PST / 2:00 PM EST

Duration:
60 minutes

Join David Newman and Network Test in a complementary webinar. Learn more about the recent Network World top-of-rack test and find out how the various switch vendors were tested and how they ranked.

Be sure to register and get a chance to win your Spirent TestCenter Virtual System!

Register to attend

Search Blogs

  • Contact us
  • Careers
  • Terms and Conditions
  • Sitemap
  • Resource Library
  • www.spirent.cn

© 2012 Spirent Communications