PipeInput on Linux (Centos 6.5)

Hi there,

We have a weird problem with using PipeOutputs on Linux with XEM6310-LX150 - it works unstable.
In our software, call to ReadFromBlockPipeOut sometimes stalls forever.

The PipeInput example fails (sometimes!) like that:

[mrc@newp]$ ./PipeTest pipetest.bit stress
---- Opal Kelly ---- PipeTest Application v2.0 ----
FrontPanel DLL loaded. Built: Mar 22 2016 14:06:29
Found a device: XEM6310-LX150
Device firmware version: 1.23
Device serial number: 1616000ED7
Device device ID: 22
FrontPanel support is enabled.
Read SS:4194304 TS:67108864 Pattern:0 Duration: 0.351 seconds – 182.27 MB/s
Read SS:4194304 TS:67108864 Pattern:1 Duration: 0.399 seconds – 160.50 MB/s
Read SS:4194304 TS:67108864 Pattern:2 Transfer Failed with error: -1
Read SS:4194304 TS:67108864 Pattern:3 Transfer Failed with error: -1
Read SS:4194304 TS:67108864 Pattern:4 Transfer Failed with error: -1
Read SS:4194304 TS:67108864 Pattern:5 Transfer Failed with error: -1
Write SS:4194304 TS:67108864 Pattern:0 Duration: 0.726 seconds – 88.18 MB/s
Write SS:4194304 TS:67108864 Pattern:1 Duration: 0.792 seconds – 80.84 MB/s
Write SS:4194304 TS:67108864 Pattern:2 Duration: 0.729 seconds – 87.75 MB/s
Write SS:4194304 TS:67108864 Pattern:3 Duration: 0.720 seconds – 88.91 MB/s

pipetest.bit is from 20121018-FP42-XEM6310-LX150.zip archive.
Assembling the bit file in ISE changes nothing - it fails in the same manner.

Note: it doesn’t fail every run. Sometimes we do have up to 5-8 successful runs in a row.
Also reproducible on BRK board, so I don’t think power supply is an issue.

OS is CentOS 6. uname -a:
Linux newp 2.6.32-431.el6.x86_64 # 1 SMP Friday Nov 22 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Anything to check?

Can you provide details of the machine? What processor? What USB controller / hardware / hub / etc ?

Intel i7 CPU, MSI B85i motherboard (MSI Global - The Leading Brand in High-end Gaming & Professional Creation).
No external usb hubs are used.

any ideas?

Additional observation: if the test run fails, next run fails to find XEM at all (“no device connected?”).
The next-next run will work again (and may even succeed).

Do you have another computer you could try? USB3 solutions have been pretty varied in quality until recently.

Are you using the USB3 cable that was provided with the board or another one? A sufficiently poor USB3 connection could in theory cause the behavior that you’re observing.

Thank you for your help,
the problem indeed is the cabling.

We did use the supplied cable, but it was connected through port bracket first (connected to internal MoBo USB 3.0 connector).
When the cable is connected directly to the MoBo backside connector, everything seems to work just fine.

Unfortunately, we have problems using backside connector in our setup (this is a DAQ system in a custom enclosure and there is not enough space for the cable on the back side of MoBo).

We tried replacing the bracket we used with this one: http://www.greenconnection.cn/product-65-en.html (the most expensive in the nearby store) but that also didn’t work - same problem (may be a little better).

Could you please provide any recommendations on

  1. Cable requirements? Some kind of compliance mark to look for?
  2. Cable brands you know works well?
  3. Based on your experience, is it possible at all to use the MoBo internal USB 3.0 connector (20 pin header)?
  4. Based on your experience, is it possible to use right-angle adapters like http://www.greenconnection.cn/product-122-en.html or is it a waste?

Thank you in advance.
It seems like every manufacturer marks their cables as “high quality”, so we would really appreciate some guidance on that.

Unfortunately there isn’t a whole lot of regulation or compliance in the USB cable market right now (I believe they are trying to change that with USB Type C down the road). We have had pretty good experiences with cables from CableMatters and Monoprice. I believe AmazonBasics also has some that are decent quality. Some of the monoprice cables are a bit thinner and easier to bend so depending on how much room you have to access the motherboard rear connectors you may be able to squeeze one in (link).

We primarily use Apple hardware internally as they provide some of the most consistent USB3 solutions. These do not use the traditional 20-pin USB3 connector on consumer motherboards however. Perhaps another user can provide some insight as to whether or not they see decent performance with them.

If you have room for the right-angle adapter I think it wouldn’t hurt to try it, though we haven’t used them internally.

If you do figure something out do let us know! It could be beneficial to other users down the road.

Thank you.

I will update the post with our findings. To the moment, ‘Cableexpert’ and ‘5bites’ doesn’t work, ‘Greenconnect’ works but gives errors once an hour, CableMatters (shipped one) works almost all the time.

Worst of all, even the shipped CableMatters cable still gives some errors when running long-term tests - something like a fail in 2-3 days of runtime. Fails are very sporadic and seems to be completely unrelated to what we are doing at all (I don’t think it is a firmware bug - fail rate varies with the cable used). Temperatures/power are OK too.

Could you please describe what exactly happens when using the “bad” cables?
I though the cable will simply limit max speed (due to increased error rates), but obviously, this is not the case - everything just hangs in ReadFromBlockPipeOut.

Can changing the block size help?

Guys,

could you please describe what is the “cable problem” technically?
We need to run-around this issue somehow, but that’s hard without understanding of what is actually happening there.

Thank you in advance.

It all comes down to signal integrity. The cables, connectors, and other wiring that attaches one device to another have to be good quality.

But generally, if you’ve got all that, then you may be having a different issue. Contact [email protected]. This is a public forum and not the proper venue for personalized, timely support from Opal Kelly.