Pushing the bulk of UHD-3.7.0 code.

6 files changed, 452 insertions, 49 deletions

diff --git a/host/docs/CMakeLists.txt b/host/docs/CMakeLists.txt
index 0163a5c20..1ee0f1ade 100644
--- a/host/docs/CMakeLists.txt
+++ b/host/docs/CMakeLists.txt
@@ -40,6 +40,7 @@ SET(manual_sources
     usrp_b200.rst
     usrp_e1x0.rst
     usrp_x3x0.rst
+    usrp_x3x0_config.rst
 )
 
 ########################################################################
diff --git a/host/docs/build.rst b/host/docs/build.rst
index 5512e71ae..f53a56d9b 100644
--- a/host/docs/build.rst
+++ b/host/docs/build.rst
@@ -14,9 +14,11 @@ the dependencies should be available in the package repositories for your
 package manager.
 
 **Mac OS X Notes:**
-Install the "Xcode Developer Tools" to get the build tools (GCC and Make).
+Install the Xcode app to get the build tools (GCC and Make).
 Use MacPorts to get the Boost and Cheetah dependencies.
-Other dependencies can be downloaded as DMG installers from the web.
+Other dependencies can be downloaded as DMG installers from the web
+or installed via MacPorts. 
+See the UHD OS X page for more information: http://code.ettus.com/redmine/ettus/projects/uhd/wiki/UHD_OS_X 
 
 **Windows Notes:**
 The dependencies can be acquired through installable EXE files.
@@ -148,11 +150,6 @@ or add it to **/etc/ld.so.conf** and make sure to run:
 
     sudo ldconfig
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Setup the library path (Mac OS X)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Make sure that **libuhd.dylib** is in your **DYLD_LIBRARY_PATH**.
-
 ------------------------------------------------------------------------
 Build Instructions (Windows)
 ------------------------------------------------------------------------
@@ -220,3 +217,12 @@ Post-Install Tasks
 For USB-based devices,
 see the `USB Transport Application Notes <./transport.html#usb-transport-libusb>`_
 for platform-specific post-installation tasks.
+
+------------------------------------------------------------------------
+Post-Install Tasks (Mac OS X)
+------------------------------------------------------------------------
+Make sure that the value of **CMAKE_INSTALL_PREFIX** is at or near the 
+front of the shell **PATH** environment variable.  Do **NOT** set 
+DYLD_LIBRARY_PATH or any related DYLD environment variable 
+permanently; these work differently than under Linux and should be 
+used for testing / temporary purposes only. 
diff --git a/host/docs/general.rst b/host/docs/general.rst
index 01d0f270c..930c18188 100644
--- a/host/docs/general.rst
+++ b/host/docs/general.rst
@@ -1,16 +1,16 @@
-========================================================================
+===============================
 UHD - General Application Notes
-========================================================================
+===============================
 
 .. contents:: Table of Contents
 
-------------------------------------------------------------------------
+------------
 Tuning Notes
-------------------------------------------------------------------------
+------------
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^
 Two-stage tuning process
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^
 A USRP device has two stages of tuning:
 
 * RF front-end: translates bewteen RF and IF
@@ -40,7 +40,7 @@ performance. The daughterboards that support this functionality are:
 * CBX-120
 
 Tuning the receive chain:
-::
+:::::::::::::::::::::::::
 
     //tuning to a desired center frequency
     usrp->set_rx_freq(target_frequency_in_hz);
@@ -49,15 +49,15 @@ Tuning the receive chain:
 
     //advanced tuning with tune_request_t
     uhd::tune_request_t tune_req(target_frequency_in_hz, desired_lo_offset);
-    tune_req.args = uhd::device_addr_t("mode_n=int-n"); //to use Int-N tuning
+    tune_req.args = uhd::device_addr_t("mode_n=integer"); //to use Int-N tuning
     //fill in any additional/optional tune request fields...
     usrp->set_rx_freq(tune_req);
 
 More information can be found in `tune_request.hpp <./../../doxygen/html/structuhd_1_1tune__request__t.html>`_.
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^
 RF front-end settling time
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^
 After tuning, the RF front-end will need time to settle into a usable state.
 Typically, this means that the local oscillators must be given time to lock
 before streaming begins.  Lock time is not consistent; it varies depending upon
@@ -66,6 +66,8 @@ should wait for the **lo_locked** sensor to become true or sleep for
 a conservative amount of time (perhaps a second).
 
 Pseudo-code for dealing with settling time after tuning on receive:
+:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
+
 ::
 
     usrp->set_rx_freq(...);
@@ -80,9 +82,10 @@ Pseudo-code for dealing with settling time after tuning on receive:
     }
     usrp->issue_stream_command(...);
 
-------------------------------------------------------------------------
+
+-------------------------------
 Specifying the Subdevice to Use
-------------------------------------------------------------------------
+-------------------------------
 A subdevice specification string for USRP family devices is composed of:
 
 ::
@@ -109,16 +112,16 @@ Ex: The subdev spec markup string to select a BasicRX on slot B.
 
     B:B
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 USRP Family Motherboard Slot Names
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 All USRP family motherboards have a first slot named **A:**.  The USRP1 has
 two daughterboard subdevice slots, known as **A:** and **B:**.  
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Daughterboard Frontend Names
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Daughterboard frontend names can be used to specify which signal path is used
 from a daughterboard.  Most daughterboards have only one frontend **:0**.  A few
@@ -126,15 +129,15 @@ daughterboards (Basic, LF and TVRX2) have multiple frontend names available.
 The frontend names are documented in the 
 `Daughterboard Application Notes <./dboards.html>`_
 
-------------------------------------------------------------------------
+------------------------
 Overflow/Underflow Notes
-------------------------------------------------------------------------
+------------------------
 **Note:** The following overflow/underflow notes do not apply to USRP1,
 which does not support the advanced features available in newer products.
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^
 Overflow notes
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^
 When receiving, the device produces samples at a constant rate.
 Overflows occurs when the host does not consume data fast enough.
 When UHD software detects the overflow, it prints an "O" or "D" to stdout,
@@ -157,21 +160,21 @@ If the device was in continuous streaming mode,
 the UHD software will automatically restart streaming when the buffer has
 space again.
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^
 Underflow notes
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^
 When transmitting, the device consumes samples at a constant rate.
 Underflow occurs when the host does not produce data fast enough.
 When UHD software detects the underflow, it prints a "U" to stdout,
 and pushes a message packet into the async message stream.
 
-------------------------------------------------------------------------
+---------------
 Threading Notes
-------------------------------------------------------------------------
+---------------
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^
 Thread safety notes
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^
 For the most part, UHD software is thread-safe.
 Please observe the following limitations:
 
@@ -188,9 +191,9 @@ This is because changing one setting could have an impact on how a call affects
 Example: setting the channel mapping affects how the antennas are set.
 It is recommended to use at most one thread context for manipulating device settings.
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^
 Thread priority scheduling
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 When UHD software spawns a new thread it may try to boost the thread's scheduling priority.
 When setting the priority fails, the UHD software prints out an error.
@@ -200,29 +203,29 @@ This error is harmless; it simply means that the thread will have a normal sched
 
 Non-privileged users need special permission to change the scheduling priority.
 Add the following line to **/etc/security/limits.conf**:
-::
+::::::::::::::::::::::::::::::::::::::::::::::::::::::::
 
     @<my_group>    -    rtprio    99
 
 Replace **<my_group>** with a group to which your user belongs.
 Settings will not take effect until the user is in a different login session.
 
-------------------------------------------------------------------------
+-------------------
 Miscellaneous Notes
-------------------------------------------------------------------------
+-------------------
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Support for dynamically loadable modules
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 For a module to be loaded at runtime, it must be:
 
 * found in the **UHD_MODULE_PATH** environment variable,
 * installed into the **<install-path>/share/uhd/modules** directory,
 * or installed into **/usr/share/uhd/modules** directory (UNIX only).
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Disabling or redirecting prints to stdout
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 The user can disable the UHD library from printing directly to stdout by registering a custom message handler.
 The handler will intercept all messages, which can be dropped or redirected.
 Only one handler can be registered at a time.
diff --git a/host/docs/index.rst b/host/docs/index.rst
index cbab651c1..ffad1488d 100644
--- a/host/docs/index.rst
+++ b/host/docs/index.rst
@@ -32,7 +32,7 @@ General UHD Manuals
 USRP N-Series Devices
 ^^^^^^^^^^^^^^^^^^^^^
 * `USRP-N2x0 Series Device Manual <./usrp2.html>`_
-* `USRP-N2x0 Internal GPSDO Device Manual <./gpsdo_x3x0.html>`_
+* `USRP-N2x0 Internal GPSDO Device Manual <./gpsdo.html>`_
 
 ^^^^^^^^^^^^^^^^^^^^^
 USRP B-Series Devices
@@ -53,6 +53,7 @@ USRP X-Series Devices
 * `USRP-X3x0 Series Device Manual <./usrp_x3x0.html>`_
 * `USRP-X3x0 Internal GPSDO Device Manual <./gpsdo_x3x0.html>`_
 * `USRP-X3x0 Front Panel GPIO API <./gpio_api.html>`_
+* `USRP-X3x0 System Configuration <./usrp_x3x0_config.html>`_
 
 ^^^^^^^^^^^^^^^^^^^^^
 USRP Legacy Series
diff --git a/host/docs/usrp_x3x0.rst b/host/docs/usrp_x3x0.rst
index 058230b5a..3b7e9914e 100644
--- a/host/docs/usrp_x3x0.rst
+++ b/host/docs/usrp_x3x0.rst
@@ -9,7 +9,7 @@ Comparative features list
 -------------------------
 
 **Hardware Capabilities:**
- * 2 transceiver card slots
+ * 2 transceiver card slots (can do 2x2 MIMO out of the box)
  * Dual SFP+ Transceivers (can be used with 1 GigE, 10 GigE)
  * PCI Express over cable (MXI) gen1 x4
  * External PPS input & output
@@ -29,6 +29,89 @@ Comparative features list
  * 16-bit and 8-bit sample modes (sc8 and sc16)
  * Up to 120 MHz of RF bandwidth with 16-bit samples
 
+---------------
+Getting started
+---------------
+
+This will run you through the first steps relevant to get your USRP X300/X310
+up and running. Here, we assume you will connect your USRP using Gigabit Ethernet (1GigE),
+as this interface is readily available in most computers. For 10 Gigabit Ethernet (10GigE) or
+PCI Express (PCIe), see the corresponding sections in this manual page.
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Assembling the X300/X310 kit
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Before you can start using your USRP, you might have to assemble the hardware,
+if this has not yet happened. Make sure you are grounded (e.g. by touching a radiator)
+in order not to damage sensitive electronics through static discharge!
+
+1. Unscrew the top of your X300/X310 (there are 2 screws which can be easily loosened
+   using a small Phillips screwdriver).
+2. Insert the daughterboards by inserting them into the slots and optionally screwing
+   them onto the motherboard.
+3. Connect the RF connectors on the daughterboards to the front panel. In order to avoid
+   confusion, make sure the internal connections match the labels on the front panel (i.e.
+   TX/RX is connected to TX/RX).
+4. If you have purchased an internal GPSDO, follow the instructions on
+   `the internal GPSDO manual page <./gpsdo_x3x0.html>`_ to insert the GPSDO. Note that you
+   will need an external GPS antenna connected to the rear GPS ANT connector in order to
+   make use of GPS, although your USRP will still be usable without.
+5. Connect the 1 GigE SFP+ transceiver into the Ethernet port 0 and connect the X300/X310 with
+   your computer.
+6. Connect the power supply and switch on the USRP.
+
+^^^^^^^^^^^^^^^^^^^^
+Network Connectivity
+^^^^^^^^^^^^^^^^^^^^
+
+The next step is to make sure your computer can talk to the USRP. An otherwise unconfigured
+USRP device will have the IP address 192.168.10.2 when using 1GigE.
+It is recommended to directly connect your USRP to the computer at first,
+and to set the IP address on your machine to 192.168.10.1.
+See Section `Setup the host interface`_ on details how to change your machine's IP address.
+
+**Note**: If you are running an automatic IP configuration service such as Network Manager, make
+sure it is either deactivated or configured to not change the network device! This can, in extreme cases,
+lead to you bricking the USRP!
+
+If your network configuration is correct, running ``uhd_find_devices`` will find your USRP
+and print some information about it. You will also be able to ping the USRP by running::
+
+  ping 192.168.10.2
+
+on the command line. At this point, you should also run::
+
+  uhd_usrp_probe --args addr=192.168.10.2
+
+to make sure all of your components (daughterboards, GPSDO) are correctly detected and usable.
+
+^^^^^^^^^^^^^^^^^^^^^
+Updating the firmware
+^^^^^^^^^^^^^^^^^^^^^
+
+If the output from ``uhd_find_devices`` and ``uhd_usrp_probe`` didn't show any warnings, you
+can skip this step. However, if there were warnings regarding version incompatibility, you will
+have to upate the FPGA image before you can start using your USRP.
+
+1. Download the current UHD images. You can use the ``uhd_images_downloader`` script provided
+   with UHD (see also `FPGA Image Flavors`_).
+2. Use the ``usrp_x3xx_fpga_burner`` utility to update the FPGA image. On the command line, run::
+
+          usrp_x3xx_fpga_burner --addr=192.168.10.2 --type=HGS # Since we are using 1GigE, type is HGS
+
+  If you have installed the images to a non-standard location, you might need to run (change the filename according to your device)::
+
+          usrp_x3xx_fpga_burner --addr=192.168.10.2 --fpga-path <path_to_images>/usrp_x310_fpga_HGS.bit
+
+  The process of updating the firmware will take several minutes. Make sure the process of flashing the image does not get interrupted.
+
+See `Load the Images onto the On-board Flash`_ for more details.
+
+When your firmware is up to date, power-cycle the device and re-run ``uhd_usrp_probe``. There should
+be no more warnings at this point, and all components should be correctly detected. Your USRP is now
+ready for development!
+
 --------------
 Hardware Setup
 --------------
@@ -40,7 +123,7 @@ Gigabit Ethernet (1 GigE)
 Installing the USRP X300/X310
 :::::::::::::::::::::::::::::
 * Prior to installing the module, the host PC can remain powered on.
-* Plug a 1 Gigabit SFP+ Transceiver into Ethernet Port 0 on the USRP X300/x310 device.
+* Plug a 1 Gigabit SFP Transceiver into Ethernet Port 0 on the USRP X300/X310 device.
 * Use the Ethernet cable to connect the SFP+ transciever on the device to the host computer. For maximum throughput, Ettus Research recommends that you connect each device to its own dedicated Gigabit Ethernet interface on the host computer.
 * Connect the AC/DC power supply to the device and plug the supply into a wall outlet.
 * The OS will automatically recognize the device (e.g. when running uhd_find_devices).
@@ -195,7 +278,7 @@ To get the latest images, simply use the uhd_images_downloader script:
 
 ::
 
-    uhd_images_downloader
+    sudo uhd_images_downloader
 
 **Windows:**
 
@@ -223,7 +306,13 @@ Use JTAG to load FPGA images
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 The USRP-X Series device features an on-board USB-JTAG programmer that can be accessed on the front-panel
 of the device. The iMPACT tool in the `Xilinx Programming Tools <http://www.xilinx.com/support/download/index.htm>`_ package can be used to load an image over
-the JTAG interface.
+the JTAG interface. This can be useful for unbricking devices.
+
+If you have iMPACT installed, you can use the impact_jtag_programmer.sh tool to install images. Make sure your X3x0 is powered on and connected to your computer using the front panel USB JTAG connector (USB 2.0 is fine for this). Then run the tool:
+
+::
+
+    <path_to_uhd_tools>/impact_jtag_programmer.sh --fpga-path=<fpga_image_path>
 
 ---------------------------------------
 Load the Images onto the On-board Flash
@@ -276,8 +365,8 @@ Use the burner tool over PCI Express
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Device recovery and bricking
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-It is possible to put the device into an unusable state by loading bad images.
-Fortunately, the USRP-X Series device can be loaded with a good image temporarily using the USB-JTAG interface. 
+It is possible to put the device into an unusable state by loading bad images ("bricking").
+Fortunately, the USRP-X Series device can be loaded with a good image temporarily using the USB-JTAG interface.
 Once booted into the safe image, the user can once again load images onto the device over Ethernet or PCI Express.
 
 ----------------
@@ -541,6 +630,13 @@ Monitor the host network traffic
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Use Wireshark to monitor packets sent to and received from the device.
 
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Observe Ethernet port LEDs
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+When there is network traffic arriving at the Ethernet port, LEDs will light up.
+You can use this to make sure the network connection is correctly set up, e.g.
+by pinging the USRP and making sure the LEDs start to blink.
+
 --------------
 Hardware Notes
 --------------
diff --git a/host/docs/usrp_x3x0_config.rst b/host/docs/usrp_x3x0_config.rst
new file mode 100644
index 000000000..9cb000275
--- /dev/null
+++ b/host/docs/usrp_x3x0_config.rst
@@ -0,0 +1,296 @@
+========================================================================
+UHD - System Configuration for USRP X3x0 Series
+========================================================================
+
+.. contents:: Table of Contents
+
+------------------------------------------------------------------------
+Configuring your Host PC
+------------------------------------------------------------------------
+
+The USRP X3x0 is capable of delivering very fast sample rates to the host PC,
+and even high-powered desktops can have trouble keeping up at the higher rates.
+You can improve the performance of your host by configuring a number of
+settings that affect the performance of your computer.
+
+These are:
+
+ * Kernel Version
+ * Network Configuration
+ * Power Management Configuration
+ * Real-Time & Priority Scheduling
+ * Building with ORC & Volk
+
+These items are covered in more detail, below.
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Kernel Version
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Performance issues may be encountered with Linux kernels earlier than 3.11.
+Ettus Research strongly recommends using kernel version 3.11 or higher for high
+sample rates.
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Network Configuration
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+When using Ethernet interfaces to communicate with the device, it is necessary
+to configure a number of facets regarding your network connection.
+
+Configuring NetworkManager
+-------------------------------------
+Fedora and Ubuntu both use NetworkManager to manage network connections.
+Unfortunately, NetworkManager often tries to take control of a connection and
+will disconnect the interface.
+
+You should open your NetworkManager configuration and tell it to ignore the
+network interface you are using. **This is not the same as simply setting
+a static IP address.** You *must* tell NetworkManager to ignore the interface.
+
+Configuring the Socket Buffers
+-------------------------------------
+It is necessary to increase the maximum size of the socket buffers to avoid
+potential overflows and underruns at high sample rates.  Add the following
+entries into /etc/sysctl.conf (root privileges required):
+
+::
+
+    net.core.rmem_max=33554432
+    net.core.wmem_max=33554432
+
+Either restart the system or issue the following commands:
+
+::
+
+    sudo sysctl -w net.core.rmem_max=33554432
+    sudo sysctl -w net.core.wmem_max=33554432
+
+
+Configuring the MTU
+-------------------------------------
+In order to achieve maximum performance, we recommend setting the MTU size to
+9000 for 10 GigE and 1500 for 1 GigE. It is possible to use smaller MTUs, but this
+can affect performance. With some NICs, setting the MTU too high can also cause issues,
+though. To set the MTU to 9000, you can use the following command:
+
+::
+
+    sudo ifconfig <interface> mtu 9000 # For 10 GigE
+
+Using these MTUs will set the frame sizes for UHD communication to 8000 and 1472,
+respectively.
+
+In some cases, specifying the frame size manually by adding the argument
+"<send/recv>_frame_size=1472" can solve issues. Note that a frame size of 1472 will limit
+the available sampling rate, although this is likely not a problem issue on 1 GigE.
+
+
+Configuring the Firewall
+-------------------------------------
+Many Linux distributions come installed with a Firewall, by default. The
+Firewall will often interfere with your ability to communicate with your USRP.
+You should configure your firewall to "trust" the interface you are using.
+Setting this properly depends on your OS and firewall configuration method.
+
+Interface Configuration File (Fedora)
+-------------------------------------
+On Fedora systems, you can configure the network interface mostly from one
+place (with the exception of the socket buffers). Each interface on your system
+should have a file in:
+
+::
+
+    /etc/sysconfig/network-scripts/
+
+As an example, if your 1GigE interface is "em1", your "ifcfg-em1" configuration
+file should look something like this, when configured for use with a USRP X3xx:
+
+::
+
+    TYPE="Ethernet"
+    BOOTPROTO="none"
+    IPADDR0="192.168.10.1"
+    DEFROUTE="yes"
+    IPV4_FAILURE_FATAL="no"
+    IPV6INIT="no"
+    IPV6_FAILURE_FATAL="no"
+    NAME="em1"
+    UUID="<specific to your device>"
+    ONBOOT="no"
+    HWADDR"<specific to your device>"
+    PEERDNS="yes"
+    PEERROUTES="yes"
+    ZONE="trusted"
+    MTU="9000"
+    NM_MANAGED="no"
+
+The above file was generated and modified on a "Fedora 20" system.
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Power Management
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Power management on the host system attempts to save power by reducing clock
+frequencies or even powering off devices while not in use.  This can lead to
+significant performance issues when trying to operate at high sample rates.
+Ettus Research strongly recommends disabling all power management.
+
+
+Setting the CPU Governors
+-------------------------------------
+In Linux, the CPU governors dictate the frequency at which the CPU operates and
+attempt to reduce the CPU frequencies at certain times to save power.  When
+running at high sample rates, reduction of CPU frequencies can cause
+significant performance issues.  To prevent those issues, set the governor to
+"performance".
+
+**Ubuntu:**
+1. Install cpufrequtils:
+
+::
+
+    sudo apt-get install cpufrequtils
+
+2. Edit /etc/init.d/cpufrequtils and set GOVERNOR="performance" on the appropriate line (run as root):
+
+::
+
+    sed s/^GOVERNOR=.*$/GOVERNOR=\"performance\"/g /etc/init.d/cpufrequtils > /etc/init.d/cpufrequtils
+
+3. Restart cpufrequtils:
+
+::
+
+    sudo /etc/init.d/cpufrequtils restart
+
+**Fedora:**
+
+::
+
+    sudo cpupower frequency-set -g performance
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Real-Time & Priority Scheduling
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Enabling real-time and priority scheduling can improve the total processing
+throughput of your application. Priority scheduling should be enabled for UHD,
+and real-time scheduling can be enabled by your application.
+
+Thread Priority Scheduling with UHD
+-------------------------------------
+For information regarding how to enable priority scheduling for UHD on your
+system, please see the `General UHD Notes <./general.html#threading-notes>`_.
+
+Real-Time Scheduling in your Application
+----------------------------------------
+Please note that turning on real-time scheduling in your application **may lock
+up your computer** if the processor cannot keep up with the application. You
+should generally avoid using real-time scheduling unless you need to.
+
+Real-time scheduling is enabled via different methods depending on your
+application and operating system. In GNU Radio Companion, it can be turned on in
+each individual flowgraph.
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Building with ORC & Volk
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Especially when running high-performance applications, processing performance
+can be dramatically improved by SIMD instructions. UHD uses ORC to provide SIMD
+capability, and GNU Radio includes a SIMD library called "Volk". These should
+both be used to guarantee optimum performance.
+
+Compiling UHD with ORC
+-------------------------------------
+ORC, the `Oil Runtime Compiler <http://code.entropywave.com/orc/>`_, is
+a third-party compiler that UHD uses to create efficient SIMD code for your
+particular computer. ORC is generally easily installed from your OS's package
+manager.
+
+On Fedora:
+
+::
+
+    $ sudo yum update; sudo yum install orc-compiler orc-devel
+
+On Ubuntu:
+
+::
+
+    $ sudo apt-get update; sudo apt-get install liborc-<version> liborc-<version>-dev
+
+After installing ORC, when building UHD from source, you should see "ORC" as
+one of the configured UHD components.
+
+::
+
+    -- ######################################################
+    -- # UHD enabled components                              
+    -- ######################################################
+    --   * LibUHD
+         <cut for brevity>
+    --   * ORC
+
+Compiling GNURadio with Volk
+-------------------------------------
+If you are using GNURadio to build applications, you should compile GNURadio
+with Volk. For instructions on how to do this, `refer to the GNURadio wiki
+<http://gnuradio.org/redmine/projects/gnuradio/wiki/Volk>`_.
+
+
+------------------------------------------------------------------------
+Host PC Hardware Selection
+------------------------------------------------------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Motherboard
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Testing has shown that some motherboards do not provide enough PCIe bus
+bandwidth to support higher sample rates.  Motherboards with PCIe 3.0 are
+required and the PCIe architecture of the motherboard should be carefully
+considered.  Slots with dedicated PCIe lanes should be used for PCIe or 10GbE
+cards that will be connected to the X3x0 device.
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+10GbE NIC
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Intel or Myricom 10GbE NICs are recommended.  Mellanox, SolarFlare, and Chelsio
+10GbE NICs are not currently recommended.  The Ethernet card should be plugged
+into the slot that has the most direct connection with the CPU (PCIe lanes are
+not shared with another slot).  Refer to the motherboard manual for more
+information on PCIe architecture.
+
+------------------------------------------------------------------------
+Troubleshooting Performance Issues
+------------------------------------------------------------------------
+The output on the host console provides indicators of performance issues in the
+form of single upper-case letters.  The following table lists the letters,
+their meanings, and possible causes:
+
+========= ====================== ====================================================================
+Indicator Meaning                Possible Causes
+========= ====================== ====================================================================
+O         Overflow on RX         - Data is not being consumed by user's application fast enough.
+                                 - CPU governor or other power management not configured correctly.
+D         Dropped packet on RX   - Network hardware failure.  (Check host NIC, cable, switch, etc...)
+                                 - PCIe bus on host cannot sustain throughput. (Check ethtool -S <interface>).
+                                 - CPU governor or other power management not configured correctly.
+                                 - Frame size might not work with the current NIC's MTU.
+U         Underflow on TX        - Samples are not being produced by user's application fast enough.
+                                 - CPU governor or other power management not configured correctly.
+L         Late packet            - Samples are not being produced by user's application fast enough.
+          (usually on MIMO TX)   - CPU governor or other power management not configured correctly.
+                                 - Incorrect/invalid time_spec provided.
+S         Sequence error on TX   - Network hardware failure.  (Check host NIC, cable, switch, etc...)
+                                 - Frame size might not work with the current NIC's MTU.
+========= ====================== ====================================================================
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Troubleshooting Ethernet Issues
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+1. First, check 'ifconfig <interface>' to see if there are any errors reported
+   on the interface.  If there are errors, it is most likely a network hardware
+   problem.
+2. Next, check the output of 'ethtool -S <interface>'.  The output is
+   driver-specific, but may give important clues as to what may be happening.
+   For example, a high value on rx_missed_errors for an Intel NIC indicates
+   that the bus (i.e. PCIe) is not keeping up.
+3. Finally, Wireshark can be used to validate the traffic between the host and
+   device and make sure there is no unwanted traffic on the interface.
+