[USRP-users] multiple N200 devices

Marcus D. Leech mleech at ripnet.com
Mon Dec 1 22:01:29 EST 2014


On 12/01/2014 09:53 PM, Dan Sego wrote:
> Thank you Marcus.
>
> I bow to your wisdom on the registry change. However there is no such 
> entity
> |Program Files <x86>/UHD/share/uhd/FastSendDatagramThreshold.reg|
> |
> |
> In the latest UHD installation (taken from 
> http://files.ettus.com/manual/page_transport.html#transport_udp_windows).
>
> Searching the complete C: directory produced no hits.
>
> I did find it at 
> http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/86c32704e864e42651a7d1529436acbbe7eeb96e
> dated April 2012, and downloaded it.
>
> I have Windows 8 (unfortunately). The UHD support page only extends to 
> Windows 7. Issue?
>
> Looking at the advanced properties of the network adapter (receive 
> 512, transmit 128) will the registry edit be reflected in these values?
>
> Good evening. Dan
Hmmm, not sure what that file is no longer there.   Here is some 
Microsoft support information about that registry value:

http://support.microsoft.com/kb/235257/en-us

That particular registry value is unrelated to specific adaptors, but 
rather to the network stack as a whole.


>
> On Sun, Nov 30, 2014 at 1:18 PM, Marcus D. Leech <mleech at ripnet.com 
> <mailto:mleech at ripnet.com>> wrote:
>
>     On 11/30/2014 04:13 PM, Dan Sego wrote:
>>     Again thank you. To avoid confusion, the error I'm referring to
>>     as this one (from the first message)
>>
>>     "Error: RuntimeError: fifo cntl timed out looking for acks"
>>
>>     which appeared during or after the "Creating UDP step". This did
>>     not occur using a ThinkPad and single N200 unit and without a
>>     registry change (though the UHD Warning on packet size was
>>     received...The MTU (1472) is larger than the
>>     FastSendDataGramThreshold (1024)! This will negatively
>>     affect.....). I still receive that warning before the error above
>>     occurs.
>>
>>     I continue to launch the program until success occurs. At that
>>     point....
>>
>>     Using to_pp_string I print "addr" which returns the correct
>>     addresses (addr0 to .10.3 and addr1 to .10.2). I appears that I
>>     am doing that correctly.
>>
>>     After "Clock Source Set"  usrp returns
>>
>>     Using Device: Multi USRP
>>        Device: USRP2 / N-Series Device
>>        Mboard 0: N200r4
>>        Mboard1: N200r4
>>        Rx Channel: 0
>>           RX DSP: 0
>>           RX Board: A
>>           RX Subdev: WBXv3 RX+GDB
>>        Rx Channel: 1
>>           RX DSP: 0
>>           RX Board: A
>>           RX Subdev: WBXv3 RX+GDB
>>        Tx Channel: 0
>>           TX DSP: 0
>>           TX Board: A
>>           TX Subdev: WBXv3 RX+GDB
>>       Tx Channel: 1
>>           TX DSP: 0
>>           TX Board: A
>>           TX Subdev: WBXv3 RX+GDB
>>
>>     I'm reluctant to muck about with the registry as a non-windows
>>     specialist.
>>
>>     vr Dan
>     Could you please copy your replies to the usrp-users mailng list,
>     as others can benefit from the discussion, and other Ettus folks
>     can also
>       contribute to a possible solution.
>
>     I strongly suggest that you modify the FastDataGramSendThreshold,
>     as described in the online manual for Windows.  Without this,
>     things are
>       happening on the slow path, which may be contributing to your
>     problem.
>
>     Also, if you ping the two devices, does that yield reliable results?
>
>
>
>
>>
>>     On Sun, Nov 30, 2014 at 11:54 AM, Marcus D. Leech
>>     <mleech at ripnet.com <mailto:mleech at ripnet.com>> wrote:
>>
>>         On 11/30/2014 02:21 PM, Dan Sego wrote:
>>>         The error is occurring at the creation of the creation of
>>>         the usrp device
>>>
>>>         uhd::device_addr_t dev_addr;
>>>
>>>         dev_addr["addr0"] = "192.168.10.3";
>>>
>>>         dev_addr["addr1"] = "192.168.10.2";
>>>
>>>         uhd::usrp::multi_usrp::sptr usrp =
>>>         uhd::usrp::multi_usrp::make(dev_addr);
>>>
>>>         I was aware of the max rate (though I had hoped to finesse
>>>         it to a higher rate - 2x - because I'm sampling in bursts at
>>>         a duty factor of 20% instead of continuous streaming - duty
>>>         of 100%).
>>>
>>>         If NIC is "network interface card" I have a brand new Lenovo
>>>         I7 Ideapad with the Realtek PCIe GBE family controller.
>>>
>>>         Registry changes - no.
>>>
>>>
>>>         Dan
>>>
>>
>>         See:
>>
>>         http://files.ettus.com/manual/page_transport.html#transport_udp_windows
>>
>>         and
>>
>>         http://files.ettus.com/manual/page_usrp2.html#usrp2_mimocable_shared
>>
>>
>>
>>
>>>
>>>         On Sun, Nov 30, 2014 at 11:09 AM, Marcus D. Leech
>>>         <mleech at ripnet.com <mailto:mleech at ripnet.com>> wrote:
>>>
>>>             On 11/30/2014 02:01 PM, Dan Sego wrote:
>>>>             correct. Requested sample rate is 12.5E+06 in bursts of
>>>>             10k samples..
>>>>
>>>>             The error occurs, at the earliest, after the UDP
>>>>             transport is opened for the first unit (-- Creating WSA
>>>>             UPD transport for 192.168.10.3:XXXXX, which occurs 4
>>>>             times), sometimes after the UDP transport for the
>>>>             second device (-- Creating WSA UPD transport for
>>>>             192.168.10.2:XXXXX, which also occurs 4 times). The
>>>>             "sequence" of the error in the flow is not the same.
>>>>
>>>>             If the execution gets past the "--Detecting internal
>>>>             GPSDO......No GPSDO found" message then it runs to
>>>>             completion.
>>>>
>>>>             I have print statements to echo the setup at each
>>>>             point with the last one after the creation of the
>>>>             rx_streamer, to localize problems
>>>>
>>>>             vr Dan
>>>             How are you addressing the devices in your code?
>>>
>>>             2 x 12.5e6 SPS is the absolute maximum you can channel
>>>             over a single 1GiGe connection.  See if there's a
>>>             relationship to sample-rate in the
>>>               emergence of the problem. What kind of NIC are you
>>>             using?  Have you applied the registry changes that are
>>>             recommended for enabling
>>>               "fast path" processing on Windows?
>>>
>>>
>>>
>>>>
>>>>             On Sun, Nov 30, 2014 at 10:47 AM, Marcus D. Leech
>>>>             <mleech at ripnet.com <mailto:mleech at ripnet.com>> wrote:
>>>>
>>>>                 On 11/30/2014 01:45 PM, Dan Sego wrote:
>>>>>                 Sorry. No the devices are on MIMO cable
>>>>                 OK, so you're using shared-ethernet mode (that is,
>>>>                 there's a single cable between your host and the
>>>>                 "master" USRP)
>>>>
>>>>
>>>>                 What sample rate are you trying to use?
>>>>
>>>>
>>>>
>>>>>
>>>>>                 On Sun, Nov 30, 2014 at 10:40 AM, Marcus D. Leech
>>>>>                 <mleech at ripnet.com <mailto:mleech at ripnet.com>> wrote:
>>>>>
>>>>>                     On 11/30/2014 01:34 PM, Dan Sego wrote:
>>>>>>                     Thank you once again. The address change was
>>>>>>                     successful. Might you be able to offer any
>>>>>>                     suggestion on the runtime error? With a
>>>>>>                     single N200 operating the likelihood of
>>>>>>                     experiencing the error was 4:10 tries to
>>>>>>                     execute the C++ code. With the two channel
>>>>>>                     code it has degraded to < 1:10 tries.
>>>>>>
>>>>>>                     cheers! Dan
>>>>>                     Did you power-cycle the device after changing
>>>>>                     the IP address?
>>>>>
>>>>>                     These devices are on a switch, no doubt?
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>                     On Fri, Nov 28, 2014 at 7:25 PM, Marcus D.
>>>>>>                     Leech via USRP-users
>>>>>>                     <usrp-users at lists.ettus.com
>>>>>>                     <mailto:usrp-users at lists.ettus.com>> wrote:
>>>>>>
>>>>>>                         On 11/28/2014 10:18 PM, Dan Sego via
>>>>>>                         USRP-users wrote:
>>>>>>>                         Good evening the List.
>>>>>>>
>>>>>>>                         I have two N200 devices connected by
>>>>>>>                         MIMO cable. Running und_find_devices
>>>>>>>                         returns:
>>>>>>>
>>>>>>>                         Win32; Microsoft Visual C++ version
>>>>>>>                         10.0; Boost_105400; UHD_003.008.000-release
>>>>>>>                         --------------------------------------------------
>>>>>>>                         -- UHD Device 0
>>>>>>>                         --------------------------------------------------
>>>>>>>                         Device Address:
>>>>>>>                             type: usrp2
>>>>>>>                             addr: 192.168.10.2
>>>>>>>                             name:
>>>>>>>                             serial: F4B96A
>>>>>>>
>>>>>>>                         --------------------------------------------------
>>>>>>>                         -- UHD Device 1
>>>>>>>                         --------------------------------------------------
>>>>>>>                         Device Address:
>>>>>>>                             type: usrp2
>>>>>>>                             addr: 192.168.10.2
>>>>>>>                             name:
>>>>>>>                             serial: F4B96A
>>>>>>>
>>>>>>>                         Should the addresses be the same? I've
>>>>>>>                         looked at several code examples where
>>>>>>>                         addr:198.162.10.2 is used for device 0
>>>>>>>                         and 198.162.10.3 for device 1.
>>>>>>>
>>>>>>>                         Running the sampling routine (derived
>>>>>>>                         from rx_multi_usrp.cpp) with the same
>>>>>>>                         address produces the following output
>>>>>>>
>>>>>>>                         in32; Microsoft Visual C++ version 10.0;
>>>>>>>                         Boost_105400; UHD_003.008.000-release
>>>>>>>
>>>>>>>                         -- Opening a USRP2/N-Series device...
>>>>>>>                         -- Current recv frame size: 1472 bytes
>>>>>>>                         -- Current send frame size: 1472 bytes
>>>>>>>                         -- Creating WSA UDP transport for
>>>>>>>                         192.168.10.2:49156
>>>>>>>                         <http://192.168.10.2:49156>
>>>>>>>                         -- Creating WSA UDP transport for
>>>>>>>                         192.168.10.2:49158
>>>>>>>                         <http://192.168.10.2:49158>
>>>>>>>                         -- Creating WSA UDP transport for
>>>>>>>                         192.168.10.2:49157
>>>>>>>                         <http://192.168.10.2:49157>
>>>>>>>                         -- Creating WSA UDP transport for
>>>>>>>                         192.168.10.2:49159
>>>>>>>                         <http://192.168.10.2:49159>
>>>>>>>                         -- Creating WSA UDP transport for
>>>>>>>                         192.168.10.2:49156
>>>>>>>                         <http://192.168.10.2:49156>
>>>>>>>                         -- Creating WSA UDP transport for
>>>>>>>                         192.168.10.2:49158
>>>>>>>                         <http://192.168.10.2:49158>
>>>>>>>                         -- Creating WSA UDP transport for
>>>>>>>                         192.168.10.2:49157
>>>>>>>                         <http://192.168.10.2:49157>
>>>>>>>                         -- Creating WSA UDP transport for
>>>>>>>                         192.168.10.2:49159
>>>>>>>                         <http://192.168.10.2:49159>
>>>>>>>                         Error: RuntimeError: fifo cntl timed out
>>>>>>>                         looking for acks
>>>>>>>
>>>>>>>                         Not shown on the command line output is
>>>>>>>                         the following
>>>>>>>                         UHD Warning:
>>>>>>>
>>>>>>>
>>>>>>>                         I am able to read successively using a
>>>>>>>                         single device (and single channel s/w)
>>>>>>>                         but approximately 50% of the times I
>>>>>>>                         launch a collect I receive the same error
>>>>>>>
>>>>>>>                         Any suggestions would be helpful.
>>>>>>>                         Cheers. Dan Sego
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                         _______________________________________________
>>>>>>>                         USRP-users mailing list
>>>>>>>                         USRP-users at lists.ettus.com  <mailto:USRP-users at lists.ettus.com>
>>>>>>>                         http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>                         The devices leave the factory with a
>>>>>>                         192.168.10.2 IP address. You have to
>>>>>>                         reprogram that address if you want
>>>>>>                         something different:
>>>>>>
>>>>>>                         http://files.ettus.com/manual/page_usrp2.html#usrp2_network
>>>>>>
>>>>>>                         The requirement for distinct devices to
>>>>>>                         have distinct IP addresses is fundamental
>>>>>>                         to IP networking.
>>>>>>
>>>>>>
>>>>>>
>>>>>>                         _______________________________________________
>>>>>>                         USRP-users mailing list
>>>>>>                         USRP-users at lists.ettus.com
>>>>>>                         <mailto:USRP-users at lists.ettus.com>
>>>>>>                         http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>                     -- 
>>>>>                     Marcus Leech
>>>>>                     Principal Investigator
>>>>>                     Shirleys Bay Radio Astronomy Consortium
>>>>>                     http://www.sbrac.org
>>>>>
>>>>>
>>>>
>>>>
>>>>                 -- 
>>>>                 Marcus Leech
>>>>                 Principal Investigator
>>>>                 Shirleys Bay Radio Astronomy Consortium
>>>>                 http://www.sbrac.org
>>>>
>>>>
>>>
>>>
>>>             -- 
>>>             Marcus Leech
>>>             Principal Investigator
>>>             Shirleys Bay Radio Astronomy Consortium
>>>             http://www.sbrac.org
>>>
>>>
>>
>>
>>         -- 
>>         Marcus Leech
>>         Principal Investigator
>>         Shirleys Bay Radio Astronomy Consortium
>>         http://www.sbrac.org
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141201/3e0651d9/attachment-0002.html>


More information about the USRP-users mailing list