VISA Read function slower for USB VCP than "real" serial port

[Edjsch]

Alisha,

To summarize, I see reduced performance on a USB VCP with LabVIEW 8.5 on both Windows 7 and XP, and on 5-year and 2-year old computers, both about 2 GHz and dual core. You said that running LV 8.2 on a Windows XP operating system on a 3.2 GHz PC (but an “older one” – I’m guessing single, not dual core. Correct?) shows ”significantly lower” speed. What are those speeds? But on your PC you see no speed degradation no matter what version of LabVIEW. Please confirm this to be correct.

Have you run the additional tests you mentioned? Should I get our NI Field Applications Engineer, whom I’m know from the User Group meetings has the latest version of LV on his laptop, involved?

Thanks,

Ed

[Alisha_P]

Ed,

Here are the speeds I saw according to your timing tests on the XP machine (not sure about the core - I'll have to check on that for you)

Speeds after 40s:

8.2: 186 rps

2009: 118 rps

2011: 112 rps

It's correct that I have seen no speed degradation on my PC on LabVIEW versions 2009-2011. I'm starting to doubt that this has anything to do with LabVIEW version. It seems much more related to machine.

We have not had a chance to complete testing yet. I will let you know what we find out.

[Edjsch]

Thanks, Alisha,

It's interesting (but disconcerting) that the newer versions of LV run SLOWER! That's not progress. Anyway, the slow speeds start instantly. The VISA Read is slower on a USB VCP than on a real COM port on each and every read. I am assuming that your would see the same average speeds in a 5 second test as in a 40 second test. Correct?

The only time the length of the run matters is when I'm storing the data in a table and/or graph and running on a real COM port. As I've told you, after around 8000 points are stored, data starts to build up in the read buffer decreasing the throughput. I'm assuming this is due to LV and Windows doing dynamic memory allocation. Do you agree? (It's been suggested that I stream the data to disk, but I haven't tried that yet. I'm wondering if there will be a slow down there, too. Do you know?)

Anyway, the first thing is to find out why VISA handles the VCP differently than a real COM port. The developers have no idea? Please keep me advised. Thank you.

Ed

[RavensFan]

I've been following along quietly.  One question that I have that I don't recall being asked or seeing an answer.  Have you tried using a different brand of USB serial port, something that has different drivers.  I've never seen any problems with the USB/RS-232 adapters I've seen.

I would really be more suspicious of flaky drivers from the adapter not behaving well with VISA then I would be of VISA being the source of the problems.

[SnowMule]

Having fought with SILabs VCP drivers for several years now... Have you tried different (older) versions of the driver?

The driver versions behave radically different from each other in my experience.  Fix one thing, break another... the "latest" version may not cooperate with USB root hubs on your PC as well as a down-rev will.

One other thing to check, I do this on every PC here... in Device Manager, under "USB Controllers", go into the details for every "USB Root Hub" and in the power tab uncheck "Allow the computer to turn off this device to save power".  That option does nothing but cause problems with test equipment.

Overall though, we've had pretty good luck with the CP2102's once we find the driver version that works best with the computers.

[Edjsch]

I thank you 2 members for your posts. Ravens Fan: I mentioned early on in my post that several years ago, when I started my project (LV8.2 was the current version), I had tried the NI USB-Serial converter. It was slower than some inexpensive ones, so we returned it. I didn’t use it in my recent tests, though. In the past we observed slower performance with any converter compared with a real serial port. But that was with a command-response protocol, which requires turning around the bus (from transmit to receive). (A real serial port is full-duplex.) In my recent tests used in this post, we are putting our device into an “auto-transmit” mode, which outputs up to (selectable) 250 readings per second, so other than the command to instruct our device to begin outputting, the data flow is in one direction, to my LV program.

Silicon Labs has “assured” me that their driver works up to the 1 M-baud their chip is rated at. When I test with HyperTerminal, it indeed does receive the 250 RPS that our device sends. So they seemed to be off the hook. Anyway, based on your query, I decided to test with 2 other converters we had lying around.

One is an older, no-name converter made inTaiwan whose driver is “FTDI”. (It came on a 3.5” floppy disk indicating how old it is). I also have a “Sabrent” converter, whose driver is “Prolific”. Well, low and behold, they BOTH keep up with 250 RPS, at least initially. They slow down as the bytes at port increased due toLVdynamic memory allocation (I believe).

I have attached a zip file of the Portmon log files for those 2 devices plus the SiLabs device. The log files show opening the port and a 1 second test run. Notice Portmon_COM6_SILAB.log has only 290 lines in the file, and the time between IOCTL_SERIAL_GET_COMMSTATUS is in the order of 5 milliseconds (mS.). If you look at the other files, Portmon_COM4_Prolific.log is the fastest, with 7375 lines averaging around 1 micro-second (uS.) times! Portmon_COM5_FTDI.log has 4235 lines and also about 1 uS. get status times. This seems to exonerate LabVIEW and seems to throw it back into Silicon Lab’s court. I’ll send them the log files, too, but I’ll bet they will point fingers at NI-LV, and vice-versa. However, Alisha has also seen the slow performance on her XP PC with the NI converter, so there seems to be an issue with NI’s driver, too.

The question remains: Why does the SiLabs driver work fast with HyperTerminal but not LabVIEW?

It appears that LV/VISA interaction with some drivers is slower than others. These VCPs have been around for quite a while, but I guess there is no standard driver and there are many driver implementations, and some work better than others.

Slow Mule: My current driver version is 5.4.24.0. What version have you found to be the best? (BTW, the USB Root Hub Power Management property is set to “Allow the computer to turn off this device to save power” on all hubs, even the 2 that work fast, so I don’t think this is the problem.)

I’ll let you know SiLabs’ reply. Comments?

Ed

[SnowMule]

---

@Edjsch wrote:

Slow Mule: My current driver version is 5.4.24.0. What version have you found to be the best? (BTW, the USB Root Hub Power Management property is set to “Allow the computer to turn off this device to save power” on all hubs, even the 2 that work fast, so I don’t think this is the problem.)

Ed

---

I've got the same version on this machine (Dell D630/XP) and it works fairly well here.  I've installed it on T3400 workstations (i think that's the model, it's one of Dell's nicer towers) and the newer V6.something works a lot better on those (and better on win7 too).   But the V6.x drivers are real flaky on my laptop.  :dunno

"Slow Mule"... I usually hear that at races, not so much online. 

[Edjsch]

Snow Mule - Sorry about the typo. No offense meant. I'm going to try it on a newer, 3 GHz Win7 PC and will let you know. But why would my older PC work fine with other USB converters? The 50% higher speed of Alisha's PC should not make such a difference. 2 GHz processor speed to soooo much higher than the 3000 characters per second that we are attempting to read. Remember, Silicon Labs claims it works up to 1 M-Baud, which is about 100,000 characters per second.

Ed

[SnowMule]

No offense taken.... Like I said, I get called that a lot

As mentioned earlier, there's a lot of layers to the USB subsystem.  Hubs, root hubs, drivers, and hardware/chipsets all play into the "big picture".

Two other things to check... One... on the root hub, what else is plugged into it?  There's a tool called "UVCView" that will let you explore what's where on USB at a lower level than Device Manager lets you look at.  Some hubs, while supporting USB2.0+ speeds, will back down to USB1.1 spec if a low-speed device is plugged into the same hub... at which point all devices on the hub will only achieve USB1.1 speeds.

Second... cabling.  Are you using decent cables, shortest reasonable length possible, connectors tight/secure? 

Regarding the programming... Rather than read/calculate/analyze in the one do-while loop, have you tried a queued producer-consumer loop?  Producer loop handles the minimum needed to read the serial port and stuff that data into a queue, consumer loop reads from that queue and does the calculations/analysis in there.  I've attached an example... it's something else to try.

(Edit: The other case in the producer loop is <0>, that just passes wires right through.  No need to read/enqueue a blank element if there's nothing at the port.)

[Alisha_P]

Hi Ed,

I just wanted to let you know that we're still working on this. I'm in correspondance with a VISA expert, but it's taking time.

Did any of SnowMule's suggestions improve things for your system?