XZ
Xinke Zhang
Wed, May 20, 2015 2:38 AM
Hi,
I found another interesting problem. Here's the detailed description:
-
i used the "benchmark_rate --rx_rate 10e6 --channels 0", and it was ok.
-
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).
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:
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
100e6, it was still successful.
Also, I tested the 2 simultaneous tx&rx of single usrp x310 with
intel adapter 82579LM (1 gigabit network), and both of them were
successful.
So I want to know what caused the 2 simultaneous rx of single usrp
x310 with intel adapter x520 (10 gigabit network) into overflow
state. Pls give me some suggestions. Thank you in advance.
FYI,
the uhd version I have tested are 3.8.2 & 3.8.4. my host pc is with
intel i7 cpu and 16G memory.
Best Regards,
Xinke Zhang
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
>>> 100e6, it was still successful.
>>>>>> Also, I tested the 2 simultaneous tx&rx of single usrp x310 with
>>> intel adapter 82579LM (*1 gigabit network*), and both of them were
>>> successful.
>>>>>> So I want to know what caused the 2 simultaneous *rx* of single usrp
>>> x310 with intel adapter x520 (10 gigabit network) into overflow
>>> state. Pls give me some suggestions. Thank you in advance.
>>>>>> FYI,
>>>>>> the uhd version I have tested are 3.8.2 & 3.8.4. my host pc is with
>>> intel i7 cpu and 16G memory.
>>>>>> Best Regards,
>>>>>> Xinke Zhang
MM
Marcus Müller
Wed, May 20, 2015 7:53 AM
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:
-
i used the "benchmark_rate --rx_rate 10e6 --channels 0", and it
was ok.
-
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
/>>>/ 100e6, it was still successful.
/>>>/
/>>>/ Also, I tested the 2 simultaneous tx&rx of single usrp x310 with
/>>>/ intel adapter 82579LM (1 gigabit network), and both of them were
/>>>/ successful.
/>>>/
/>>>/ So I want to know what caused the 2 simultaneous rx of single usrp
/>>>/ x310 with intel adapter x520 (10 gigabit network) into overflow
/>>>/ state. Pls give me some suggestions. Thank you in advance.
/>>>/
/>>>/ FYI,
/>>>/
/>>>/ the uhd version I have tested are 3.8.2 & 3.8.4. my host pc is with
/>>>/ intel i7 cpu and 16G memory.
/>>>/
/>>>/ Best Regards,
/>>>/
/>>>/ Xinke Zhang/
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
> />>>/ 100e6, it was still successful.
> />>>/
> />>>/ Also, I tested the 2 simultaneous tx&rx of single usrp x310 with
> />>>/ intel adapter 82579LM (*1 gigabit network*), and both of them were
> />>>/ successful.
> />>>/
> />>>/ So I want to know what caused the 2 simultaneous *rx* of single usrp
> />>>/ x310 with intel adapter x520 (10 gigabit network) into overflow
> />>>/ state. Pls give me some suggestions. Thank you in advance.
> />>>/
> />>>/ FYI,
> />>>/
> />>>/ the uhd version I have tested are 3.8.2 & 3.8.4. my host pc is with
> />>>/ intel i7 cpu and 16G memory.
> />>>/
> />>>/ Best Regards,
> />>>/
> />>>/ Xinke Zhang/
>
>
>
>
>
>
XZ
Xinke Zhang
Wed, May 20, 2015 8:00 AM
Hi,
the version of daughterboards used is sbx-120.
Best Regards,
Xinke
-----Original Messages-----
From: "Marcus Müller" marcus.mueller@ettus.com
Sent Time: Wednesday, May 20, 2015
To: "Xinke Zhang" zhangxinke@iie.ac.cn, mleech@ripnet.com
Cc: usrp-users@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:
-
i used the "benchmark_rate --rx_rate 10e6 --channels 0", and it was ok.
-
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).
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:
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
100e6, it was still successful.
Also, I tested the 2 simultaneous tx&rx of single usrp x310 with
intel adapter 82579LM (1 gigabit network), and both of them were
successful.
So I want to know what caused the 2 simultaneous rx of single usrp
x310 with intel adapter x520 (10 gigabit network) into overflow
state. Pls give me some suggestions. Thank you in advance.
FYI,
the uhd version I have tested are 3.8.2 & 3.8.4. my host pc is with
intel i7 cpu and 16G memory.
Best Regards,
Xinke Zhang
Hi,
the version of daughterboards used is sbx-120.
Best Regards,
Xinke
-----Original Messages-----
From: "Marcus Müller" <marcus.mueller@ettus.com>
Sent Time: Wednesday, May 20, 2015
To: "Xinke Zhang" <zhangxinke@iie.ac.cn>, mleech@ripnet.com
Cc: usrp-users@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
>>> 100e6, it was still successful.
>>>>>> Also, I tested the 2 simultaneous tx&rx of single usrp x310 with
>>> intel adapter 82579LM (*1 gigabit network*), and both of them were
>>> successful.
>>>>>> So I want to know what caused the 2 simultaneous *rx* of single usrp
>>> x310 with intel adapter x520 (10 gigabit network) into overflow
>>> state. Pls give me some suggestions. Thank you in advance.
>>>>>> FYI,
>>>>>> the uhd version I have tested are 3.8.2 & 3.8.4. my host pc is with
>>> intel i7 cpu and 16G memory.
>>>>>> Best Regards,
>>>>>> Xinke Zhang
MM
Marcus Müller
Wed, May 20, 2015 8:29 AM
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@ettus.com>
*Sent Time:* Wednesday, May 20, 2015
*To:* "Xinke Zhang" <zhangxinke@iie.ac.cn>, mleech@ripnet.com
*Cc:* usrp-users@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
/>>>/ 100e6, it was still successful.
/>>>/
/>>>/ Also, I tested the 2 simultaneous tx&rx of single usrp x310 with
/>>>/ intel adapter 82579LM (*1 gigabit network*), and both of them were
/>>>/ successful.
/>>>/
/>>>/ So I want to know what caused the 2 simultaneous *rx* of single usrp
/>>>/ x310 with intel adapter x520 (10 gigabit network) into overflow
/>>>/ state. Pls give me some suggestions. Thank you in advance.
/>>>/
/>>>/ FYI,
/>>>/
/>>>/ the uhd version I have tested are 3.8.2 & 3.8.4. my host pc is with
/>>>/ intel i7 cpu and 16G memory.
/>>>/
/>>>/ Best Regards,
/>>>/
/>>>/ Xinke Zhang/
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@ettus.com>
> *Sent Time:* Wednesday, May 20, 2015
> *To:* "Xinke Zhang" <zhangxinke@iie.ac.cn>, mleech@ripnet.com
> *Cc:* usrp-users@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
>> />>>/ 100e6, it was still successful.
>> />>>/
>> />>>/ Also, I tested the 2 simultaneous tx&rx of single usrp x310 with
>> />>>/ intel adapter 82579LM (*1 gigabit network*), and both of them were
>> />>>/ successful.
>> />>>/
>> />>>/ So I want to know what caused the 2 simultaneous *rx* of single usrp
>> />>>/ x310 with intel adapter x520 (10 gigabit network) into overflow
>> />>>/ state. Pls give me some suggestions. Thank you in advance.
>> />>>/
>> />>>/ FYI,
>> />>>/
>> />>>/ the uhd version I have tested are 3.8.2 & 3.8.4. my host pc is with
>> />>>/ intel i7 cpu and 16G memory.
>> />>>/
>> />>>/ Best Regards,
>> />>>/
>> />>>/ Xinke Zhang/
>>
>>
>>
>>
>>
>>
>
>
>
>
>
XZ
Xinke Zhang
Wed, May 20, 2015 8:43 AM
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@ettus.com
Sent Time: Wednesday, May 20, 2015
To: "Xinke Zhang" zhangxinke@iie.ac.cn
Cc: mleech@ripnet.com, usrp-users@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@ettus.com
Sent Time: Wednesday, May 20, 2015
To: "Xinke Zhang" zhangxinke@iie.ac.cn, mleech@ripnet.com
Cc:usrp-users@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:
-
i used the "benchmark_rate --rx_rate 10e6 --channels 0", and it was ok.
-
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).
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:
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
100e6, it was still successful.
Also, I tested the 2 simultaneous tx&rx of single usrp x310 with
intel adapter 82579LM (1 gigabit network), and both of them were
successful.
So I want to know what caused the 2 simultaneous rx of single usrp
x310 with intel adapter x520 (10 gigabit network) into overflow
state. Pls give me some suggestions. Thank you in advance.
FYI,
the uhd version I have tested are 3.8.2 & 3.8.4. my host pc is with
intel i7 cpu and 16G memory.
Best Regards,
Xinke Zhang
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@ettus.com>
Sent Time: Wednesday, May 20, 2015
To: "Xinke Zhang" <zhangxinke@iie.ac.cn>
Cc: mleech@ripnet.com, usrp-users@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@ettus.com>
Sent Time: Wednesday, May 20, 2015
To: "Xinke Zhang" <zhangxinke@iie.ac.cn>, mleech@ripnet.com
Cc:usrp-users@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
>>> 100e6, it was still successful.
>>>>>> Also, I tested the 2 simultaneous tx&rx of single usrp x310 with
>>> intel adapter 82579LM (*1 gigabit network*), and both of them were
>>> successful.
>>>>>> So I want to know what caused the 2 simultaneous *rx* of single usrp
>>> x310 with intel adapter x520 (10 gigabit network) into overflow
>>> state. Pls give me some suggestions. Thank you in advance.
>>>>>> FYI,
>>>>>> the uhd version I have tested are 3.8.2 & 3.8.4. my host pc is with
>>> intel i7 cpu and 16G memory.
>>>>>> Best Regards,
>>>>>> Xinke Zhang
RK
Rob Kossler
Wed, May 20, 2015 1:34 PM
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@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@ettus.com
Sent Time: Wednesday, May 20, 2015
To: "Xinke Zhang" zhangxinke@iie.ac.cn
Cc: mleech@ripnet.com, usrp-users@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@ettus.com
marcus.mueller@ettus.com
Sent Time: Wednesday, May 20, 2015
To: "Xinke Zhang" zhangxinke@iie.ac.cn zhangxinke@iie.ac.cn,
mleech@ripnet.com
Cc: usrp-users@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:
-
i used the "benchmark_rate --rx_rate 10e6 --channels 0", and it was
ok.
-
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:
>>>> 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
>>> 100e6, it was still successful.
>>>>>> Also, I tested the 2 simultaneous tx&rx of single usrp x310 with
>>> intel adapter 82579LM (1 gigabit network), and both of them were
>>> successful.
>>>>>> So I want to know what caused the 2 simultaneous rx of single usrp
>>> x310 with intel adapter x520 (10 gigabit network) into overflow
>>> state. Pls give me some suggestions. Thank you in advance.
>>>>>> FYI,
>>>>>> the uhd version I have tested are 3.8.2 & 3.8.4. my host pc is with
>>> intel i7 cpu and 16G memory.
>>>>>> Best Regards,
>>>>>> Xinke Zhang*
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
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@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@ettus.com>
> *Sent Time:* Wednesday, May 20, 2015
> *To:* "Xinke Zhang" <zhangxinke@iie.ac.cn>
> *Cc:* mleech@ripnet.com, usrp-users@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@ettus.com>
> <marcus.mueller@ettus.com>
> *Sent Time:* Wednesday, May 20, 2015
> *To:* "Xinke Zhang" <zhangxinke@iie.ac.cn> <zhangxinke@iie.ac.cn>,
> mleech@ripnet.com
> *Cc:* usrp-users@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
> *>>>* 100e6, it was still successful.
> *>>>>>>* Also, I tested the 2 simultaneous tx&rx of single usrp x310 with
> *>>>* intel adapter 82579LM (*1 gigabit network*), and both of them were
> *>>>* successful.
> *>>>>>>* So I want to know what caused the 2 simultaneous *rx* of single usrp
> *>>>* x310 with intel adapter x520 (10 gigabit network) into overflow
> *>>>* state. Pls give me some suggestions. Thank you in advance.
> *>>>>>>* FYI,
> *>>>>>>* the uhd version I have tested are 3.8.2 & 3.8.4. my host pc is with
> *>>>* intel i7 cpu and 16G memory.
> *>>>>>>* Best Regards,
> *>>>>>>* Xinke Zhang*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
XZ
Xinke Zhang
Wed, May 20, 2015 10:31 PM
Hi Rob,
Thank you for your info.
Hi Marcus,
Do you have a solution for this mtu specific problem? Thank you.
Best regards,
Xinke
在 2015-05-20 21:34:50，"Rob Kossler" rkossler@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@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@ettus.com
Sent Time: Wednesday, May 20, 2015
To: "Xinke Zhang" zhangxinke@iie.ac.cn
Cc:mleech@ripnet.com, usrp-users@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@ettus.com
Sent Time: Wednesday, May 20, 2015
To: "Xinke Zhang" zhangxinke@iie.ac.cn, mleech@ripnet.com
Cc:usrp-users@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:
-
i used the "benchmark_rate --rx_rate 10e6 --channels 0", and it was ok.
-
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).
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:
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
100e6, it was still successful.
Also, I tested the 2 simultaneous tx&rx of single usrp x310 with
intel adapter 82579LM (1 gigabit network), and both of them were
successful.
So I want to know what caused the 2 simultaneous rx of single usrp
x310 with intel adapter x520 (10 gigabit network) into overflow
state. Pls give me some suggestions. Thank you in advance.
FYI,
the uhd version I have tested are 3.8.2 & 3.8.4. my host pc is with
intel i7 cpu and 16G memory.
Best Regards,
Xinke Zhang
Hi Rob,
Thank you for your info.
Hi Marcus,
Do you have a solution for this mtu specific problem? Thank you.
Best regards,
Xinke
在 2015-05-20 21:34:50，"Rob Kossler" <rkossler@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@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@ettus.com>
>Sent Time: Wednesday, May 20, 2015
>To: "Xinke Zhang" <zhangxinke@iie.ac.cn>
>Cc:mleech@ripnet.com, usrp-users@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@ettus.com>
>Sent Time: Wednesday, May 20, 2015
>To: "Xinke Zhang" <zhangxinke@iie.ac.cn>, mleech@ripnet.com
>Cc:usrp-users@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
>>>> 100e6, it was still successful.
>>>>>>> Also, I tested the 2 simultaneous tx&rx of single usrp x310 with
>>>> intel adapter 82579LM (*1 gigabit network*), and both of them were
>>>> successful.
>>>>>>> So I want to know what caused the 2 simultaneous *rx* of single usrp
>>>> x310 with intel adapter x520 (10 gigabit network) into overflow
>>>> state. Pls give me some suggestions. Thank you in advance.
>>>>>>> FYI,
>>>>>>> the uhd version I have tested are 3.8.2 & 3.8.4. my host pc is with
>>>> intel i7 cpu and 16G memory.
>>>>>>> Best Regards,
>>>>>>> Xinke Zhang
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>_______________________________________________
>USRP-users mailing list
>USRP-users@lists.ettus.com
>http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
MD
Marcus D. Leech
Wed, May 20, 2015 10:42 PM
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.
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@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@ettus.com
Sent Time: Wednesday, May 20, 2015
To: "Xinke Zhang" zhangxinke@iie.ac.cn
Cc:mleech@ripnet.com, usrp-users@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@ettus.com
Sent Time: Wednesday, May 20, 2015
To: "Xinke Zhang" zhangxinke@iie.ac.cn, mleech@ripnet.com
Cc:usrp-users@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:
-
i used the "benchmark_rate --rx_rate 10e6 --channels 0", and it was ok.
-
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).
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:
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
100e6, it was still successful.
Also, I tested the 2 simultaneous tx&rx of single usrp x310 with
intel adapter 82579LM (1 gigabit network), and both of them were
successful.
So I want to know what caused the 2 simultaneous rx of single usrp
x310 with intel adapter x520 (10 gigabit network) into overflow
state. Pls give me some suggestions. Thank you in advance.
FYI,
the uhd version I have tested are 3.8.2 & 3.8.4. my host pc is with
intel i7 cpu and 16G memory.
Best Regards,
Xinke Zhang
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@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@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@ettus.com>
>> Sent Time: Wednesday, May 20, 2015
>> To: "Xinke Zhang" <zhangxinke@iie.ac.cn>
>> Cc:mleech@ripnet.com, usrp-users@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@ettus.com>
>> Sent Time: Wednesday, May 20, 2015
>> To: "Xinke Zhang" <zhangxinke@iie.ac.cn>, mleech@ripnet.com
>> Cc:usrp-users@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
>>>>> 100e6, it was still successful.
>>>>>>>> Also, I tested the 2 simultaneous tx&rx of single usrp x310 with
>>>>> intel adapter 82579LM (*1 gigabit network*), and both of them were
>>>>> successful.
>>>>>>>> So I want to know what caused the 2 simultaneous *rx* of single usrp
>>>>> x310 with intel adapter x520 (10 gigabit network) into overflow
>>>>> state. Pls give me some suggestions. Thank you in advance.
>>>>>>>> FYI,
>>>>>>>> the uhd version I have tested are 3.8.2 & 3.8.4. my host pc is with
>>>>> intel i7 cpu and 16G memory.
>>>>>>>> Best Regards,
>>>>>>>> Xinke Zhang
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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
XZ
Xinke Zhang
Wed, May 20, 2015 10:53 PM
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
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:
-
i used the "benchmark_rate --rx_rate 10e6 --channels 0", and it was ok.
-
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).
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:
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,
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
>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
>
MD
Marcus D. Leech
Wed, May 20, 2015 10:57 PM
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:
-
i used the "benchmark_rate --rx_rate 10e6 --channels 0", and it was ok.
-
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).
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:
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
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
>
>
