Re: [USRP-users] Demuxer Error : Bad Frames (My Solution So Far)

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [USRP-users] Demuxer Error : Bad Frames (My Solution So Far)

Martin Braun via USRP-users
/usrp/common/recv_packet_demuxer.cpp:90: That is the error that I have been getting.

It already looks like corruption from rx_index < _queue.size(). The trick is to see if it actually is and anything else is corrupted. I doubt just a few bytes would suffer; however, it is possible. Line 45 shows that this is a simple read out of the packet header at byte position 4 of 4 bytes. Looking at the bad SID it is obvious the entire identifier is just garbage in value. It is also interesting because I can see when it does happen that it is constant. Not just a single lost packet. Although, recently, I observed a few random ones as I change some parameters on the card. 

The next culprit location could be _transport->get_recv_buff(timeout). 

It makes me wonder if a timeout is happening and the function is returning junk in the buffer..

On Mon, Mar 21, 2016 at 4:35 PM, Kevin McGuire <[hidden email]> wrote:
It worked for quite some time and has now degraded back, LOL.

UHD Error:
    recv packet demuxer unexpected sid 0xfecdfe78

I power cycled the board. It could be my USB chipset I suppose:

00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:12.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller
00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:13.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller

I may be able to figure it out eventually if I go digging into the UHD source code.

Best,
- Kevin McGuire

On Mon, Mar 21, 2016 at 10:23 AM, Kevin McGuire <[hidden email]> wrote:
I have been suffering from this from time to time. I normally just RX with USB 2.0 power. However, if I set it to use 8-bit complex or 12-bit complex I can usually have this error happen fairly quickly.

I know that the documentation says that I should be using the DC external power but I ignored that for some time. Today, that issue really stopped me in my tracks while doing RX and TX, which caused me to remember, so I connected the external power and the error seems to have gone away. 

I have read old mail from this list about people having similar problem. I thought that I might throw this in for you guys to chew on and perhaps it could be the problem at times.

I can not confirm it without a doubt but I will surely report back if the error happens again using external power. It does make sense that something could be drawing too much power and causing some timing issues or even preventing the proper voltages and current sourcing onto the USB bus, therefore, corrupting frames.

Best,
- Kevin McGuire.



_______________________________________________
USRP-users mailing list
[hidden email]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Reply | Threaded
Open this post in threaded view
|

Re: [USRP-users] Demuxer Error : Bad Frames (My Solution So Far)

Martin Braun via USRP-users
Kevin,
I every case I have seen when presented with the UHD error :
recv packet demuxer unexpected sid

…the cause is the loss of a small portion of a packet starting at the header. What you see as "corruption" is in fact raw sample data now being interpreted as header data.
The ultimate root cause is a H/W bug in the DMA engine in the Cypress FX3 chip related to a corner case race condition when it swaps out an underlying RAM DMA buffer for another.

-Ian

On Apr 3, 2016, at 6:55 AM, Kevin McGuire via USRP-users <[hidden email]> wrote:

/usrp/common/recv_packet_demuxer.cpp:90: That is the error that I have been getting.

It already looks like corruption from rx_index < _queue.size(). The trick is to see if it actually is and anything else is corrupted. I doubt just a few bytes would suffer; however, it is possible. Line 45 shows that this is a simple read out of the packet header at byte position 4 of 4 bytes. Looking at the bad SID it is obvious the entire identifier is just garbage in value. It is also interesting because I can see when it does happen that it is constant. Not just a single lost packet. Although, recently, I observed a few random ones as I change some parameters on the card. 

The next culprit location could be _transport->get_recv_buff(timeout). 

It makes me wonder if a timeout is happening and the function is returning junk in the buffer..

On Mon, Mar 21, 2016 at 4:35 PM, Kevin McGuire <[hidden email]> wrote:
It worked for quite some time and has now degraded back, LOL.

UHD Error:
    recv packet demuxer unexpected sid 0xfecdfe78

I power cycled the board. It could be my USB chipset I suppose:

00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:12.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller
00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:13.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller

I may be able to figure it out eventually if I go digging into the UHD source code.

Best,
- Kevin McGuire

On Mon, Mar 21, 2016 at 10:23 AM, Kevin McGuire <[hidden email]> wrote:
I have been suffering from this from time to time. I normally just RX with USB 2.0 power. However, if I set it to use 8-bit complex or 12-bit complex I can usually have this error happen fairly quickly.

I know that the documentation says that I should be using the DC external power but I ignored that for some time. Today, that issue really stopped me in my tracks while doing RX and TX, which caused me to remember, so I connected the external power and the error seems to have gone away. 

I have read old mail from this list about people having similar problem. I thought that I might throw this in for you guys to chew on and perhaps it could be the problem at times.

I can not confirm it without a doubt but I will surely report back if the error happens again using external power. It does make sense that something could be drawing too much power and causing some timing issues or even preventing the proper voltages and current sourcing onto the USB bus, therefore, corrupting frames.

Best,
- Kevin McGuire.


_______________________________________________
USRP-users mailing list
[hidden email]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


_______________________________________________
USRP-users mailing list
[hidden email]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Reply | Threaded
Open this post in threaded view
|

Re: [USRP-users] Demuxer Error : Bad Frames (My Solution So Far)

Martin Braun via USRP-users
That's not actually the chipset, thats the device end of the USB link on the B210. The world has, until recently been struggling along with only one vendor with a suitable part to make a USB3 SS radio.
It's heavily mitigated in UHD but the best workaround I'm aware would require a big architectural change. It's a frustrating one for sure, its very hard to understand why certain host systems trigger it way more readily than others.

On Apr 3, 2016, at 9:24 PM, Kevin McGuire <[hidden email]> wrote:

On Apr 3, 2016 12:26 PM, "Ian Buckley" <[hidden email]> wrote:
>
> Kevin,
> I every case I have seen when presented with the UHD error :
>>>
>>> recv packet demuxer unexpected sid
>
>
> …the cause is the loss of a small portion of a packet starting at the header. What you see as "corruption" is in fact raw sample data now being interpreted as header data.
> The ultimate root cause is a H/W bug in the DMA engine in the Cypress FX3 chip related to a corner case race condition when it swaps out an underlying RAM DMA buffer for another.

Darn, I read about this. I thought I did not have that chipset. I likely do. I apologize, if I had known, or remembered, I would not have posted to the list.

However, since I have gone this far I only need to prove it by interpreting the alignment correctly and validating they are raw samples just for rigor and well more evidence never hurts. It should be one simple quick check and complex vectors using 32-bit little endian floats should pop out.

Luckily, I have another chipset I am switching too for other reasons not related. Gosh, I am sorry to bother you with this; however, I am grateful you took your time to tell me!

I wish I could better express my sincere thanks for your information.



_______________________________________________
USRP-users mailing list
[hidden email]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Reply | Threaded
Open this post in threaded view
|

Re: [USRP-users] Demuxer Error : Bad Frames (My Solution So Far)

Martin Braun via USRP-users
On Mon, Apr 4, 2016 at 1:03 AM, Ian Buckley <[hidden email]> wrote:
That's not actually the chipset, thats the device end of the USB link on the B210. The world has, until recently been struggling along with only one vendor with a suitable part to make a USB3 SS radio.
It's heavily mitigated in UHD but the best workaround I'm aware would require a big architectural change. It's a frustrating one for sure, its very hard to understand why certain host systems trigger it way more readily than others.

I was about to purchase a new development machine. I have actually become in need of the increased bandwidth that USB 3.0 can provide. However, I would like to purchase something that does not trigger this bug in the Cypress FX3 chipset. I did some google searching for some type of list of compatible host chipsets. At least, I thought there existed some sort of list like that, but it might be something else I am confusing that with.

Thanks,
Kevin 

_______________________________________________
USRP-users mailing list
[hidden email]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Reply | Threaded
Open this post in threaded view
|

Re: [USRP-users] Demuxer Error : Bad Frames (My Solution So Far)

Martin Braun via USRP-users
I should say that even ARM boards would be fine as long as they can handle a small build of Linux.

On Wed, Sep 7, 2016 at 9:03 PM, Kevin McGuire <[hidden email]> wrote:
On Mon, Apr 4, 2016 at 1:03 AM, Ian Buckley <[hidden email]> wrote:
That's not actually the chipset, thats the device end of the USB link on the B210. The world has, until recently been struggling along with only one vendor with a suitable part to make a USB3 SS radio.
It's heavily mitigated in UHD but the best workaround I'm aware would require a big architectural change. It's a frustrating one for sure, its very hard to understand why certain host systems trigger it way more readily than others.

I was about to purchase a new development machine. I have actually become in need of the increased bandwidth that USB 3.0 can provide. However, I would like to purchase something that does not trigger this bug in the Cypress FX3 chipset. I did some google searching for some type of list of compatible host chipsets. At least, I thought there existed some sort of list like that, but it might be something else I am confusing that with.

Thanks,
Kevin 


_______________________________________________
USRP-users mailing list
[hidden email]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Reply | Threaded
Open this post in threaded view
|

Re: [USRP-users] Demuxer Error : Bad Frames (My Solution So Far)

Martin Braun via USRP-users
On 09/07/2016 10:04 PM, Kevin McGuire via USRP-users wrote:
I should say that even ARM boards would be fine as long as they can handle a small build of Linux.
I've used the Odroid XU4 with a pair of B205minis.  Haven't really seen what the envelope is yet.

I've also used a Orico USB3 card, that uses the VIA VL800-series chipset with a B210, and an AMD FX-series 6-core motherboard,
  FWIW.

The problem is that the consumer electronics end of the PC world changes very quickly.  You can find that a card that was called
  a "wonderthing 5000 USB3 card" will change controllers mid-production.  So, an early production run of it might be fine, and then
  a later run, it's something totally different.



On Wed, Sep 7, 2016 at 9:03 PM, Kevin McGuire <[hidden email]> wrote:
On Mon, Apr 4, 2016 at 1:03 AM, Ian Buckley <[hidden email]> wrote:
That's not actually the chipset, thats the device end of the USB link on the B210. The world has, until recently been struggling along with only one vendor with a suitable part to make a USB3 SS radio.
It's heavily mitigated in UHD but the best workaround I'm aware would require a big architectural change. It's a frustrating one for sure, its very hard to understand why certain host systems trigger it way more readily than others.

I was about to purchase a new development machine. I have actually become in need of the increased bandwidth that USB 3.0 can provide. However, I would like to purchase something that does not trigger this bug in the Cypress FX3 chipset. I did some google searching for some type of list of compatible host chipsets. At least, I thought there existed some sort of list like that, but it might be something else I am confusing that with.

Thanks,
Kevin 



_______________________________________________
USRP-users mailing list
[hidden email]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


_______________________________________________
USRP-users mailing list
[hidden email]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Reply | Threaded
Open this post in threaded view
|

[USRP-users] Fwd: Demuxer Error : Bad Frames (My Solution So Far)

Martin Braun via USRP-users
On Wed, Sep 7, 2016 at 9:26 PM, Marcus D. Leech <[hidden email]> wrote:
The problem is that the consumer electronics end of the PC world changes very quickly.  You can find that a card that was called
  a "wonderthing 5000 USB3 card" will change controllers mid-production.  So, an early production run of it might be fine, and then
  a later run, it's something totally different.

Good news. My new system works great with Linux. It is a mid-performance system as a HP Pavilion G7. I suppose as you said listing the hardware or chipset is not very helpful; however, I did experience a bad VRT header under VirtualBox'ed Linux system hosted by Windows. It may be that systems that are too slow trigger the big also. I was able to test and get 56MSPS (I believe I had to use scalar complex 8-bit over the wire) on this system for RX--- and I am sure that RX and TX would work if properly sharing the bandwidth.

So, a wonderful piece of engineering! Was wonderful even when it only did 6MSPS too, lol.

_______________________________________________
USRP-users mailing list
[hidden email]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com