*LIGHT* pressure….. On May 21, 2015, at 10:54 AM, Michael West via USRP-users <usrp-users@lists.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 >> >> > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Hi Rob/Xinke, The issue could be a number of things, actually. There is an obvious problem and it seems specific to the particular X310, so I recommend doing an RMA on the unit. That way you can get a working unit and we can get the failing unit back here for troubleshooting. If there is a hardware or FPGA issue, we would like to know about it and get it resolved as quickly as possible. If you RMA the unit, please send me the RMA number so I can follow up. Regards, Michael On Thu, May 21, 2015 at 11:03 AM, Ian Buckley <ianb@ionconcepts.com> wrote: > *LIGHT* pressure….. > > On May 21, 2015, at 10:54 AM, Michael West via USRP-users <usrp-users@lists.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 >>> >>> >> >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >

Hi Rob, Thanks for the detailed description of your observations. I have tried to power cycle the unit again and again, but nothing changes. Maybe my unit likes to stay in the faulty state. just for joking. Best regards, Xinke -----Original Messages----- From: "Rob Kossler" <rkossler@nd.edu> Sent Time: Thursday, May 21, 2015 To: "Michael West" <michael.west@ettus.com> Cc: "Xinke Zhang" <zhangxinke@iie.ac.cn>, "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com> Subject: Re: [USRP-users] benchmark_rate error: usrp x310 with intel adapter x520 (10 gigabit network) 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