Send USRP-users mailing list submissions to
[email protected]
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
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Is it possible to launch two differents flow-graphs on the
same usrp ? (Abouda Yassine via USRP-users)
2. Re: Is it possible to launch two differents flow-graphs on
the same usrp ? (Mike Jameson via USRP-users)
3. Re: Debugging Overflow Out of Sequence Errors
(Gareth Crispin via USRP-users)
4. Re: Debugging Overflow Out of Sequence Errors
(Gareth Crispin via USRP-users)
5. Re: Debugging Overflow Out of Sequence Errors
(Gareth Crispin via USRP-users)
----------------------------------------------------------------------
Message: 1
Date: Mon, 19 May 2014 12:28:46 +0200
From: Abouda Yassine via USRP-users <[email protected]>
To: [email protected]
Subject: [USRP-users] Is it possible to launch two differents
flow-graphs on the same usrp ?
Message-ID:
<cahkxc+mzcq1_tjeyywuvppprhjvksf2f8zqo4u+zvxmz5ss...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I would like to know if it is possible to launch for example a program
using one daughterboard and then launch another program on the same USRP
using another daughterboard.
thx!!The error I got was "run time Error".Can I fix it or am I do
something not logic?
reagards,
Yassine
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140519/51c762d8/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 19 May 2014 11:47:27 +0100
From: Mike Jameson via USRP-users <[email protected]>
To: Abouda Yassine <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Is it possible to launch two differents
flow-graphs on the same usrp ?
Message-ID:
<CAJcjmiT1=rWMzxxhng2FgE+JA5uqij-+=6fDVoqikb+G2j+V=w...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
It is possible to use two of the USRP1 daughterboards at once, however you
need to run the code in the same GRC flowgraph in order to utilise the
single UHD interface instance that the USRP is running. You can however use
the "TCP Source" and "TCP Sink" blocks to pump your data stream into a
standalone program from a GRC flowgraph.
Mike
Mike
--
Mike Jameson M0MIK BSc MIET
Ettus Research Technical Support
Email: [email protected]
Web: http://ettus.com
On Mon, May 19, 2014 at 11:28 AM, Abouda Yassine via USRP-users <
[email protected]> wrote:
> Hi,
>
> I would like to know if it is possible to launch for example a program
> using one daughterboard and then launch another program on the same USRP
> using another daughterboard.
> thx!!The error I got was "run time Error".Can I fix it or am I do
> something not logic?
>
> reagards,
> Yassine
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> 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/20140519/e882a774/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 16 May 2014 21:53:20 +0100
From: Gareth Crispin via USRP-users <[email protected]>
To: "Perelman Nathan (Nathan)" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Debugging Overflow Out of Sequence Errors
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
It looks like that card has a kernel driver bug in Centos 6:
http://www.doxer.org/learn-linux/resolved-intel-e1000e-driver-bug-on-82574l-ethernet-controller-causing-network-blipping/
Might be worth following the article above and installing the e1000 driver from
elrepo to see if it helps..
Kind regards,
Gareth
On 15 May 2014, at 17:44, Perelman Nathan (Nathan) via USRP-users
<[email protected]> wrote:
> Thanks for the suggetions.
> I have not confirmed that it is just single packets being dropped.
> Lost packets sometimes correlate with counter increases in the kernel/driver,
> and sometimes do not. When they do, the dropped count from ifconfig and the
> rx_no_buffer_count and rx_missed_errors fields from ethtool -S increase.
> Usually it reports around 1000 dropped packets.
> I did increase the kernel buffer space to 300M.
> I have not changed the default MTU.
> The chip on my NIC is a 82574L. Do you know what specific changes should be
> made to get it to not drop packets? Alternatively, is there a 1x PCI-E
> gigabit NIC you would recommend?
>
> I tried the following things:
> Upgrading to the most recent driver (3.0.4-NAPI)
> Disabling flow control with ethtool -A
> Increasing the rx ring buffers to max with ethtool -G
> Setting these kernel options (found through Google, not really sure exactly
> how some of these are supposed to help): pcie_aspm=off e1000e.IntMode=1,1
> e1000e.InterruptThrottleRate=10000,10000 acpi=off
>
> After all that, I?m still seeing packets being dropped when running
> benchmark_rate:
> ./a.out --rx_cpu=sc16 --mode mimo --args
> addr0=192.168.11.2,addr1=192.168.11.3 --rx_rate 12500000 --channels 0,1
> --duration 7200
> linux; GNU C++ version 4.4.7 20120313 (Red Hat 4.4.7-3); Boost_104100;
> UHD_003.007.001-0-unknown
>
>
> Creating the usrp device with: addr0=192.168.11.2,addr1=192.168.11.3...
> -- Opening a USRP2/N-Series device...
> -- Current recv frame size: 1472 bytes
> -- Current send frame size: 1472 bytes
> Using Device: Multi USRP:
> Device: USRP2 / N-Series Device
> Mboard 0: N210r4
> Mboard 1: N210r4
> RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: SBXv3 RX
> RX Channel: 1
> RX DSP: 0
> RX Dboard: A
> RX Subdev: SBXv3 RX
> TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: SBXv3 TX
> TX Channel: 1
> TX DSP: 0
> TX Dboard: A
> TX Subdev: SBXv3 TX
>
> Testing receive rate 12.500000 Msps on 2 channels
> Receiver error: ERROR_CODE_TIMEOUT
> Unexpected error on recv, continuing...
> DDDDReceiver error: ERROR_CODE_TIMEOUT
> Unexpected error on recv, continuing...
> DDD
> Benchmark rate summary:
> Num received samples: 179990917524
> Num dropped samples: 3918948
> Num overflows detected: 0
> Num transmitted samples: 0
> Num sequence errors: 0
> Num underflows detected: 0
>
>
> Done!
>
>
> A similar test for the other 2 USRPs on the other Ethernet port reports zero
> dropped samples. Any ideas for other things to try or should I just invest in
> a different NIC?
> Thanks.
> -Nathan
>
> From: Ian Buckley [mailto:[email protected]]
> Sent: Friday, May 9, 2014 8:25 PM
> To: Perelman Nathan (Nathan)
> Cc: [email protected]
> Subject: Re: [USRP-users] Debugging Overflow Out of Sequence Errors
>
> A few thoughts Nathan.
> It sounds like you are just loosing single packets at a time, have you
> confirmed this?
> Do lost packets correlate with counter increases in the Kernel/Driver?
> (ifconfig & ethool -S) or are they silently lost?
> Have you followed basic configuration info form here
> (http://files.ettus.com/uhd_docs/manual/html/transport.html)? Particularly
> stuff that increases available kernel buffer space.
> Have you changed the default MTU from 1500 to something larger? This is a
> cause of issues in a surprising number of cases.
> Have you investigated the errata for the exact model of chip used in you NIC?
> In recent years Intel 82574L and 82579LM have both had errata that caused
> random packet loss and there are some configuration fixes for these issues.
> Has your NIC/Kernel decided to enable 802.3x ethernet flow control? (ethtool
> -a). If so disable that. (ethtool -A INTERFACE autoneg off tx off rx off)
>
> -Ian
>
> On May 9, 2014, at 3:37 PM, Perelman Nathan (Nathan) via USRP-users
> <[email protected]> wrote:
>
>
> Any recommendation on debugging overflow out of sequence errors? I can?t seem
> to sustain captures for longer than about 15 minutes without seeing a D
> printed to the output and getting an error, and sometimes get one as soon as
> 30 seconds in.
>
> My setup is as follows:
> UHD 3.7.1 on CentOS 6 (built from source)
> 4 USRP N210s with SBX daughtboards, 2 connected directly to my computer via
> gigabit Ethernet to individual gigabit Ethernet ports on separate subnets,
> the other 2 connected with a MIMO cable to the first 2 USRPs.
> The 2 master USRPs are connected to the same GPS based 1 PPS and 10 MHz
> reference through a splitter. Time_source and clock_source for those is set
> to ?external?
> The 2 slave USRPs have time_source and clock_source set to mimo.
> I?m setting the time using set_time_next_pps() on the 2 master USRPs, and
> checking to make sure the time is synced between all 4 USRPs before starting
> the capture.
> The sample rate for all 4 USRPs is set to 12.5 MHz.
> I?m starting the capture as a continuous stream with a start time 0.5 seconds
> in the future.
> 3.7.1 firmware image flashed on all USRPs.
> One multi_usrp object constructed with all 4 USRPs and recv_buff_size=150e6.
> I?m calling recv() in one thread and then passing the buffers to 4 separate
> threads for writing to files. The files are on an SSD that is not having any
> issues keeping up with the writing.
>
> Thanks.
> -Nathan
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> 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/20140516/d4a94a8b/attachment-0001.html>
------------------------------
Message: 4
Date: Fri, 16 May 2014 22:20:11 +0100
From: Gareth Crispin via USRP-users <[email protected]>
To: "Perelman Nathan (Nathan)" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Debugging Overflow Out of Sequence Errors
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
My apologies - I see you mentioned that already.
There are some other settings in that document that might be useful to try,
namely: disable offloading, auto negotiation, and Active-State Power Management.
Have you ruled out the possibility of dodgy network cables? Do the two USRP?s
that work correctly in the other NIC continue to do so if you plug them into
the 82574L interface, or does the problem migrate?
-Gareth
On 16 May 2014, at 21:56, Perelman Nathan (Nathan)
<[email protected]> wrote:
> Thanks, I already tried building the most recent driver from Intel from
> source though and it did not make a difference.
> -Nathan
>
> From: [email protected] [mailto:[email protected]] On Behalf Of Gareth
> Crispin
> Sent: Friday, May 16, 2014 4:53 PM
> To: Perelman Nathan (Nathan)
> Cc: Ian Buckley; [email protected]
> Subject: Re: [USRP-users] Debugging Overflow Out of Sequence Errors
>
> It looks like that card has a kernel driver bug in Centos 6:
> http://www.doxer.org/learn-linux/resolved-intel-e1000e-driver-bug-on-82574l-ethernet-controller-causing-network-blipping/
>
> Might be worth following the article above and installing the e1000 driver
> from elrepo to see if it helps..
>
> Kind regards,
> Gareth
>
>
> On 15 May 2014, at 17:44, Perelman Nathan (Nathan) via USRP-users
> <[email protected]> wrote:
>
>
> Thanks for the suggetions.
> I have not confirmed that it is just single packets being dropped.
> Lost packets sometimes correlate with counter increases in the kernel/driver,
> and sometimes do not. When they do, the dropped count from ifconfig and the
> rx_no_buffer_count and rx_missed_errors fields from ethtool -S increase.
> Usually it reports around 1000 dropped packets.
> I did increase the kernel buffer space to 300M.
> I have not changed the default MTU.
> The chip on my NIC is a 82574L. Do you know what specific changes should be
> made to get it to not drop packets? Alternatively, is there a 1x PCI-E
> gigabit NIC you would recommend?
>
> I tried the following things:
> Upgrading to the most recent driver (3.0.4-NAPI)
> Disabling flow control with ethtool -A
> Increasing the rx ring buffers to max with ethtool -G
> Setting these kernel options (found through Google, not really sure exactly
> how some of these are supposed to help): pcie_aspm=off e1000e.IntMode=1,1
> e1000e.InterruptThrottleRate=10000,10000 acpi=off
>
> After all that, I?m still seeing packets being dropped when running
> benchmark_rate:
> ./a.out --rx_cpu=sc16 --mode mimo --args
> addr0=192.168.11.2,addr1=192.168.11.3 --rx_rate 12500000 --channels 0,1
> --duration 7200
> linux; GNU C++ version 4.4.7 20120313 (Red Hat 4.4.7-3); Boost_104100;
> UHD_003.007.001-0-unknown
>
>
> Creating the usrp device with: addr0=192.168.11.2,addr1=192.168.11.3...
> -- Opening a USRP2/N-Series device...
> -- Current recv frame size: 1472 bytes
> -- Current send frame size: 1472 bytes
> Using Device: Multi USRP:
> Device: USRP2 / N-Series Device
> Mboard 0: N210r4
> Mboard 1: N210r4
> RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: SBXv3 RX
> RX Channel: 1
> RX DSP: 0
> RX Dboard: A
> RX Subdev: SBXv3 RX
> TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: SBXv3 TX
> TX Channel: 1
> TX DSP: 0
> TX Dboard: A
> TX Subdev: SBXv3 TX
>
> Testing receive rate 12.500000 Msps on 2 channels
> Receiver error: ERROR_CODE_TIMEOUT
> Unexpected error on recv, continuing...
> DDDDReceiver error: ERROR_CODE_TIMEOUT
> Unexpected error on recv, continuing...
> DDD
> Benchmark rate summary:
> Num received samples: 179990917524
> Num dropped samples: 3918948
> Num overflows detected: 0
> Num transmitted samples: 0
> Num sequence errors: 0
> Num underflows detected: 0
>
>
> Done!
>
>
>
> A similar test for the other 2 USRPs on the other Ethernet port reports zero
> dropped samples. Any ideas for other things to try or should I just invest in
> a different NIC?
> Thanks.
> -Nathan
>
> From: Ian Buckley [mailto:[email protected]]
> Sent: Friday, May 9, 2014 8:25 PM
> To: Perelman Nathan (Nathan)
> Cc: [email protected]
> Subject: Re: [USRP-users] Debugging Overflow Out of Sequence Errors
>
> A few thoughts Nathan.
> It sounds like you are just loosing single packets at a time, have you
> confirmed this?
> Do lost packets correlate with counter increases in the Kernel/Driver?
> (ifconfig & ethool -S) or are they silently lost?
> Have you followed basic configuration info form here
> (http://files.ettus.com/uhd_docs/manual/html/transport.html)? Particularly
> stuff that increases available kernel buffer space.
> Have you changed the default MTU from 1500 to something larger? This is a
> cause of issues in a surprising number of cases.
> Have you investigated the errata for the exact model of chip used in you NIC?
> In recent years Intel 82574L and 82579LM have both had errata that caused
> random packet loss and there are some configuration fixes for these issues.
> Has your NIC/Kernel decided to enable 802.3x ethernet flow control? (ethtool
> -a). If so disable that. (ethtool -A INTERFACE autoneg off tx off rx off)
>
> -Ian
>
> On May 9, 2014, at 3:37 PM, Perelman Nathan (Nathan) via USRP-users
> <[email protected]> wrote:
>
>
>
> Any recommendation on debugging overflow out of sequence errors? I can?t seem
> to sustain captures for longer than about 15 minutes without seeing a D
> printed to the output and getting an error, and sometimes get one as soon as
> 30 seconds in.
>
> My setup is as follows:
> UHD 3.7.1 on CentOS 6 (built from source)
> 4 USRP N210s with SBX daughtboards, 2 connected directly to my computer via
> gigabit Ethernet to individual gigabit Ethernet ports on separate subnets,
> the other 2 connected with a MIMO cable to the first 2 USRPs.
> The 2 master USRPs are connected to the same GPS based 1 PPS and 10 MHz
> reference through a splitter. Time_source and clock_source for those is set
> to ?external?
> The 2 slave USRPs have time_source and clock_source set to mimo.
> I?m setting the time using set_time_next_pps() on the 2 master USRPs, and
> checking to make sure the time is synced between all 4 USRPs before starting
> the capture.
> The sample rate for all 4 USRPs is set to 12.5 MHz.
> I?m starting the capture as a continuous stream with a start time 0.5 seconds
> in the future.
> 3.7.1 firmware image flashed on all USRPs.
> One multi_usrp object constructed with all 4 USRPs and recv_buff_size=150e6.
> I?m calling recv() in one thread and then passing the buffers to 4 separate
> threads for writing to files. The files are on an SSD that is not having any
> issues keeping up with the writing.
>
> Thanks.
> -Nathan
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> 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/20140516/cf49a586/attachment-0001.html>
------------------------------
Message: 5
Date: Fri, 16 May 2014 22:24:29 +0100
From: Gareth Crispin via USRP-users <[email protected]>
To: "Perelman Nathan (Nathan)" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Debugging Overflow Out of Sequence Errors
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Also - it might be worth removing the USRP from the picture entirely and focus
on the NIC, if you have another machine you can use to test with, you could try
running iperf to get an idea of bandwidth, delay jitter and datagram loss of
the 82574L vs. your other NIC
This will give you a consistent set of benchmarks and figures to be able to see
whether your changes are helping to address the issue, or making things worse...
On 16 May 2014, at 22:20, Gareth Crispin <[email protected]> wrote:
> My apologies - I see you mentioned that already.
>
> There are some other settings in that document that might be useful to try,
> namely: disable offloading, auto negotiation, and Active-State Power
> Management.
>
> Have you ruled out the possibility of dodgy network cables? Do the two USRP?s
> that work correctly in the other NIC continue to do so if you plug them into
> the 82574L interface, or does the problem migrate?
>
> -Gareth
>
>
> On 16 May 2014, at 21:56, Perelman Nathan (Nathan)
> <[email protected]> wrote:
>
>> Thanks, I already tried building the most recent driver from Intel from
>> source though and it did not make a difference.
>> -Nathan
>>
>> From: [email protected] [mailto:[email protected]] On Behalf Of Gareth
>> Crispin
>> Sent: Friday, May 16, 2014 4:53 PM
>> To: Perelman Nathan (Nathan)
>> Cc: Ian Buckley; [email protected]
>> Subject: Re: [USRP-users] Debugging Overflow Out of Sequence Errors
>>
>> It looks like that card has a kernel driver bug in Centos 6:
>> http://www.doxer.org/learn-linux/resolved-intel-e1000e-driver-bug-on-82574l-ethernet-controller-causing-network-blipping/
>>
>> Might be worth following the article above and installing the e1000 driver
>> from elrepo to see if it helps..
>>
>> Kind regards,
>> Gareth
>>
>>
>> On 15 May 2014, at 17:44, Perelman Nathan (Nathan) via USRP-users
>> <[email protected]> wrote:
>>
>>
>> Thanks for the suggetions.
>> I have not confirmed that it is just single packets being dropped.
>> Lost packets sometimes correlate with counter increases in the
>> kernel/driver, and sometimes do not. When they do, the dropped count from
>> ifconfig and the rx_no_buffer_count and rx_missed_errors fields from ethtool
>> -S increase. Usually it reports around 1000 dropped packets.
>> I did increase the kernel buffer space to 300M.
>> I have not changed the default MTU.
>> The chip on my NIC is a 82574L. Do you know what specific changes should be
>> made to get it to not drop packets? Alternatively, is there a 1x PCI-E
>> gigabit NIC you would recommend?
>>
>> I tried the following things:
>> Upgrading to the most recent driver (3.0.4-NAPI)
>> Disabling flow control with ethtool -A
>> Increasing the rx ring buffers to max with ethtool -G
>> Setting these kernel options (found through Google, not really sure exactly
>> how some of these are supposed to help): pcie_aspm=off e1000e.IntMode=1,1
>> e1000e.InterruptThrottleRate=10000,10000 acpi=off
>>
>> After all that, I?m still seeing packets being dropped when running
>> benchmark_rate:
>> ./a.out --rx_cpu=sc16 --mode mimo --args
>> addr0=192.168.11.2,addr1=192.168.11.3 --rx_rate 12500000 --channels 0,1
>> --duration 7200
>> linux; GNU C++ version 4.4.7 20120313 (Red Hat 4.4.7-3); Boost_104100;
>> UHD_003.007.001-0-unknown
>>
>>
>> Creating the usrp device with: addr0=192.168.11.2,addr1=192.168.11.3...
>> -- Opening a USRP2/N-Series device...
>> -- Current recv frame size: 1472 bytes
>> -- Current send frame size: 1472 bytes
>> Using Device: Multi USRP:
>> Device: USRP2 / N-Series Device
>> Mboard 0: N210r4
>> Mboard 1: N210r4
>> RX Channel: 0
>> RX DSP: 0
>> RX Dboard: A
>> RX Subdev: SBXv3 RX
>> RX Channel: 1
>> RX DSP: 0
>> RX Dboard: A
>> RX Subdev: SBXv3 RX
>> TX Channel: 0
>> TX DSP: 0
>> TX Dboard: A
>> TX Subdev: SBXv3 TX
>> TX Channel: 1
>> TX DSP: 0
>> TX Dboard: A
>> TX Subdev: SBXv3 TX
>>
>> Testing receive rate 12.500000 Msps on 2 channels
>> Receiver error: ERROR_CODE_TIMEOUT
>> Unexpected error on recv, continuing...
>> DDDDReceiver error: ERROR_CODE_TIMEOUT
>> Unexpected error on recv, continuing...
>> DDD
>> Benchmark rate summary:
>> Num received samples: 179990917524
>> Num dropped samples: 3918948
>> Num overflows detected: 0
>> Num transmitted samples: 0
>> Num sequence errors: 0
>> Num underflows detected: 0
>>
>>
>> Done!
>>
>>
>>
>> A similar test for the other 2 USRPs on the other Ethernet port reports zero
>> dropped samples. Any ideas for other things to try or should I just invest
>> in a different NIC?
>> Thanks.
>> -Nathan
>>
>> From: Ian Buckley [mailto:[email protected]]
>> Sent: Friday, May 9, 2014 8:25 PM
>> To: Perelman Nathan (Nathan)
>> Cc: [email protected]
>> Subject: Re: [USRP-users] Debugging Overflow Out of Sequence Errors
>>
>> A few thoughts Nathan.
>> It sounds like you are just loosing single packets at a time, have you
>> confirmed this?
>> Do lost packets correlate with counter increases in the Kernel/Driver?
>> (ifconfig & ethool -S) or are they silently lost?
>> Have you followed basic configuration info form here
>> (http://files.ettus.com/uhd_docs/manual/html/transport.html)? Particularly
>> stuff that increases available kernel buffer space.
>> Have you changed the default MTU from 1500 to something larger? This is a
>> cause of issues in a surprising number of cases.
>> Have you investigated the errata for the exact model of chip used in you
>> NIC? In recent years Intel 82574L and 82579LM have both had errata that
>> caused random packet loss and there are some configuration fixes for these
>> issues.
>> Has your NIC/Kernel decided to enable 802.3x ethernet flow control? (ethtool
>> -a). If so disable that. (ethtool -A INTERFACE autoneg off tx off rx off)
>>
>> -Ian
>>
>> On May 9, 2014, at 3:37 PM, Perelman Nathan (Nathan) via USRP-users
>> <[email protected]> wrote:
>>
>>
>>
>> Any recommendation on debugging overflow out of sequence errors? I can?t
>> seem to sustain captures for longer than about 15 minutes without seeing a D
>> printed to the output and getting an error, and sometimes get one as soon as
>> 30 seconds in.
>>
>> My setup is as follows:
>> UHD 3.7.1 on CentOS 6 (built from source)
>> 4 USRP N210s with SBX daughtboards, 2 connected directly to my computer via
>> gigabit Ethernet to individual gigabit Ethernet ports on separate subnets,
>> the other 2 connected with a MIMO cable to the first 2 USRPs.
>> The 2 master USRPs are connected to the same GPS based 1 PPS and 10 MHz
>> reference through a splitter. Time_source and clock_source for those is set
>> to ?external?
>> The 2 slave USRPs have time_source and clock_source set to mimo.
>> I?m setting the time using set_time_next_pps() on the 2 master USRPs, and
>> checking to make sure the time is synced between all 4 USRPs before starting
>> the capture.
>> The sample rate for all 4 USRPs is set to 12.5 MHz.
>> I?m starting the capture as a continuous stream with a start time 0.5
>> seconds in the future.
>> 3.7.1 firmware image flashed on all USRPs.
>> One multi_usrp object constructed with all 4 USRPs and recv_buff_size=150e6.
>> I?m calling recv() in one thread and then passing the buffers to 4 separate
>> threads for writing to files. The files are on an SSD that is not having any
>> issues keeping up with the writing.
>>
>> Thanks.
>> -Nathan
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> 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/20140516/7abacce3/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 45, Issue 17
******************************************
