[USRP-users] Using 4 USRP with a Gigabit switch

Damien Serant damien.serant at gmail.com
Thu Feb 7 19:13:04 EST 2013


Thanks for your help. My problem is solved but i added some
answers/comments here below.

"Are you requesting continuous or finite streaming?"
I was using a continuous streaming.  The number of received samples is
equal to the requested one.
I tried the progressive approach as you suggested:
 - 1 USRP : OK
 - 2 USRP : OK
 - 3 USRP : OK
 - 4 USRP : KO -> 30 sec to acquire 5 seconds.
I suspected a problem with my network card so i tried on another PC (a
laptop) and it works fine with 4 USRP even at 5MHz sampling freq ! So
problem solved
FYI the network card that was the source of the problem is a broadcom
NetXtreme Gigabit Ethernet. You can see the configurable parmaters of this
card on the screenshoot hare attached, may be one of them is causing the
problem ?
In addition during my test to write the receievd sample on HHD, i noticed
that use C-style files (FILE *) is much more efficient than usint C++-style
files (ofstream). The difference is spectacular : with the C-style file i
write 50 MB/s in real time, with C++-style, the first slow-down appears at
16 MB/s. Someone has already observed that ?

[image: Images intégrées 1]


2013/2/7 Josh Blum <josh at ettus.com>

>
>
> On 02/06/2013 03:14 PM, Damien Serant wrote:
> > Hi list,
> >
> > I am experiencing some issue with my configuration using an Ethernet
> switch
> > even if i read on the list that it should work seamlessly . Here is the
> > situation:
> >  - I use 2 pairs of USRPN200. In each pair, the 2 USRP are connected
> > together with a MIMO cable, and the master USRP of each pair has the
> > internal GPSDO from Ettus.
> >  - The master USRP of each pair is connected to a Netgear 8 port Gigabit
> > switch.
> >  - My PC is also connected to this switch.
> >  - I wrote a simple UHD program (based on multi_sample_to_file) to record
> > the sample of each USRP. I use 1 multi_usrp object constructed with the 4
> > IP address of my USRP2 (all different of course). 1 have 1 rx_stream
> mapped
> > over my four channels so obtained.
> > - I record 4 files as expected, but the program spends more than 30
> seconds
> > to record 5 seconds of signal as if there was some bottle-neck somewhere
> > (the same without writing to the HDD). The problem is that the sampling
> > frequency is 200 kHz so the Gigabit network should handle that without
> any
> > issue, no ?
> >
>
> That sounds like a few MB worth of data. Shouldnt take much time at all.
>
> Are you requesting continuous or finite streaming? I would recommend to
> first count the number of samples coming out of the recv() call and make
> sure its what is expected.
>
> I guess another good approach would be to add in one device at a time
> and see where the application starts getting funny / breaking assumptions.



>
> > So my conclusion is that i am doing wrong somewhere. Actually i'm not
> sure
> > how to handle my 4 usrp with UHD:
> >  - Treat each USRP pair in different USRP object ?
> >  - Use one multi_usrp object, but one rx_stream per pair ?
> >  - Execute multi_sample_to_file.exe for each pair ? -> i tried this
> > solution but it does not work : the files of one of two pair remains
> empty.
>
> All of those options should work. Usually ganging all 4 devices together
> into one object is a just convenience for dealing w/ alignment.
>

> -josh
>
> >
> > Thanks in advance
> > Damien
> >
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > 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/20130208/77905634/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 19934 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130208/77905634/attachment.png>


More information about the USRP-users mailing list