Jumbo Packets

  • 1
  • Question
  • Updated 4 years ago
  • Answered
  • (Edited)
Does the 6000 series network adapter support "Jumbo" packets, and if so, would there be any value (or risk) in using the larger network packet size in a wired network where the PC NIC also supports jumbo?

Photo of George Molnar, KF2T

George Molnar, KF2T, Elmer

  • 1590 Posts
  • 555 Reply Likes

Posted 4 years ago

  • 1
Photo of Tim - W4TME

Tim - W4TME, Customer Experience Manager

  • 9152 Posts
  • 3478 Reply Likes
The network interface in the FLEX-6000 can support different packet MTUs.  However, to support jumbo frames, both the network and the client hardware would have to support jumbo frames and be configured to use them.  This significantly complicates the network configuration and subsequently makes supporting it problematic.

In general, the advantage provided by jumbo frames is the reduction of CPU overhead for TCP processing and to achieve an increase network throughput.  The FLEX-6000 employs a "thin pipe" architecture, meaning that the network bandwidth consumption is significantly less than with other direct sampling radios that offload processing on the PC.  From an ROI standpoint, there is no real application-level benefit for supporting them in the customer network vs. the additional support overhead expense.  
Photo of K6OZY

K6OZY, Elmer

  • 532 Posts
  • 198 Reply Likes
Ah, The big Jumbo Debate.    This topic comes up very often in my circles by various admins trying to "tweak" things.  Jumbo frames really only play a benefit when you are approaching network saturation.   The goal of jumbo frames is to get rid of overhead to leave room for more datagram payload.  When looking at the VITA49 format, the specification does allow for a variable length data payload, so you may think that increasing frame size could help.

In most time-sensitive applications, this is not the case.  Very much like changing the cluster size of a disk, if you change your MTU, you now have bigger chunks flying around.   This causes increased latency per frame exchange.  

If you run wireshark and examine the data coming from the Flex, you can see that most VITA 49 frames are around 500 bytes in size on average and vary to as low as 86 bytes and as high as 900 bytes, well under the 1500 byte MTU.   This means increasing the MTU would be bad.

 If a latency-sensitive packet ends up being queued up behind a full-size frame for access to the medium, it takes 6x as long to get on the medium if that full-size frame is a 9kB jumbo frame rather than a standard 1500 Byte frame.

If a latency-sensitive protocol (i.e. VITA49) used jumbo frames and tried to fill them up for bandwidth efficiency's sake, the delivery of first bytes of the frame would be delayed greatly while waiting for the last bytes of the frame to be constructed, before the frame can be sent onto the wire. For perhaps a worst-case example, some high-efficiency voice codecs can use a 2kbps bitrate, so a single 9k frame could be about 36 seconds of speech. Imagine having 36 seconds of lag in a VoIP call because this.

A 9kB jumbo frame is 6x as large as the largest standard Ethernet frames, which are 1500 Bytes. So at the same bit error rate, jumbo frames have a 6x higher chance of having an error, and when an error happens, the whole 6x larger frame has to be retransmitted.   

Also, if you ever forget that you reconfigured a few hosts or ports to use jumbo frames and stick non jumbo devices on it,  you won't immediately see an issue.   You will start getting packet loss.   It will drive you crazy to diagnose it if you don't quickly remember why.

In general, Jumbo frames can be considered on 10G+ networks when using storage, such as NFS, CIFS, or iSCSI on NAS arrays, or vMotion on VMware.  Larger frames can reduce CPU overhead a bit if that becomes an issue, but with advanced NICs ,that is usually handled by offloading the workload from the CPU.

TL;DR - Not recommended in our use case.
Photo of George Molnar, KF2T

George Molnar, KF2T, Elmer

  • 1590 Posts
  • 555 Reply Likes
Curiosity officially satisfied! Thanks, guys.