[USRP-users] USRP-users Digest, Vol 62, Issue 27

Giovanni MARINO giovanni.marino at jrc.ec.europa.eu
Thu Oct 29 11:33:28 EDT 2015


Hi
Obviously it isn't the complete code, which is the following one:

#!/usr/bin/env python2
##################################################
# GNU Radio Python Flow Graph
# Title: Top Block
# Generated: Wed Sep 30 15:13:48 2015
##################################################


if __name__ == '__main__':
    import ctypes
    import sys
    if sys.platform.startswith('linux'):
        try:
            x11 = ctypes.cdll.LoadLibrary('libX11.so')
            x11.XInitThreads()
        except:
            print "Warning: failed to XInitThreads()"


from PyQt4 import Qt
from gnuradio import blocks
from gnuradio import eng_notation
from gnuradio import gr
from gnuradio import uhd
from gnuradio.eng_option import eng_option
from gnuradio.filter import firdes
from optparse import OptionParser
from datetime import datetime
import sys
import time
import platform
import os




class top_block(gr.top_block, Qt.QWidget):


    def __init__(self):
        gr.top_block.__init__(self, "Top Block")
        Qt.QWidget.__init__(self)
        self.setWindowTitle("Top Block")
        try:
             self.setWindowIcon(Qt.QIcon.fromTheme('gnuradio-grc'))
        except:
             pass
        self.top_scroll_layout = Qt.QVBoxLayout()
        self.setLayout(self.top_scroll_layout)
        self.top_scroll = Qt.QScrollArea()
        self.top_scroll.setFrameStyle(Qt.QFrame.NoFrame)
        self.top_scroll_layout.addWidget(self.top_scroll)
        self.top_scroll.setWidgetResizable(True)
        self.top_widget = Qt.QWidget()
        self.top_scroll.setWidget(self.top_widget)
        self.top_layout = Qt.QVBoxLayout(self.top_widget)
        self.top_grid_layout = Qt.QGridLayout()
        self.top_layout.addLayout(self.top_grid_layout)


        self.settings = Qt.QSettings("GNU Radio", "top_block")
        self.restoreGeometry(self.settings.value("geometry").toByteArray())


        ##################################################
        # Variables
        ##################################################
        self.samp_rate = samp_rate = 250000


        ##################################################
        # Blocks
        ##################################################
        self.uhd_usrp_source_0 = uhd.usrp_source(
        	",".join(("", "")),
        	uhd.stream_args(
        		cpu_format="fc32",
        		channels=range(1),
        	),
        )
        gps_time=self.uhd_usrp_source_0.get_mboard_sensor("gps_time",0).to_int()
        timestamp1 = time.mktime(datetime.now().timetuple())
        print "Timenow", timestamp1
        print "GPS time", gps_time
        start_time='28.10.2015 12:25:00'
        start_time = time.mktime(time.strptime(start_time,'%d.%m.%Y %H:%M:%S'))
        self.uhd_usrp_source_0.set_start_time(uhd.time_spec_t(start_time))
        print "Start time:",str(uhd.time_spec_t(start_time).get_real_secs())
        self.uhd_usrp_source_0.set_samp_rate(samp_rate)
        self.uhd_usrp_source_0.set_center_freq(162e6, 0)
        self.uhd_usrp_source_0.set_gain(25, 0)
        self.uhd_usrp_source_0.set_antenna("TX/RX", 0)
        self.uhd_usrp_source_0.set_bandwidth(60000, 0)
        mboard_name=platform.node()
        Date=time.strftime("%c")
        #print Date
        Filediscr=mboard_name+Date[0:3]+Date[4:6]+Date[7:10]+Date[11:15]+Date[16:18]+Date[19:21]+Date[22:24]
        #print Filediscr
        if not os.path.isdir("./Files"):
             os.makedirs("./Files")
        Strdir="./Files/Datafrom"
        StrdirGPSfile="./Files/GPSepoch"
        Fnlstr=".dat"
        FnlstrGPSfile=".txt"
        filename=Strdir+Filediscr+Fnlstr
        filenameGPS=StrdirGPSfile+Filediscr+FnlstrGPSfile
        self.blocks_file_sink_0 = blocks.file_sink(gr.sizeof_gr_complex*1,filename, False)
        self.blocks_file_sink_0.set_unbuffered(False)
        f = open(filenameGPS, "w" )
        f.write("GPS Epoch = " + repr(gps_time) + "\n" )
        f.close()
        #current_t=self.uhd_usrp_source_0.get_time_now();
        #print current_t
        ##################################################
        # Connections
        ##################################################
        self.connect((self.uhd_usrp_source_0, 0), (self.blocks_file_sink_0, 0))    


    def closeEvent(self, event):
        self.settings = Qt.QSettings("GNU Radio", "top_block")
        self.settings.setValue("geometry", self.saveGeometry())
        event.accept()


    def get_samp_rate(self):
        return self.samp_rate


    def set_samp_rate(self, samp_rate):
        self.samp_rate = samp_rate
        self.uhd_usrp_source_0.set_samp_rate(self.samp_rate)




if __name__ == '__main__':
    parser = OptionParser(option_class=eng_option, usage="%prog: [options]")
    (options, args) = parser.parse_args()
    from distutils.version import StrictVersion
    if StrictVersion(Qt.qVersion()) >= StrictVersion("4.5.0"):
        Qt.QApplication.setGraphicsSystem(gr.prefs().get_string('qtgui','style','raster'))
    qapp = Qt.QApplication(sys.argv)
    tb = top_block()
    tb.start()
    tb.show()


    def quitting():
        tb.stop()
        tb.wait()
    qapp.connect(qapp, Qt.SIGNAL("aboutToQuit()"), quitting)
    qapp.exec_()
    tb = None  # to clean up Qt widgets
##################################################################################################################################




I have to synchronize the N210 with several others usrp, therefore I need to understand how to start the acquisition at a fixed time. 
I considered as model of my program the following code I found in the usrp list:



        gps_lock=self.uhd_usrp_source_0.get_mboard_sensor("gps_locked",0)
     
        if gps_lock.to_bool() == False:
            print "!!!!!No GPS sync!!!!!"
        else:
        #initialization of USRP's internal clock to gps_time
            #find moment of impulse on pps line
            last_pps_time = self.uhd_usrp_source_0.get_time_last_pps()
            while last_pps_time.get_real_secs() ==
self.uhd_usrp_source_0.get_time_last_pps().get_real_secs():
                time.sleep(0.1)


            #get current gps_time
            gps_time=self.uhd_usrp_source_0.get_mboard_sensor("gps_time",0)
            #set the gps_time+1 on the next pps edge
           
self.uhd_usrp_source_0.set_time_next_pps(uhd.time_spec(gps_time.to_int()+1))
            last_pps_time = self.uhd_usrp_source_0.get_time_last_pps()
            #wait for change to take effect
            while last_pps_time.get_real_secs() ==
self.uhd_usrp_source_0.get_time_last_pps().get_real_secs():
                time.sleep(0.1)


        if self.start_time != "":
            #parse self_start_time into time since epoch
            self.start_time =
time.mktime(time.strptime(self.start_time,'%d.%m.%Y %H:%M:%S'))
            #set start of reception
           
self.uhd_usrp_source_0.set_start_time(uhd.time_spec_t(self.start_time))


##########################################################################################
The problem that I got, despite the the following output:

Timenow 1446132281.0
GPS time 1446132281
Start time: 1446132420.0
when the start time epoch is reached, the file where I should save the raw data doesn't change size (i.e. it is always equal to zero). 
Thank you again for any suggestion.
Giovanni






On 10/28/15, usrp-users-request at lists.ettus.com wrote:
> 
> Send USRP-users mailing list submissions to
> 	usrp-users at lists.ettus.com
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> or, via email, send a message with subject or body 'help' to
> 	usrp-users-request at lists.ettus.com
> 
> You can reach the person managing the list at
> 	usrp-users-owner at lists.ettus.com
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of USRP-users digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: about 10 Gig ethernet configuration (Marcus M?ller)
>    2. Re: Precise transmit control of X310 (Marcus M?ller)
>    3. Re: B200mini Series: some general questions (Derek Kozel)
>    4. Re: Installing PCIE drivers for x310 (Martin Braun)
>    5. Re: Installing PCIE drivers for x310 (James Humphries)
>    6. Re: Installing PCIE drivers for x310 (Jared Dulmage)
>    7. Re: Installing PCIE drivers for x310 (James Humphries)
>    8. Re: Installing PCIE drivers for x310 (Jared Dulmage)
>    9. Re: Installing PCIE drivers for x310 (James Humphries)
>   10. Re: Installing PCIE drivers for x310 (Jared Dulmage)
>   11. Re: look for gfortran (=?gbk?B?wfW6o8zO?=)
>   12. Re: look for gfortran (Chris Kuethe)
>   13. Re: look for gfortran (=?gbk?B?wfW6o8zO?=)
>   14. Re: Precise transmit control of X310 (Carel Combrink)
>   15. Sell USRP & Complete Daughterboard (Anak Galer)
>   16. Error in x300 generation fpga bit file (mojtaba rostami)
>   17. Re: Installing PCIE drivers for x310 (Marcus M?ller)
>   18. Re: Precise transmit control of X310 (Marcus M?ller)
>   19. Problem with N210 and start GPS time (Giovanni MARINO)
>   20. Re: Problem with N210 and start GPS time (Marcus D. Leech)
>   21. Re: roundtrip delay with x310 and RIO express card interface
>       (Lecoq Yann)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 27 Oct 2015 18:16:17 +0100
> From: Marcus M?ller <marcus.mueller at ettus.com>
> To: usrp-users at lists.ettus.com
> Subject: Re: [USRP-users] about 10 Gig ethernet configuration
> Message-ID: <562FB161.4080608 at ettus.com>
> Content-Type: text/plain; charset="windows-1252"
> 
> That's a trick worth keeping! Thanks.
> 
> On 10/27/2015 04:18 PM, Peter Witkowski via USRP-users wrote:
> > We were having similar issues on our end.
> >
> > I ended up needing to maximize the number of descriptors used by the
> > Intel driver.  Dropped packets (Ds) went away totally.
> >
> > Here's the command (where ethN is the connection to your USRP):
> > ethtool -G ethN rx 4096 tx 4096
> >
> > -Pete Witkowski
> >
> > On Mon, Oct 26, 2015 at 4:05 AM, Michael West via USRP-users
> > <usrp-users at lists.ettus.com <mailto:usrp-users at lists.ettus.com <usrp-users at lists.ettus.com>>> wrote:
> >
> >     Hi Sanjoy,
> >
> >     I agree with Marcus.  It looks like the governor is not working. 
> >     The performance governor should be setting the CPU frequency to
> >     its highest value.
> >
> >     Try setting the frequency by running:
> >     > cpufreq-set -r -f 3200000000
> >     or setting the min frequency by running:
> >     > cpufreq-set -r -d 3200000000
> >
> >     Regards,
> >     Michael
> >
> >     On Mon, Oct 26, 2015 at 12:43 AM, Sanjoy Basak
> >     <sanjoybasak14 at gmail.com <mailto:sanjoybasak14 at gmail.com <sanjoybasak14 at gmail.com>>> wrote:
> >
> >         Hi Michael,
> >         The OS is native. Ubuntu 14.4.3. 
> >
> >
> >         On Mon, Oct 26, 2015 at 9:37 AM, Michael West
> >         <michael.west at ettus.com <mailto:michael.west at ettus.com <michael.west at ettus.com>>> wrote:
> >
> >             Is the OS native or are you using a virtual machine?
> >
> >             On Sun, Oct 25, 2015 at 1:30 PM, Marcus M?ller
> >             <marcus.mueller at ettus.com
> >             <mailto:marcus.mueller at ettus.com <marcus.mueller at ettus.com>>> wrote:
> >
> >                 Hm, that looks as if the CPU governor doesn't actually
> >                 do its job...
> >
> >                 On 25.10.2015 17:44, Sanjoy Basak wrote:
> >>                 Hi Marcus,
> >>                 Thanks for the reply.
> >>
> >>                 I tried this 
> >>                 sudo sysctl -w net.core.wmem_max = 536870912
> >>                 sudo sysctl -w net.core.rmem_max = 536870912
> >>
> >>                 Now 
> >>                 net.core.rmem_max = 536870912
> >>                 net.core.wmem_max = 536870912
> >>
> >>                 Even now it shows drop at 25 MSps as previous.
> >>
> >>                 I tried cpufreq-info again. It's always at
> >>                 performance. However, the cpu freq at different core
> >>                 is different. I am also putting the output here. Is
> >>                 it making any issue? Should the cpufreq at each core
> >>                 be at maximum?
> >>
> >>                 analyzing CPU 0:
> >>                   driver: intel_pstate
> >>                   CPUs which run at the same hardware frequency: 0
> >>                   CPUs which need to have their frequency coordinated
> >>                 by software: 0
> >>                   maximum transition latency: 0.97 ms.
> >>                   hardware limits: 1.20 GHz - 3.20 GHz
> >>                   available cpufreq governors: performance, powersave
> >>                   current policy: frequency should be within 1.20 GHz
> >>                 and 3.20 GHz.
> >>                                   The governor "performance" may
> >>                 decide which speed to use
> >>                                   within this range.
> >>                   current CPU frequency is 1.85 GHz.
> >>                 analyzing CPU 1:
> >>                   driver: intel_pstate
> >>                   CPUs which run at the same hardware frequency: 1
> >>                   CPUs which need to have their frequency coordinated
> >>                 by software: 1
> >>                   maximum transition latency: 0.97 ms.
> >>                   hardware limits: 1.20 GHz - 3.20 GHz
> >>                   available cpufreq governors: performance, powersave
> >>                   current policy: frequency should be within 1.20 GHz
> >>                 and 3.20 GHz.
> >>                                   The governor "performance" may
> >>                 decide which speed to use
> >>                                   within this range.
> >>                   current CPU frequency is 2.24 GHz.
> >>                 analyzing CPU 2:
> >>                   driver: intel_pstate
> >>                   CPUs which run at the same hardware frequency: 2
> >>                   CPUs which need to have their frequency coordinated
> >>                 by software: 2
> >>                   maximum transition latency: 0.97 ms.
> >>                   hardware limits: 1.20 GHz - 3.20 GHz
> >>                   available cpufreq governors: performance, powersave
> >>                   current policy: frequency should be within 1.20 GHz
> >>                 and 3.20 GHz.
> >>                                   The governor "performance" may
> >>                 decide which speed to use
> >>                                   within this range.
> >>                   current CPU frequency is 2.25 GHz.
> >>                 analyzing CPU 3:
> >>                   driver: intel_pstate
> >>                   CPUs which run at the same hardware frequency: 3
> >>                   CPUs which need to have their frequency coordinated
> >>                 by software: 3
> >>                   maximum transition latency: 0.97 ms.
> >>                   hardware limits: 1.20 GHz - 3.20 GHz
> >>                   available cpufreq governors: performance, powersave
> >>                   current policy: frequency should be within 1.20 GHz
> >>                 and 3.20 GHz.
> >>                                   The governor "performance" may
> >>                 decide which speed to use
> >>                                   within this range.
> >>                   current CPU frequency is 2.77 GHz.
> >>                 analyzing CPU 4:
> >>                   driver: intel_pstate
> >>                   CPUs which run at the same hardware frequency: 4
> >>                   CPUs which need to have their frequency coordinated
> >>                 by software: 4
> >>                   maximum transition latency: 0.97 ms.
> >>                   hardware limits: 1.20 GHz - 3.20 GHz
> >>                   available cpufreq governors: performance, powersave
> >>                   current policy: frequency should be within 1.20 GHz
> >>                 and 3.20 GHz.
> >>                                   The governor "performance" may
> >>                 decide which speed to use
> >>                                   within this range.
> >>                   current CPU frequency is 2.18 GHz.
> >>                 analyzing CPU 5:
> >>                   driver: intel_pstate
> >>                   CPUs which run at the same hardware frequency: 5
> >>                   CPUs which need to have their frequency coordinated
> >>                 by software: 5
> >>                   maximum transition latency: 0.97 ms.
> >>                   hardware limits: 1.20 GHz - 3.20 GHz
> >>                   available cpufreq governors: performance, powersave
> >>                   current policy: frequency should be within 1.20 GHz
> >>                 and 3.20 GHz.
> >>                                   The governor "performance" may
> >>                 decide which speed to use
> >>                                   within this range.
> >>                   current CPU frequency is 1.95 GHz.
> >>                 analyzing CPU 6:
> >>                   driver: intel_pstate
> >>                   CPUs which run at the same hardware frequency: 6
> >>                   CPUs which need to have their frequency coordinated
> >>                 by software: 6
> >>                   maximum transition latency: 0.97 ms.
> >>                   hardware limits: 1.20 GHz - 3.20 GHz
> >>                   available cpufreq governors: performance, powersave
> >>                   current policy: frequency should be within 1.20 GHz
> >>                 and 3.20 GHz.
> >>                                   The governor "performance" may
> >>                 decide which speed to use
> >>                                   within this range.
> >>                   current CPU frequency is 2.12 GHz.
> >>                 analyzing CPU 7:
> >>                   driver: intel_pstate
> >>                   CPUs which run at the same hardware frequency: 7
> >>                   CPUs which need to have their frequency coordinated
> >>                 by software: 7
> >>                   maximum transition latency: 0.97 ms.
> >>                   hardware limits: 1.20 GHz - 3.20 GHz
> >>                   available cpufreq governors: performance, powersave
> >>                   current policy: frequency should be within 1.20 GHz
> >>                 and 3.20 GHz.
> >>                                   The governor "performance" may
> >>                 decide which speed to use
> >>                                   within this range.
> >>                   current CPU frequency is 2.39 GHz.
> >>                 analyzing CPU 8:
> >>                   driver: intel_pstate
> >>                   CPUs which run at the same hardware frequency: 8
> >>                   CPUs which need to have their frequency coordinated
> >>                 by software: 8
> >>                   maximum transition latency: 0.97 ms.
> >>                   hardware limits: 1.20 GHz - 3.20 GHz
> >>                   available cpufreq governors: performance, powersave
> >>                   current policy: frequency should be within 1.20 GHz
> >>                 and 3.20 GHz.
> >>                                   The governor "performance" may
> >>                 decide which speed to use
> >>                                   within this range.
> >>                   current CPU frequency is 2.53 GHz.
> >>                 analyzing CPU 9:
> >>                   driver: intel_pstate
> >>                   CPUs which run at the same hardware frequency: 9
> >>                   CPUs which need to have their frequency coordinated
> >>                 by software: 9
> >>                   maximum transition latency: 0.97 ms.
> >>                   hardware limits: 1.20 GHz - 3.20 GHz
> >>                   available cpufreq governors: performance, powersave
> >>                   current policy: frequency should be within 1.20 GHz
> >>                 and 3.20 GHz.
> >>                                   The governor "performance" may
> >>                 decide which speed to use
> >>                                   within this range.
> >>                   current CPU frequency is 2.79 GHz.
> >>                 analyzing CPU 10:
> >>                   driver: intel_pstate
> >>                   CPUs which run at the same hardware frequency: 10
> >>                   CPUs which need to have their frequency coordinated
> >>                 by software: 10
> >>                   maximum transition latency: 0.97 ms.
> >>                   hardware limits: 1.20 GHz - 3.20 GHz
> >>                   available cpufreq governors: performance, powersave
> >>                   current policy: frequency should be within 1.20 GHz
> >>                 and 3.20 GHz.
> >>                                   The governor "performance" may
> >>                 decide which speed to use
> >>                                   within this range.
> >>                   current CPU frequency is 2.24 GHz.
> >>                 analyzing CPU 11:
> >>                   driver: intel_pstate
> >>                   CPUs which run at the same hardware frequency: 11
> >>                   CPUs which need to have their frequency coordinated
> >>                 by software: 11
> >>                   maximum transition latency: 0.97 ms.
> >>                   hardware limits: 1.20 GHz - 3.20 GHz
> >>                   available cpufreq governors: performance, powersave
> >>                   current policy: frequency should be within 1.20 GHz
> >>                 and 3.20 GHz.
> >>                                   The governor "performance" may
> >>                 decide which speed to use
> >>                                   within this range.
> >>                   current CPU frequency is 2.21 GHz.
> >>
> >>
> >>                 Best regards
> >>                 Sanjoy
> >>
> >>                 On Sun, Oct 25, 2015 at 10:22 AM, Marcus M?ller
> >>                 <marcus.mueller at ettus.com
> >>                 <mailto:marcus.mueller at ettus.com <marcus.mueller at ettus.com>>> wrote:
> >>
> >>                     Hi Sanjoy,
> >>
> >>                     Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
> >>                     eth2 9000 0 1084 0 0 0 1153 0 0 0 BMRU
> >>
> >>
> >>                     You get 1153 packets that were dropped due to not
> >>                     being picked up on RX side.
> >>                     I was first not quite sure who really defines
> >>                     this value, whether it's the network hardware or
> >>                     the linux kernel itself, but after reading
> >>                     netstat code and linux kernel code, it seems that
> >>                     netstat kind of mislabels what is called
> >>                     "rx_fifo_errors" in the kernel as "RX-OVR". That
> >>                     didn't make things more intuitive researching
> >>                     (because of course there's also a overrun field
> >>                     in the stats struct in the netdev in the kernel... ).
> >>                     The good news: rx_fifo_errors is not something
> >>                     the Intel ixgbe driver modifies -- which means it
> >>                     doesn't seem to be a hardware counter on packets
> >>                     that weren't fetched from the card.
> >>
> >>                     So, could you share what
> >>
> >>                     sysctl net.core.rmem_max net.core.wmem_max   
> >>
> >>
> >>                     says? It's the maximum memory that your linux
> >>                     might allocate for receive and transmit buffers
> >>                     on the card.
> >>
> >>                     sudo sysctl -w net.core.rmem_max $(( 512 * 2**20 )) 
> >>                     sudo sysctl -w net.core.wmem_max $(( 512 * 2**20 )) 
> >>
> >>                     should set the sizes to 512MB (cave: only til
> >>                     next reboot). Could you try with that?
> >>
> >>                     Best regards,
> >>                     Marcus
> >>
> >>
> >>                     On 24.10.2015 18:28, Sanjoy Basak wrote:
> >>>                     Hi Marcus,
> >>>                     Thanks a lot for the quick reply. The kernel
> >>>                     version is 3.19.0-31-generic
> >>>
> >>>                     I just checked again at 30s, 25MSps. I got 4 D
> >>>                     and 5 D for 2 consecutive initiations.
> >>>
> >>>                     *@30sec*
> >>>
> >>>                     Setting RX Rate: 25.000000 Msps...
> >>>
> >>>                     Actual RX Rate: 25.000000 Msps...
> >>>
> >>>                     Setting RX Freq: 2000.000000 MHz...
> >>>
> >>>                     Actual RX Freq: 2000.000000 MHz...
> >>>
> >>>                     Waiting for "lo_locked": ++++++++++ locked.
> >>>
> >>>                     Press Ctrl + C to stop streaming...
> >>>
> >>>                     DGot an overflow indication. Please consider the
> >>>                     following:
> >>>
> >>>                     Your write medium must sustain a rate of
> >>>                     100.000000MB/s.
> >>>
> >>>                     Dropped samples will not be written to the file.
> >>>
> >>>                     Please modify this example for your purposes.
> >>>
> >>>                     This message will not appear again.
> >>>
> >>>                     DDDD
> >>>
> >>>                     Done!
> >>>
> >>>
> >>>                     *@240 sec*
> >>>
> >>>                     Setting RX Rate: 25.000000 Msps...
> >>>
> >>>                     Actual RX Rate: 25.000000 Msps...
> >>>
> >>>                     Setting RX Freq: 2000.000000 MHz...
> >>>
> >>>                     Actual RX Freq: 2000.000000 MHz...
> >>>
> >>>                     Waiting for "lo_locked": ++++++++++ locked.
> >>>
> >>>                     Press Ctrl + C to stop streaming...
> >>>
> >>>                     DGot an overflow indication. Please consider the
> >>>                     following:
> >>>
> >>>                     Your write medium must sustain a rate of
> >>>                     100.000000MB/s.
> >>>
> >>>                     Dropped samples will not be written to the file.
> >>>
> >>>                     Please modify this example for your purposes.
> >>>
> >>>                     This message will not appear again.
> >>>
> >>>                     DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
> >>>
> >>>                     Done!
> >>>
> >>>
> >>>                     This is the netstat right after restarting the
> >>>                     computer
> >>>
> >>>                     netstat -i eth2
> >>>
> >>>                     Kernel Interface table
> >>>
> >>>                     Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK
> >>>                     TX-ERR TX-DRP TX-OVR Flg
> >>>
> >>>                     eth0 1500 0 9 0 0 0 26 0 0 0 BMRU
> >>>
> >>>                     eth1 1500 0 0 0 0 0 0 0 0 0 BMU
> >>>
> >>>                     eth2 9000 0 1084 0 0 0 1153 0 0 0 BMRU
> >>>
> >>>                     lo 65536 0 177 0 0 0 177 0 0 0 L
> >>>
> >>>
> >>>                     And this is netstat after
> >>>
> >>>                     ./rx_samples_to_file --duration 240 --rate 200e6
> >>>                     --freq=2e9 --file /dev/null
> >>>
> >>>                     which gave a lot of D (did not count how many
> >>>                     but a lot)
> >>>
> >>>                     Kernel Interface table
> >>>
> >>>                     Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK
> >>>                     TX-ERR TX-DRP TX-OVR Flg
> >>>
> >>>                     eth0 1500 0 94 0 0 0 30 0 0 0 BMRU
> >>>
> >>>                     eth1 1500 0 0 0 0 0 0 0 0 0 BMU
> >>>
> >>>                     eth2 9000 0 24190524 936 0 0 355025 0 0 0 BMRU
> >>>
> >>>                     lo 65536 0 183 0 0 0 183 0 0 0 LRU
> >>>
> >>>
> >>>                     Best regards
> >>>
> >>>                     Sanjoy
> >>>
> >>>
> >>>
> >>>
> >>>                     On Sat, Oct 24, 2015 at 5:31 PM, Marcus M?ller
> >>>                     <marcus.mueller at ettus.com
> >>>                     <mailto:marcus.mueller at ettus.com <marcus.mueller at ettus.com>>> wrote:
> >>>
> >>>                         Hi Sanjoy,
> >>>
> >>>                         Two observations:
> >>>                         Your routing table looks fine.
> >>>
> >>>                         Then, these rx_samples... results are
> >>>                         interesting. Basically, 30s of 200MS/s are 8
> >>>                         times the amount of packets as 30s at
> >>>                         25MS/s; however the former produces 53
> >>>                         sequence errors, and the latter only 3.
> >>>                         That's off by a factor of 2. To verify,
> >>>                         could you try 240s at 25MS/s?
> >>>                         If this holds, the sequence errors would
> >>>                         seem to be load-related. Kernel version
> >>>                         currently used (uname -r)?
> >>>                         Let's analyze where things go missing. Could
> >>>                         you compare the output of "netstat -i eth2"
> >>>                         before and after a rx_samples_to_file run
> >>>                         that produced lots of D?
> >>>
> >>>                         Best regards,
> >>>                         Marcus
> >>>
> >>>
> >>>                         Am 24. Oktober 2015 15:58:28 MESZ, schrieb
> >>>                         Sanjoy Basak <sanjoybasak14 at gmail.com
> >>>                         <mailto:sanjoybasak14 at gmail.com <sanjoybasak14 at gmail.com>>>:
> >>>
> >>>                             Hi Micheal,
> >>>                             I made the cpu governor to performance.
> >>>                             This is always performance now, does not
> >>>                             change. We did not buy the cable from
> >>>                             ettus. 
> >>>                             We bought DeLOCK Twinaxial-Kabel SFP+ M
> >>>                             SFP+ M 3,0m SFF-8431 86222 from a store
> >>>                             here.
> >>>
> >>>                             Hi Rob,
> >>>                             Thanks for the command. I am not really
> >>>                             sure which cable you used. But I am
> >>>                             still having drop of packets. I don't
> >>>                             have any other cable right now to test. 
> >>>
> >>>
> >>>                             Hi Marcus,
> >>>                             I tried your suggestions. I put the
> >>>                             output here.
> >>>
> >>>                             *ip route *
> >>>
> >>>                             192.168.40.0/24 <http://192.168.40.0/24>
> >>>                             dev eth2 proto kernel scope link src
> >>>                             192.168.40.1 metric 1
> >>>
> >>>
> >>>                             I don't get any drop at this.
> >>>
> >>>                             rx_samples_to_file --rate 200e6 --file
> >>>                             /dev/null --nsamps $(( 2 * 1000  * 1000 ))
> >>>
> >>>                             Setting RX Rate: 200.000000 Msps...
> >>>
> >>>                             Actual RX Rate: 200.000000 Msps...
> >>>
> >>>                             Setting RX Freq: 0.000000 MHz...
> >>>
> >>>                             Actual RX Freq: 340.000000 MHz...
> >>>
> >>>                             Waiting for "lo_locked": ++++++++++ locked.
> >>>
> >>>                             Done!
> >>>
> >>>
> >>>                             However with
> >>>
> >>>                             ./rx_samples_to_file --duration 30
> >>>                             --rate 200e6 --freq=2e9 --file /dev/null
> >>>
> >>>                             Setting RX Rate: 200.000000 Msps...
> >>>
> >>>                             Actual RX Rate: 200.000000 Msps...
> >>>
> >>>                             Setting RX Freq: 2000.000000 MHz...
> >>>
> >>>                             Actual RX Freq: 2000.000000 MHz...
> >>>
> >>>                             Waiting for "lo_locked": ++++++++++ locked.
> >>>
> >>>                             Press Ctrl + C to stop streaming...
> >>>
> >>>                             DGot an overflow indication. Please
> >>>                             consider the following:
> >>>
> >>>                             Your write medium must sustain a rate of
> >>>                             800.000000MB/s.
> >>>
> >>>                             Dropped samples will not be written to
> >>>                             the file.
> >>>
> >>>                             Please modify this example for your
> >>>                             purposes.
> >>>
> >>>                             This message will not appear again.
> >>>
> >>>                             DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
> >>>
> >>>
> >>>                             Done!
> >>>
> >>>
> >>>                             Even at 25 MSps I got drop of packet
> >>>
> >>>                             ./rx_samples_to_file --duration 30
> >>>                             --rate 25e6 --freq=2e9 --file /dev/null
> >>>
> >>>                             Setting RX Rate: 25.000000 Msps...
> >>>
> >>>                             Actual RX Rate: 25.000000 Msps...
> >>>
> >>>                             Setting RX Freq: 2000.000000 MHz...
> >>>
> >>>                             Actual RX Freq: 2000.000000 MHz...
> >>>
> >>>                             Waiting for "lo_locked": ++++++++++ locked.
> >>>
> >>>                             Press Ctrl + C to stop streaming...
> >>>
> >>>                             DGot an overflow indication. Please
> >>>                             consider the following:
> >>>
> >>>                               Your write medium must sustain a rate
> >>>                             of 100.000000MB/s.
> >>>
> >>>                               Dropped samples will not be written to
> >>>                             the file.
> >>>
> >>>                               Please modify this example for your
> >>>                             purposes.
> >>>
> >>>                               This message will not appear again.
> >>>
> >>>                             DD
> >>>
> >>>                             Done!
> >>>
> >>>
> >>>                             But with  1 Gig interface with 25 MSps I
> >>>                             am not getting any drop
> >>>
> >>>                             ./rx_samples_to_file --duration 30
> >>>                             --rate 25e6 --freq=2e9 --file /dev/null
> >>>
> >>>                             Setting RX Rate: 25.000000 Msps...
> >>>
> >>>                             Actual RX Rate: 25.000000 Msps...
> >>>
> >>>                             Setting RX Freq: 2000.000000 MHz...
> >>>
> >>>                             Actual RX Freq: 2000.000000 MHz...
> >>>
> >>>                             Waiting for "lo_locked": ++++++++++ locked.
> >>>
> >>>                             Press Ctrl + C to stop streaming...
> >>>
> >>>                             Done!
> >>>
> >>>
> >>>                             I hope raid is not making an issue here,
> >>>                             as I don't see any indication when I
> >>>                             tried with 1 Gig interface.
> >>>
> >>>                             Please let me know from  seeing the
> >>>                             output what you think making the trouble. 
> >>>
> >>>
> >>>                             Best regards
> >>>                             Sanjoy
> >>>
> >>>
> >>>                             On Sat, Oct 24, 2015 at 1:48 AM, Michael
> >>>                             West <michael.west at ettus.com
> >>>                             <mailto:michael.west at ettus.com <michael.west at ettus.com>>> wrote:
> >>>
> >>>                                 I was corrected regarding the 10 GbE
> >>>                                 copper cables.  The long copper
> >>>                                 cables were failing our tests due to
> >>>                                 a bug in the IP used for the 10 GbE
> >>>                                 in the FPGA image that has since
> >>>                                 been resolved.  We are currently
> >>>                                 using cables up to 3m with no
> >>>                                 problems.  We have found some 5m
> >>>                                 cables work and some don't depending
> >>>                                 on the quality of the cable.  The 10
> >>>                                 GbE cables and NICs sold on the
> >>>                                 Ettus website all work well.
> >>>
> >>>                                 Regards,
> >>>                                 Michael
> >>>
> >>>
> >>>
> >>>
> >>>                                 On Fri, Oct 23, 2015 at 3:47 PM,
> >>>                                 Marcus M?ller
> >>>                                 <marcus.mueller at ettus.com
> >>>                                 <mailto:marcus.mueller at ettus.com <marcus.mueller at ettus.com>>>
> >>>                                 wrote:
> >>>
> >>>                                     So to understand this
> >>>
> >>>                                     TX much more stable than RX, and
> >>>                                     RX showing not a single "O" (a
> >>>                                     proper overflow) but a lot of
> >>>                                     "D" packet errors (which are, in
> >>>                                     fact, either very serious packet
> >>>                                     losses, or package reordering).
> >>>                                     It's probably the cable, or your
> >>>                                     network stack might be up to no
> >>>                                     good.
> >>>
> >>>                                     Could you share the output of
> >>>
> >>>                                     ip route
> >>>
> >>>                                     Also, it's possible that some
> >>>                                     default firewall rule makes your
> >>>                                     CPU break a sweat; you could try
> >>>                                     to bypass firewall for the eth2
> >>>                                     device
> >>>
> >>>                                     sudo iptables -A INPUT -i eth2
> >>>                                     -j ACCEPT
> >>>
> >>>                                     (this is *not* permanent).
> >>>                                     If that doesn't help, maybe
> >>>                                     inspecting the packets captured
> >>>                                     with "wireshark" might help. For
> >>>                                     example, set up wireshark to
> >>>                                     listen to eth2, power up the
> >>>                                     USRP; you should see a few
> >>>                                     packets being exchanged on the
> >>>                                     interface.
> >>>                                     Then run
> >>>
> >>>                                     rx_samples_to_file --rate 200e6
> >>>                                     --file /dev/null --nsamps $(( 2
> >>>                                     * 1000  * 1000 ))
> >>>
> >>>                                     then stop the capture. Did you
> >>>                                     see "D"s? If yes, I'd like to
> >>>                                     have a look at the captured
> >>>                                     data; please save it. We'll
> >>>                                     figure out a way to exchange it.
> >>>
> >>>                                     Best regards,
> >>>                                     Marcus
> >>>                                     On 23.10.2015 21:21, Sanjoy
> >>>                                     Basak wrote:
> >>>>                                     Hi Michael, Neel and Marcus,
> >>>>
> >>>>                                     Thanks a lot for the
> >>>>                                     suggestions. I tried each of
> >>>>                                     those. 
> >>>>                                     I updated the kernel to
> >>>>                                     3.19.0-31-generic. 
> >>>>
> >>>>                                     CPU governors, I set to
> >>>>                                     performance as instruction
> >>>>                                     given in this link. 
> >>>>                                     http://files.ettus.com/manual/page_usrp_x3x0_config.html#x3x0cfg_hostpc_pwr
> >>>>                                     Now, after setting it to
> >>>>                                     performance and restarting, if
> >>>>                                     I check with cpu-freq, I find
> >>>>                                     all governers are set at
> >>>>                                     performance. But after a
> >>>>                                     while(5/10 mins later) if I
> >>>>                                     check again cpu-freq info, I
> >>>>                                     see all governers are set to
> >>>>                                     powersave. 
> >>>>                                     Could you please tell me why
> >>>>                                     and how to configure it properly?
> >>>>
> >>>>                                     I tried with benchmark_rate to
> >>>>                                     check the performance. With
> >>>>                                     tx-rate till 200 MSps I do not
> >>>>                                     get any overflow/underflow.
> >>>>                                     However with rx-rate 25/50/100
> >>>>                                     MSps I get drop of packets. I
> >>>>                                     made a direct connection from
> >>>>                                     computer to the X310. No switch
> >>>>                                     is used.
> >>>>
> >>>>                                     On the contrary with
> >>>>                                     shorter(copper) cable at 1Gig
> >>>>                                     interface I do not get any drop
> >>>>                                     of packets at 25MSps (on both
> >>>>                                     tx_rate and rx_rate). 
> >>>>                                     Is 3m copper cable really bad? 
> >>>>
> >>>>                                     We don't have fibre cable right
> >>>>                                     now. We already ordered. I hope
> >>>>                                     we will get it next week and
> >>>>                                     check how it is. We don't have
> >>>>                                     any SFP+ 10 Gig interface. So
> >>>>                                     can't really test 10 gig
> >>>>                                     interface with short 10 gig
> >>>>                                     copper cable.
> >>>>
> >>>>                                     These are the benchmark_rate
> >>>>                                     results for 10 Gig interface
> >>>>
> >>>>
> >>>>                                     Testing receive rate 25.000000
> >>>>                                     Msps on 1 channels
> >>>>                                     DDDDDDDD
> >>>>                                     Benchmark rate summary:
> >>>>                                       Num received samples:  
> >>>>                                      249845308
> >>>>                                       Num dropped samples:     15968
> >>>>                                       Num overflows detected:  0
> >>>>                                       Num transmitted samples: 0
> >>>>                                       Num sequence errors:     0
> >>>>                                       Num underflows detected: 0
> >>>>
> >>>>
> >>>>                                     Testing receive rate 100.000000
> >>>>                                     Msps on 1 channels 
> >>>>                                     DDDDDDDDDDDDDDDDDDDDD 
> >>>>                                     Benchmark rate summary: 
> >>>>                                       Num received samples:  
> >>>>                                      999934124 
> >>>>                                       Num dropped samples:     41916 
> >>>>                                       Num overflows detected:  0 
> >>>>                                       Num transmitted samples: 0 
> >>>>                                       Num sequence errors:     0 
> >>>>                                       Num underflows detected: 0
> >>>>
> >>>>                                      I also used this command
> >>>>                                     sudo ethtool -C eth2 rx-usecs
> >>>>                                     16 rx-frames 20
> >>>>
> >>>>                                     Please let me know what you
> >>>>                                     think occurring the problem and
> >>>>                                     whether replacing copper cable
> >>>>                                     with short fibre cable solves
> >>>>                                     the problem.
> >>>>
> >>>>                                     Best regards
> >>>>                                     Sanjoy
> >>>>
> >>>>
> >>>>                                     On Wed, Oct 21, 2015 at 12:27
> >>>>                                     PM, Marcus M?ller
> >>>>                                     <usrp-users at lists.ettus.com
> >>>>                                     <mailto:usrp-users at lists.ettus.com <usrp-users at lists.ettus.com>>>
> >>>>                                     wrote:
> >>>>
> >>>>                                         Hi Sanjoy,
> >>>>
> >>>>                                         furthermore, and I found
> >>>>                                         that to be crucial on my
> >>>>                                         system, you should make
> >>>>                                         sure that your 10GE card
> >>>>                                         doesn't generate an
> >>>>                                         interrupt for every packet
> >>>>                                         it receives (your
> >>>>                                         application will pull these
> >>>>                                         packets as fast as
> >>>>                                         possible, anyway).
> >>>>                                         On linux, you'd do
> >>>>
> >>>>                                         sudo ethtool -c {name of
> >>>>                                         ethernet interface, e.g. eth1}
> >>>>
> >>>>                                         to see the coalescing
> >>>>                                         options available with your
> >>>>                                         device and kernel version,
> >>>>                                         and modify a setting using
> >>>>
> >>>>                                         sudo ethtool -C {name of
> >>>>                                         ethernet interface, e.g.
> >>>>                                         eth1} {name of setting}
> >>>>                                         {new value of setting}
> >>>>
> >>>>                                         For example, I set
> >>>>                                         "rx_usecs" (microseconds to
> >>>>                                         wait between triggering an
> >>>>                                         interrupt) to 16, and
> >>>>                                         "rx_frames" to 20 or so --
> >>>>                                         your milage might vary,
> >>>>                                         depending on your
> >>>>                                         application, OS and also a
> >>>>                                         few hardware factors.
> >>>>
> >>>>                                         Best regards,
> >>>>                                         Marcus
> >>>>
> >>>>
> >>>>                                         On 19.10.2015 21:56,
> >>>>                                         Michael West via USRP-users
> >>>>                                         wrote:
> >>>>>                                         Also, check the CPU
> >>>>>                                         governor and make sure it
> >>>>>                                         is set to "performance".
> >>>>>
> >>>>>                                         Your output indicates
> >>>>>                                         frame errors on the
> >>>>>                                         interface, which could be
> >>>>>                                         due to the cable.  If
> >>>>>                                         possible, try using a
> >>>>>                                         shorter copper cable or
> >>>>>                                         switch to a fibre cable. 
> >>>>>                                         With 10 GbE over copper,
> >>>>>                                         the shorter the better. 
> >>>>>                                         If you need the length,
> >>>>>                                         you should be using fibre.
> >>>>>
> >>>>>                                         If you still have issues,
> >>>>>                                         please provide a little
> >>>>>                                         more information:  Are you
> >>>>>                                         connected directly with
> >>>>>                                         the X310 or through a
> >>>>>                                         switch?  How are you
> >>>>>                                         testing the performance? 
> >>>>>                                         Are you using your own
> >>>>>                                         application or
> >>>>>                                         benchmark_rate?  If your
> >>>>>                                         own application, what is
> >>>>>                                         it doing with the received
> >>>>>                                         data (processing it with
> >>>>>                                         the same thread or
> >>>>>                                         different thread, saving
> >>>>>                                         to disk, etc...)?
> >>>>>
> >>>>>                                         Regards,
> >>>>>                                         Michael
> >>>>>
> >>>>>                                         On Mon, Oct 19, 2015 at
> >>>>>                                         12:51 PM, Neel Pandeya via
> >>>>>                                         USRP-users
> >>>>>                                         <usrp-users at lists.ettus.com <mailto:usrp-users at lists.ettus.com <usrp-users at lists.ettus.com>>>
> >>>>>                                         wrote:
> >>>>>
> >>>>>                                             Hello Sanjoy:
> >>>>>
> >>>>>                                             That Intel X520 10GbE
> >>>>>                                             card with Ubuntu
> >>>>>                                             14.04.3 should be
> >>>>>                                             working well for you.
> >>>>>
> >>>>>                                             Could you try
> >>>>>                                             upgrading to kernel
> >>>>>                                             3.16 or 3.19, and let
> >>>>>                                             us know your results?
> >>>>>
> >>>>>                                             To upgrade to kernel
> >>>>>                                             3.16, run "sudo
> >>>>>                                             apt-get install
> >>>>>                                             linux-generic-lts-utopic".
> >>>>>
> >>>>>                                             To upgrade to kernel
> >>>>>                                             3.19, run "sudo
> >>>>>                                             apt-get install
> >>>>>                                             linux-generic-lts-vivid".
> >>>>>
> >>>>>                                             After the upgrade, be
> >>>>>                                             sure to reboot the system.
> >>>>>
> >>>>>                                             Also, check that you
> >>>>>                                             have the CPU governors
> >>>>>                                             set to "performance",
> >>>>>                                             and that you have the
> >>>>>                                             highest clock rate set.
> >>>>>
> >>>>>                                             --Neel
> >>>>>
> >>>>>
> >>>>>
> >>>>>                                             On 19 October 2015 at
> >>>>>                                             12:03, Sanjoy Basak
> >>>>>                                             via USRP-users
> >>>>>                                             <usrp-users at lists.ettus.com
> >>>>>                                             <mailto:usrp-users at lists.ettus.com <usrp-users at lists.ettus.com>>>
> >>>>>                                             wrote:
> >>>>>
> >>>>>                                                 Hi Experts,
> >>>>>                                                 We recently bought
> >>>>>                                                 a 10 Gig ethernet
> >>>>>                                                 card (X510-DA2)
> >>>>>                                                 and Twinaxial-Kabel SFP+
> >>>>>                                                 M SFP+ M 3,0m. I
> >>>>>                                                 installed it in
> >>>>>                                                 our pc (OS: Ubuntu
> >>>>>                                                 Mate 14.04.3 LTS)
> >>>>>                                                 and can
> >>>>>                                                 communicate with
> >>>>>                                                 X310/SBX-120
> >>>>>                                                 properly. However,
> >>>>>                                                 the performance we
> >>>>>                                                 are getting is
> >>>>>                                                 quite poor. I am
> >>>>>                                                 getting dropped
> >>>>>                                                 packets (D O)
> >>>>>                                                 mostly at 25,50
> >>>>>                                                 MSps and goes
> >>>>>                                                 quite crazy at 100
> >>>>>                                                 MSps and sometimes
> >>>>>                                                 even at lower
> >>>>>                                                 sample rates. 
> >>>>>                                                 Previously I
> >>>>>                                                 tested with 1 Gig
> >>>>>                                                 ethernet, at 25
> >>>>>                                                 MSps I could
> >>>>>                                                 stream without any
> >>>>>                                                 drop/late packet
> >>>>>                                                 or underrun. 
> >>>>>                                                 The CPU uses or
> >>>>>                                                 network uses is
> >>>>>                                                 also not reaching
> >>>>>                                                 100%. 
> >>>>>
> >>>>>                                                 Could you please
> >>>>>                                                 tell me what to
> >>>>>                                                 check/correct so I
> >>>>>                                                 can stream at 100
> >>>>>                                                 MSps without any
> >>>>>                                                 error?
> >>>>>
> >>>>>                                                 I am putting the
> >>>>>                                                 ifconfig and
> >>>>>                                                 ethtool results
> >>>>>                                                 and the kernel
> >>>>>                                                 version(3.16.0-30-generic)
> >>>>>
> >>>>>                                                 eth2      Link
> >>>>>                                                 encap:Ethernet
> >>>>>                                                  HWaddr
> >>>>>                                                 90:e2:ba:a6:a9:dd  
> >>>>>                                                           inet6
> >>>>>                                                 addr:
> >>>>>                                                 fe80::92e2:baff:fea6:a9dd/64
> >>>>>                                                 Scope:Link
> >>>>>                                                           UP
> >>>>>                                                 BROADCAST
> >>>>>                                                 MULTICAST
> >>>>>                                                  MTU:9000  Metric:1
> >>>>>                                                           RX
> >>>>>                                                 packets:4530726
> >>>>>                                                 errors:146
> >>>>>                                                 dropped:0
> >>>>>                                                 overruns:0 frame:146
> >>>>>                                                           TX
> >>>>>                                                 packets:6811057
> >>>>>                                                 errors:0 dropped:0
> >>>>>                                                 overruns:0 carrier:0
> >>>>>                                                          
> >>>>>                                                 collisions:0
> >>>>>                                                 txqueuelen:1000 
> >>>>>                                                           RX
> >>>>>                                                 bytes:26331306938
> >>>>>                                                 (26.3 GB)  TX
> >>>>>                                                 bytes:35856233935
> >>>>>                                                 (35.8 GB)
> >>>>>
> >>>>>                                                 Settings for eth2:
> >>>>>                                                 Supported ports: [
> >>>>>                                                 FIBRE ]
> >>>>>                                                 Supported link
> >>>>>                                                 modes:  
> >>>>>                                                 10000baseT/Full 
> >>>>>                                                 Supported pause
> >>>>>                                                 frame use: No
> >>>>>                                                 Supports
> >>>>>                                                 auto-negotiation: No
> >>>>>                                                 Advertised link
> >>>>>                                                 modes:
> >>>>>                                                  10000baseT/Full 
> >>>>>                                                 Advertised pause
> >>>>>                                                 frame use: No
> >>>>>                                                 Advertised
> >>>>>                                                 auto-negotiation: No
> >>>>>                                                 Speed: 10000Mb/s
> >>>>>                                                 Duplex: Full
> >>>>>                                                 Port: Other
> >>>>>                                                 PHYAD: 0
> >>>>>                                                 Transceiver: external
> >>>>>                                                 Auto-negotiation: off
> >>>>>                                                 Cannot get
> >>>>>                                                 wake-on-lan
> >>>>>                                                 settings:
> >>>>>                                                 Operation not
> >>>>>                                                 permitted
> >>>>>                                                 Current message
> >>>>>                                                 level: 0x00000007 (7)
> >>>>>                                                       drv probe link
> >>>>>                                                 Link detected: yes
> >>>>>
> >>>>>                                                 Our computer
> >>>>>                                                 config is:
> >>>>>                                                 Processor:
> >>>>>                                                 12*Intel(R) Xeon
> >>>>>                                                 (R) CPU E5-2620 v3
> >>>>>                                                 @2.40 GHz
> >>>>>                                                 RAM: 65871 MB
> >>>>>                                                 SSD raid 5
> >>>>>
> >>>>>
> >>>>>                                                 Best regards
> >>>>>                                                 Sanjoy
> >>>>>
> >>>>>                                                 _______________________________________________
> >>>>>                                                 USRP-users mailing
> >>>>>                                                 list
> >>>>>                                                 USRP-users at lists.ettus.com
> >>>>>                                                 <mailto:USRP-users at lists.ettus.com <USRP-users at lists.ettus.com>>
> >>>>>                                                 http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>>>>
> >>>>>
> >>>>>
> >>>>>                                             _______________________________________________
> >>>>>                                             USRP-users mailing list
> >>>>>                                             USRP-users at lists.ettus.com
> >>>>>                                             <mailto:USRP-users at lists.ettus.com <USRP-users at lists.ettus.com>>
> >>>>>                                             http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>                                         _______________________________________________
> >>>>>                                         USRP-users mailing list
> >>>>>                                         USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com <USRP-users at lists.ettus.com>>
> >>>>>                                         http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>>>
> >>>>
> >>>>                                         _______________________________________________
> >>>>                                         USRP-users mailing list
> >>>>                                         USRP-users at lists.ettus.com
> >>>>                                         <mailto:USRP-users at lists.ettus.com <USRP-users at lists.ettus.com>>
> >>>>                                         http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>>                         -- 
> >>>                         Sent from my Android device with K-9 Mail.
> >>>                         Please excuse my brevity.
> >>>
> >>>
> >>
> >>
> >
> >
> >
> >
> >
> >     _______________________________________________
> >     USRP-users mailing list
> >     USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com <USRP-users at lists.ettus.com>>
> >     http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users at lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151027/4cc20e56/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 27 Oct 2015 18:29:30 +0100
> From: Marcus M?ller <marcus.mueller at ettus.com>
> To: usrp-users at lists.ettus.com
> Subject: Re: [USRP-users] Precise transmit control of X310
> Message-ID: <562FB47A.1030305 at ettus.com>
> Content-Type: text/plain; charset="windows-1252"
> 
> Hi Carel,
> 
> >
> > 1. How accurately can we control the GPIO pins using the timed commands:
> > multi_usrp::set_command_time()?
> That should be 1/master_clock_rate resolution, i.e. 1/200MHz= 5ns on the
> default setting. Notice that these ATR registers are pretty "close" to
> the port, so there's only two flops between the settings register and
> the actual hardware pin, and hence latency between the command time and
> the pin changing state is much shorter than the DSP chain for samples!
> > 2. How accurate is the transmission based on the time_spec set on the
> > uhd::tx_metadata_t?
> 1/mcr, too. Basically, the clock at which the settings registers in the
> FPGA are driven.
> 
> Regarding the time stamps: Internally (and on the wire), the time stamps
> are transmitted as to fixed point numbers for the full seconds and the
> fractions of the second. get_real_secs calculates a double precision
> floating point values out of these. For large full seconds there's less
> precision "behind the comma", as floating point numbers typically have a
> fixed number of significant digits -- so if you increase the overall
> order of magnitude of the number, you lose precision on the less
> significant end.
> 
> Best regards,
> Marcus
> 
> On 10/27/2015 02:12 PM, Carel Combrink via USRP-users wrote:
> > Hi,
> >
> > We are using a X310 to transmit bursts and require very accurate
> > transmit precision.
> >
> > Currently we are having some issues regarding the control.
> >
> > 1. How accurately can we control the GPIO pins using the timed commands:
> > multi_usrp::set_command_time()?
> >
> >     m_usrp->set_command_time(specHigh);
> >     m_usrp->set_gpio_attr("FP0", std::string("OUT"),
> > FPGPIO_BIT(manualStrobePin), FPGPIO_BIT(manualStrobePin));
> >     m_usrp->clear_command_time();
> >
> > 2. How accurate is the transmission based on the time_spec set on the
> > uhd::tx_metadata_t?
> >
> > 3. What precision can I expect using uhd::time_spec_t?
> >
> > The reason that I ask about 3:
> > I print out the following (Using Qt)
> >             qDebug() << "TS: " << md.time_spec.get_full_secs()
> >                      << " - " <<
> > QString::number(md.time_spec.get_frac_secs(), 'f', 15)
> >                      << "(" <<
> > QString::number(md.time_spec.get_real_secs(), 'f', 15) << ")";
> >
> > And the result is:
> > TS:  1445950858  -  "0.027400000000000" ( "1445950858.027400016784668" )
> > TS:  1445950858  -  "0.027600000000000" ( "1445950858.027600049972534" )
> > TS:  1445950858  -  "0.027700000000000" ( "1445950858.027699947357178" )
> > TS:  1445950858  -  "0.027800000000000" ( "1445950858.027800083160400" )
> > TS:  1445950858  -  "0.028300000000000" ( "1445950858.028300046920776" )
> > TS:  1445950858  -  "0.028800000000000" ( "1445950858.028800010681152" )
> > TS:  1445950858  -  "0.029100000000000" ( "1445950858.029099941253662" )
> > TS:  1445950858  -  "0.029400000000000" ( "1445950858.029400110244751" )
> > TS:  1445950858  -  "0.029600000000000" ( "1445950858.029599905014038" )
> > TS:  1445950858  -  "0.029800000000000" ( "1445950858.029799938201904" )
> > TS:  1445950858  -  "0.030800000000000" ( "1445950858.030800104141235" )
> > TS:  1445950858  -  "0.031800000000000" ( "1445950858.031800031661987" )
> > TS:  1445950858  -  "0.032000000000000" ( "1445950858.032000064849854" )
> >
> > So looking at the full_sec and frac_sec it is rather accurate
> > according to my time spec that I set up for the different busts. But
> > on the real_sec it is not so accurate. I know the documentation on
> > get_real_secs() say that precision might be lost. But what part of the
> > time_spec does the device use when transmitting, the accurate
> > full+frac or the real?
> >
> > Regards,
> >
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users at lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151027/be9febd3/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 3
> Date: Tue, 27 Oct 2015 17:59:44 +0000
> From: Derek Kozel <derek.kozel at ettus.com>
> To: Emanuel.Staudinger at dlr.de, 	"usrp-users at lists.ettus.com"
> 	<usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] B200mini Series: some general questions
> Message-ID:
> 	<CAA+K=tvwhejrv+K79N=8+JQ_mypa99djs2GgTxep3rX5UFHUWw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Hello Emanuel,
> 
> The oscillator is the 520M05DA40M0000, the datasheet is located at
> http://www.ctscorp.com/components/Datasheets/008-0371-0.pdf
> 
> A temperature range test of the B200mini has not been done so there is no
> certified temperature range. The oscillator is specified for -30C to +85C.
> 
> The FPGA utilization for a very recent master code is as below.
> 
> Regards,
> Derek
> 
> Device utilization summary:
> ---------------------------
> 
> Selected Device : 6slx75csg484-3
> 
> 
> Slice Logic Utilization:
>  Number of Slice Registers:           16008  out of  93296    17%
>  Number of Slice LUTs:                20088  out of  46648    43%
>     Number used as Logic:             16183  out of  46648    34%
>     Number used as Memory:             3905  out of  11072    35%
>        Number used as RAM:              972
>        Number used as SRL:             2933
> 
> Slice Logic Distribution:
>  Number of LUT Flip Flop pairs used:  25867
>    Number with an unused Flip Flop:    9859  out of  25867    38%
>    Number with an unused LUT:          5779  out of  25867    22%
>    Number of fully used LUT-FF pairs: 10229  out of  25867    39%
>    Number of unique control sets:       437
> 
> IO Utilization:
>  Number of IOs:                         123
>  Number of bonded IOBs:                 114  out of    328    34%
>     IOB Flip Flops/Latches:             137
> 
> Specific Feature Utilization:
>  Number of Block RAM/FIFO:              110  out of    172    63%
>     Number using Block RAM only:        110
>  Number of BUFG/BUFGCTRLs:                6  out of     16    37%
>  Number of DSP48A1s:                     76  out of    132    57%
>  Number of PLL_ADVs:                      1  out of      6    16%
> 
> 
> 
> On Fri, Oct 23, 2015 at 1:15 PM, Derek Kozel <derek.kozel at ettus.com> wrote:
> 
> > RFNoC will also not be possible with B205mini(-i). The LX150 FPGA that the
> > B205mini will have is the same that the B210 has. For now the E300 and X300
> > families are the only ones which RFNoC is developed for.
> >
> > I'll let you know the oscillator part number soon as I find out the full
> > one.
> >
> >
> >
> > On Fri, Oct 23, 2015 at 11:01 AM, <Emanuel.Staudinger at dlr.de> wrote:
> >
> >> Hello Derek,
> >>
> >>
> >>
> >> Thanks for your answers.
> >>
> >> Indeed, I overlooked that the third SMA connector is for the 1PPS or
> >> 10MHz reference.
> >>
> >> Which VCTCXO exactly are you using? The schematic does not state any
> >> specific part number.
> >>
> >>
> >>
> >> The B200mini data sheet states a version called B205mini-i with a larger
> >> FPGA. Is this version available soon and will RFNOC be possible with this
> >> version or not?
> >>
> >>
> >>
> >> Regards,
> >>
> >> Emanuel
> >>
> >>
> >>
> >> *Von:* Derek Kozel [mailto:derek.kozel at ettus.com] <derek.kozel at ettus.com]>
> >> *Gesendet:* Thursday, October 22, 2015 1:58 PM
> >> *An:* Staudinger, Emanuel
> >> *Cc:* usrp-users at lists.ettus.com
> >> *Betreff:* Re: [USRP-users] B200mini Series: some general questions
> >>
> >>
> >>
> >> Hello Emanuel,
> >>
> >> The B200mini has an SMA connector which accepts either a 1PPS or 10MHz
> >> reference so no breakout adapter is needed. The built in VCTCXO has a basic
> >> accuracy of 0.5ppm. The datasheet I have is generic for a range of
> >> oscillator frequencies and doesn't have a phase noise plot for the 40MHz
> >> version. I am looking to see if we have that information available. The
> >> clocking structure of the B200mini can be seen on page 4 of the schematics.
> >> http://files.ettus.com/schematics/b200mini/b200mini.pdf
> >>
> >> The FPGA used, the Spartan-6 XC6SLX75, is the same as the B200 has so
> >> unfortunately it is not possible to use RFNoC with the B200mini. The FPGA
> >> resource usage is also about the same as the B200, though I'll check with
> >> one of the designers for actual numbers.
> >>
> >> Regards,
> >>
> >> Derek
> >>
> >>
> >>
> >> On Thu, Oct 22, 2015 at 8:27 AM, Emanuel via USRP-users <
> >> usrp-users at lists.ettus.com> wrote:
> >>
> >> Dear Ettus team,
> >>
> >>
> >>
> >> Your new B200mini looks great, very nice work indeed. I have some general
> >> questions you could probably answer easily, as I did not find additional
> >> information on that on your website:
> >>
> >> 1.       Do you ship the B200mini with a sort of breakout adapter such
> >> that the B200mini can easily be fed from an external 10MHz source?
> >>
> >> 2.       You also have a B200mini-i series with an industrial
> >> temperature range: what is the allowed temperature range for the normal
> >> B200mini? Does the B200mini-i series also cover an extended temperature
> >> range for the oscillator?
> >>
> >> 3.       Do you have some specifications of the used oscillator?
> >> Accuracy/drift? A link to the datasheet is fine for me.
> >>
> >> 4.       How many FPGA resources are still available on the FPGA?
> >>
> >> 5.       Is it possible to use RFNOC with the B200mini series?
> >>
> >>
> >>
> >> Best regards,
> >>
> >> Emanuel
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> USRP-users mailing list
> >> USRP-users at lists.ettus.com
> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>
> >>
> >>
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151027/dd36d668/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 4
> Date: Tue, 27 Oct 2015 11:53:48 -0700
> From: Martin Braun <martin.braun at ettus.com>
> To: usrp-users at lists.ettus.com
> Subject: Re: [USRP-users] Installing PCIE drivers for x310
> Message-ID: <562FC83C.8000400 at ettus.com>
> Content-Type: text/plain; charset=windows-1252
> 
> On 27.10.2015 08:51, Jared Dulmage via USRP-users wrote:
> > Martin,
> > 
> > When I go faster than 50M I get scrolling O's which I thought meant
> > overflow.  This happens whether I'm postprocessing, e.g. using
> > gr-fosphor, or w/o any postprocessing, i.e. just saving to file.
> 
> Sorry if you answered this in an earlier thread, but if you do
> benchmark_rate, do you still see this? Writing to a file is actually
> quite a bottleneck.
> 
> Cheers,
> Martin
> 
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Tue, 27 Oct 2015 15:07:03 -0400
> From: James Humphries <james.humphries at ettus.com>
> To: Martin Braun <martin.braun at ettus.com>
> Cc: "USRP-users at lists.ettus.com" <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] Installing PCIE drivers for x310
> Message-ID:
> 	<CAEwGFhXFTOp6UW=CTSeiVoeCPFqs2Vadry931Jv4FtCLDp=KUA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> For future reference, if you want to save to a file, you could try setting
> up a ramdisk to alleviate the write bottleneck:
> 
> I have used this guide in the past to set one up:
> http://www.jamescoyle.net/how-to/943-create-a-ram-disk-in-linux
> 
> Alternatively, you could try using a vector sink in GNU Radio.
> 
> -Trip
> 
> On Tue, Oct 27, 2015 at 2:53 PM, Martin Braun via USRP-users <
> usrp-users at lists.ettus.com> wrote:
> 
> > On 27.10.2015 08:51, Jared Dulmage via USRP-users wrote:
> > > Martin,
> > >
> > > When I go faster than 50M I get scrolling O's which I thought meant
> > > overflow.  This happens whether I'm postprocessing, e.g. using
> > > gr-fosphor, or w/o any postprocessing, i.e. just saving to file.
> >
> > Sorry if you answered this in an earlier thread, but if you do
> > benchmark_rate, do you still see this? Writing to a file is actually
> > quite a bottleneck.
> >
> > Cheers,
> > Martin
> >
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users at lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151027/4a8271f8/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 6
> Date: Tue, 27 Oct 2015 22:47:03 +0000
> From: Jared Dulmage <jared.dulmage at aero.org>
> To: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] Installing PCIE drivers for x310
> Message-ID:
> 	<SN1PR09MB08154DD2660F4D94D3F54B4292220 at SN1PR09MB0815.namprd09.prod.outlook.com>
> 	
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Martin,
> 
> The benchmark_rate utility gives overflows for any rate over 50 MSps, I tried it for 100 M and 66.67 M also.
> 
> Trip,
> Thanks for the advice, we've done similar save-to-file-in-ram tests in the past and that does work well.  However, I was just surprised that I couldn't get the faster rate since I would expect the hardware could handle it.
> 
> Jared.
> ------------------------------------------------------
> Jared Dulmage
> Engineering Specialist
> Digital Comm. and Implementation Dept.
> Aerospace Corporation
> 310-336-3140
> 
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Tue, 27 Oct 2015 19:19:20 -0400
> From: James Humphries <james.humphries at ettus.com>
> To: Jared Dulmage <jared.dulmage at aero.org>
> Cc: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] Installing PCIE drivers for x310
> Message-ID:
> 	<CAEwGFhXUuGtfaWKEfuy5ff22jM_54o__en=2HicCx+d9fLpUWw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi Jared,
> 
> Could you confirm you system specifications (just for reference)? I see you
> are using HP Z620. I assume this is Intel Xeon processor? How about
> processor speed, RAM, etc?
> 
> Maybe you are already, but could you try a tool to set the CPU to maximum
> performance. I like to use ' indicator-cpufreq ' in Ubuntu, it should give
> you a dropdown to select maximum CPU speed.
> 
> -Trip
> 
> On Tue, Oct 27, 2015 at 6:47 PM, Jared Dulmage via USRP-users <
> usrp-users at lists.ettus.com> wrote:
> 
> > Martin,
> >
> > The benchmark_rate utility gives overflows for any rate over 50 MSps, I
> > tried it for 100 M and 66.67 M also.
> >
> > Trip,
> > Thanks for the advice, we've done similar save-to-file-in-ram tests in the
> > past and that does work well.  However, I was just surprised that I
> > couldn't get the faster rate since I would expect the hardware could handle
> > it.
> >
> > Jared.
> > ------------------------------------------------------
> > Jared Dulmage
> > Engineering Specialist
> > Digital Comm. and Implementation Dept.
> > Aerospace Corporation
> > 310-336-3140
> >
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users at lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151027/7905b924/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 8
> Date: Tue, 27 Oct 2015 23:42:21 +0000
> From: Jared Dulmage <jared.dulmage at aero.org>
> To: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] Installing PCIE drivers for x310
> Message-ID:
> 	<SN1PR09MB0815A01FA84DCCFB3A576E1792220 at SN1PR09MB0815.namprd09.prod.outlook.com>
> 	
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Trip,
> 
> > cpuinfo
> Intel(R) Xeon(R)  CPU E5-2640 0 
> =====  Processor composition  =====
> Processors(CPUs)  : 12
> Packages(sockets) : 1
> Cores per package : 6
> Threads per core  : 2
> =====  Processor identification  =====
> Processor	Thread Id.	Core Id.	Package Id.
> 0       	0           	0           	0   
> 1       	0           	1           	0   
> 2       	0           	2           	0   
> 3       	0           	3           	0   
> 4       	0           	4           	0   
> 5       	0           	5           	0   
> 6       	1           	0           	0   
> 7       	1           	1           	0   
> 8       	1           	2           	0   
> 9       	1           	3           	0   
> 10      	1           	4           	0   
> 11      	1           	5           	0   
> =====  Placement on packages  =====
> Package Id.	Core Id.	Processors
> 0           	0,1,2,3,4,5        	(0,6)(1,7)(2,8)(3,9)(4,10)(5,11)
> =====  Cache sharing  =====
> Cache	Size        	Processors
> L1	32  KB        	(0,6)(1,7)(2,8)(3,9)(4,10)(5,11)
> L2	256 KB        	(0,6)(1,7)(2,8)(3,9)(4,10)(5,11)
> L3	15  MB        	(0,1,2,3,4,5,6,7,8,9,10,11)
> 
> > head /proc/meminfo 
> MemTotal:       32875268 kB
> MemFree:        14926632 kB
> Buffers:          525708 kB
> Cached:         13960396 kB
> SwapCached:            0 kB
> Active:          9449492 kB
> Inactive:        7474852 kB
> Active(anon):    2439312 kB
> Inactive(anon):   133116 kB
> Active(file):    7010180 kB
> 
> > cpupower frequency-info
> analyzing CPU 0:
>   driver: acpi-cpufreq
>   CPUs which run at the same hardware frequency: 0
>   CPUs which need to have their frequency coordinated by software: 0
>   maximum transition latency: 10.0 us.
>   hardware limits: 1.20 GHz - 2.50 GHz
>   available frequency steps: 2.50 GHz, 2.50 GHz, 2.40 GHz, 2.30 GHz, 2.20 GHz, 2.10 GHz, 2.00 GHz, 1.90 GHz, 1.80 GHz, 1.70 GHz, 1.60 GHz, 1.50 GHz, 1.40 GHz, 1.30 GHz, 1.20 GHz
>   available cpufreq governors: conservative, ondemand, userspace, powersave, performance
>   current policy: frequency should be within 1.20 GHz and 2.50 GHz.
>                   The governor "ondemand" may decide which speed to use
>                   within this range.
>   current CPU frequency is 1.20 GHz.
>   cpufreq stats: 2.50 GHz:2.57%, 2.50 GHz:0.00%, 2.40 GHz:0.14%, 2.30 GHz:0.07%, 2.20 GHz:0.05%, 2.10 GHz:0.06%, 2.00 GHz:0.06%, 1.90 GHz:0.15%, 1.80 GHz:1.44%, 1.70 GHz:1.87%, 1.60 GHz:0.55%, 1.50 GHz:0.26%, 1.40 GHz:0.17%, 1.30 GHz:0.14%, 1.20 GHz:92.48%  (77054)
>   boost state support:
>     Supported: yes
>     Active: yes
>     25500 MHz max turbo 4 active cores
>     25500 MHz max turbo 3 active cores
>     25500 MHz max turbo 2 active cores
>     25500 MHz max turbo 1 active cores
> 
> I did this and still got overruns with 100 Msps
> > cpupower frequency-set -g performance
> 
> One thing I noticed was that there's a huge number of interrupts during a test.
> 
> > dstat -crimp
> ----total-cpu-usage---- --io/total- ----interrupts--- ------memory-usage----- ---procs---
> usr sys idl wai hiq siq| read  writ|  90    91    92 | used  buff  cach  free|run blk new
>   1   1  97   0   0   0|   0     0 |   0     0    49 |3628M  511M 13.1G 14.2G|1.0   0   0
>   1   1  98   0   0   0|   0     0 |   0     0    44 |3628M  511M 13.1G 14.2G|  0   0   0
>   3   6  91   0   0   0|   0     0 |3503     0   181 |3644M  511M 13.1G 14.2G|1.0   0 1.0 <<<< start benchmark test
>   3   8  90   0   0   0|   0     0 |5189     0   265 |3644M  511M 13.1G 14.2G|1.0   0   0
>   3   8  89   0   0   0|   0     0 |5032     0   288 |3644M  511M 13.1G 14.2G|1.0   0   0
>   3   8  89   0   0   0|   0     0 |5176     0   286 |3644M  511M 13.1G 14.2G|2.0   0   0
>   3   8  89   0   0   0|   0  11.0 |5084     0   280 |3644M  511M 13.1G 14.2G|1.0   0   0
> 
> Interrupt 90 is niusrpriok in /proc/interrupts.
> 
> Could perhaps improve performance through interrupt binding or something like that?
> 
> Jared.
> ------------------------------------------------------
> Jared Dulmage
> Engineering Specialist
> Digital Comm. and Implementation Dept.
> Aerospace Corporation
> 310-336-3140
> 
> 
> 
> ------------------------------
> 
> Message: 9
> Date: Tue, 27 Oct 2015 20:29:57 -0400
> From: James Humphries <james.humphries at ettus.com>
> To: Jared Dulmage <jared.dulmage at aero.org>
> Cc: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] Installing PCIE drivers for x310
> Message-ID:
> 	<CAEwGFhU7=AzmEwsxbAAHw+o4JjQwtbwrnFVzr0ZmFirJufyG5Q at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Jared,
> 
> Another user pointed out (in a different thread) that you can run this
> command to keep the system from changing governor settings on you:
> 
> sudo update-rc.d ondemand disable
> 
> Also, you could try specifying the CPU freq, something like:
> 
> cpufreq-set -r -f 2500000000  (Set CPU Freq)
> 
> or
> 
> cpufreq-set -r -d 2500000000 (Set Min CPU Freq)
> 
> -Trip
> 
> 
> On Tue, Oct 27, 2015 at 7:42 PM, Jared Dulmage via USRP-users <
> usrp-users at lists.ettus.com> wrote:
> 
> > Trip,
> >
> > > cpuinfo
> > Intel(R) Xeon(R)  CPU E5-2640 0
> > =====  Processor composition  =====
> > Processors(CPUs)  : 12
> > Packages(sockets) : 1
> > Cores per package : 6
> > Threads per core  : 2
> > =====  Processor identification  =====
> > Processor       Thread Id.      Core Id.        Package Id.
> > 0               0               0               0
> > 1               0               1               0
> > 2               0               2               0
> > 3               0               3               0
> > 4               0               4               0
> > 5               0               5               0
> > 6               1               0               0
> > 7               1               1               0
> > 8               1               2               0
> > 9               1               3               0
> > 10              1               4               0
> > 11              1               5               0
> > =====  Placement on packages  =====
> > Package Id.     Core Id.        Processors
> > 0               0,1,2,3,4,5             (0,6)(1,7)(2,8)(3,9)(4,10)(5,11)
> > =====  Cache sharing  =====
> > Cache   Size            Processors
> > L1      32  KB          (0,6)(1,7)(2,8)(3,9)(4,10)(5,11)
> > L2      256 KB          (0,6)(1,7)(2,8)(3,9)(4,10)(5,11)
> > L3      15  MB          (0,1,2,3,4,5,6,7,8,9,10,11)
> >
> > > head /proc/meminfo
> > MemTotal:       32875268 kB
> > MemFree:        14926632 kB
> > Buffers:          525708 kB
> > Cached:         13960396 kB
> > SwapCached:            0 kB
> > Active:          9449492 kB
> > Inactive:        7474852 kB
> > Active(anon):    2439312 kB
> > Inactive(anon):   133116 kB
> > Active(file):    7010180 kB
> >
> > > cpupower frequency-info
> > analyzing CPU 0:
> >   driver: acpi-cpufreq
> >   CPUs which run at the same hardware frequency: 0
> >   CPUs which need to have their frequency coordinated by software: 0
> >   maximum transition latency: 10.0 us.
> >   hardware limits: 1.20 GHz - 2.50 GHz
> >   available frequency steps: 2.50 GHz, 2.50 GHz, 2.40 GHz, 2.30 GHz, 2.20
> > GHz, 2.10 GHz, 2.00 GHz, 1.90 GHz, 1.80 GHz, 1.70 GHz, 1.60 GHz, 1.50 GHz,
> > 1.40 GHz, 1.30 GHz, 1.20 GHz
> >   available cpufreq governors: conservative, ondemand, userspace,
> > powersave, performance
> >   current policy: frequency should be within 1.20 GHz and 2.50 GHz.
> >                   The governor "ondemand" may decide which speed to use
> >                   within this range.
> >   current CPU frequency is 1.20 GHz.
> >   cpufreq stats: 2.50 GHz:2.57%, 2.50 GHz:0.00%, 2.40 GHz:0.14%, 2.30
> > GHz:0.07%, 2.20 GHz:0.05%, 2.10 GHz:0.06%, 2.00 GHz:0.06%, 1.90 GHz:0.15%,
> > 1.80 GHz:1.44%, 1.70 GHz:1.87%, 1.60 GHz:0.55%, 1.50 GHz:0.26%, 1.40
> > GHz:0.17%, 1.30 GHz:0.14%, 1.20 GHz:92.48%  (77054)
> >   boost state support:
> >     Supported: yes
> >     Active: yes
> >     25500 MHz max turbo 4 active cores
> >     25500 MHz max turbo 3 active cores
> >     25500 MHz max turbo 2 active cores
> >     25500 MHz max turbo 1 active cores
> >
> > I did this and still got overruns with 100 Msps
> > > cpupower frequency-set -g performance
> >
> > One thing I noticed was that there's a huge number of interrupts during a
> > test.
> >
> > > dstat -crimp
> > ----total-cpu-usage---- --io/total- ----interrupts---
> > ------memory-usage----- ---procs---
> > usr sys idl wai hiq siq| read  writ|  90    91    92 | used  buff  cach
> > free|run blk new
> >   1   1  97   0   0   0|   0     0 |   0     0    49 |3628M  511M 13.1G
> > 14.2G|1.0   0   0
> >   1   1  98   0   0   0|   0     0 |   0     0    44 |3628M  511M 13.1G
> > 14.2G|  0   0   0
> >   3   6  91   0   0   0|   0     0 |3503     0   181 |3644M  511M 13.1G
> > 14.2G|1.0   0 1.0 <<<< start benchmark test
> >   3   8  90   0   0   0|   0     0 |5189     0   265 |3644M  511M 13.1G
> > 14.2G|1.0   0   0
> >   3   8  89   0   0   0|   0     0 |5032     0   288 |3644M  511M 13.1G
> > 14.2G|1.0   0   0
> >   3   8  89   0   0   0|   0     0 |5176     0   286 |3644M  511M 13.1G
> > 14.2G|2.0   0   0
> >   3   8  89   0   0   0|   0  11.0 |5084     0   280 |3644M  511M 13.1G
> > 14.2G|1.0   0   0
> >
> > Interrupt 90 is niusrpriok in /proc/interrupts.
> >
> > Could perhaps improve performance through interrupt binding or something
> > like that?
> >
> > Jared.
> > ------------------------------------------------------
> > Jared Dulmage
> > Engineering Specialist
> > Digital Comm. and Implementation Dept.
> > Aerospace Corporation
> > 310-336-3140
> >
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users at lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151027/84046bfc/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 10
> Date: Wed, 28 Oct 2015 00:40:06 +0000
> From: Jared Dulmage <jared.dulmage at aero.org>
> To: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] Installing PCIE drivers for x310
> Message-ID:
> 	<SN1PR09MB0815EB5374ED9E250DC3A11792210 at SN1PR09MB0815.namprd09.prod.outlook.com>
> 	
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Trip,
> 
> Thanks for all the advice.  I did
> 
> > cpupower frequency-set -d 2.5GHz
> 
> such that
> > cpupower -c 0-11 frequency-info  -f
> analyzing CPU 0:
> 2501000
> analyzing CPU 1:
> 2501000
> analyzing CPU 2:
> 2501000
> analyzing CPU 3:
> 2501000
> analyzing CPU 4:
> 2501000
> analyzing CPU 5:
> 2501000
> analyzing CPU 6:
> 2501000
> analyzing CPU 7:
> 2501000
> analyzing CPU 8:
> 2501000
> analyzing CPU 9:
> 2501000
> analyzing CPU 10:
> 2501000
> analyzing CPU 11:
> 2501000
> 
> benchmark_rate still gives overruns at 100 Msps.
> 
> Jared.
> ------------------------------------------------------
> Jared Dulmage
> Engineering Specialist
> Digital Comm. and Implementation Dept.
> Aerospace Corporation
> 310-336-3140
> 
> 
> 
> ------------------------------
> 
> Message: 11
> Date: Wed, 28 Oct 2015 09:36:08 +0800(CST)
> From: "=?gbk?B?wfW6o8zO?=" <liuhaitao at bupt.edu.cn>
> To: "USRP-users-p6fHTpcPDZaz3Dx2OeFgIA"
> 	<USRP-users-p6fHTpcPDZaz3Dx2OeFgIA at public.gmane.org>,	"usrp-users"
> 	<usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] look for gfortran
> Message-ID: <20151028013608.5BD4719F37D at mx2.bupt.edu.cn>
> Content-Type: text/plain; charset="us-ascii"
> 
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151028/3a9d6b67/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 12
> Date: Tue, 27 Oct 2015 18:54:55 -0700
> From: Chris Kuethe <chris.kuethe at gmail.com>
> To: ??? <liuhaitao at bupt.edu.cn>
> Cc: USRP-users-p6fHTpcPDZaz3Dx2OeFgIA
> 	<USRP-users-p6fHTpcPDZaz3Dx2OeFgIA at public.gmane.org>, 	usrp-users
> 	<usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] look for gfortran
> Message-ID:
> 	<CAGHP0p+hRktf45iEync+xeAexX3vtzgbc1uhsXE=Hey8krG44w at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
> Have you tried a cross-compiler?
> 
> $ apt-cache search armhf | grep fortran | head -1
> gfortran-arm-linux-gnueabihf - The GNU Fortran 95 compiler for armhf
> architecture
> 
> There is probably something similar for your distribution.
> 
> On Tue, Oct 27, 2015 at 6:36 PM, ??? via USRP-users
> <usrp-users at lists.ettus.com> wrote:
> > Hi Marcus,
> >       I'm using sdimage-gnuraido-dev for e310.
> >       It does not contain fortran and that's exactly the problem. Because I
> > need to use ITPP library for some FFT and other functions.
> >       To install ITPP have to install BLAS?LAPACK first. And they are
> > compiled by fortran ,so I have to use gfortran.
> >       I'm sorry if you receive my letter twice or more.= =
> >
> > Best Regard!
> > Liu Haitao
> >
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users at lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> 
> 
> 
> -- 
> GDB has a 'break' feature; why doesn't it have 'fix' too?
> 
> 
> 
> ------------------------------
> 
> Message: 13
> Date: Wed, 28 Oct 2015 11:29:15 +0800(CST)
> From: "=?gbk?B?wfW6o8zO?=" <liuhaitao at bupt.edu.cn>
> To: "ChrisKuethe" <chris.kuethe at gmail.com>,	"usrp-users"
> 	<usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] look for gfortran
> Message-ID: <20151028032915.9ECF919F39F at mx2.bupt.edu.cn>
> Content-Type: text/plain; charset="us-ascii"
> 
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151028/4a803d2c/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 14
> Date: Wed, 28 Oct 2015 07:32:36 +0200
> From: Carel Combrink <carel.combrink at gmail.com>
> To: Marcus M?ller <marcus.mueller at ettus.com>
> Cc: usrp-users <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] Precise transmit control of X310
> Message-ID:
> 	<CAAxNqaoXsppuktuBD2m5PO_5FnEMe3LGubzivTCaveTjo1GzdA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi Marcus,
> 
> Thank you for the answers, it helps a lot.
> 
> Regarding the time stamps: Internally (and on the wire), the time stamps
> > are transmitted as to fixed point numbers for the full seconds and the
> > fractions of the second.
> >
> 
> Out of curiosity (if I may ask), why is uhd::time_spec_t using a double
> instead of something like a unsigned long for the fraction part? The timespec
> struct (in time.h) handles it using a time_t and a long.
> 
> Regards,
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151028/438065c3/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 15
> Date: Wed, 28 Oct 2015 14:24:31 +0700
> From: Anak Galer <galersekali at gmail.com>
> To: usrp-users <usrp-users at lists.ettus.com>
> Subject: [USRP-users] Sell USRP & Complete Daughterboard
> Message-ID:
> 	<CAO_+gxKmKov7=a02HiUWAJXXRmkFQNbAUhffoQ9Z6WLiOwB-5w at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
> Dear
> 
> i just want help my friend for selling USRP1 , N200 , with complete
> daughterboard , antenna and booster.
> if anyone interested, please contact tri.sumarno.sh at gmail.com for best price
> 
> 
> for detail pic
> https://drive.google.com/file/d/0B2AuSZ6hkrlYbVMtZFN3VHJuV1k/view
> 
> Regards
> 
> 
> 
> ------------------------------
> 
> Message: 16
> Date: Wed, 28 Oct 2015 07:46:10 +0000 (UTC)
> From: mojtaba rostami <mrbilandi at yahoo.com>
> To: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
> Subject: [USRP-users] Error in x300 generation fpga bit file
> Message-ID:
> 	<1600515507.4253567.1446018370876.JavaMail.yahoo at mail.yahoo.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi,
> When i generate x300 FPGA Bit file via "make X300_XGS GUI=1" encounter to this DRC error: 
> But when i generate without GUI it generate successfully bit file!
> [DRC 23-20] Rule violation (RTSTAT-3) Unplaced terminals on net - 486 net(s) have unplaced terminals. The problem bus(es) and/or net(s) are CPRI_CLK_OUT_P, lvfpga_chinch_inst/EttusUsrpChinchWrapperx/ChinchLvFpgaInterfacex/ChinchRegisterAccessx/Mcount_bTimeoutCounterReg_cy[9], lvfpga_chinch_inst/EttusUsrpChinchWrapperx/ChinchLvFpgaInterfacex/DmaBlk.DmaComponents[0].DmaInput.ChinchDmaInputx/ChinchDmaInputControllerx/Mcompar_HandleArbiterRequests.bFifoFullCountDelay2[9]_HandleArbiterRequests.bFifoFullCountDelay[9]_LessThan_82_o_cy[4:0], lvfpga_chinch_inst/EttusUsrpChinchWrapperx/ChinchLvFpgaInterfacex/DmaBlk.DmaComponents[0].DmaInput.ChinchDmaInputx/ChinchDmaInputControllerx/Mcount_HandleArbiterRequests.bEvictionCounter_cy[6], lvfpga_chinch_inst/EttusUsrpChinchWrapperx/ChinchLvFpgaInterfacex/DmaBlk.DmaComponents[0].DmaInput.ChinchDmaInputx/ChinchDmaInputControllerx/Mcount_bDataWordCounter_cy[6], lvfpga_chinch_inst/EttusUsrpChinchWrapperx/ChinchLvFpgaInterfacex/DmaBlk.DmaCompone!
>  nts[0].DmaInput.ChinchDmaInputx/ChinchInterfaceDmaRegistersx/Maccum_bSatcr_cy[30], lvfpga_chinch_inst/EttusUsrpChinchWrapperx/ChinchLvFpgaInterfacex/DmaBlk.DmaComponents[0].DmaInput.ChinchDmaInputx/ChinchInterfaceDmaRegistersx/Mcompar_GND_565_o_SatcrRegister.bSatcrNx[31]_LessThan_22_o_cy[9:0], lvfpga_chinch_inst/EttusUsrpChinchWrapperx/ChinchLvFpgaInterfacex/DmaBlk.DmaComponents[0].DmaInput.ChinchDmaInputx/ChinchInterfaceDmaRegistersx/Mmux_bSatcr[31]_GND_565_o_mux_19_OUT_rs_cy[30], lvfpga_chinch_inst/EttusUsrpChinchWrapperx/ChinchLvFpgaInterfacex/DmaBlk.DmaComponents[0].DmaInput.ChinchDmaInputx/ChinchInterfaceDmaRegistersx/Msub_GND_565_o_GND_565_o_sub_24_OUT<9:0>_cy[8], lvfpga_chinch_inst/EttusUsrpChinchWrapperx/ChinchLvFpgaInterfacex/DmaBlk.DmaComponents[1].DmaInput.ChinchDmaInputx/ChinchDmaInputControllerx/Mcompar_HandleArbiterRequests.bFifoFullCountDelay2[9]_HandleArbiterRequests.bFifoFullCountDelay[9]_LessThan_82_o_cy[4:0], lvfpga_chinch_inst/EttusUsrpChinchWrapperx/Chi!
>  nchLvFpgaInterfacex/DmaBlk.DmaComponents[1].DmaInput.ChinchDmaInputx/C
> hinchDmaInputControllerx/Mcount_HandleArbiterRequests.bEvictionCounter_cy[6], lvfpga_chinch_inst/EttusUsrpChinchWrapperx/ChinchLvFpgaInterfacex/DmaBlk.DmaComponents[1].DmaInput.ChinchDmaInputx/ChinchDmaInputControllerx/Mcount_bDataWordCounter_cy[6], lvfpga_chinch_inst/EttusUsrpChinchWrapperx/ChinchLvFpgaInterfacex/DmaBlk.DmaComponents[1].DmaInput.ChinchDmaInputx/ChinchInterfaceDmaRegistersx/Maccum_bSatcr_cy[30], lvfpga_chinch_inst/EttusUsrpChinchWrapperx/ChinchLvFpgaInterfacex/DmaBlk.DmaComponents[1].DmaInput.ChinchDmaInputx/ChinchInterfaceDmaRegistersx/Mcompar_GND_576_o_SatcrRegister.bSatcrNx[31]_LessThan_22_o_cy[9:0], lvfpga_chinch_inst/EttusUsrpChinchWrapperx/ChinchLvFpgaInterfacex/DmaBlk.DmaComponents[1].DmaInput.ChinchDmaInputx/ChinchInterfaceDmaRegistersx/Mmux_bSatcr[31]_GND_576_o_mux_19_OUT_rs_cy[30] (the first 15 of 347 listed).
> 
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151028/6264bf0f/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 17
> Date: Wed, 28 Oct 2015 10:47:11 +0100
> From: Marcus M?ller <marcus.mueller at ettus.com>
> To: usrp-users at lists.ettus.com
> Subject: Re: [USRP-users] Installing PCIE drivers for x310
> Message-ID: <5630999F.6010105 at ettus.com>
> Content-Type: text/plain; charset=windows-1252
> 
> Hi Jared,
> 
> On 28.10.2015 00:42, Jared Dulmage via USRP-users wrote:
> > One thing I noticed was that there's a huge number of interrupts during a test.
> Yes, that's to be expected -- basically, you'll get one interrupt per
> buffer coming from (or going to) the USRP -- for 50MS/s, that's already
> a lot of interrupts per second. If I remember correctly, optimal PCIe
> throughput performance is given with a frame size of about 2040 samples
> (8120B), which UHD will automatically choose. So roughly, at 5e7 S/s and
> 1 Interrupt/2e3 S, you should be seeing 25 kInterrupts/s; does that
> roughly match your observation?
> 
> Best regards,
> Marcus
> 
> 
> 
> ------------------------------
> 
> Message: 18
> Date: Wed, 28 Oct 2015 11:01:26 +0100
> From: Marcus M?ller <marcus.mueller at ettus.com>
> To: Carel Combrink <carel.combrink at gmail.com>
> Cc: usrp-users <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] Precise transmit control of X310
> Message-ID: <56309CF6.7050809 at ettus.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi Carel,
> 
> to be honest, that's a good question and I can't answer it, because I
> wasn't around when the timespec_t was changed from having a counter for
> "ticks" in the fractional seconds to double fractional nanoseconds, to
> double fractional seconds later on.
> Rationale here might be:
> an integer for the fractional seconds would only make sense if you're
> actually counting in multiples of the tick rate of the individual device
> that will execute the command; it doesn't make sense to tell a device
> that runs with a fixed rate of 100MHz to tune at 12.5ns, but with a B200
> that might as well run at 32MHz, that might make a lot more sense than
> using whole nanoseconds. And then, there are 4G-compatible tick rates
> like 184.32MHz ... . So the double gives you enough precision let you
> correctly represent any "ticked" time for any of the foreseeable devices.
> 
> Best regards,
> Marcus
> 
> On 28.10.2015 06:32, Carel Combrink wrote:
> >
> > Hi Marcus,
> >
> > Thank you for the answers, it helps a lot. 
> >
> >     Regarding the time stamps: Internally (and on the wire), the time
> >     stamps are transmitted as to fixed point numbers for the full
> >     seconds and the fractions of the second. 
> >
>> > Out of curiosity (if I may ask), why is uhd::time_spec_t using a
> > double instead of something like a unsigned long for the fraction
> > part? The timespec struct (in time.h) handles it using a time_t and a
> > long. 
> >
> > Regards,
> >
> >
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151028/e5305971/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 19
> Date: Wed, 28 Oct 2015 14:37:14 +0100
> From: Giovanni MARINO <giovanni.marino at jrc.ec.europa.eu>
> To: usrp-users at lists.ettus.com
> Subject: [USRP-users] Problem with N210 and start GPS time
> Message-ID: <7400db85207a.5630dd9a at jrc.ec.europa.eu>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Hi,?
> I found some examples in order to understand how to set the time for starting data acquisition with a N210 at determined date and hour therefore I wrote the following code:
> 
> ? ? ? ? gps_time=self.uhd_usrp_source_0.get_mboard_sensor("gps_time",0).to_int()
> ? ? ? ? timestamp1 = time.mktime(datetime.now().timetuple()) #in order to check if the epochs are the same.
> ? ? ? ? print "Timenow", timestamp1
> ? ? ? ? print "GPS time", gps_time
> ? ? ? ? start_time='28.10.2015 12:25:00' #(it has be updated)
> ? ? ? ? start_time = time.mktime(time.strptime(start_time,'%d.%m.%Y %H:%M:%S'))
> ? ? ? ? self.uhd_usrp_source_0.set_start_time(uhd.time_spec_t(start_time))
> ? ? ? ? print "Start time:",str(uhd.time_spec_t(start_time).get_real_secs())
> ? ? ? ??self.blocks_file_sink_0 = blocks.file_sink(gr.sizeof_gr_complex*1,"./Data/DatafromN210.dat", False)
> ? ? ? ? self.blocks_file_sink_0.set_unbuffered(False)
> ? ? ? ??
> I suppose that something does not work, because I am not able to save the data into the file (i.e. the file does not contain data as expected).?
> What's wrong with the above-mentioned code?
> Thank you in advance for your time and help.
> Regards
> Giovanni
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151028/7a825efe/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 20
> Date: Wed, 28 Oct 2015 11:12:14 -0400
> From: "Marcus D. Leech" <mleech at ripnet.com>
> To: usrp-users at lists.ettus.com
> Subject: Re: [USRP-users] Problem with N210 and start GPS time
> Message-ID: <5630E5CE.2050704 at ripnet.com>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
> 
> On 10/28/2015 09:37 AM, Giovanni MARINO via USRP-users wrote:
> > Hi,
> > I found some examples in order to understand how to set the time for 
> > starting data acquisition with a N210 at determined date and hour 
> > therefore I wrote the following code:
> > gps_time=self.uhd_usrp_source_0.get_mboard_sensor("gps_time",0).to_int()
> >         timestamp1 = time.mktime(datetime.now().timetuple()) #in order 
> > to check if the epochs are the same.
> >         print "Timenow", timestamp1
> >         print "GPS time", gps_time
> >         start_time='28.10.2015 12:25:00' #(it has be updated)
> >         start_time = time.mktime(time.strptime(start_time,'%d.%m.%Y 
> > %H:%M:%S'))
> > self.uhd_usrp_source_0.set_start_time(uhd.time_spec_t(start_time))
> >         print "Start 
> > time:",str(uhd.time_spec_t(start_time).get_real_secs())
> >       self.blocks_file_sink_0 = 
> > blocks.file_sink(gr.sizeof_gr_complex*1,"./Data/DatafromN210.dat", False)
> >       self.blocks_file_sink_0.set_unbuffered(False)
> > I suppose that something does not work, because I am not able to save 
> > the data into the file (i.e. the file does not contain data as expected).
> > What's wrong with the above-mentioned code?
> > Thank you in advance for your time and help.
> > Regards
> > Giovanni
> >
> Is that the entirety of your code, or just a piece of it?
> 
> If you want to start streaming very far in the future, I'd suggest just 
> using ordinary systemy things to "soak up" most of that time, like a 
> "sleep" or don't actually invoke your
>    program until close to the time you want to start streaming, and then 
> use the timed-streaming to do a more precise start-time.
> 
> 
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151028/e8e99ccb/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 21
> Date: Wed, 28 Oct 2015 16:35:24 +0100
> From: "Lecoq Yann" <Yann.Lecoq at obspm.fr>
> To: "Michael West" <michael.west at ettus.com>
> Cc: USRP-users at lists.ettus.com <USRP-users at lists.ettus.com>
> Subject: Re: [USRP-users] roundtrip delay with x310 and RIO express
> 	card interface
> Message-ID: <4b1d-5630eb00-5-7288de80 at 264053643>
> Content-Type: text/plain; charset="utf-8"
> 
> Hello Michael,
> 
> Thanks for the feed-back and tips.
> 
> I played a little with the sample rate and frame size, with no much improvement. I also tried using sc16 instead of fc32, went from the generic Linux kernel to the low-latency version (Ubuntu 14.04), and used cpufreq-set to get all the 8 "seen" cores (4 hyperthreaded cores in reality, on my intel core i7 laptop processor) at max frequency (2.9GHz).
> 
> With a bit of all these tricks, the best I could get to was about 500?s delay, with still a few L and U packets transmits warning every hour. This points more towards, as you said yourself, a gnuradio (or UHD) latency overhead issue than a PCIe latency issue. I will try again with a PCIe x4 connection when I receive the necessary equipment, just to be sure though.
> 
> Best regards,
> 
> Yann 
> 
> 
> Le Vendredi 23 Octobre 2015 21:25 CEST, Michael West <michael.west at ettus.com> a ?crit: 
>  
> > Hi Yann,
> > 
> > GnuRadio may not be the best to use for lowest latency.  There is overhead
> > added and each block runs in its own thread, so the latency introduced by
> > GnuRadio can be significant.  It is very easy to write a program that
> > receives and immediately sends the received data using the UHD C++ API.
> > One of the many examples packaged with UHD could be easily modified to do
> > that.
> > 
> > The ExpressCard PCIe interface is only x1 and the 10us latency was measured
> > on a PCIe x4 interface.  Furthermore, the latency is only the UHD and
> > transport latency and does not include the DSP chains.  It was tested by
> > taking the timespec from the received packet, adding an offset, sending the
> > packet and checking the asynchronous data to see if a late packet was
> > reported using the UHD C++ API.  Sample rate and frame size will also
> > significantly affect latency.
> > 
> > The simple things to try:
> > 1)  Increase the sample rate.
> > 2)  Reduce frame size.  Add "recv_frame_size=XXX,send_frame_size=XXX" to
> > the device address field (where XXX is the size in bytes).  The default for
> > PCIe is ~8K.
> > 
> > The more drastic things to try:
> > 1)  Use a PCIe x4 connection
> > 2)  Use the UHD C++ API and have a single thread call recv() and send()
> > back to back.
> > 
> > Best regards,
> > Michael
> > 
> > 
> > On Fri, Oct 23, 2015 at 3:19 AM, Lecoq Yann via USRP-users <
> > usrp-users at lists.ettus.com> wrote:
> > 
> > > Hello,
> > >
> > > I am trying to see if I can use a X310 for a (reasonnably fast) servo loop
> > > involving the RX and TX of a UBX160 daughter board. To this aim, I need to
> > > sync the RX and TX and reduce the round trip delay for a signal going from
> > > RX to TX via the host computer as much as possible.
> > >
> > > The test bench for this is a simple gnuradio flowgraph, connected as such:
> > >
> > > ****
> > > usrp source (from RFA/RX)-> delay block -> usrp sink (to RFA/TX)
> > > ****
> > >
> > > In the python file, after declaring the usrp source and sink, I synch them
> > > with:
> > >
> > >         now = self.uhd_usrp_source_0.get_time_now().get_real_secs()
> > >         start = uhd.time_spec(now + 1.3)
> > >         self.uhd_usrp_source_0.set_start_time(start)
> > >         self.uhd_usrp_sink_0.set_start_time(start)
> > >
> > > I feed the RFA/Rx with an external RF synthesizer near 80MHz. The gnuradio
> > > sample rate is 20MSPS. The sinewave produced by this synthesizer is
> > > therefore coppied to the Tx channel, with a fix and predictable delay that
> > > is set by the delayblock value. I can check the delay that is effectivel
> > > realized with an oscilloscope monitoring both the signal from the RF
> > > synthesizer and the signal emmited by the TX. This perfectly agrees with
> > > what is expected from the flowgraph delay block.
> > >
> > > By reducing the delay time, I can get down to 2ms no problem. If I try to
> > > go to 1ms or less, I start loosing samples which, to me, means that the
> > > minimum roundtrip delay is somewhere between 1 and 2ms.
> > >
> > > I am using a X310 with RIO interface on a Express card laptop, and the
> > > website claims a roundtrip latency for this interface "as low as 10?s". I
> > > understand that this is probably obtained in a very specific situation not
> > > necessarly identical to what I have in mind, but I am still puzzled by the
> > > 200x difference between what I obtain as a roundtrip delay and what is
> > > specified.
> > >
> > > Am I doing something wrong ? Is there any way or clever trick to reduce
> > > the round trip delay for a X310 RX to X310 TX in gnuradio ? I understand
> > > that RFNoC may be a possible answer, but if I could get down to a few 100?s
> > > roundtrip delay without ressorting to RFNoC it would be good enough for my
> > > application. Note that I have tried doing the exact same thing in both
> > > Python and C++ Gnuradio, which doesn't do any better.
> > >
> > >
> > > Thanks for any help or hint on this issue.
> > >
> > > -Yann Le Coq
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > USRP-users mailing list
> > > USRP-users at lists.ettus.com
> > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> > >
>  
>  
>  
>  
> 
> 
> 
> 
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 
> 
> ------------------------------
> 
> End of USRP-users Digest, Vol 62, Issue 27
> ******************************************
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151029/81697b68/attachment-0002.html>


More information about the USRP-users mailing list