Re: [Discuss-gnuradio] Packet drop from Ethernet (A BIG PROBLEM)
Hi Mostafa, You seem to be confused about sample resolution. There is sample resolution taking place at the FPGA, and sample resolution that can take place at uhd driver in the host. Important to know is that usrp ADCs will sample at 16 bits I/Q (32 bits) /sample. That's a hardware limit you cannot improve upon. If you reduce that at the FPGA to 8bits you save bandwidth from your ethernet. If you change it at the driver, you only make it compatible with your userspace app. Both are controlled at the same place, the streamer. FPGA resolution is configured at stream_args.otw_format, while uhd output resolution is configured at stream_args.cpu_format. For more info check the uhd_usrp_get_rx_streamer at http://files.ettus.com/manual/globals_func_u.html You also are using a PCI NIC for transfer. These are cheap but notoriously bad. I've tried both a DG-Link and a TP-Link and couldn't get over 300 Mbps, using Realtek's r8169 driver, without even having anything else in my PCI bus. HTH, Nikos On Wed, Mar 9, 2016 at 11:33 AM, Mostafa Alizadeh wrote: > Hi Nikos, > > This is exaclty the issue related to the GNURadio application rather than > USRP because the problem is from the host. That is not possible to transfer > 30 Msps, however, what about 20 Msps? I expect to be able to transfer 20 > Msps at least. > > Another point that you mentioned is "changing the resolution of the > samples". In contrast, as far as I know, if you change the sample > resolution it does not reduce the bit rate of the Ethernet interface, > however, it changes the interpretation of the samples! It is easy to run a > program for different sample resolution and observe that there is no change > in the bit rate of the Eth. Interface. > > How to change the ethernet parameters or anything else ( if any idea ) to > reduce packet dropping?? > > Thanks in advance, > Mostafa > On Mar 9, 2016 11:25 AM, "Nikos Balkanas" wrote: > >> Hi, >> >> This issue is better addressed to usrp-us...@ettus.com. Briefly I can >> tell you that you can never reach 30M samples/sec over a 1 GbE interface. >> 30 x 32/bits/sample = 960. Need a bit for metadata, packet overheads, >> etc. you will drop packages. Especially if your NIC is PCI based :( >> Try reducing your sample resolution to 8 bits. You may have better luck. >> >> HTH, >> Nikos >> >> On Wed, Mar 9, 2016 at 9:42 AM, Mostafa Alizadeh >> wrote: >> >>> Hello all, >>> I stuck on an incridible challenge in sending/receiving a large >>> bandwidth. I have an USRP N210 and an WBX daughterboard, while I must be >>> able to capture/transfer up to 30Msample/sec(1Gig ethernet limit ), with >>> the sample rate of 25Msps or even 20Msps I have some dropped packets. Based >>> on my knowledge, this is due to CPU which does not have enough time to >>> capture from Ethernet, however, I have the powerful one, 12 core CPU. When >>> I have a large GNURadio program to run, there are some dropped packets. I >>> searched everywhere but I did not find a complete description of the >>> solution. What is (are ) the solution(s )? Please help me with any >>> information! :( >>> >>> Best regards >>> Mostafa >>> >>> ___ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Packet drop from Ethernet (A BIG PROBLEM)
Hi Nikos, you're absolutely right with respect to it just being a bus bandwidth limitation: Gigabit ethernet can only carry 1Gbit/s, and with 16 bit per I and Q part, 31.25 Megasamples would be the maximum rate you could get through; adding a bit of overhead (it's not that much, roughly 40B overhead per 1450B payload, so roughly 2.7%), this gets reduced to roughly 30 MS/s, and including the fact that an average NIC isn't always using the cable to its fullest extent, that might be even less. So another reason why this isn't a GNU Radio issue is that 30MS/s is not a rate supported by the USRP: sampling rates need to be master_clock_rate/N, N being a natural number. That master clock rate is fixed to 100MHz on N210, so the only possible rates are 100MS/s (impossible over Gigabit Ethernet), 50MS/s (only possible with 8bit samples), 33.333MS/s (only possible with 8bit samples, but bad, because 3 is an odd decimation, and anti-aliasing filter performance is much worse for these), 25MS/s, 20MS/s, and so on. UHD will print a warning that the rate is impossible and that a "close by" rate was used. Best regards, Marcus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Packet drop from Ethernet (A BIG PROBLEM)
Hi Mostafa, This is a usrp issue, and depends exactly on the hardware. Before you look into the host for optimizing its networking parameters, you should make sure that your hardware can handle it. For example reducing the sample resolution in your N200. ADCs in USRPs use quad sampling, which means they generate I/Q (imaginary/real) data for each sample. At full resolution, this is 16 bits each or 32 bits/Sample. At reduced sample resolution, which takes place in the FPGA, you get 8 + 8 = 16 bits/sample, therefore half the bandwidth of full resolution going through the wire. Now, you should be able to handle 20 MS/s at full resolution, 20x32 = 640 Mbps. But a lot of NICS have problems, especially the PCI ones. What is your NIC? What is your OS? BR, Nikos On Wed, Mar 9, 2016 at 11:33 AM, Mostafa Alizadeh wrote: > Hi Nikos, > > This is exaclty the issue related to the GNURadio application rather than > USRP because the problem is from the host. That is not possible to transfer > 30 Msps, however, what about 20 Msps? I expect to be able to transfer 20 > Msps at least. > > Another point that you mentioned is "changing the resolution of the > samples". In contrast, as far as I know, if you change the sample > resolution it does not reduce the bit rate of the Ethernet interface, > however, it changes the interpretation of the samples! It is easy to run a > program for different sample resolution and observe that there is no change > in the bit rate of the Eth. Interface. > > How to change the ethernet parameters or anything else ( if any idea ) to > reduce packet dropping?? > > Thanks in advance, > Mostafa > On Mar 9, 2016 11:25 AM, "Nikos Balkanas" wrote: > >> Hi, >> >> This issue is better addressed to usrp-us...@ettus.com. Briefly I can >> tell you that you can never reach 30M samples/sec over a 1 GbE interface. >> 30 x 32/bits/sample = 960. Need a bit for metadata, packet overheads, >> etc. you will drop packages. Especially if your NIC is PCI based :( >> Try reducing your sample resolution to 8 bits. You may have better luck. >> >> HTH, >> Nikos >> >> On Wed, Mar 9, 2016 at 9:42 AM, Mostafa Alizadeh >> wrote: >> >>> Hello all, >>> I stuck on an incridible challenge in sending/receiving a large >>> bandwidth. I have an USRP N210 and an WBX daughterboard, while I must be >>> able to capture/transfer up to 30Msample/sec(1Gig ethernet limit ), with >>> the sample rate of 25Msps or even 20Msps I have some dropped packets. Based >>> on my knowledge, this is due to CPU which does not have enough time to >>> capture from Ethernet, however, I have the powerful one, 12 core CPU. When >>> I have a large GNURadio program to run, there are some dropped packets. I >>> searched everywhere but I did not find a complete description of the >>> solution. What is (are ) the solution(s )? Please help me with any >>> information! :( >>> >>> Best regards >>> Mostafa >>> >>> ___ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Packet drop from Ethernet (A BIG PROBLEM)
Hi Nikos, This is exaclty the issue related to the GNURadio application rather than USRP because the problem is from the host. That is not possible to transfer 30 Msps, however, what about 20 Msps? I expect to be able to transfer 20 Msps at least. Another point that you mentioned is "changing the resolution of the samples". In contrast, as far as I know, if you change the sample resolution it does not reduce the bit rate of the Ethernet interface, however, it changes the interpretation of the samples! It is easy to run a program for different sample resolution and observe that there is no change in the bit rate of the Eth. Interface. How to change the ethernet parameters or anything else ( if any idea ) to reduce packet dropping?? Thanks in advance, Mostafa On Mar 9, 2016 11:25 AM, "Nikos Balkanas" wrote: > Hi, > > This issue is better addressed to usrp-us...@ettus.com. Briefly I can > tell you that you can never reach 30M samples/sec over a 1 GbE interface. > 30 x 32/bits/sample = 960. Need a bit for metadata, packet overheads, etc. > you will drop packages. Especially if your NIC is PCI based :( > Try reducing your sample resolution to 8 bits. You may have better luck. > > HTH, > Nikos > > On Wed, Mar 9, 2016 at 9:42 AM, Mostafa Alizadeh > wrote: > >> Hello all, >> I stuck on an incridible challenge in sending/receiving a large >> bandwidth. I have an USRP N210 and an WBX daughterboard, while I must be >> able to capture/transfer up to 30Msample/sec(1Gig ethernet limit ), with >> the sample rate of 25Msps or even 20Msps I have some dropped packets. Based >> on my knowledge, this is due to CPU which does not have enough time to >> capture from Ethernet, however, I have the powerful one, 12 core CPU. When >> I have a large GNURadio program to run, there are some dropped packets. I >> searched everywhere but I did not find a complete description of the >> solution. What is (are ) the solution(s )? Please help me with any >> information! :( >> >> Best regards >> Mostafa >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Packet drop from Ethernet (A BIG PROBLEM)
Hi, This issue is better addressed to usrp-us...@ettus.com. Briefly I can tell you that you can never reach 30M samples/sec over a 1 GbE interface. 30 x 32/bits/sample = 960. Need a bit for metadata, packet overheads, etc. you will drop packages. Especially if your NIC is PCI based :( Try reducing your sample resolution to 8 bits. You may have better luck. HTH, Nikos On Wed, Mar 9, 2016 at 9:42 AM, Mostafa Alizadeh wrote: > Hello all, > I stuck on an incridible challenge in sending/receiving a large bandwidth. > I have an USRP N210 and an WBX daughterboard, while I must be able to > capture/transfer up to 30Msample/sec(1Gig ethernet limit ), with the sample > rate of 25Msps or even 20Msps I have some dropped packets. Based on my > knowledge, this is due to CPU which does not have enough time to capture > from Ethernet, however, I have the powerful one, 12 core CPU. When I have a > large GNURadio program to run, there are some dropped packets. I searched > everywhere but I did not find a complete description of the solution. What > is (are ) the solution(s )? Please help me with any information! :( > > Best regards > Mostafa > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Packet drop from Ethernet (A BIG PROBLEM)
Hello all, I stuck on an incridible challenge in sending/receiving a large bandwidth. I have an USRP N210 and an WBX daughterboard, while I must be able to capture/transfer up to 30Msample/sec(1Gig ethernet limit ), with the sample rate of 25Msps or even 20Msps I have some dropped packets. Based on my knowledge, this is due to CPU which does not have enough time to capture from Ethernet, however, I have the powerful one, 12 core CPU. When I have a large GNURadio program to run, there are some dropped packets. I searched everywhere but I did not find a complete description of the solution. What is (are ) the solution(s )? Please help me with any information! :( Best regards Mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
