> > Use a 5-6V supply capable of 2 or 3 amps. > > Thanks, it's actually working fine, the led properly turned green after the firmware and gateware were uploaded. Trying .\benchmark_rate.exe --rx_rate 40e6 I get Benchmark rate summary: Num received samples: 201778444 Num dropped samples: 2800 Num overruns detected: 2800 Num transmitted samples: 0 Num sequence errors (Tx): 0 Num sequence errors (Rx): 0 Num underruns detected: 0 Num late commands: 0 Num timeouts (Tx): 0 Num timeouts (Rx): 0 It seems I still can't stream faster than around 28MS/s. I still get similar results with .\rx_samples_to_file.exe (using --null to not store to file). Should I try to run some tests from http://files.ettus.com/manual/page_rdtesting.html ? Concerning the error "[ERROR] [USB] libusb_session_impl::libusb_event_handler_task: LIBUSB_ERROR_CODE -1" that I get when specifying num_recv_frames, what could I do? Should I try a different driver? Has anyone already experienced that error? Thanks.

 Use a 5-6V supply capable of 2 or 3 amps.

On 07/25/2018 01:08 PM, RizThon wrote: > >> Use a 5-6V supply capable of 2 or 3 amps. > > Thanks, it's actually working fine, the led properly turned green > after the firmware and gateware were uploaded. > > Trying .\benchmark_rate.exe --rx_rate 40e6 I get > Benchmark rate summary: > Num received samples: 201778444 > Num dropped samples: 2800 > Num overruns detected: 2800 > Num transmitted samples: 0 > Num sequence errors (Tx): 0 > Num sequence errors (Rx): 0 > Num underruns detected: 0 > Num late commands: 0 > Num timeouts (Tx): 0 > Num timeouts (Rx): 0 > > It seems I still can't stream faster than around 28MS/s. I still get > similar results with .\rx_samples_to_file.exe (using --null to not > store to file). > > Should I try to run some tests from > http://files.ettus.com/manual/page_rdtesting.html ? > > Concerning the error "[ERROR] [USB] > libusb_session_impl::libusb_event_handler_task: LIBUSB_ERROR_CODE > -1" that I get when specifying num_recv_frames, what could I do? > Should I try a different driver? Has anyone already experienced that > error? > > Thanks. > Try with a smaller number? The Windows LIBUSB behaves differently than the Linux version. On Linux, I can usually ask for 256 without any issue. Try 64.

I already tried smaller values, but not small enough. It seems the highest I can go is num_recv_frames=44. Anything higher gives me errors. At 40MS/s, without that parameter, I get 160 to 180 overflows over 20 seconds, while with num_recv_frames=44 I only get 20 to 30. This actually allows me to stream at 55MS/s in *sc8* for 20s without any overflow! With sc16 though, I don't seem much difference and still get more than 5000 overflows. Is it possible to use sc12 with the B2x0? The ADC having a 12 bits resolution, we wouldn't lose any data. Concerning num_recv_frames, is this a problem with the Windows USB driver, meaning I wouldn't get better results on another Windows computer? I tried other drivers, using Zadig. Only the "WinUSB" driver works, but it doesn't work better than the original Ettus driver. Do you advise people to use Linux rather than Windows for USB performance reasons? Should using 256 or 128 fix my streaming problems? Thanks. On Thu, Jul 26, 2018 at 2:00 AM Marcus D. Leech <mleech@ripnet.com> wrote: > On 07/25/2018 01:08 PM, RizThon wrote: > > Use a 5-6V supply capable of 2 or 3 amps. >> >> Thanks, it's actually working fine, the led properly turned green after > the firmware and gateware were uploaded. > > Trying .\benchmark_rate.exe --rx_rate 40e6 I get > Benchmark rate summary: > Num received samples: 201778444 > Num dropped samples: 2800 > Num overruns detected: 2800 > Num transmitted samples: 0 > Num sequence errors (Tx): 0 > Num sequence errors (Rx): 0 > Num underruns detected: 0 > Num late commands: 0 > Num timeouts (Tx): 0 > Num timeouts (Rx): 0 > > It seems I still can't stream faster than around 28MS/s. I still get > similar results with .\rx_samples_to_file.exe (using --null to not store > to file). > > Should I try to run some tests from > http://files.ettus.com/manual/page_rdtesting.html ? > > Concerning the error "[ERROR] [USB] > libusb_session_impl::libusb_event_handler_task: LIBUSB_ERROR_CODE -1" that > I get when specifying num_recv_frames, what could I do? Should I try a > different driver? Has anyone already experienced that error? > > Thanks. > > Try with a smaller number? The Windows LIBUSB behaves differently than > the Linux version. On Linux, I can usually ask for 256 without > any issue. Try 64. > > >

 On 07/25/2018 01:08 PM, RizThon wrote:

     Use a 5-6V supply capable of 2 or 3 amps.

 Thanks, it's actually working fine, the led properly turned green
 after the firmware and gateware were uploaded.

 Trying .\benchmark_rate.exe --rx_rate 40e6 I get
 Benchmark rate summary:
   Num received samples:     201778444
   Num dropped samples:      2800
   Num overruns detected:    2800
   Num transmitted samples:  0
   Num sequence errors (Tx): 0
   Num sequence errors (Rx): 0
   Num underruns detected:   0
   Num late commands:        0
   Num timeouts (Tx):        0
   Num timeouts (Rx):        0

 It seems I still can't stream faster than around 28MS/s. I still
 get similar results with .\rx_samples_to_file.exe (using --null
 to not store to file).

 Should I try to run some tests from
 http://files.ettus.com/manual/page_rdtesting.html ?

 Concerning the error "[ERROR] [USB]
 libusb_session_impl::libusb_event_handler_task: LIBUSB_ERROR_CODE
 -1" that I get when specifying num_recv_frames, what could I do?
 Should I try a different driver? Has anyone already experienced
 that error?

 Thanks.

 Try with a smaller number?    The Windows LIBUSB behaves
 differently than the Linux version.  On Linux, I can usually ask
 for 256 without
   any issue.  Try 64.

On 07/25/2018 10:18 PM, RizThon wrote: > I already tried smaller values, but not small enough. It seems the > highest I can go is num_recv_frames=44. Anything higher gives me errors. > > At 40MS/s, without that parameter, I get 160 to 180 overflows over 20 > seconds, while with num_recv_frames=44 I only get 20 to 30. > > This actually allows me to stream at 55MS/s in *sc8* for 20s without > any overflow! With sc16 though, I don't seem much difference and still > get more than 5000 overflows. > > Is it possible to use sc12 with the B2x0? The ADC having a 12 bits > resolution, we wouldn't lose any data. > > Concerning num_recv_frames, is this a problem with the Windows USB > driver, meaning I wouldn't get better results on another Windows > computer? I tried other drivers, using Zadig. Only the "WinUSB" driver > works, but it doesn't work better than the original Ettus driver. > > Do you advise people to use Linux rather than Windows for USB > performance reasons? Should using 256 or 128 fix my streaming problems? > > Thanks. > > > > On Thu, Jul 26, 2018 at 2:00 AM Marcus D. Leech <mleech@ripnet.com > <mailto:mleech@ripnet.com>> wrote: > > On 07/25/2018 01:08 PM, RizThon wrote: >> >>> Use a 5-6V supply capable of 2 or 3 amps. >> >> Thanks, it's actually working fine, the led properly turned green >> after the firmware and gateware were uploaded. >> >> Trying .\benchmark_rate.exe --rx_rate 40e6 I get >> Benchmark rate summary: >> Num received samples: 201778444 >> Num dropped samples: 2800 >> Num overruns detected: 2800 >> Num transmitted samples: 0 >> Num sequence errors (Tx): 0 >> Num sequence errors (Rx): 0 >> Num underruns detected: 0 >> Num late commands: 0 >> Num timeouts (Tx): 0 >> Num timeouts (Rx): 0 >> >> It seems I still can't stream faster than around 28MS/s. I still >> get similar results with .\rx_samples_to_file.exe (using --null >> to not store to file). >> >> Should I try to run some tests from >> http://files.ettus.com/manual/page_rdtesting.html ? >> >> Concerning the error "[ERROR] [USB] >> libusb_session_impl::libusb_event_handler_task: LIBUSB_ERROR_CODE >> -1" that I get when specifying num_recv_frames, what could I do? >> Should I try a different driver? Has anyone already experienced >> that error? >> >> Thanks. >> > Try with a smaller number? The Windows LIBUSB behaves > differently than the Linux version. On Linux, I can usually ask > for 256 without > any issue. Try 64. > > The SC12 format should work just fine. The particular values available for num_recv_frames seem to be libusb implementation specific, and to a certain extent controller specific as well. Windows is known to have somewhat poorer performance (at least with LibUSB type schemes) that Linux, TBH.

SC12 actually gives me an error as soon as it starts streaming (with or without specifying num_recv_frames=44). Using the --continue option, I get tons of such errors: [ERROR] [STREAMER] The receive packet handler caught a value exception. ValueError: bad vrt header or packet fragment Error: Receiver error: ERROR_CODE_BAD_PACKET Is this specific to my issues with USB, meaning on Linux it works well, or is the B210 (and B2x0 generally) not handling sc12? ( https://files.ettus.com/manual/structuhd_1_1stream__args__t.html mentions *Only some devices* for SC12). Thanks again. On Thu, Jul 26, 2018 at 10:25 AM Marcus D. Leech <mleech@ripnet.com> wrote: > On 07/25/2018 10:18 PM, RizThon wrote: > > I already tried smaller values, but not small enough. It seems the highest > I can go is num_recv_frames=44. Anything higher gives me errors. > > At 40MS/s, without that parameter, I get 160 to 180 overflows over 20 > seconds, while with num_recv_frames=44 I only get 20 to 30. > > This actually allows me to stream at 55MS/s in *sc8* for 20s without any > overflow! With sc16 though, I don't seem much difference and still get more > than 5000 overflows. > > Is it possible to use sc12 with the B2x0? The ADC having a 12 bits > resolution, we wouldn't lose any data. > > Concerning num_recv_frames, is this a problem with the Windows USB driver, > meaning I wouldn't get better results on another Windows computer? I > tried other drivers, using Zadig. Only the "WinUSB" driver works, but it > doesn't work better than the original Ettus driver. > > Do you advise people to use Linux rather than Windows for USB performance > reasons? Should using 256 or 128 fix my streaming problems? > > Thanks. > > > > On Thu, Jul 26, 2018 at 2:00 AM Marcus D. Leech <mleech@ripnet.com> wrote: > >> On 07/25/2018 01:08 PM, RizThon wrote: >> >> Use a 5-6V supply capable of 2 or 3 amps. >>> >>> Thanks, it's actually working fine, the led properly turned green after >> the firmware and gateware were uploaded. >> >> Trying .\benchmark_rate.exe --rx_rate 40e6 I get >> Benchmark rate summary: >> Num received samples: 201778444 >> Num dropped samples: 2800 >> Num overruns detected: 2800 >> Num transmitted samples: 0 >> Num sequence errors (Tx): 0 >> Num sequence errors (Rx): 0 >> Num underruns detected: 0 >> Num late commands: 0 >> Num timeouts (Tx): 0 >> Num timeouts (Rx): 0 >> >> It seems I still can't stream faster than around 28MS/s. I still get >> similar results with .\rx_samples_to_file.exe (using --null to not store >> to file). >> >> Should I try to run some tests from >> http://files.ettus.com/manual/page_rdtesting.html ? >> >> Concerning the error "[ERROR] [USB] >> libusb_session_impl::libusb_event_handler_task: LIBUSB_ERROR_CODE -1" that >> I get when specifying num_recv_frames, what could I do? Should I try a >> different driver? Has anyone already experienced that error? >> >> Thanks. >> >> Try with a smaller number? The Windows LIBUSB behaves differently than >> the Linux version. On Linux, I can usually ask for 256 without >> any issue. Try 64. >> >> >> The SC12 format should work just fine. > > The particular values available for num_recv_frames seem to be libusb > implementation specific, and to a certain extent controller specific as > well. > > Windows is known to have somewhat poorer performance (at least with LibUSB > type schemes) that Linux, TBH. > > >

What version of UHD? I’ve used SC12 myself without issue. Sent from my iPhone > On Jul 26, 2018, at 1:28 AM, RizThon <rizthon@gmail.com> wrote: > > SC12 actually gives me an error as soon as it starts streaming (with or without specifying num_recv_frames=44). Using the --continue option, I get tons of such errors: > > [ERROR] [STREAMER] The receive packet handler caught a value exception. > ValueError: bad vrt header or packet fragment > Error: Receiver error: ERROR_CODE_BAD_PACKET > > Is this specific to my issues with USB, meaning on Linux it works well, or is the B210 (and B2x0 generally) not handling sc12? (https://files.ettus.com/manual/structuhd_1_1stream__args__t.html mentions Only some devices for SC12). > > Thanks again. > >> On Thu, Jul 26, 2018 at 10:25 AM Marcus D. Leech <mleech@ripnet.com> wrote: >>> On 07/25/2018 10:18 PM, RizThon wrote: >>> I already tried smaller values, but not small enough. It seems the highest I can go is num_recv_frames=44. Anything higher gives me errors. >>> >>> At 40MS/s, without that parameter, I get 160 to 180 overflows over 20 seconds, while with num_recv_frames=44 I only get 20 to 30. >>> >>> This actually allows me to stream at 55MS/s in sc8 for 20s without any overflow! With sc16 though, I don't seem much difference and still get more than 5000 overflows. >>> >>> Is it possible to use sc12 with the B2x0? The ADC having a 12 bits resolution, we wouldn't lose any data. >>> >>> Concerning num_recv_frames, is this a problem with the Windows USB driver, meaning I wouldn't get better results on another Windows computer? I tried other drivers, using Zadig. Only the "WinUSB" driver works, but it doesn't work better than the original Ettus driver. >>> >>> Do you advise people to use Linux rather than Windows for USB performance reasons? Should using 256 or 128 fix my streaming problems? >>> >>> Thanks. >>> >>> >>> >>>> On Thu, Jul 26, 2018 at 2:00 AM Marcus D. Leech <mleech@ripnet.com> wrote: >>>>> On 07/25/2018 01:08 PM, RizThon wrote: >>>>>>> Use a 5-6V supply capable of 2 or 3 amps. >>>>> Thanks, it's actually working fine, the led properly turned green after the firmware and gateware were uploaded. >>>>> >>>>> Trying .\benchmark_rate.exe --rx_rate 40e6 I get >>>>> Benchmark rate summary: >>>>> Num received samples: 201778444 >>>>> Num dropped samples: 2800 >>>>> Num overruns detected: 2800 >>>>> Num transmitted samples: 0 >>>>> Num sequence errors (Tx): 0 >>>>> Num sequence errors (Rx): 0 >>>>> Num underruns detected: 0 >>>>> Num late commands: 0 >>>>> Num timeouts (Tx): 0 >>>>> Num timeouts (Rx): 0 >>>>> >>>>> It seems I still can't stream faster than around 28MS/s. I still get similar results with .\rx_samples_to_file.exe (using --null to not store to file). >>>>> >>>>> Should I try to run some tests from http://files.ettus.com/manual/page_rdtesting.html ? >>>>> >>>>> Concerning the error "[ERROR] [USB] libusb_session_impl::libusb_event_handler_task: LIBUSB_ERROR_CODE -1" that I get when specifying num_recv_frames, what could I do? Should I try a different driver? Has anyone already experienced that error? >>>>> >>>>> Thanks. >>>>> >>>> Try with a smaller number? The Windows LIBUSB behaves differently than the Linux version. On Linux, I can usually ask for 256 without >>>> any issue. Try 64. >>>> >>>> >> The SC12 format should work just fine. >> >> The particular values available for num_recv_frames seem to be libusb implementation specific, and to a certain extent controller specific as well. >> >> Windows is known to have somewhat poorer performance (at least with LibUSB type schemes) that Linux, TBH. >> >>

I've tried with 3.12.0.0, on both Windows and Linux. On Ubuntu 18.04, I can set num_recv_frames to what seems like any number without getting error. I tried 128, 256, even 512 and 1024. I do get better results than on Windows, but I'm still getting lots of overflows. I did try 3.13.0.0 on Windows just when it was out, but I got worst result (2850 overruns at 28MS/s in SC16 instead of just a few). So for now I reverted back to 3.12. So you confirm SC12 is supposed to work on a B210 (and I guess also on any B2x0)? That may allow me to reach 56MS/s If that's the case, what can be the problem? Thanks a lot. On Fri, Jul 27, 2018 at 12:14 AM Marcus D. Leech <mleech@ripnet.com> wrote: > What version of UHD? I’ve used SC12 myself without issue. > > Sent from my iPhone > > On Jul 26, 2018, at 1:28 AM, RizThon <rizthon@gmail.com> wrote: > > SC12 actually gives me an error as soon as it starts streaming (with or > without specifying num_recv_frames=44). Using the --continue option, I > get tons of such errors: > > [ERROR] [STREAMER] The receive packet handler caught a value exception. > ValueError: bad vrt header or packet fragment > Error: Receiver error: ERROR_CODE_BAD_PACKET > > Is this specific to my issues with USB, meaning on Linux it works well, or > is the B210 (and B2x0 generally) not handling sc12? ( > https://files.ettus.com/manual/structuhd_1_1stream__args__t.html mentions *Only > some devices* for SC12). > > Thanks again. > > On Thu, Jul 26, 2018 at 10:25 AM Marcus D. Leech <mleech@ripnet.com> > wrote: > >> On 07/25/2018 10:18 PM, RizThon wrote: >> >> I already tried smaller values, but not small enough. It seems the >> highest I can go is num_recv_frames=44. Anything higher gives me errors. >> >> At 40MS/s, without that parameter, I get 160 to 180 overflows over 20 >> seconds, while with num_recv_frames=44 I only get 20 to 30. >> >> This actually allows me to stream at 55MS/s in *sc8* for 20s without any >> overflow! With sc16 though, I don't seem much difference and still get more >> than 5000 overflows. >> >> Is it possible to use sc12 with the B2x0? The ADC having a 12 bits >> resolution, we wouldn't lose any data. >> >> Concerning num_recv_frames, is this a problem with the Windows USB >> driver, meaning I wouldn't get better results on another Windows computer? I >> tried other drivers, using Zadig. Only the "WinUSB" driver works, but it >> doesn't work better than the original Ettus driver. >> >> Do you advise people to use Linux rather than Windows for USB performance >> reasons? Should using 256 or 128 fix my streaming problems? >> >> Thanks. >> >> >> >> On Thu, Jul 26, 2018 at 2:00 AM Marcus D. Leech <mleech@ripnet.com> >> wrote: >> >>> On 07/25/2018 01:08 PM, RizThon wrote: >>> >>> Use a 5-6V supply capable of 2 or 3 amps. >>>> >>>> Thanks, it's actually working fine, the led properly turned green after >>> the firmware and gateware were uploaded. >>> >>> Trying .\benchmark_rate.exe --rx_rate 40e6 I get >>> Benchmark rate summary: >>> Num received samples: 201778444 >>> Num dropped samples: 2800 >>> Num overruns detected: 2800 >>> Num transmitted samples: 0 >>> Num sequence errors (Tx): 0 >>> Num sequence errors (Rx): 0 >>> Num underruns detected: 0 >>> Num late commands: 0 >>> Num timeouts (Tx): 0 >>> Num timeouts (Rx): 0 >>> >>> It seems I still can't stream faster than around 28MS/s. I still get >>> similar results with .\rx_samples_to_file.exe (using --null to not >>> store to file). >>> >>> Should I try to run some tests from >>> http://files.ettus.com/manual/page_rdtesting.html ? >>> >>> Concerning the error "[ERROR] [USB] >>> libusb_session_impl::libusb_event_handler_task: LIBUSB_ERROR_CODE -1" that >>> I get when specifying num_recv_frames, what could I do? Should I try a >>> different driver? Has anyone already experienced that error? >>> >>> Thanks. >>> >>> Try with a smaller number? The Windows LIBUSB behaves differently >>> than the Linux version. On Linux, I can usually ask for 256 without >>> any issue. Try 64. >>> >>> >>> The SC12 format should work just fine. >> >> The particular values available for num_recv_frames seem to be libusb >> implementation specific, and to a certain extent controller specific as >> well. >> >> Windows is known to have somewhat poorer performance (at least with >> LibUSB type schemes) that Linux, TBH. >> >> >>

 What version of UHD?  I’ve used SC12 myself without issue.

 Sent from my iPhone

 On Jul 26, 2018, at 1:28 AM, RizThon <rizthon@gmail.com
 <mailto:rizthon@gmail.com>> wrote:

 SC12 actually gives me an error as soon as it starts streaming
 (with or without specifying num_recv_frames=44). Using the
 --continue option, I get tons of such errors:

 [ERROR] [STREAMER] The receive packet handler caught a value
 exception.
 ValueError: bad vrt header or packet fragment
 Error: Receiver error: ERROR_CODE_BAD_PACKET

 Is this specific to my issues with USB, meaning on Linux it works
 well, or is the B210 (and B2x0 generally) not handling sc12?
 (https://files.ettus.com/manual/structuhd_1_1stream__args__t.htmlmentions/Only
 some devices/for SC12).

 Thanks again.

 On Thu, Jul 26, 2018 at 10:25 AM Marcus D. Leech
 <mleech@ripnet.com <mailto:mleech@ripnet.com>> wrote:

     On 07/25/2018 10:18 PM, RizThon wrote:

     I already tried smaller values, but not small enough. It
     seems the highest I can go is num_recv_frames=44. Anything
     higher gives me errors.

     At 40MS/s, without that parameter, I get 160 to 180
     overflows over 20 seconds, while with num_recv_frames=44 I
     only get 20 to 30.

     This actually allows me to stream at 55MS/s in *sc8* for 20s
     without any overflow! With sc16 though, I don't seem much
     difference and still get more than 5000 overflows.

     Is it possible to use sc12 with the B2x0? The ADC having a
     12 bits resolution, we wouldn't lose any data.

     Concerning num_recv_frames, is this a problem with the
     Windows USB driver, meaning I wouldn't get better results on
     another Windows computer? I tried other drivers, using
     Zadig. Only the "WinUSB" driver works, but it doesn't work
     better than the original Ettus driver.

     Do you advise people to use Linux rather than Windows for
     USB performance reasons? Should using 256 or 128 fix my
     streaming problems?

     Thanks.



     On Thu, Jul 26, 2018 at 2:00 AM Marcus D. Leech
     <mleech@ripnet.com <mailto:mleech@ripnet.com>> wrote:

         On 07/25/2018 01:08 PM, RizThon wrote:

             Use a 5-6V supply capable of 2 or 3 amps.

         Thanks, it's actually working fine, the led properly
         turned green after the firmware and gateware were uploaded.

         Trying .\benchmark_rate.exe --rx_rate 40e6 I get
         Benchmark rate summary:
           Num received samples:     201778444
           Num dropped samples:      2800
           Num overruns detected:    2800
           Num transmitted samples:  0
           Num sequence errors (Tx): 0
           Num sequence errors (Rx): 0
           Num underruns detected:   0
           Num late commands:        0
           Num timeouts (Tx):        0
           Num timeouts (Rx):        0

         It seems I still can't stream faster than around
         28MS/s. I still get similar results with
         .\rx_samples_to_file.exe (using --null to not store to
         file).

         Should I try to run some tests from
         http://files.ettus.com/manual/page_rdtesting.html ?

         Concerning the error "[ERROR] [USB]
         libusb_session_impl::libusb_event_handler_task:
         LIBUSB_ERROR_CODE -1" that I get when specifying
         num_recv_frames, what could I do? Should I try a
         different driver? Has anyone already experienced that
         error?

         Thanks.

         Try with a smaller number?    The Windows LIBUSB behaves
         differently than the Linux version.  On Linux, I can
         usually ask for 256 without
           any issue.  Try 64.

     The SC12 format should work just fine.

     The particular values available for num_recv_frames seem to
     be libusb implementation specific, and to a certain extent
     controller specific as well.

     Windows is known to have somewhat poorer performance (at
     least with LibUSB type schemes) that Linux, TBH.

On 07/27/2018 12:02 AM, RizThon wrote: > I've tried with 3.12.0.0, on both Windows and Linux. > > On Ubuntu 18.04, I can set num_recv_frames to what seems like any > number without getting error. I tried 128, 256, even 512 and 1024. > > I do get better results than on Windows, but I'm still getting lots of > overflows. > > I did try 3.13.0.0 on Windows just when it was out, but I got worst > result (2850 overruns at 28MS/s in SC16 instead of just a few). So for > now I reverted back to 3.12. > > So you confirm SC12 is supposed to work on a B210 (and I guess also on > any B2x0)? That may allow me to reach 56MS/s > > If that's the case, what can be the problem? The SC12 support apparently broke at some point. I know that Michael West (Ettus R&D team) has been working to get it working again, but won't be ready for a little bit. I use SC12 myself in my lab, but I don't recall which UHD version I'm using in the lab, and won't be there until tomorrow evening. If possible try to revert to 3.10. Thing is, there's no way anyone can guarantee any particular sample rate is possible on your system, because of significant differences from system to system, and significant differences from workload to workload. Anything that involves recording samples to disk at high input rates is very tricky to make work, for example. Anything that involves a lot of processing of the samples is going to have a higher compute load, and be more likely to cause overruns. > > Thanks a lot. > > On Fri, Jul 27, 2018 at 12:14 AM Marcus D. Leech <mleech@ripnet.com > <mailto:mleech@ripnet.com>> wrote: > > What version of UHD? I’ve used SC12 myself without issue. > > Sent from my iPhone > > On Jul 26, 2018, at 1:28 AM, RizThon <rizthon@gmail.com > <mailto:rizthon@gmail.com>> wrote: > >> SC12 actually gives me an error as soon as it starts streaming >> (with or without specifying num_recv_frames=44). Using the >> --continue option, I get tons of such errors: >> >> [ERROR] [STREAMER] The receive packet handler caught a value >> exception. >> ValueError: bad vrt header or packet fragment >> Error: Receiver error: ERROR_CODE_BAD_PACKET >> >> Is this specific to my issues with USB, meaning on Linux it works >> well, or is the B210 (and B2x0 generally) not handling sc12? >> (https://files.ettus.com/manual/structuhd_1_1stream__args__t.htmlmentions/Only >> some devices/for SC12). >> >> Thanks again. >> >> On Thu, Jul 26, 2018 at 10:25 AM Marcus D. Leech >> <mleech@ripnet.com <mailto:mleech@ripnet.com>> wrote: >> >> On 07/25/2018 10:18 PM, RizThon wrote: >>> I already tried smaller values, but not small enough. It >>> seems the highest I can go is num_recv_frames=44. Anything >>> higher gives me errors. >>> >>> At 40MS/s, without that parameter, I get 160 to 180 >>> overflows over 20 seconds, while with num_recv_frames=44 I >>> only get 20 to 30. >>> >>> This actually allows me to stream at 55MS/s in *sc8* for 20s >>> without any overflow! With sc16 though, I don't seem much >>> difference and still get more than 5000 overflows. >>> >>> Is it possible to use sc12 with the B2x0? The ADC having a >>> 12 bits resolution, we wouldn't lose any data. >>> >>> Concerning num_recv_frames, is this a problem with the >>> Windows USB driver, meaning I wouldn't get better results on >>> another Windows computer? I tried other drivers, using >>> Zadig. Only the "WinUSB" driver works, but it doesn't work >>> better than the original Ettus driver. >>> >>> Do you advise people to use Linux rather than Windows for >>> USB performance reasons? Should using 256 or 128 fix my >>> streaming problems? >>> >>> Thanks. >>> >>> >>> >>> On Thu, Jul 26, 2018 at 2:00 AM Marcus D. Leech >>> <mleech@ripnet.com <mailto:mleech@ripnet.com>> wrote: >>> >>> On 07/25/2018 01:08 PM, RizThon wrote: >>>> >>>>> Use a 5-6V supply capable of 2 or 3 amps. >>>> >>>> Thanks, it's actually working fine, the led properly >>>> turned green after the firmware and gateware were uploaded. >>>> >>>> Trying .\benchmark_rate.exe --rx_rate 40e6 I get >>>> Benchmark rate summary: >>>> Num received samples: 201778444 >>>> Num dropped samples: 2800 >>>> Num overruns detected: 2800 >>>> Num transmitted samples: 0 >>>> Num sequence errors (Tx): 0 >>>> Num sequence errors (Rx): 0 >>>> Num underruns detected: 0 >>>> Num late commands: 0 >>>> Num timeouts (Tx): 0 >>>> Num timeouts (Rx): 0 >>>> >>>> It seems I still can't stream faster than around >>>> 28MS/s. I still get similar results with >>>> .\rx_samples_to_file.exe (using --null to not store to >>>> file). >>>> >>>> Should I try to run some tests from >>>> http://files.ettus.com/manual/page_rdtesting.html ? >>>> >>>> Concerning the error "[ERROR] [USB] >>>> libusb_session_impl::libusb_event_handler_task: >>>> LIBUSB_ERROR_CODE -1" that I get when specifying >>>> num_recv_frames, what could I do? Should I try a >>>> different driver? Has anyone already experienced that >>>> error? >>>> >>>> Thanks. >>>> >>> Try with a smaller number? The Windows LIBUSB behaves >>> differently than the Linux version. On Linux, I can >>> usually ask for 256 without >>> any issue. Try 64. >>> >>> >> The SC12 format should work just fine. >> >> The particular values available for num_recv_frames seem to >> be libusb implementation specific, and to a certain extent >> controller specific as well. >> >> Windows is known to have somewhat poorer performance (at >> least with LibUSB type schemes) that Linux, TBH. >> >>

> > > The SC12 support apparently broke at some point. I know that Michael West > (Ettus R&D team) has been working to get it working again, > but won't be ready for a little bit. > > I use SC12 myself in my lab, but I don't recall which UHD version I'm > using in the lab, and won't be there until tomorrow evening. If possible > try to revert to 3.10. > Thanks a lot for your feedback, I'll try with older versions then. They did say that they fixed things with 3.13.0.0 concerning sc12/8, but it seemed it made things worse. I'll try that again also. If someone from Ettus is following, is there any schedule on the SC12 issue? Was that supposed to be fixed in 3.13.0.0? > Thing is, there's no way anyone can guarantee any particular sample rate > is possible on your system, because of significant differences from > system to system, and significant differences from workload to > workload. Anything that involves recording samples to disk at high input > rates is very tricky to make work, for example. Anything that involves > a lot of processing of the samples is going to have a higher compute > load, and be more likely to cause overruns. > I understand, it's just that at this point I'm only streaming, without any processing, not even saving to disk, on what I would expect be a more than decent computer, without much happening on the side.