Hi, I'm using the same cable in both cases. And both of them are connected to port 1. Have you come across this problem before? In the email list, rob mentioned it, too. Best regards, Xinke 在 2015-05-21 06:57:11，"Marcus D. Leech" <mleech@ripnet.com> 写道： >On 05/20/2015 06:53 PM, Xinke Zhang wrote: >> Hi, >> >> I drop it down to 8000, but it still cannot work. >> >> And I borrowed a usrp x300 yesterday, and tested it with my host PC. It worked with mtu size specified to 9000. >> >> Now I suspect it is a hardware specific problem.pls help check it. Thank you. >> >> Best regards, >> Xinke >Are you using the same cable in both cases (X310 and X300)? What about >which port on the X3xx? Is that the same? > >>> On 05/20/2015 06:31 PM, Xinke Zhang via USRP-users wrote: >>> Hi Rob, >>> >>> Thank you for your info. >>> >>> Hi Marcus, >>> >>> Do you have a solution for this mtu specific problem? Thank you. >>> >>> Best regards, >>> Xinke >>> That likekly means that your kernel/hardware/drivers don't support >>> larger MTU. Try dropping it down to 8000, and see if that works. >>> I've found that some hardware will claim to set a large MTU, but in >>> fact, it isn't. It happily takes the command from ethtool, but actually >>> silently ignores >>> or truncates the MTU request. >> >>> 在 2015-05-20 21:34:50，"Rob Kossler" <rkossler at nd.edu> 写道： >>> >>>> I have also seen problems with channel 1 of a 2 channel X310 not working (in the same or similar manner as described). I have several X310 devices, but have only noticed this issue with one of them. In my case I am usually able to "fix" the issue by power-cycling the X310 (sometimes it takes multiple times). It seems that once it is in a "good" state, it stays that way as long as it remains powered up. >>>> >>>> >>>> Rob >>>> >>>> >>>> On Wed, May 20, 2015 at 4:43 AM, Xinke Zhang via USRP-users <usrp-users at lists.ettus.com> wrote: >>>> >>>> >>>> Hi, >>>> >>>> "benchmark_rate --rx_rate 10e6 --channels 0,1" didn't work, too. >>>> >>>> when i changed the mtu size from 9000 to 1500, "benchmark_rate --rx_rate 10e6" with " --channels 0", "--channels 1", and "--channels 0,1"all worked, but there are some warning which are about mtu size is too small. In the "system configuration for usrp x3x0 series", it mentions that when using the 10 gigabit nic, we should change the mtu size to 9000. and now i only can use mtu size 1500 for 10gigabit nic. why? >>>> >>>> Best Regards, >>>> >>>> Xinke >>>> >>>> >>>> -----Original Messages----- >>>> From: "Marcus Müller" <marcus.mueller at ettus.com> >>>> Sent Time: Wednesday, May 20, 2015 >>>> To: "Xinke Zhang" <zhangxinke at iie.ac.cn> >>>> Cc:mleech at ripnet.com, usrp-users at lists.ettus.com >>>> >>>> Subject: Re: [USRP-users] benchmark_rate error: usrp x310 with intel adapter x520 (10 gigabit network) >>>> >>>> So you have two; my first intuition was that maybe something goes wrong when you only have one daughterboard in slot A, but try to get channel 1. >>>> Does --channel 0,1 work? >>>> >>>> Best regards, >>>> Marcus >>>> >>>> >>>> On 05/20/2015 10:00 AM, Xinke Zhang wrote: >>>> >>>> >>>> Hi, >>>> >>>> the version of daughterboards used is sbx-120. >>>> >>>> Best Regards, >>>> >>>> Xinke >>>> >>>> >>>> -----Original Messages----- >>>> From: "Marcus Müller" <marcus.mueller at ettus.com> >>>> Sent Time: Wednesday, May 20, 2015 >>>> To: "Xinke Zhang" <zhangxinke at iie.ac.cn>, mleech at ripnet.com >>>> Cc:usrp-users at lists.ettus.com >>>> Subject: Re: [USRP-users] benchmark_rate error: usrp x310 with intel adapter x520 (10 gigabit network) >>>> >>>> Hi, >>>> what are your daughterboards? >>>> >>>> Best regards, >>>> Marcus >>>> >>>> >>>> On 05/20/2015 04:38 AM, Xinke Zhang wrote: >>>> >>>> >>>> Hi, >>>> >>>> I found another interesting problem. Here's the detailed description: >>>> >>>> 1. i used the "benchmark_rate --rx_rate 10e6 --channels 0", and it was ok. >>>> >>>> 2. i used the "benchmark_rate --rx_rate 10e6 --channels 1", and it reseulted into the overflow state. the console ouput was "Receive error: ERROR_CODE_TIMEOUT, Unexpected error on recv, continuing...". >>>> >>>> in conclusion, the only difference between them is channel index (one is channel 0, and the other is channel 1). pls help me check what will cause this problem. >>>> >>>> Best Regards, >>>> >>>> Xinke Zhang >>>> >>>> >>>> On 05/19/2015 08:29 AM, Marcus D. Leech via USRP-users wrote: >>>> >>>>>> On 05/19/2015 03:10 AM, Marcus Müller via USRP-users wrote: >>>>>> Hello Xinke, >>>>>>>> this is indeed interesting, on many levels: >>>>>> You're successfully sending 100MS/s (no "U"s, right?), so your >>>>>> computer doesn't seem to be underpowered; the very asymmetric way that >>>>>> 10MS/s RX fails leads me to believe that there might be something >>>>>> wrong with receiving at all. >>>>>> Can you try >>>>>> rx_samples_to_file --rate 10e6 --duration 5 --file rx.dat >>>>>> and see if the resulting file rx.dat has nonzero size (in an ideal >>>>>> world, it would be 200,000,000B in size, around 190MiB). >>>>>>>> Best regards, >>>>>> Marcus >>>>>>> Also, what OS? Is it up-to-date? >>>>> What is the cabling setup between the X310 and the host PC? >>>>> >>>>> >>>>>>> On 05/19/2015 08:33 AM, Xinke Zhang via USRP-users wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>> My goal is to test the 2 simultaneous *rx* of single usrp x310 with >>>>>>> intel adapter x520 (*10 gigabit network*). i used the benchmark_rate >>>>>>> function provided by uhd examples (benchmark_rate --*rx*_rate 10e6 >>>>>>> --channels 0,1), but i got the overflow error. when i tried to >>>>>>> decreased the *rx*_rate, console ouptut was still overflow. Howerver, >>>>>>> when i tested 2 simultaneous *tx* of single usrp x310 with intel >>>>>>> adapter x520 (10 gigabit network) (benchmark_rate --*tx*_rate 10e6 >>>>>>> --channels 0,1), it was successful. i even changed the *tx*_rate to >> >> >

Hi Rob/Xinke, Did either of you try swapping the daughter boards to see if the problem followed (i.e. moved to channel 0)? Also, how frequently does the problem occur (i.e. how many power cycles does it take to reproduce)? Rob - What daughter board(s) did you see the issue on? Regards, Michael On Wed, May 20, 2015 at 4:01 PM, Xinke Zhang via USRP-users <usrp-users@lists.ettus.com> wrote: > Hi, > > I'm using the same cable in both cases. And both of them are connected to port 1. Have you come across this problem before? In the email list, rob mentioned it, too. > > Best regards, > Xinke > > > 在 2015-05-21 06:57:11，"Marcus D. Leech" <mleech@ripnet.com> 写道： > >>On 05/20/2015 06:53 PM, Xinke Zhang wrote: >>> Hi, >>> >>> I drop it down to 8000, but it still cannot work. >>> >>> And I borrowed a usrp x300 yesterday, and tested it with my host PC. It worked with mtu size specified to 9000. >>> >>> Now I suspect it is a hardware specific problem.pls help check it. Thank you. >>> >>> Best regards, >>> Xinke >>Are you using the same cable in both cases (X310 and X300)? What about >>which port on the X3xx? Is that the same? >> >>>> On 05/20/2015 06:31 PM, Xinke Zhang via USRP-users wrote: >>>> Hi Rob, >>>> >>>> Thank you for your info. >>>> >>>> Hi Marcus, >>>> >>>> Do you have a solution for this mtu specific problem? Thank you. >>>> >>>> Best regards, >>>> Xinke >>>> That likekly means that your kernel/hardware/drivers don't support >>>> larger MTU. Try dropping it down to 8000, and see if that works. >>>> I've found that some hardware will claim to set a large MTU, but in >>>> fact, it isn't. It happily takes the command from ethtool, but actually >>>> silently ignores >>>> or truncates the MTU request. >>> >>>> 在 2015-05-20 21:34:50，"Rob Kossler" <rkossler at nd.edu> 写道： >>>> >>>>> I have also seen problems with channel 1 of a 2 channel X310 not working (in the same or similar manner as described). I have several X310 devices, but have only noticed this issue with one of them. In my case I am usually able to "fix" the issue by power-cycling the X310 (sometimes it takes multiple times). It seems that once it is in a "good" state, it stays that way as long as it remains powered up. >>>>> >>>>> >>>>> Rob >>>>> >>>>> >>>>> On Wed, May 20, 2015 at 4:43 AM, Xinke Zhang via USRP-users <usrp-users at lists.ettus.com> wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> "benchmark_rate --rx_rate 10e6 --channels 0,1" didn't work, too. >>>>> >>>>> when i changed the mtu size from 9000 to 1500, "benchmark_rate --rx_rate 10e6" with " --channels 0", "--channels 1", and "--channels 0,1"all worked, but there are some warning which are about mtu size is too small. In the "system configuration for usrp x3x0 series", it mentions that when using the 10 gigabit nic, we should change the mtu size to 9000. and now i only can use mtu size 1500 for 10gigabit nic. why? >>>>> >>>>> Best Regards, >>>>> >>>>> Xinke >>>>> >>>>> >>>>> -----Original Messages----- >>>>> From: "Marcus Müller" <marcus.mueller at ettus.com> >>>>> Sent Time: Wednesday, May 20, 2015 >>>>> To: "Xinke Zhang" <zhangxinke at iie.ac.cn> >>>>> Cc:mleech at ripnet.com, usrp-users at lists.ettus.com >>>>> >>>>> Subject: Re: [USRP-users] benchmark_rate error: usrp x310 with intel adapter x520 (10 gigabit network) >>>>> >>>>> So you have two; my first intuition was that maybe something goes wrong when you only have one daughterboard in slot A, but try to get channel 1. >>>>> Does --channel 0,1 work? >>>>> >>>>> Best regards, >>>>> Marcus >>>>> >>>>> >>>>> On 05/20/2015 10:00 AM, Xinke Zhang wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> the version of daughterboards used is sbx-120. >>>>> >>>>> Best Regards, >>>>> >>>>> Xinke >>>>> >>>>> >>>>> -----Original Messages----- >>>>> From: "Marcus Müller" <marcus.mueller at ettus.com> >>>>> Sent Time: Wednesday, May 20, 2015 >>>>> To: "Xinke Zhang" <zhangxinke at iie.ac.cn>, mleech at ripnet.com >>>>> Cc:usrp-users at lists.ettus.com >>>>> Subject: Re: [USRP-users] benchmark_rate error: usrp x310 with intel adapter x520 (10 gigabit network) >>>>> >>>>> Hi, >>>>> what are your daughterboards? >>>>> >>>>> Best regards, >>>>> Marcus >>>>> >>>>> >>>>> On 05/20/2015 04:38 AM, Xinke Zhang wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> I found another interesting problem. Here's the detailed description: >>>>> >>>>> 1. i used the "benchmark_rate --rx_rate 10e6 --channels 0", and it was ok. >>>>> >>>>> 2. i used the "benchmark_rate --rx_rate 10e6 --channels 1", and it reseulted into the overflow state. the console ouput was "Receive error: ERROR_CODE_TIMEOUT, Unexpected error on recv, continuing...". >>>>> >>>>> in conclusion, the only difference between them is channel index (one is channel 0, and the other is channel 1). pls help me check what will cause this problem. >>>>> >>>>> Best Regards, >>>>> >>>>> Xinke Zhang >>>>> >>>>> >>>>> On 05/19/2015 08:29 AM, Marcus D. Leech via USRP-users wrote: >>>>> >>>>>>> On 05/19/2015 03:10 AM, Marcus Müller via USRP-users wrote: >>>>>>> Hello Xinke, >>>>>>>>> this is indeed interesting, on many levels: >>>>>>> You're successfully sending 100MS/s (no "U"s, right?), so your >>>>>>> computer doesn't seem to be underpowered; the very asymmetric way that >>>>>>> 10MS/s RX fails leads me to believe that there might be something >>>>>>> wrong with receiving at all. >>>>>>> Can you try >>>>>>> rx_samples_to_file --rate 10e6 --duration 5 --file rx.dat >>>>>>> and see if the resulting file rx.dat has nonzero size (in an ideal >>>>>>> world, it would be 200,000,000B in size, around 190MiB). >>>>>>>>> Best regards, >>>>>>> Marcus >>>>>>>> Also, what OS? Is it up-to-date? >>>>>> What is the cabling setup between the X310 and the host PC? >>>>>> >>>>>> >>>>>>>> On 05/19/2015 08:33 AM, Xinke Zhang via USRP-users wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>> My goal is to test the 2 simultaneous *rx* of single usrp x310 with >>>>>>>> intel adapter x520 (*10 gigabit network*). i used the benchmark_rate >>>>>>>> function provided by uhd examples (benchmark_rate --*rx*_rate 10e6 >>>>>>>> --channels 0,1), but i got the overflow error. when i tried to >>>>>>>> decreased the *rx*_rate, console ouptut was still overflow. Howerver, >>>>>>>> when i tested 2 simultaneous *tx* of single usrp x310 with intel >>>>>>>> adapter x520 (10 gigabit network) (benchmark_rate --*tx*_rate 10e6 >>>>>>>> --channels 0,1), it was successful. i even changed the *tx*_rate to >>> >>> >> > > > > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Hi Michael, I swapped the daughter boards yesterday, and the problem followed. The problem occurs frequently, and it is easy to reproduce.Rob mentioned that In order to work properly, we need to power cycle it several times. However, if you want to reproduce the problem, just find a specific x310 and you will find the problem. Best regards, Xinke 在 2015-05-21 07:22:00，"Michael West" <michael.west@ettus.com> 写道： >Hi Rob/Xinke, > >Did either of you try swapping the daughter boards to see if the >problem followed (i.e. moved to channel 0)? Also, how frequently does >the problem occur (i.e. how many power cycles does it take to >reproduce)? > >Rob - What daughter board(s) did you see the issue on? > >Regards, >Michael > >On Wed, May 20, 2015 at 4:01 PM, Xinke Zhang via USRP-users ><usrp-users@lists.ettus.com> wrote: >> Hi, >> >> I'm using the same cable in both cases. And both of them are connected to port 1. Have you come across this problem before? In the email list, rob mentioned it, too. >> >> Best regards, >> Xinke >> >> >> 在 2015-05-21 06:57:11，"Marcus D. Leech" <mleech@ripnet.com> 写道： >> >>>On 05/20/2015 06:53 PM, Xinke Zhang wrote: >>>> Hi, >>>> >>>> I drop it down to 8000, but it still cannot work. >>>> >>>> And I borrowed a usrp x300 yesterday, and tested it with my host PC. It worked with mtu size specified to 9000. >>>> >>>> Now I suspect it is a hardware specific problem.pls help check it. Thank you. >>>> >>>> Best regards, >>>> Xinke >>>Are you using the same cable in both cases (X310 and X300)? What about >>>which port on the X3xx? Is that the same? >>> >>>>> On 05/20/2015 06:31 PM, Xinke Zhang via USRP-users wrote: >>>>> Hi Rob, >>>>> >>>>> Thank you for your info. >>>>> >>>>> Hi Marcus, >>>>> >>>>> Do you have a solution for this mtu specific problem? Thank you. >>>>> >>>>> Best regards, >>>>> Xinke >>>>> That likekly means that your kernel/hardware/drivers don't support >>>>> larger MTU. Try dropping it down to 8000, and see if that works. >>>>> I've found that some hardware will claim to set a large MTU, but in >>>>> fact, it isn't. It happily takes the command from ethtool, but actually >>>>> silently ignores >>>>> or truncates the MTU request. >>>> >>>>> 在 2015-05-20 21:34:50，"Rob Kossler" <rkossler at nd.edu> 写道： >>>>> >>>>>> I have also seen problems with channel 1 of a 2 channel X310 not working (in the same or similar manner as described). I have several X310 devices, but have only noticed this issue with one of them. In my case I am usually able to "fix" the issue by power-cycling the X310 (sometimes it takes multiple times). It seems that once it is in a "good" state, it stays that way as long as it remains powered up. >>>>>> >>>>>> >>>>>> Rob >>>>>> >>>>>> >>>>>> On Wed, May 20, 2015 at 4:43 AM, Xinke Zhang via USRP-users <usrp-users at lists.ettus.com> wrote: >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> "benchmark_rate --rx_rate 10e6 --channels 0,1" didn't work, too. >>>>>> >>>>>> when i changed the mtu size from 9000 to 1500, "benchmark_rate --rx_rate 10e6" with " --channels 0", "--channels 1", and "--channels 0,1"all worked, but there are some warning which are about mtu size is too small. In the "system configuration for usrp x3x0 series", it mentions that when using the 10 gigabit nic, we should change the mtu size to 9000. and now i only can use mtu size 1500 for 10gigabit nic. why? >>>>>> >>>>>> Best Regards, >>>>>> >>>>>> Xinke >>>>>> >>>>>> >>>>>> -----Original Messages----- >>>>>> From: "Marcus Müller" <marcus.mueller at ettus.com> >>>>>> Sent Time: Wednesday, May 20, 2015 >>>>>> To: "Xinke Zhang" <zhangxinke at iie.ac.cn> >>>>>> Cc:mleech at ripnet.com, usrp-users at lists.ettus.com >>>>>> >>>>>> Subject: Re: [USRP-users] benchmark_rate error: usrp x310 with intel adapter x520 (10 gigabit network) >>>>>> >>>>>> So you have two; my first intuition was that maybe something goes wrong when you only have one daughterboard in slot A, but try to get channel 1. >>>>>> Does --channel 0,1 work? >>>>>> >>>>>> Best regards, >>>>>> Marcus >>>>>> >>>>>> >>>>>> On 05/20/2015 10:00 AM, Xinke Zhang wrote: >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> the version of daughterboards used is sbx-120. >>>>>> >>>>>> Best Regards, >>>>>> >>>>>> Xinke >>>>>> >>>>>> >>>>>> -----Original Messages----- >>>>>> From: "Marcus Müller" <marcus.mueller at ettus.com> >>>>>> Sent Time: Wednesday, May 20, 2015 >>>>>> To: "Xinke Zhang" <zhangxinke at iie.ac.cn>, mleech at ripnet.com >>>>>> Cc:usrp-users at lists.ettus.com >>>>>> Subject: Re: [USRP-users] benchmark_rate error: usrp x310 with intel adapter x520 (10 gigabit network) >>>>>> >>>>>> Hi, >>>>>> what are your daughterboards? >>>>>> >>>>>> Best regards, >>>>>> Marcus >>>>>> >>>>>> >>>>>> On 05/20/2015 04:38 AM, Xinke Zhang wrote: >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> I found another interesting problem. Here's the detailed description: >>>>>> >>>>>> 1. i used the "benchmark_rate --rx_rate 10e6 --channels 0", and it was ok. >>>>>> >>>>>> 2. i used the "benchmark_rate --rx_rate 10e6 --channels 1", and it reseulted into the overflow state. the console ouput was "Receive error: ERROR_CODE_TIMEOUT, Unexpected error on recv, continuing...". >>>>>> >>>>>> in conclusion, the only difference between them is channel index (one is channel 0, and the other is channel 1). pls help me check what will cause this problem. >>>>>> >>>>>> Best Regards, >>>>>> >>>>>> Xinke Zhang >>>>>> >>>>>> >>>>>> On 05/19/2015 08:29 AM, Marcus D. Leech via USRP-users wrote: >>>>>> >>>>>>>> On 05/19/2015 03:10 AM, Marcus Müller via USRP-users wrote: >>>>>>>> Hello Xinke, >>>>>>>>>> this is indeed interesting, on many levels: >>>>>>>> You're successfully sending 100MS/s (no "U"s, right?), so your >>>>>>>> computer doesn't seem to be underpowered; the very asymmetric way that >>>>>>>> 10MS/s RX fails leads me to believe that there might be something >>>>>>>> wrong with receiving at all. >>>>>>>> Can you try >>>>>>>> rx_samples_to_file --rate 10e6 --duration 5 --file rx.dat >>>>>>>> and see if the resulting file rx.dat has nonzero size (in an ideal >>>>>>>> world, it would be 200,000,000B in size, around 190MiB). >>>>>>>>>> Best regards, >>>>>>>> Marcus >>>>>>>>> Also, what OS? Is it up-to-date? >>>>>>> What is the cabling setup between the X310 and the host PC? >>>>>>> >>>>>>> >>>>>>>>> On 05/19/2015 08:33 AM, Xinke Zhang via USRP-users wrote: >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>> My goal is to test the 2 simultaneous *rx* of single usrp x310 with >>>>>>>>> intel adapter x520 (*10 gigabit network*). i used the benchmark_rate >>>>>>>>> function provided by uhd examples (benchmark_rate --*rx*_rate 10e6 >>>>>>>>> --channels 0,1), but i got the overflow error. when i tried to >>>>>>>>> decreased the *rx*_rate, console ouptut was still overflow. Howerver, >>>>>>>>> when i tested 2 simultaneous *tx* of single usrp x310 with intel >>>>>>>>> adapter x520 (10 gigabit network) (benchmark_rate --*tx*_rate 10e6 >>>>>>>>> --channels 0,1), it was successful. i even changed the *tx*_rate to >>>> >>>> >>> >> >> >> >> >> >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Hi Xinke, Thanks for the information. If the problem follows the daughter board, then it seems to me it is more likely to be an issue with that particular daughter board. It may be a matter of finding the specific daughter board and not the specific X310 to reproduce. Regards, Michael On Wed, May 20, 2015 at 4:29 PM, Xinke Zhang <zhangxinke@iie.ac.cn> wrote: > Hi Michael, > > I swapped the daughter boards yesterday, and the problem followed. > > The problem occurs frequently, and it is easy to reproduce.Rob mentioned that In order to work properly, we need to power cycle it several times. However, if you want to reproduce the problem, just find a specific x310 and you will find the problem. > > Best regards, > Xinke > > > 在 2015-05-21 07:22:00，"Michael West" <michael.west@ettus.com> 写道： > >>Hi Rob/Xinke, >> >>Did either of you try swapping the daughter boards to see if the >>problem followed (i.e. moved to channel 0)? Also, how frequently does >>the problem occur (i.e. how many power cycles does it take to >>reproduce)? >> >>Rob - What daughter board(s) did you see the issue on? >> >>Regards, >>Michael >> >>On Wed, May 20, 2015 at 4:01 PM, Xinke Zhang via USRP-users >><usrp-users@lists.ettus.com> wrote: >>> Hi, >>> >>> I'm using the same cable in both cases. And both of them are connected to port 1. Have you come across this problem before? In the email list, rob mentioned it, too. >>> >>> Best regards, >>> Xinke >>> >>> >>> 在 2015-05-21 06:57:11，"Marcus D. Leech" <mleech@ripnet.com> 写道： >>> >>>>On 05/20/2015 06:53 PM, Xinke Zhang wrote: >>>>> Hi, >>>>> >>>>> I drop it down to 8000, but it still cannot work. >>>>> >>>>> And I borrowed a usrp x300 yesterday, and tested it with my host PC. It worked with mtu size specified to 9000. >>>>> >>>>> Now I suspect it is a hardware specific problem.pls help check it. Thank you. >>>>> >>>>> Best regards, >>>>> Xinke >>>>Are you using the same cable in both cases (X310 and X300)? What about >>>>which port on the X3xx? Is that the same? >>>> >>>>>> On 05/20/2015 06:31 PM, Xinke Zhang via USRP-users wrote: >>>>>> Hi Rob, >>>>>> >>>>>> Thank you for your info. >>>>>> >>>>>> Hi Marcus, >>>>>> >>>>>> Do you have a solution for this mtu specific problem? Thank you. >>>>>> >>>>>> Best regards, >>>>>> Xinke >>>>>> That likekly means that your kernel/hardware/drivers don't support >>>>>> larger MTU. Try dropping it down to 8000, and see if that works. >>>>>> I've found that some hardware will claim to set a large MTU, but in >>>>>> fact, it isn't. It happily takes the command from ethtool, but actually >>>>>> silently ignores >>>>>> or truncates the MTU request. >>>>> >>>>>> 在 2015-05-20 21:34:50，"Rob Kossler" <rkossler at nd.edu> 写道： >>>>>> >>>>>>> I have also seen problems with channel 1 of a 2 channel X310 not working (in the same or similar manner as described). I have several X310 devices, but have only noticed this issue with one of them. In my case I am usually able to "fix" the issue by power-cycling the X310 (sometimes it takes multiple times). It seems that once it is in a "good" state, it stays that way as long as it remains powered up. >>>>>>> >>>>>>> >>>>>>> Rob >>>>>>> >>>>>>> >>>>>>> On Wed, May 20, 2015 at 4:43 AM, Xinke Zhang via USRP-users <usrp-users at lists.ettus.com> wrote: >>>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> "benchmark_rate --rx_rate 10e6 --channels 0,1" didn't work, too. >>>>>>> >>>>>>> when i changed the mtu size from 9000 to 1500, "benchmark_rate --rx_rate 10e6" with " --channels 0", "--channels 1", and "--channels 0,1"all worked, but there are some warning which are about mtu size is too small. In the "system configuration for usrp x3x0 series", it mentions that when using the 10 gigabit nic, we should change the mtu size to 9000. and now i only can use mtu size 1500 for 10gigabit nic. why? >>>>>>> >>>>>>> Best Regards, >>>>>>> >>>>>>> Xinke >>>>>>> >>>>>>> >>>>>>> -----Original Messages----- >>>>>>> From: "Marcus Müller" <marcus.mueller at ettus.com> >>>>>>> Sent Time: Wednesday, May 20, 2015 >>>>>>> To: "Xinke Zhang" <zhangxinke at iie.ac.cn> >>>>>>> Cc:mleech at ripnet.com, usrp-users at lists.ettus.com >>>>>>> >>>>>>> Subject: Re: [USRP-users] benchmark_rate error: usrp x310 with intel adapter x520 (10 gigabit network) >>>>>>> >>>>>>> So you have two; my first intuition was that maybe something goes wrong when you only have one daughterboard in slot A, but try to get channel 1. >>>>>>> Does --channel 0,1 work? >>>>>>> >>>>>>> Best regards, >>>>>>> Marcus >>>>>>> >>>>>>> >>>>>>> On 05/20/2015 10:00 AM, Xinke Zhang wrote: >>>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> the version of daughterboards used is sbx-120. >>>>>>> >>>>>>> Best Regards, >>>>>>> >>>>>>> Xinke >>>>>>> >>>>>>> >>>>>>> -----Original Messages----- >>>>>>> From: "Marcus Müller" <marcus.mueller at ettus.com> >>>>>>> Sent Time: Wednesday, May 20, 2015 >>>>>>> To: "Xinke Zhang" <zhangxinke at iie.ac.cn>, mleech at ripnet.com >>>>>>> Cc:usrp-users at lists.ettus.com >>>>>>> Subject: Re: [USRP-users] benchmark_rate error: usrp x310 with intel adapter x520 (10 gigabit network) >>>>>>> >>>>>>> Hi, >>>>>>> what are your daughterboards? >>>>>>> >>>>>>> Best regards, >>>>>>> Marcus >>>>>>> >>>>>>> >>>>>>> On 05/20/2015 04:38 AM, Xinke Zhang wrote: >>>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I found another interesting problem. Here's the detailed description: >>>>>>> >>>>>>> 1. i used the "benchmark_rate --rx_rate 10e6 --channels 0", and it was ok. >>>>>>> >>>>>>> 2. i used the "benchmark_rate --rx_rate 10e6 --channels 1", and it reseulted into the overflow state. the console ouput was "Receive error: ERROR_CODE_TIMEOUT, Unexpected error on recv, continuing...". >>>>>>> >>>>>>> in conclusion, the only difference between them is channel index (one is channel 0, and the other is channel 1). pls help me check what will cause this problem. >>>>>>> >>>>>>> Best Regards, >>>>>>> >>>>>>> Xinke Zhang >>>>>>> >>>>>>> >>>>>>> On 05/19/2015 08:29 AM, Marcus D. Leech via USRP-users wrote: >>>>>>> >>>>>>>>> On 05/19/2015 03:10 AM, Marcus Müller via USRP-users wrote: >>>>>>>>> Hello Xinke, >>>>>>>>>>> this is indeed interesting, on many levels: >>>>>>>>> You're successfully sending 100MS/s (no "U"s, right?), so your >>>>>>>>> computer doesn't seem to be underpowered; the very asymmetric way that >>>>>>>>> 10MS/s RX fails leads me to believe that there might be something >>>>>>>>> wrong with receiving at all. >>>>>>>>> Can you try >>>>>>>>> rx_samples_to_file --rate 10e6 --duration 5 --file rx.dat >>>>>>>>> and see if the resulting file rx.dat has nonzero size (in an ideal >>>>>>>>> world, it would be 200,000,000B in size, around 190MiB). >>>>>>>>>>> Best regards, >>>>>>>>> Marcus >>>>>>>>>> Also, what OS? Is it up-to-date? >>>>>>>> What is the cabling setup between the X310 and the host PC? >>>>>>>> >>>>>>>> >>>>>>>>>> On 05/19/2015 08:33 AM, Xinke Zhang via USRP-users wrote: >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>> My goal is to test the 2 simultaneous *rx* of single usrp x310 with >>>>>>>>>> intel adapter x520 (*10 gigabit network*). i used the benchmark_rate >>>>>>>>>> function provided by uhd examples (benchmark_rate --*rx*_rate 10e6 >>>>>>>>>> --channels 0,1), but i got the overflow error. when i tried to >>>>>>>>>> decreased the *rx*_rate, console ouptut was still overflow. Howerver, >>>>>>>>>> when i tested 2 simultaneous *tx* of single usrp x310 with intel >>>>>>>>>> adapter x520 (10 gigabit network) (benchmark_rate --*tx*_rate 10e6 >>>>>>>>>> --channels 0,1), it was successful. i even changed the *tx*_rate to >>>>> >>>>> >>>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> USRP-users mailing list >>> USRP-users@lists.ettus.com >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > >

Hi Michael, You mentioned that it may be a daughter board problem. I don't think so. I used "benchmark_rate --rx_rate 10e6 --channels 1", and it was overflow. But I used "benchmark_rate --rx_rate 10e6 --channels 0", and it worked properly. However, When I swapped the daughter board, it remained channel 1 overflow, and channel 0 ok. Best regards, Xinke 在 2015-05-21 07:47:00，"Michael West" <michael.west@ettus.com> 写道： >Hi Xinke, > >Thanks for the information. If the problem follows the daughter >board, then it seems to me it is more likely to be an issue with that >particular daughter board. It may be a matter of finding the specific >daughter board and not the specific X310 to reproduce. > >Regards, >Michael > >On Wed, May 20, 2015 at 4:29 PM, Xinke Zhang <zhangxinke@iie.ac.cn> wrote: >> Hi Michael, >> >> I swapped the daughter boards yesterday, and the problem followed. >> >> The problem occurs frequently, and it is easy to reproduce.Rob mentioned that In order to work properly, we need to power cycle it several times. However, if you want to reproduce the problem, just find a specific x310 and you will find the problem. >> >> Best regards, >> Xinke >> >> >> 在 2015-05-21 07:22:00，"Michael West" <michael.west@ettus.com> 写道： >> >>>Hi Rob/Xinke, >>> >>>Did either of you try swapping the daughter boards to see if the >>>problem followed (i.e. moved to channel 0)? Also, how frequently does >>>the problem occur (i.e. how many power cycles does it take to >>>reproduce)? >>> >>>Rob - What daughter board(s) did you see the issue on? >>> >>>Regards, >>>Michael >>> >>>On Wed, May 20, 2015 at 4:01 PM, Xinke Zhang via USRP-users >>><usrp-users@lists.ettus.com> wrote: >>>> Hi, >>>> >>>> I'm using the same cable in both cases. And both of them are connected to port 1. Have you come across this problem before? In the email list, rob mentioned it, too. >>>> >>>> Best regards, >>>> Xinke >>>> >>>> >>>> 在 2015-05-21 06:57:11，"Marcus D. Leech" <mleech@ripnet.com> 写道： >>>> >>>>>On 05/20/2015 06:53 PM, Xinke Zhang wrote: >>>>>> Hi, >>>>>> >>>>>> I drop it down to 8000, but it still cannot work. >>>>>> >>>>>> And I borrowed a usrp x300 yesterday, and tested it with my host PC. It worked with mtu size specified to 9000. >>>>>> >>>>>> Now I suspect it is a hardware specific problem.pls help check it. Thank you. >>>>>> >>>>>> Best regards, >>>>>> Xinke >>>>>Are you using the same cable in both cases (X310 and X300)? What about >>>>>which port on the X3xx? Is that the same? >>>>> >>>>>>> On 05/20/2015 06:31 PM, Xinke Zhang via USRP-users wrote: >>>>>>> Hi Rob, >>>>>>> >>>>>>> Thank you for your info. >>>>>>> >>>>>>> Hi Marcus, >>>>>>> >>>>>>> Do you have a solution for this mtu specific problem? Thank you. >>>>>>> >>>>>>> Best regards, >>>>>>> Xinke >>>>>>> That likekly means that your kernel/hardware/drivers don't support >>>>>>> larger MTU. Try dropping it down to 8000, and see if that works. >>>>>>> I've found that some hardware will claim to set a large MTU, but in >>>>>>> fact, it isn't. It happily takes the command from ethtool, but actually >>>>>>> silently ignores >>>>>>> or truncates the MTU request. >>>>>> >>>>>>> 在 2015-05-20 21:34:50，"Rob Kossler" <rkossler at nd.edu> 写道： >>>>>>> >>>>>>>> I have also seen problems with channel 1 of a 2 channel X310 not working (in the same or similar manner as described). I have several X310 devices, but have only noticed this issue with one of them. In my case I am usually able to "fix" the issue by power-cycling the X310 (sometimes it takes multiple times). It seems that once it is in a "good" state, it stays that way as long as it remains powered up. >>>>>>>> >>>>>>>> >>>>>>>> Rob >>>>>>>> >>>>>>>> >>>>>>>> On Wed, May 20, 2015 at 4:43 AM, Xinke Zhang via USRP-users <usrp-users at lists.ettus.com> wrote: >>>>>>>> >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> "benchmark_rate --rx_rate 10e6 --channels 0,1" didn't work, too. >>>>>>>> >>>>>>>> when i changed the mtu size from 9000 to 1500, "benchmark_rate --rx_rate 10e6" with " --channels 0", "--channels 1", and "--channels 0,1"all worked, but there are some warning which are about mtu size is too small. In the "system configuration for usrp x3x0 series", it mentions that when using the 10 gigabit nic, we should change the mtu size to 9000. and now i only can use mtu size 1500 for 10gigabit nic. why? >>>>>>>> >>>>>>>> Best Regards, >>>>>>>> >>>>>>>> Xinke >>>>>>>> >>>>>>>> >>>>>>>> -----Original Messages----- >>>>>>>> From: "Marcus Müller" <marcus.mueller at ettus.com> >>>>>>>> Sent Time: Wednesday, May 20, 2015 >>>>>>>> To: "Xinke Zhang" <zhangxinke at iie.ac.cn> >>>>>>>> Cc:mleech at ripnet.com, usrp-users at lists.ettus.com >>>>>>>> >>>>>>>> Subject: Re: [USRP-users] benchmark_rate error: usrp x310 with intel adapter x520 (10 gigabit network) >>>>>>>> >>>>>>>> So you have two; my first intuition was that maybe something goes wrong when you only have one daughterboard in slot A, but try to get channel 1. >>>>>>>> Does --channel 0,1 work? >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Marcus >>>>>>>> >>>>>>>> >>>>>>>> On 05/20/2015 10:00 AM, Xinke Zhang wrote: >>>>>>>> >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> the version of daughterboards used is sbx-120. >>>>>>>> >>>>>>>> Best Regards, >>>>>>>> >>>>>>>> Xinke >>>>>>>> >>>>>>>> >>>>>>>> -----Original Messages----- >>>>>>>> From: "Marcus Müller" <marcus.mueller at ettus.com> >>>>>>>> Sent Time: Wednesday, May 20, 2015 >>>>>>>> To: "Xinke Zhang" <zhangxinke at iie.ac.cn>, mleech at ripnet.com >>>>>>>> Cc:usrp-users at lists.ettus.com >>>>>>>> Subject: Re: [USRP-users] benchmark_rate error: usrp x310 with intel adapter x520 (10 gigabit network) >>>>>>>> >>>>>>>> Hi, >>>>>>>> what are your daughterboards? >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Marcus >>>>>>>> >>>>>>>> >>>>>>>> On 05/20/2015 04:38 AM, Xinke Zhang wrote: >>>>>>>> >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I found another interesting problem. Here's the detailed description: >>>>>>>> >>>>>>>> 1. i used the "benchmark_rate --rx_rate 10e6 --channels 0", and it was ok. >>>>>>>> >>>>>>>> 2. i used the "benchmark_rate --rx_rate 10e6 --channels 1", and it reseulted into the overflow state. the console ouput was "Receive error: ERROR_CODE_TIMEOUT, Unexpected error on recv, continuing...". >>>>>>>> >>>>>>>> in conclusion, the only difference between them is channel index (one is channel 0, and the other is channel 1). pls help me check what will cause this problem. >>>>>>>> >>>>>>>> Best Regards, >>>>>>>> >>>>>>>> Xinke Zhang >>>>>>>> >>>>>>>> >>>>>>>> On 05/19/2015 08:29 AM, Marcus D. Leech via USRP-users wrote: >>>>>>>> >>>>>>>>>> On 05/19/2015 03:10 AM, Marcus Müller via USRP-users wrote: >>>>>>>>>> Hello Xinke, >>>>>>>>>>>> this is indeed interesting, on many levels: >>>>>>>>>> You're successfully sending 100MS/s (no "U"s, right?), so your >>>>>>>>>> computer doesn't seem to be underpowered; the very asymmetric way that >>>>>>>>>> 10MS/s RX fails leads me to believe that there might be something >>>>>>>>>> wrong with receiving at all. >>>>>>>>>> Can you try >>>>>>>>>> rx_samples_to_file --rate 10e6 --duration 5 --file rx.dat >>>>>>>>>> and see if the resulting file rx.dat has nonzero size (in an ideal >>>>>>>>>> world, it would be 200,000,000B in size, around 190MiB). >>>>>>>>>>>> Best regards, >>>>>>>>>> Marcus >>>>>>>>>>> Also, what OS? Is it up-to-date? >>>>>>>>> What is the cabling setup between the X310 and the host PC? >>>>>>>>> >>>>>>>>> >>>>>>>>>>> On 05/19/2015 08:33 AM, Xinke Zhang via USRP-users wrote: >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> My goal is to test the 2 simultaneous *rx* of single usrp x310 with >>>>>>>>>>> intel adapter x520 (*10 gigabit network*). i used the benchmark_rate >>>>>>>>>>> function provided by uhd examples (benchmark_rate --*rx*_rate 10e6 >>>>>>>>>>> --channels 0,1), but i got the overflow error. when i tried to >>>>>>>>>>> decreased the *rx*_rate, console ouptut was still overflow. Howerver, >>>>>>>>>>> when i tested 2 simultaneous *tx* of single usrp x310 with intel >>>>>>>>>>> adapter x520 (10 gigabit network) (benchmark_rate --*tx*_rate 10e6 >>>>>>>>>>> --channels 0,1), it was successful. i even changed the *tx*_rate to >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> USRP-users mailing list >>>> USRP-users@lists.ettus.com >>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >> >> >>

Hi Xinke, Sorry. I misunderstood your previous post where you stated "I swapped the daughter boards yesterday, and the problem followed." Then, yes, it looks like it may be an X310 issue. The fact that power cycling can result in a success is interesting. Can you try burning the FPGA image again to see if the behaviour changes? Also, can you send the output of uhd_usrp_probe? This will tell us the versions of all the software, firmware, and hardware. Regards, Michael On Wed, May 20, 2015 at 4:59 PM, Xinke Zhang <zhangxinke@iie.ac.cn> wrote: > > Hi Michael, > > You mentioned that it may be a daughter board problem. I don't think so. > > I used "benchmark_rate --rx_rate 10e6 --channels 1", and it was overflow. But I used "benchmark_rate --rx_rate 10e6 --channels 0", and it worked properly. > > However, When I swapped the daughter board, it remained channel 1 overflow, and channel 0 ok. > > Best regards, > Xinke > > > 在 2015-05-21 07:47:00，"Michael West" <michael.west@ettus.com> 写道： > >>Hi Xinke, >> >>Thanks for the information. If the problem follows the daughter >>board, then it seems to me it is more likely to be an issue with that >>particular daughter board. It may be a matter of finding the specific >>daughter board and not the specific X310 to reproduce. >> >>Regards, >>Michael >> >>On Wed, May 20, 2015 at 4:29 PM, Xinke Zhang <zhangxinke@iie.ac.cn> wrote: >>> Hi Michael, >>> >>> I swapped the daughter boards yesterday, and the problem followed. >>> >>> The problem occurs frequently, and it is easy to reproduce.Rob mentioned that In order to work properly, we need to power cycle it several times. However, if you want to reproduce the problem, just find a specific x310 and you will find the problem. >>> >>> Best regards, >>> Xinke >>> >>> >>> 在 2015-05-21 07:22:00，"Michael West" <michael.west@ettus.com> 写道： >>> >>>>Hi Rob/Xinke, >>>> >>>>Did either of you try swapping the daughter boards to see if the >>>>problem followed (i.e. moved to channel 0)? Also, how frequently does >>>>the problem occur (i.e. how many power cycles does it take to >>>>reproduce)? >>>> >>>>Rob - What daughter board(s) did you see the issue on? >>>> >>>>Regards, >>>>Michael >>>> >>>>On Wed, May 20, 2015 at 4:01 PM, Xinke Zhang via USRP-users >>>><usrp-users@lists.ettus.com> wrote: >>>>> Hi, >>>>> >>>>> I'm using the same cable in both cases. And both of them are connected to port 1. Have you come across this problem before? In the email list, rob mentioned it, too. >>>>> >>>>> Best regards, >>>>> Xinke >>>>> >>>>> >>>>> 在 2015-05-21 06:57:11，"Marcus D. Leech" <mleech@ripnet.com> 写道： >>>>> >>>>>>On 05/20/2015 06:53 PM, Xinke Zhang wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I drop it down to 8000, but it still cannot work. >>>>>>> >>>>>>> And I borrowed a usrp x300 yesterday, and tested it with my host PC. It worked with mtu size specified to 9000. >>>>>>> >>>>>>> Now I suspect it is a hardware specific problem.pls help check it. Thank you. >>>>>>> >>>>>>> Best regards, >>>>>>> Xinke >>>>>>Are you using the same cable in both cases (X310 and X300)? What about >>>>>>which port on the X3xx? Is that the same? >>>>>> >>>>>>>> On 05/20/2015 06:31 PM, Xinke Zhang via USRP-users wrote: >>>>>>>> Hi Rob, >>>>>>>> >>>>>>>> Thank you for your info. >>>>>>>> >>>>>>>> Hi Marcus, >>>>>>>> >>>>>>>> Do you have a solution for this mtu specific problem? Thank you. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Xinke >>>>>>>> That likekly means that your kernel/hardware/drivers don't support >>>>>>>> larger MTU. Try dropping it down to 8000, and see if that works. >>>>>>>> I've found that some hardware will claim to set a large MTU, but in >>>>>>>> fact, it isn't. It happily takes the command from ethtool, but actually >>>>>>>> silently ignores >>>>>>>> or truncates the MTU request. >>>>>>> >>>>>>>> 在 2015-05-20 21:34:50，"Rob Kossler" <rkossler at nd.edu> 写道： >>>>>>>> >>>>>>>>> I have also seen problems with channel 1 of a 2 channel X310 not working (in the same or similar manner as described). I have several X310 devices, but have only noticed this issue with one of them. In my case I am usually able to "fix" the issue by power-cycling the X310 (sometimes it takes multiple times). It seems that once it is in a "good" state, it stays that way as long as it remains powered up. >>>>>>>>> >>>>>>>>> >>>>>>>>> Rob >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, May 20, 2015 at 4:43 AM, Xinke Zhang via USRP-users <usrp-users at lists.ettus.com> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> "benchmark_rate --rx_rate 10e6 --channels 0,1" didn't work, too. >>>>>>>>> >>>>>>>>> when i changed the mtu size from 9000 to 1500, "benchmark_rate --rx_rate 10e6" with " --channels 0", "--channels 1", and "--channels 0,1"all worked, but there are some warning which are about mtu size is too small. In the "system configuration for usrp x3x0 series", it mentions that when using the 10 gigabit nic, we should change the mtu size to 9000. and now i only can use mtu size 1500 for 10gigabit nic. why? >>>>>>>>> >>>>>>>>> Best Regards, >>>>>>>>> >>>>>>>>> Xinke >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Messages----- >>>>>>>>> From: "Marcus Müller" <marcus.mueller at ettus.com> >>>>>>>>> Sent Time: Wednesday, May 20, 2015 >>>>>>>>> To: "Xinke Zhang" <zhangxinke at iie.ac.cn> >>>>>>>>> Cc:mleech at ripnet.com, usrp-users at lists.ettus.com >>>>>>>>> >>>>>>>>> Subject: Re: [USRP-users] benchmark_rate error: usrp x310 with intel adapter x520 (10 gigabit network) >>>>>>>>> >>>>>>>>> So you have two; my first intuition was that maybe something goes wrong when you only have one daughterboard in slot A, but try to get channel 1. >>>>>>>>> Does --channel 0,1 work? >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Marcus >>>>>>>>> >>>>>>>>> >>>>>>>>> On 05/20/2015 10:00 AM, Xinke Zhang wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> the version of daughterboards used is sbx-120. >>>>>>>>> >>>>>>>>> Best Regards, >>>>>>>>> >>>>>>>>> Xinke >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Messages----- >>>>>>>>> From: "Marcus Müller" <marcus.mueller at ettus.com> >>>>>>>>> Sent Time: Wednesday, May 20, 2015 >>>>>>>>> To: "Xinke Zhang" <zhangxinke at iie.ac.cn>, mleech at ripnet.com >>>>>>>>> Cc:usrp-users at lists.ettus.com >>>>>>>>> Subject: Re: [USRP-users] benchmark_rate error: usrp x310 with intel adapter x520 (10 gigabit network) >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> what are your daughterboards? >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Marcus >>>>>>>>> >>>>>>>>> >>>>>>>>> On 05/20/2015 04:38 AM, Xinke Zhang wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I found another interesting problem. Here's the detailed description: >>>>>>>>> >>>>>>>>> 1. i used the "benchmark_rate --rx_rate 10e6 --channels 0", and it was ok. >>>>>>>>> >>>>>>>>> 2. i used the "benchmark_rate --rx_rate 10e6 --channels 1", and it reseulted into the overflow state. the console ouput was "Receive error: ERROR_CODE_TIMEOUT, Unexpected error on recv, continuing...". >>>>>>>>> >>>>>>>>> in conclusion, the only difference between them is channel index (one is channel 0, and the other is channel 1). pls help me check what will cause this problem. >>>>>>>>> >>>>>>>>> Best Regards, >>>>>>>>> >>>>>>>>> Xinke Zhang >>>>>>>>> >>>>>>>>> >>>>>>>>> On 05/19/2015 08:29 AM, Marcus D. Leech via USRP-users wrote: >>>>>>>>> >>>>>>>>>>> On 05/19/2015 03:10 AM, Marcus Müller via USRP-users wrote: >>>>>>>>>>> Hello Xinke, >>>>>>>>>>>>> this is indeed interesting, on many levels: >>>>>>>>>>> You're successfully sending 100MS/s (no "U"s, right?), so your >>>>>>>>>>> computer doesn't seem to be underpowered; the very asymmetric way that >>>>>>>>>>> 10MS/s RX fails leads me to believe that there might be something >>>>>>>>>>> wrong with receiving at all. >>>>>>>>>>> Can you try >>>>>>>>>>> rx_samples_to_file --rate 10e6 --duration 5 --file rx.dat >>>>>>>>>>> and see if the resulting file rx.dat has nonzero size (in an ideal >>>>>>>>>>> world, it would be 200,000,000B in size, around 190MiB). >>>>>>>>>>>>> Best regards, >>>>>>>>>>> Marcus >>>>>>>>>>>> Also, what OS? Is it up-to-date? >>>>>>>>>> What is the cabling setup between the X310 and the host PC? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> On 05/19/2015 08:33 AM, Xinke Zhang via USRP-users wrote: >>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> My goal is to test the 2 simultaneous *rx* of single usrp x310 with >>>>>>>>>>>> intel adapter x520 (*10 gigabit network*). i used the benchmark_rate >>>>>>>>>>>> function provided by uhd examples (benchmark_rate --*rx*_rate 10e6 >>>>>>>>>>>> --channels 0,1), but i got the overflow error. when i tried to >>>>>>>>>>>> decreased the *rx*_rate, console ouptut was still overflow. Howerver, >>>>>>>>>>>> when i tested 2 simultaneous *tx* of single usrp x310 with intel >>>>>>>>>>>> adapter x520 (10 gigabit network) (benchmark_rate --*tx*_rate 10e6 >>>>>>>>>>>> --channels 0,1), it was successful. i even changed the *tx*_rate to >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> USRP-users mailing list >>>>> USRP-users@lists.ettus.com >>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>> >>> >>> >>> > > >

Hi Michael, I have reburned the fpga, but nothing changes. here is the output of uhd_usrp_probe. pls check it. linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.003-0-unknown -- X300 initialization sequence... -- Determining maximum frame size... 8000 bytes. -- Setup basic communication... -- Loading values from EEPROM... -- Setup RF frontend clocking... -- Radio 1x clock:200 -- Initialize Radio control... -- Performing register loopback test... pass -- Performing register loopback test... pass -- Initializing clock and time using internal sources... done _____________________________________________________ / | Device: X-Series Device | _____________________________________________________ | / | | Mboard: X310 | | revision: 6 | | product: 30410 | | mac-addr0: 00:80:2f:19:9b:90 | | mac-addr1: 00:80:2f:19:9b:91 | | gateway: 192.168.10.1 | | ip-addr0: 192.168.10.2 | | subnet0: 255.255.255.0 | | ip-addr1: 192.168.20.2 | | subnet1: 255.255.255.0 | | ip-addr2: 192.168.30.2 | | subnet2: 255.255.255.0 | | ip-addr3: 192.168.40.2 | | subnet3: 255.255.255.0 | | serial: 30779DE | | FW Version: 3.0 | | FPGA Version: 9.0 | | | | Time sources: internal, external, gpsdo | | Clock sources: internal, external, gpsdo | | Sensors: ref_locked | | _____________________________________________________ | | / | | | RX DSP: 0 | | | Freq range: -100.000 to 100.000 MHz | | _____________________________________________________ | | / | | | RX DSP: 1 | | | Freq range: -100.000 to 100.000 MHz | | _____________________________________________________ | | / | | | RX Dboard: A | | | ID: SBX-120 (0x0083) | | | Serial: 307D173 | | | _____________________________________________________ | | | / | | | | RX Frontend: 0 | | | | Name: SBX-120 RX | | | | Antennas: TX/RX, RX2, CAL | | | | Sensors: lo_locked | | | | Freq range: 400.000 to 4400.000 MHz | | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB | | | | Bandwidth range: 120000000.0 to 120000000.0 step 0.0 Hz | | | | Connection Type: IQ | | | | Uses LO offset: No | | | _____________________________________________________ | | | / | | | | RX Codec: A | | | | Name: ads62p48 | | | | Gain range digital: 0.0 to 6.0 step 0.5 dB | | _____________________________________________________ | | / | | | RX Dboard: B | | | ID: SBX-120 (0x0083) | | | Serial: 307D17A | | | _____________________________________________________ | | | / | | | | RX Frontend: 0 | | | | Name: SBX-120 RX | | | | Antennas: TX/RX, RX2, CAL | | | | Sensors: lo_locked | | | | Freq range: 400.000 to 4400.000 MHz | | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB | | | | Bandwidth range: 120000000.0 to 120000000.0 step 0.0 Hz | | | | Connection Type: IQ | | | | Uses LO offset: No | | | _____________________________________________________ | | | / | | | | RX Codec: B | | | | Name: ads62p48 | | | | Gain range digital: 0.0 to 6.0 step 0.5 dB | | _____________________________________________________ | | / | | | TX DSP: 0 | | | Freq range: -100.000 to 100.000 MHz | | _____________________________________________________ | | / | | | TX DSP: 1 | | | Freq range: -100.000 to 100.000 MHz | | _____________________________________________________ | | / | | | TX Dboard: A | | | ID: SBX-120 (0x0082) | | | Serial: 307D173 | | | _____________________________________________________ | | | / | | | | TX Frontend: 0 | | | | Name: SBX-120 TX | | | | Antennas: TX/RX, CAL | | | | Sensors: lo_locked | | | | Freq range: 400.000 to 4400.000 MHz | | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB | | | | Bandwidth range: 120000000.0 to 120000000.0 step 0.0 Hz | | | | Connection Type: QI | | | | Uses LO offset: No | | | _____________________________________________________ | | | / | | | | TX Codec: A | | | | Name: ad9146 | | | | Gain Elements: None | | _____________________________________________________ | | / | | | TX Dboard: B | | | ID: SBX-120 (0x0082) | | | Serial: 307D17A | | | _____________________________________________________ | | | / | | | | TX Frontend: 0 | | | | Name: SBX-120 TX | | | | Antennas: TX/RX, CAL | | | | Sensors: lo_locked | | | | Freq range: 400.000 to 4400.000 MHz | | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB | | | | Bandwidth range: 120000000.0 to 120000000.0 step 0.0 Hz | | | | Connection Type: QI | | | | Uses LO offset: No | | | _____________________________________________________ | | | / | | | | TX Codec: B | | | | Name: ad9146 | | | | Gain Elements: None Best Regards, Xinke > -----Original Messages----- > From: "Michael West" <michael.west@ettus.com> > Sent Time: Thursday, May 21, 2015 > To: "Xinke Zhang" <zhangxinke@iie.ac.cn> > Cc: "Marcus D. Leech" <mleech@ripnet.com>, "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com> > Subject: Re: Re: Re: [USRP-users] benchmark_rate error: usrp x310 with intel adapter x520 (10 gigabit network) > > Hi Xinke, > > Sorry. I misunderstood your previous post where you stated "I swapped > the daughter boards yesterday, and the problem followed." Then, yes, > it looks like it may be an X310 issue. The fact that power cycling > can result in a success is interesting. Can you try burning the FPGA > image again to see if the behaviour changes? > > Also, can you send the output of uhd_usrp_probe? This will tell us > the versions of all the software, firmware, and hardware. > > Regards, > Michael > > On Wed, May 20, 2015 at 4:59 PM, Xinke Zhang <zhangxinke@iie.ac.cn> wrote: > > > > Hi Michael, > > > > You mentioned that it may be a daughter board problem. I don't think so. > > > > I used "benchmark_rate --rx_rate 10e6 --channels 1", and it was overflow. But I used "benchmark_rate --rx_rate 10e6 --channels 0", and it worked properly. > > > > However, When I swapped the daughter board, it remained channel 1 overflow, and channel 0 ok. > > > > Best regards, > > Xinke > > > > > > 在 2015-05-21 07:47:00，"Michael West" <michael.west@ettus.com> 写道： > > > >>Hi Xinke, > >> > >>Thanks for the information. If the problem follows the daughter > >>board, then it seems to me it is more likely to be an issue with that > >>particular daughter board. It may be a matter of finding the specific > >>daughter board and not the specific X310 to reproduce. > >> > >>Regards, > >>Michael > >> > >>On Wed, May 20, 2015 at 4:29 PM, Xinke Zhang <zhangxinke@iie.ac.cn> wrote: > >>> Hi Michael, > >>> > >>> I swapped the daughter boards yesterday, and the problem followed. > >>> > >>> The problem occurs frequently, and it is easy to reproduce.Rob mentioned that In order to work properly, we need to power cycle it several times. However, if you want to reproduce the problem, just find a specific x310 and you will find the problem. > >>> > >>> Best regards, > >>> Xinke > >>> > >>> > >>> 在 2015-05-21 07:22:00，"Michael West" <michael.west@ettus.com> 写道： > >>> > >>>>Hi Rob/Xinke, > >>>> > >>>>Did either of you try swapping the daughter boards to see if the > >>>>problem followed (i.e. moved to channel 0)? Also, how frequently does > >>>>the problem occur (i.e. how many power cycles does it take to > >>>>reproduce)? > >>>> > >>>>Rob - What daughter board(s) did you see the issue on? > >>>> > >>>>Regards, > >>>>Michael > >>>> > >>>>On Wed, May 20, 2015 at 4:01 PM, Xinke Zhang via USRP-users > >>>><usrp-users@lists.ettus.com> wrote: > >>>>> Hi, > >>>>> > >>>>> I'm using the same cable in both cases. And both of them are connected to port 1. Have you come across this problem before? In the email list, rob mentioned it, too. > >>>>> > >>>>> Best regards, > >>>>> Xinke > >>>>> > >>>>> > >>>>> 在 2015-05-21 06:57:11，"Marcus D. Leech" <mleech@ripnet.com> 写道： > >>>>> > >>>>>>On 05/20/2015 06:53 PM, Xinke Zhang wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> I drop it down to 8000, but it still cannot work. > >>>>>>> > >>>>>>> And I borrowed a usrp x300 yesterday, and tested it with my host PC. It worked with mtu size specified to 9000. > >>>>>>> > >>>>>>> Now I suspect it is a hardware specific problem.pls help check it. Thank you. > >>>>>>> > >>>>>>> Best regards, > >>>>>>> Xinke > >>>>>>Are you using the same cable in both cases (X310 and X300)? What about > >>>>>>which port on the X3xx? Is that the same? > >>>>>> > >>>>>>>> On 05/20/2015 06:31 PM, Xinke Zhang via USRP-users wrote: > >>>>>>>> Hi Rob, > >>>>>>>> > >>>>>>>> Thank you for your info. > >>>>>>>> > >>>>>>>> Hi Marcus, > >>>>>>>> > >>>>>>>> Do you have a solution for this mtu specific problem? Thank you. > >>>>>>>> > >>>>>>>> Best regards, > >>>>>>>> Xinke > >>>>>>>> That likekly means that your kernel/hardware/drivers don't support > >>>>>>>> larger MTU. Try dropping it down to 8000, and see if that works. > >>>>>>>> I've found that some hardware will claim to set a large MTU, but in > >>>>>>>> fact, it isn't. It happily takes the command from ethtool, but actually > >>>>>>>> silently ignores > >>>>>>>> or truncates the MTU request. > >>>>>>> > >>>>>>>> 在 2015-05-20 21:34:50，"Rob Kossler" <rkossler at nd.edu> 写道： > >>>>>>>> > >>>>>>>>> I have also seen problems with channel 1 of a 2 channel X310 not working (in the same or similar manner as described). I have several X310 devices, but have only noticed this issue with one of them. In my case I am usually able to "fix" the issue by power-cycling the X310 (sometimes it takes multiple times). It seems that once it is in a "good" state, it stays that way as long as it remains powered up. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Rob > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Wed, May 20, 2015 at 4:43 AM, Xinke Zhang via USRP-users <usrp-users at lists.ettus.com> wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> "benchmark_rate --rx_rate 10e6 --channels 0,1" didn't work, too. > >>>>>>>>> > >>>>>>>>> when i changed the mtu size from 9000 to 1500, "benchmark_rate --rx_rate 10e6" with " --channels 0", "--channels 1", and "--channels 0,1"all worked, but there are some warning which are about mtu size is too small. In the "system configuration for usrp x3x0 series", it mentions that when using the 10 gigabit nic, we should change the mtu size to 9000. and now i only can use mtu size 1500 for 10gigabit nic. why? > >>>>>>>>> > >>>>>>>>> Best Regards, > >>>>>>>>> > >>>>>>>>> Xinke > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> -----Original Messages----- > >>>>>>>>> From: "Marcus Müller" <marcus.mueller at ettus.com> > >>>>>>>>> Sent Time: Wednesday, May 20, 2015 > >>>>>>>>> To: "Xinke Zhang" <zhangxinke at iie.ac.cn> > >>>>>>>>> Cc:mleech at ripnet.com, usrp-users at lists.ettus.com > >>>>>>>>> > >>>>>>>>> Subject: Re: [USRP-users] benchmark_rate error: usrp x310 with intel adapter x520 (10 gigabit network) > >>>>>>>>> > >>>>>>>>> So you have two; my first intuition was that maybe something goes wrong when you only have one daughterboard in slot A, but try to get channel 1. > >>>>>>>>> Does --channel 0,1 work? > >>>>>>>>> > >>>>>>>>> Best regards, > >>>>>>>>> Marcus > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On 05/20/2015 10:00 AM, Xinke Zhang wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> the version of daughterboards used is sbx-120. > >>>>>>>>> > >>>>>>>>> Best Regards, > >>>>>>>>> > >>>>>>>>> Xinke > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> -----Original Messages----- > >>>>>>>>> From: "Marcus Müller" <marcus.mueller at ettus.com> > >>>>>>>>> Sent Time: Wednesday, May 20, 2015 > >>>>>>>>> To: "Xinke Zhang" <zhangxinke at iie.ac.cn>, mleech at ripnet.com > >>>>>>>>> Cc:usrp-users at lists.ettus.com > >>>>>>>>> Subject: Re: [USRP-users] benchmark_rate error: usrp x310 with intel adapter x520 (10 gigabit network) > >>>>>>>>> > >>>>>>>>> Hi, > >>>>>>>>> what are your daughterboards? > >>>>>>>>> > >>>>>>>>> Best regards, > >>>>>>>>> Marcus > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On 05/20/2015 04:38 AM, Xinke Zhang wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> I found another interesting problem. Here's the detailed description: > >>>>>>>>> > >>>>>>>>> 1. i used the "benchmark_rate --rx_rate 10e6 --channels 0", and it was ok. > >>>>>>>>> > >>>>>>>>> 2. i used the "benchmark_rate --rx_rate 10e6 --channels 1", and it reseulted into the overflow state. the console ouput was "Receive error: ERROR_CODE_TIMEOUT, Unexpected error on recv, continuing...". > >>>>>>>>> > >>>>>>>>> in conclusion, the only difference between them is channel index (one is channel 0, and the other is channel 1). pls help me check what will cause this problem. > >>>>>>>>> > >>>>>>>>> Best Regards, > >>>>>>>>> > >>>>>>>>> Xinke Zhang > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On 05/19/2015 08:29 AM, Marcus D. Leech via USRP-users wrote: > >>>>>>>>> > >>>>>>>>>>> On 05/19/2015 03:10 AM, Marcus Müller via USRP-users wrote: > >>>>>>>>>>> Hello Xinke, > >>>>>>>>>>>>> this is indeed interesting, on many levels: > >>>>>>>>>>> You're successfully sending 100MS/s (no "U"s, right?), so your > >>>>>>>>>>> computer doesn't seem to be underpowered; the very asymmetric way that > >>>>>>>>>>> 10MS/s RX fails leads me to believe that there might be something > >>>>>>>>>>> wrong with receiving at all. > >>>>>>>>>>> Can you try > >>>>>>>>>>> rx_samples_to_file --rate 10e6 --duration 5 --file rx.dat > >>>>>>>>>>> and see if the resulting file rx.dat has nonzero size (in an ideal > >>>>>>>>>>> world, it would be 200,000,000B in size, around 190MiB). > >>>>>>>>>>>>> Best regards, > >>>>>>>>>>> Marcus > >>>>>>>>>>>> Also, what OS? Is it up-to-date? > >>>>>>>>>> What is the cabling setup between the X310 and the host PC? > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>> On 05/19/2015 08:33 AM, Xinke Zhang via USRP-users wrote: > >>>>>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>> My goal is to test the 2 simultaneous *rx* of single usrp x310 with > >>>>>>>>>>>> intel adapter x520 (*10 gigabit network*). i used the benchmark_rate > >>>>>>>>>>>> function provided by uhd examples (benchmark_rate --*rx*_rate 10e6 > >>>>>>>>>>>> --channels 0,1), but i got the overflow error. when i tried to > >>>>>>>>>>>> decreased the *rx*_rate, console ouptut was still overflow. Howerver, > >>>>>>>>>>>> when i tested 2 simultaneous *tx* of single usrp x310 with intel > >>>>>>>>>>>> adapter x520 (10 gigabit network) (benchmark_rate --*tx*_rate 10e6 > >>>>>>>>>>>> --channels 0,1), it was successful. i even changed the *tx*_rate to > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> USRP-users mailing list > >>>>> USRP-users@lists.ettus.com > >>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > >>> > >>> > >>> > >>> > > > > > >

Hi Michael, I don't recall if I tried swapping or not. I am not surprised by the email from Xinke Zhang stating that the problem stayed with Channel 1 after swapping - this was my expectation. I can't say how frequently it occurs since I don't use the system consistently. However, it occurs reasonably often - in fact, it happened yesterday. Here are a couple of observations. 1) When it is in this faulty state, it seems to stay in this state as long as it remains powered up. Conversely, when it starts in a good state, it seems to stay in the good state as long as it remains powered up. The reason I say "seems" is that I haven't performed exhaustive testing to confirm this, but I don't recall any contrary cases. 2) It always occurs on channel 1 - I have never seen it on channel 0. 3) I did not realize until yesterday when reading Xinke's email that the issue was only for RX and not TX. But, when the problem occurred for me yesterday, I specifically verified that the TX was fine on both channels while the RX was bad only on channel 1 4) It is not an Ethernet issue. I can run the good RX channel at 100 MS/s or both good TX channels at 100 MS/s whereas the problem channel will not work even at 1 MS/s. 5) I have several X310 devices. I have only seen this issue on one of them. However, I caution that I use the devices somewhat sporadically so we can't draw too many conclusions - it is possible that the problem would show up on the other devices if I was using them all regularly. Xinke, Have you tried to power cycle the unit to see if this can make the problem go away? Rob On Wed, May 20, 2015 at 7:22 PM, Michael West via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi Rob/Xinke, > > Did either of you try swapping the daughter boards to see if the > problem followed (i.e. moved to channel 0)? Also, how frequently does > the problem occur (i.e. how many power cycles does it take to > reproduce)? > > Rob - What daughter board(s) did you see the issue on? > > Regards, > Michael > > On Wed, May 20, 2015 at 4:01 PM, Xinke Zhang via USRP-users > <usrp-users@lists.ettus.com> wrote: > > Hi, > > > > I'm using the same cable in both cases. And both of them are connected > to port 1. Have you come across this problem before? In the email list, rob > mentioned it, too. > > > > Best regards, > > Xinke > > > > > > 在 2015-05-21 06:57:11，"Marcus D. Leech" <mleech@ripnet.com> 写道： > > > >>On 05/20/2015 06:53 PM, Xinke Zhang wrote: > >>> Hi, > >>> > >>> I drop it down to 8000, but it still cannot work. > >>> > >>> And I borrowed a usrp x300 yesterday, and tested it with my host PC. > It worked with mtu size specified to 9000. > >>> > >>> Now I suspect it is a hardware specific problem.pls help check it. > Thank you. > >>> > >>> Best regards, > >>> Xinke > >>Are you using the same cable in both cases (X310 and X300)? What about > >>which port on the X3xx? Is that the same? > >> > >>>> On 05/20/2015 06:31 PM, Xinke Zhang via USRP-users wrote: > >>>> Hi Rob, > >>>> > >>>> Thank you for your info. > >>>> > >>>> Hi Marcus, > >>>> > >>>> Do you have a solution for this mtu specific problem? Thank you. > >>>> > >>>> Best regards, > >>>> Xinke > >>>> That likekly means that your kernel/hardware/drivers don't support > >>>> larger MTU. Try dropping it down to 8000, and see if that works. > >>>> I've found that some hardware will claim to set a large MTU, but in > >>>> fact, it isn't. It happily takes the command from ethtool, but > actually > >>>> silently ignores > >>>> or truncates the MTU request. > >>> > >>>> 在 2015-05-20 21:34:50，"Rob Kossler" <rkossler at nd.edu> 写道： > >>>> > >>>>> I have also seen problems with channel 1 of a 2 channel X310 not > working (in the same or similar manner as described). I have several X310 > devices, but have only noticed this issue with one of them. In my case I > am usually able to "fix" the issue by power-cycling the X310 (sometimes it > takes multiple times). It seems that once it is in a "good" state, it stays > that way as long as it remains powered up. > >>>>> > >>>>> > >>>>> Rob > >>>>> > >>>>> > >>>>> On Wed, May 20, 2015 at 4:43 AM, Xinke Zhang via USRP-users > <usrp-users at lists.ettus.com> wrote: > >>>>> > >>>>> > >>>>> Hi, > >>>>> > >>>>> "benchmark_rate --rx_rate 10e6 --channels 0,1" didn't work, too. > >>>>> > >>>>> when i changed the mtu size from 9000 to 1500, "benchmark_rate > --rx_rate 10e6" with " --channels 0", "--channels 1", and "--channels > 0,1"all worked, but there are some warning which are about mtu size is too > small. In the "system configuration for usrp x3x0 series", it mentions that > when using the 10 gigabit nic, we should change the mtu size to 9000. and > now i only can use mtu size 1500 for 10gigabit nic. why? > >>>>> > >>>>> Best Regards, > >>>>> > >>>>> Xinke > >>>>> > >>>>> > >>>>> -----Original Messages----- > >>>>> From: "Marcus Müller" <marcus.mueller at ettus.com> > >>>>> Sent Time: Wednesday, May 20, 2015 > >>>>> To: "Xinke Zhang" <zhangxinke at iie.ac.cn> > >>>>> Cc:mleech at ripnet.com, usrp-users at lists.ettus.com > >>>>> > >>>>> Subject: Re: [USRP-users] benchmark_rate error: usrp x310 with intel > adapter x520 (10 gigabit network) > >>>>> > >>>>> So you have two; my first intuition was that maybe something goes > wrong when you only have one daughterboard in slot A, but try to get > channel 1. > >>>>> Does --channel 0,1 work? > >>>>> > >>>>> Best regards, > >>>>> Marcus > >>>>> > >>>>> > >>>>> On 05/20/2015 10:00 AM, Xinke Zhang wrote: > >>>>> > >>>>> > >>>>> Hi, > >>>>> > >>>>> the version of daughterboards used is sbx-120. > >>>>> > >>>>> Best Regards, > >>>>> > >>>>> Xinke > >>>>> > >>>>> > >>>>> -----Original Messages----- > >>>>> From: "Marcus Müller" <marcus.mueller at ettus.com> > >>>>> Sent Time: Wednesday, May 20, 2015 > >>>>> To: "Xinke Zhang" <zhangxinke at iie.ac.cn>, mleech at ripnet.com > >>>>> Cc:usrp-users at lists.ettus.com > >>>>> Subject: Re: [USRP-users] benchmark_rate error: usrp x310 with intel > adapter x520 (10 gigabit network) > >>>>> > >>>>> Hi, > >>>>> what are your daughterboards? > >>>>> > >>>>> Best regards, > >>>>> Marcus > >>>>> > >>>>> > >>>>> On 05/20/2015 04:38 AM, Xinke Zhang wrote: > >>>>> > >>>>> > >>>>> Hi, > >>>>> > >>>>> I found another interesting problem. Here's the detailed description: > >>>>> > >>>>> 1. i used the "benchmark_rate --rx_rate 10e6 --channels 0", and it > was ok. > >>>>> > >>>>> 2. i used the "benchmark_rate --rx_rate 10e6 --channels 1", and it > reseulted into the overflow state. the console ouput was "Receive error: > ERROR_CODE_TIMEOUT, Unexpected error on recv, continuing...". > >>>>> > >>>>> in conclusion, the only difference between them is channel index > (one is channel 0, and the other is channel 1). pls help me check what will > cause this problem. > >>>>> > >>>>> Best Regards, > >>>>> > >>>>> Xinke Zhang > >>>>> > >>>>> > >>>>> On 05/19/2015 08:29 AM, Marcus D. Leech via USRP-users wrote: > >>>>> > >>>>>>> On 05/19/2015 03:10 AM, Marcus Müller via USRP-users wrote: > >>>>>>> Hello Xinke, > >>>>>>>>> this is indeed interesting, on many levels: > >>>>>>> You're successfully sending 100MS/s (no "U"s, right?), so your > >>>>>>> computer doesn't seem to be underpowered; the very asymmetric way > that > >>>>>>> 10MS/s RX fails leads me to believe that there might be something > >>>>>>> wrong with receiving at all. > >>>>>>> Can you try > >>>>>>> rx_samples_to_file --rate 10e6 --duration 5 --file rx.dat > >>>>>>> and see if the resulting file rx.dat has nonzero size (in an ideal > >>>>>>> world, it would be 200,000,000B in size, around 190MiB). > >>>>>>>>> Best regards, > >>>>>>> Marcus > >>>>>>>> Also, what OS? Is it up-to-date? > >>>>>> What is the cabling setup between the X310 and the host PC? > >>>>>> > >>>>>> > >>>>>>>> On 05/19/2015 08:33 AM, Xinke Zhang via USRP-users wrote: > >>>>>>>>>>>>>> Hi, > >>>>>>>>>>> My goal is to test the 2 simultaneous *rx* of single usrp x310 > with > >>>>>>>> intel adapter x520 (*10 gigabit network*). i used the > benchmark_rate > >>>>>>>> function provided by uhd examples (benchmark_rate --*rx*_rate 10e6 > >>>>>>>> --channels 0,1), but i got the overflow error. when i tried to > >>>>>>>> decreased the *rx*_rate, console ouptut was still overflow. > Howerver, > >>>>>>>> when i tested 2 simultaneous *tx* of single usrp x310 with intel > >>>>>>>> adapter x520 (10 gigabit network) (benchmark_rate --*tx*_rate 10e6 > >>>>>>>> --channels 0,1), it was successful. i even changed the *tx*_rate > to > >>> > >>> > >> > > > > > > > > > > > > _______________________________________________ > > USRP-users mailing list > > USRP-users@lists.ettus.com > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >

Xinke/Rob, Thank you for all the valuable information. From your experiences, it does seem like it has something to do with the FPGA on the X310. This could be a bug in the FPGA image or a hardware issue. I am starting to suspect you may be right about it being a hardware issue. One possible issue is poor attachment of the FPGA to the motherboard. Although not a definitive test, putting downward pressure on the heat sink while powering on the device and running benchmark rate could indicate whether or not this is true. If the application works more often when the pressure is applied but fails more often when not, it may be the problem. Temperature also plays a significant factor if this is the case. If there are small fractures in the solder balls connecting the chip to the board, they can open and close based on temperature from direct or indirect expansion and contraction. This may also explain why it may work on one power cycle and fail the next. Assuming it is a hardware issue, you can either run the pressure experiment yourself to confirm or contact support@ettus.com to RMA the unit and get a replacement. Regards, Michael On Thu, May 21, 2015 at 6:54 AM, Rob Kossler <rkossler@nd.edu> wrote: > Hi Michael, > I don't recall if I tried swapping or not. I am not surprised by the email > from Xinke Zhang stating that the problem stayed with Channel 1 after > swapping - this was my expectation. > > I can't say how frequently it occurs since I don't use the system > consistently. However, it occurs reasonably often - in fact, it happened > yesterday. Here are a couple of observations. > 1) When it is in this faulty state, it seems to stay in this state as long > as it remains powered up. Conversely, when it starts in a good state, it > seems to stay in the good state as long as it remains powered up. The > reason I say "seems" is that I haven't performed exhaustive testing to > confirm this, but I don't recall any contrary cases. > 2) It always occurs on channel 1 - I have never seen it on channel 0. > 3) I did not realize until yesterday when reading Xinke's email that the > issue was only for RX and not TX. But, when the problem occurred for me > yesterday, I specifically verified that the TX was fine on both channels > while the RX was bad only on channel 1 > 4) It is not an Ethernet issue. I can run the good RX channel at 100 MS/s > or both good TX channels at 100 MS/s whereas the problem channel will not > work even at 1 MS/s. > 5) I have several X310 devices. I have only seen this issue on one of them. > However, I caution that I use the devices somewhat sporadically so we can't > draw too many conclusions - it is possible that the problem would show up on > the other devices if I was using them all regularly. > > Xinke, > Have you tried to power cycle the unit to see if this can make the problem > go away? > > Rob > > > On Wed, May 20, 2015 at 7:22 PM, Michael West via USRP-users > <usrp-users@lists.ettus.com> wrote: >> >> Hi Rob/Xinke, >> >> Did either of you try swapping the daughter boards to see if the >> problem followed (i.e. moved to channel 0)? Also, how frequently does >> the problem occur (i.e. how many power cycles does it take to >> reproduce)? >> >> Rob - What daughter board(s) did you see the issue on? >> >> Regards, >> Michael >> >> On Wed, May 20, 2015 at 4:01 PM, Xinke Zhang via USRP-users >> <usrp-users@lists.ettus.com> wrote: >> > Hi, >> > >> > I'm using the same cable in both cases. And both of them are connected >> > to port 1. Have you come across this problem before? In the email list, rob >> > mentioned it, too. >> > >> > Best regards, >> > Xinke >> > >> > >> > 在 2015-05-21 06:57:11，"Marcus D. Leech" <mleech@ripnet.com> 写道： >> > >> >>On 05/20/2015 06:53 PM, Xinke Zhang wrote: >> >>> Hi, >> >>> >> >>> I drop it down to 8000, but it still cannot work. >> >>> >> >>> And I borrowed a usrp x300 yesterday, and tested it with my host PC. >> >>> It worked with mtu size specified to 9000. >> >>> >> >>> Now I suspect it is a hardware specific problem.pls help check it. >> >>> Thank you. >> >>> >> >>> Best regards, >> >>> Xinke >> >>Are you using the same cable in both cases (X310 and X300)? What about >> >>which port on the X3xx? Is that the same? >> >> >> >>>> On 05/20/2015 06:31 PM, Xinke Zhang via USRP-users wrote: >> >>>> Hi Rob, >> >>>> >> >>>> Thank you for your info. >> >>>> >> >>>> Hi Marcus, >> >>>> >> >>>> Do you have a solution for this mtu specific problem? Thank you. >> >>>> >> >>>> Best regards, >> >>>> Xinke >> >>>> That likekly means that your kernel/hardware/drivers don't support >> >>>> larger MTU. Try dropping it down to 8000, and see if that works. >> >>>> I've found that some hardware will claim to set a large MTU, but in >> >>>> fact, it isn't. It happily takes the command from ethtool, but >> >>>> actually >> >>>> silently ignores >> >>>> or truncates the MTU request. >> >>> >> >>>> 在 2015-05-20 21:34:50，"Rob Kossler" <rkossler at nd.edu> 写道： >> >>>> >> >>>>> I have also seen problems with channel 1 of a 2 channel X310 not >> >>>>> working (in the same or similar manner as described). I have several X310 >> >>>>> devices, but have only noticed this issue with one of them. In my case I am >> >>>>> usually able to "fix" the issue by power-cycling the X310 (sometimes it >> >>>>> takes multiple times). It seems that once it is in a "good" state, it stays >> >>>>> that way as long as it remains powered up. >> >>>>> >> >>>>> >> >>>>> Rob >> >>>>> >> >>>>> >> >>>>> On Wed, May 20, 2015 at 4:43 AM, Xinke Zhang via USRP-users >> >>>>> <usrp-users at lists.ettus.com> wrote: >> >>>>> >> >>>>> >> >>>>> Hi, >> >>>>> >> >>>>> "benchmark_rate --rx_rate 10e6 --channels 0,1" didn't work, too. >> >>>>> >> >>>>> when i changed the mtu size from 9000 to 1500, "benchmark_rate >> >>>>> --rx_rate 10e6" with " --channels 0", "--channels 1", and "--channels >> >>>>> 0,1"all worked, but there are some warning which are about mtu size is too >> >>>>> small. In the "system configuration for usrp x3x0 series", it mentions that >> >>>>> when using the 10 gigabit nic, we should change the mtu size to 9000. and >> >>>>> now i only can use mtu size 1500 for 10gigabit nic. why? >> >>>>> >> >>>>> Best Regards, >> >>>>> >> >>>>> Xinke >> >>>>> >> >>>>> >> >>>>> -----Original Messages----- >> >>>>> From: "Marcus Müller" <marcus.mueller at ettus.com> >> >>>>> Sent Time: Wednesday, May 20, 2015 >> >>>>> To: "Xinke Zhang" <zhangxinke at iie.ac.cn> >> >>>>> Cc:mleech at ripnet.com, usrp-users at lists.ettus.com >> >>>>> >> >>>>> Subject: Re: [USRP-users] benchmark_rate error: usrp x310 with intel >> >>>>> adapter x520 (10 gigabit network) >> >>>>> >> >>>>> So you have two; my first intuition was that maybe something goes >> >>>>> wrong when you only have one daughterboard in slot A, but try to get channel >> >>>>> 1. >> >>>>> Does --channel 0,1 work? >> >>>>> >> >>>>> Best regards, >> >>>>> Marcus >> >>>>> >> >>>>> >> >>>>> On 05/20/2015 10:00 AM, Xinke Zhang wrote: >> >>>>> >> >>>>> >> >>>>> Hi, >> >>>>> >> >>>>> the version of daughterboards used is sbx-120. >> >>>>> >> >>>>> Best Regards, >> >>>>> >> >>>>> Xinke >> >>>>> >> >>>>> >> >>>>> -----Original Messages----- >> >>>>> From: "Marcus Müller" <marcus.mueller at ettus.com> >> >>>>> Sent Time: Wednesday, May 20, 2015 >> >>>>> To: "Xinke Zhang" <zhangxinke at iie.ac.cn>, mleech at ripnet.com >> >>>>> Cc:usrp-users at lists.ettus.com >> >>>>> Subject: Re: [USRP-users] benchmark_rate error: usrp x310 with intel >> >>>>> adapter x520 (10 gigabit network) >> >>>>> >> >>>>> Hi, >> >>>>> what are your daughterboards? >> >>>>> >> >>>>> Best regards, >> >>>>> Marcus >> >>>>> >> >>>>> >> >>>>> On 05/20/2015 04:38 AM, Xinke Zhang wrote: >> >>>>> >> >>>>> >> >>>>> Hi, >> >>>>> >> >>>>> I found another interesting problem. Here's the detailed >> >>>>> description: >> >>>>> >> >>>>> 1. i used the "benchmark_rate --rx_rate 10e6 --channels 0", and it >> >>>>> was ok. >> >>>>> >> >>>>> 2. i used the "benchmark_rate --rx_rate 10e6 --channels 1", and it >> >>>>> reseulted into the overflow state. the console ouput was "Receive error: >> >>>>> ERROR_CODE_TIMEOUT, Unexpected error on recv, continuing...". >> >>>>> >> >>>>> in conclusion, the only difference between them is channel index >> >>>>> (one is channel 0, and the other is channel 1). pls help me check what will >> >>>>> cause this problem. >> >>>>> >> >>>>> Best Regards, >> >>>>> >> >>>>> Xinke Zhang >> >>>>> >> >>>>> >> >>>>> On 05/19/2015 08:29 AM, Marcus D. Leech via USRP-users wrote: >> >>>>> >> >>>>>>> On 05/19/2015 03:10 AM, Marcus Müller via USRP-users wrote: >> >>>>>>> Hello Xinke, >> >>>>>>>>> this is indeed interesting, on many levels: >> >>>>>>> You're successfully sending 100MS/s (no "U"s, right?), so your >> >>>>>>> computer doesn't seem to be underpowered; the very asymmetric way >> >>>>>>> that >> >>>>>>> 10MS/s RX fails leads me to believe that there might be something >> >>>>>>> wrong with receiving at all. >> >>>>>>> Can you try >> >>>>>>> rx_samples_to_file --rate 10e6 --duration 5 --file rx.dat >> >>>>>>> and see if the resulting file rx.dat has nonzero size (in an ideal >> >>>>>>> world, it would be 200,000,000B in size, around 190MiB). >> >>>>>>>>> Best regards, >> >>>>>>> Marcus >> >>>>>>>> Also, what OS? Is it up-to-date? >> >>>>>> What is the cabling setup between the X310 and the host PC? >> >>>>>> >> >>>>>> >> >>>>>>>> On 05/19/2015 08:33 AM, Xinke Zhang via USRP-users wrote: >> >>>>>>>>>>>>>> Hi, >> >>>>>>>>>>> My goal is to test the 2 simultaneous *rx* of single usrp x310 >> >>>>>>>>>>> with >> >>>>>>>> intel adapter x520 (*10 gigabit network*). i used the >> >>>>>>>> benchmark_rate >> >>>>>>>> function provided by uhd examples (benchmark_rate --*rx*_rate >> >>>>>>>> 10e6 >> >>>>>>>> --channels 0,1), but i got the overflow error. when i tried to >> >>>>>>>> decreased the *rx*_rate, console ouptut was still overflow. >> >>>>>>>> Howerver, >> >>>>>>>> when i tested 2 simultaneous *tx* of single usrp x310 with intel >> >>>>>>>> adapter x520 (10 gigabit network) (benchmark_rate --*tx*_rate >> >>>>>>>> 10e6 >> >>>>>>>> --channels 0,1), it was successful. i even changed the *tx*_rate >> >>>>>>>> to >> >>> >> >>> >> >> >> > >> > >> > >> > >> > >> > _______________________________________________ >> > USRP-users mailing list >> > USRP-users@lists.ettus.com >> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > >

Michael, My suspicion is that it is an FPGA timing issue where the timing is on-the-edge such that the failure only manifests itself on certain hardware. I do not suspect it is a HW issue - primarily because I have had the hardware for a while and this issue is recent. Plus, when powered up in the "good" state, it remains good for as long as the device is powered. While this certainly doesn't rule out a HW issue, my first inclination is to suspect something that we know has changed over time (such as FPGA image). By the way, I just realized that I didn't answer all of your previous questions. The daughterboard I am using is CBX-120. As far as how many power cycles are needed to "fix" the issue, take a look at the following experimental results. For this experiment, I ran the command "benchmark_rate" and checked for overflows. If no overflows then I reported "OK", otherwise "Fail". I then powered off the X310, waited 5 secs, and powered back on. Below are the results of repeating these steps 22 times. You can see that in these results that it never took more than 3 power cycles to "fix" the issue. But, I know in the past it has sometimes taken more than that. Rob OK OK OK Fail Fail Fail OK OK OK Fail OK OK Fail Fail OK Fail Fail OK Fail Fail Fail OK On Thu, May 21, 2015 at 1:54 PM, Michael West <michael.west@ettus.com> wrote: > Xinke/Rob, > > Thank you for all the valuable information. From your experiences, it > does seem like it has something to do with the FPGA on the X310. This > could be a bug in the FPGA image or a hardware issue. I am starting > to suspect you may be right about it being a hardware issue. > > One possible issue is poor attachment of the FPGA to the motherboard. > Although not a definitive test, putting downward pressure on the heat > sink while powering on the device and running benchmark rate could > indicate whether or not this is true. If the application works more > often when the pressure is applied but fails more often when not, it > may be the problem. Temperature also plays a significant factor if > this is the case. If there are small fractures in the solder balls > connecting the chip to the board, they can open and close based on > temperature from direct or indirect expansion and contraction. This > may also explain why it may work on one power cycle and fail the next. > > Assuming it is a hardware issue, you can either run the pressure > experiment yourself to confirm or contact support@ettus.com to RMA the > unit and get a replacement. > > Regards, > Michael > > On Thu, May 21, 2015 at 6:54 AM, Rob Kossler <rkossler@nd.edu> wrote: > > Hi Michael, > > I don't recall if I tried swapping or not. I am not surprised by the > email > > from Xinke Zhang stating that the problem stayed with Channel 1 after > > swapping - this was my expectation. > > > > I can't say how frequently it occurs since I don't use the system > > consistently. However, it occurs reasonably often - in fact, it happened > > yesterday. Here are a couple of observations. > > 1) When it is in this faulty state, it seems to stay in this state as > long > > as it remains powered up. Conversely, when it starts in a good state, it > > seems to stay in the good state as long as it remains powered up. The > > reason I say "seems" is that I haven't performed exhaustive testing to > > confirm this, but I don't recall any contrary cases. > > 2) It always occurs on channel 1 - I have never seen it on channel 0. > > 3) I did not realize until yesterday when reading Xinke's email that the > > issue was only for RX and not TX. But, when the problem occurred for me > > yesterday, I specifically verified that the TX was fine on both channels > > while the RX was bad only on channel 1 > > 4) It is not an Ethernet issue. I can run the good RX channel at 100 > MS/s > > or both good TX channels at 100 MS/s whereas the problem channel will not > > work even at 1 MS/s. > > 5) I have several X310 devices. I have only seen this issue on one of > them. > > However, I caution that I use the devices somewhat sporadically so we > can't > > draw too many conclusions - it is possible that the problem would show > up on > > the other devices if I was using them all regularly. > > > > Xinke, > > Have you tried to power cycle the unit to see if this can make the > problem > > go away? > > > > Rob > > > > > > On Wed, May 20, 2015 at 7:22 PM, Michael West via USRP-users > > <usrp-users@lists.ettus.com> wrote: > >> > >> Hi Rob/Xinke, > >> > >> Did either of you try swapping the daughter boards to see if the > >> problem followed (i.e. moved to channel 0)? Also, how frequently does > >> the problem occur (i.e. how many power cycles does it take to > >> reproduce)? > >> > >> Rob - What daughter board(s) did you see the issue on? > >> > >> Regards, > >> Michael > >> > >> On Wed, May 20, 2015 at 4:01 PM, Xinke Zhang via USRP-users > >> <usrp-users@lists.ettus.com> wrote: > >> > Hi, > >> > > >> > I'm using the same cable in both cases. And both of them are connected > >> > to port 1. Have you come across this problem before? In the email > list, rob > >> > mentioned it, too. > >> > > >> > Best regards, > >> > Xinke > >> > > >> > > >> > 在 2015-05-21 06:57:11，"Marcus D. Leech" <mleech@ripnet.com> 写道： > >> > > >> >>On 05/20/2015 06:53 PM, Xinke Zhang wrote: > >> >>> Hi, > >> >>> > >> >>> I drop it down to 8000, but it still cannot work. > >> >>> > >> >>> And I borrowed a usrp x300 yesterday, and tested it with my host PC. > >> >>> It worked with mtu size specified to 9000. > >> >>> > >> >>> Now I suspect it is a hardware specific problem.pls help check it. > >> >>> Thank you. > >> >>> > >> >>> Best regards, > >> >>> Xinke > >> >>Are you using the same cable in both cases (X310 and X300)? What about > >> >>which port on the X3xx? Is that the same? > >> >> > >> >>>> On 05/20/2015 06:31 PM, Xinke Zhang via USRP-users wrote: > >> >>>> Hi Rob, > >> >>>> > >> >>>> Thank you for your info. > >> >>>> > >> >>>> Hi Marcus, > >> >>>> > >> >>>> Do you have a solution for this mtu specific problem? Thank you. > >> >>>> > >> >>>> Best regards, > >> >>>> Xinke > >> >>>> That likekly means that your kernel/hardware/drivers don't support > >> >>>> larger MTU. Try dropping it down to 8000, and see if that works. > >> >>>> I've found that some hardware will claim to set a large MTU, but in > >> >>>> fact, it isn't. It happily takes the command from ethtool, but > >> >>>> actually > >> >>>> silently ignores > >> >>>> or truncates the MTU request. > >> >>> > >> >>>> 在 2015-05-20 21:34:50，"Rob Kossler" <rkossler at nd.edu> 写道： > >> >>>> > >> >>>>> I have also seen problems with channel 1 of a 2 channel X310 not > >> >>>>> working (in the same or similar manner as described). I have > several X310 > >> >>>>> devices, but have only noticed this issue with one of them. In > my case I am > >> >>>>> usually able to "fix" the issue by power-cycling the X310 > (sometimes it > >> >>>>> takes multiple times). It seems that once it is in a "good" > state, it stays > >> >>>>> that way as long as it remains powered up. > >> >>>>> > >> >>>>> > >> >>>>> Rob > >> >>>>> > >> >>>>> > >> >>>>> On Wed, May 20, 2015 at 4:43 AM, Xinke Zhang via USRP-users > >> >>>>> <usrp-users at lists.ettus.com> wrote: > >> >>>>> > >> >>>>> > >> >>>>> Hi, > >> >>>>> > >> >>>>> "benchmark_rate --rx_rate 10e6 --channels 0,1" didn't work, too. > >> >>>>> > >> >>>>> when i changed the mtu size from 9000 to 1500, "benchmark_rate > >> >>>>> --rx_rate 10e6" with " --channels 0", "--channels 1", and > "--channels > >> >>>>> 0,1"all worked, but there are some warning which are about mtu > size is too > >> >>>>> small. In the "system configuration for usrp x3x0 series", it > mentions that > >> >>>>> when using the 10 gigabit nic, we should change the mtu size to > 9000. and > >> >>>>> now i only can use mtu size 1500 for 10gigabit nic. why? > >> >>>>> > >> >>>>> Best Regards, > >> >>>>> > >> >>>>> Xinke > >> >>>>> > >> >>>>> > >> >>>>> -----Original Messages----- > >> >>>>> From: "Marcus Müller" <marcus.mueller at ettus.com> > >> >>>>> Sent Time: Wednesday, May 20, 2015 > >> >>>>> To: "Xinke Zhang" <zhangxinke at iie.ac.cn> > >> >>>>> Cc:mleech at ripnet.com, usrp-users at lists.ettus.com > >> >>>>> > >> >>>>> Subject: Re: [USRP-users] benchmark_rate error: usrp x310 with > intel > >> >>>>> adapter x520 (10 gigabit network) > >> >>>>> > >> >>>>> So you have two; my first intuition was that maybe something goes > >> >>>>> wrong when you only have one daughterboard in slot A, but try to > get channel > >> >>>>> 1. > >> >>>>> Does --channel 0,1 work? > >> >>>>> > >> >>>>> Best regards, > >> >>>>> Marcus > >> >>>>> > >> >>>>> > >> >>>>> On 05/20/2015 10:00 AM, Xinke Zhang wrote: > >> >>>>> > >> >>>>> > >> >>>>> Hi, > >> >>>>> > >> >>>>> the version of daughterboards used is sbx-120. > >> >>>>> > >> >>>>> Best Regards, > >> >>>>> > >> >>>>> Xinke > >> >>>>> > >> >>>>> > >> >>>>> -----Original Messages----- > >> >>>>> From: "Marcus Müller" <marcus.mueller at ettus.com> > >> >>>>> Sent Time: Wednesday, May 20, 2015 > >> >>>>> To: "Xinke Zhang" <zhangxinke at iie.ac.cn>, mleech at ripnet.com > >> >>>>> Cc:usrp-users at lists.ettus.com > >> >>>>> Subject: Re: [USRP-users] benchmark_rate error: usrp x310 with > intel > >> >>>>> adapter x520 (10 gigabit network) > >> >>>>> > >> >>>>> Hi, > >> >>>>> what are your daughterboards? > >> >>>>> > >> >>>>> Best regards, > >> >>>>> Marcus > >> >>>>> > >> >>>>> > >> >>>>> On 05/20/2015 04:38 AM, Xinke Zhang wrote: > >> >>>>> > >> >>>>> > >> >>>>> Hi, > >> >>>>> > >> >>>>> I found another interesting problem. Here's the detailed > >> >>>>> description: > >> >>>>> > >> >>>>> 1. i used the "benchmark_rate --rx_rate 10e6 --channels 0", and it > >> >>>>> was ok. > >> >>>>> > >> >>>>> 2. i used the "benchmark_rate --rx_rate 10e6 --channels 1", and it > >> >>>>> reseulted into the overflow state. the console ouput was "Receive > error: > >> >>>>> ERROR_CODE_TIMEOUT, Unexpected error on recv, continuing...". > >> >>>>> > >> >>>>> in conclusion, the only difference between them is channel index > >> >>>>> (one is channel 0, and the other is channel 1). pls help me check > what will > >> >>>>> cause this problem. > >> >>>>> > >> >>>>> Best Regards, > >> >>>>> > >> >>>>> Xinke Zhang > >> >>>>> > >> >>>>> > >> >>>>> On 05/19/2015 08:29 AM, Marcus D. Leech via USRP-users wrote: > >> >>>>> > >> >>>>>>> On 05/19/2015 03:10 AM, Marcus Müller via USRP-users wrote: > >> >>>>>>> Hello Xinke, > >> >>>>>>>>> this is indeed interesting, on many levels: > >> >>>>>>> You're successfully sending 100MS/s (no "U"s, right?), so your > >> >>>>>>> computer doesn't seem to be underpowered; the very asymmetric > way > >> >>>>>>> that > >> >>>>>>> 10MS/s RX fails leads me to believe that there might be > something > >> >>>>>>> wrong with receiving at all. > >> >>>>>>> Can you try > >> >>>>>>> rx_samples_to_file --rate 10e6 --duration 5 --file rx.dat > >> >>>>>>> and see if the resulting file rx.dat has nonzero size (in an > ideal > >> >>>>>>> world, it would be 200,000,000B in size, around 190MiB). > >> >>>>>>>>> Best regards, > >> >>>>>>> Marcus > >> >>>>>>>> Also, what OS? Is it up-to-date? > >> >>>>>> What is the cabling setup between the X310 and the host PC? > >> >>>>>> > >> >>>>>> > >> >>>>>>>> On 05/19/2015 08:33 AM, Xinke Zhang via USRP-users wrote: > >> >>>>>>>>>>>>>> Hi, > >> >>>>>>>>>>> My goal is to test the 2 simultaneous *rx* of single usrp > x310 > >> >>>>>>>>>>> with > >> >>>>>>>> intel adapter x520 (*10 gigabit network*). i used the > >> >>>>>>>> benchmark_rate > >> >>>>>>>> function provided by uhd examples (benchmark_rate --*rx*_rate > >> >>>>>>>> 10e6 > >> >>>>>>>> --channels 0,1), but i got the overflow error. when i tried to > >> >>>>>>>> decreased the *rx*_rate, console ouptut was still overflow. > >> >>>>>>>> Howerver, > >> >>>>>>>> when i tested 2 simultaneous *tx* of single usrp x310 with > intel > >> >>>>>>>> adapter x520 (10 gigabit network) (benchmark_rate --*tx*_rate > >> >>>>>>>> 10e6 > >> >>>>>>>> --channels 0,1), it was successful. i even changed the > *tx*_rate > >> >>>>>>>> to > >> >>> > >> >>> > >> >> > >> > > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > USRP-users mailing list > >> > USRP-users@lists.ettus.com > >> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > >> > >> _______________________________________________ > >> USRP-users mailing list > >> USRP-users@lists.ettus.com > >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > > >