Remote desktop causes timeout

[wideofthemark]

Hi,

I am having some issues with my application when using it through remote desktop.  Essentially it works fine when I am controlling it 'locally' - but when I control it using remote desktop, at times the band width seems to cause the time critical vis to hang - essentially they can't keep up with the data coming through the FIFO from my FPGA application.  I have tried my best to make the 'time critical' parts of the app be time critical - but they still seem to be over-ridden by remote desktop.  Any thoughts on how to improve things - ie to force remote desktop to accept lower band width-or to enforce labview being more important?  Or is it worth trying to monitor things through remote front panels - what is the overhead for this in terms of development - there are quite a few front panels in my application.

[ShalimarA]

Hi wideofthemark,

Thanks for posting. This is definitely an interesting question and I'd like to ask you a few more questions to clarify that I understand the issue.

Firstly, what hardware are you using? I understand that you're running an FPGA VI, meaning that real-time hardware is involved. Is your hardware connected to the PC you are trying to remote desktop into or is it connected to a network? If the RT hardware is connected to a network then I'm uncertain as to the purpose of the remote desktop as RT hardware is considered a remote device. If both PC's and the hardware are on the same network then there would be no need to use a remote desktop. Essentially, I'd like to know more about the setup you're currently using.

In terms of actually adjusting the band-width, this is something that I'll look in to, as it would depend on the remote-desktop software rather than the National Instruments software configurations.

[wideofthemark]

Hi,

So Basically I have a 'Lab' computer which is connected directly to the FPGA.  (It is one of the 'PCIe 7842R' series  boards).  It is running my Labview Application (in the development suite.).  Essentially the issue is that when I'm remote desktopping in - from home\my office etc, the lab computer's interface with it seems to break(at least when the network is being slow). 

I guess I would expect that when the network is slow the update rate would be slower - in terms of responsivity to the remote desktop - but i wouldn't expect it to actually cause the Lab computer to slow down.  In some senses what i'm doing when i remote desktop in is monitoring a long running experiment - so i don't need to 'do' much - just check everything is fine.  Obviously if me loggging in to check if it is running causes a breakdown - this isn't ideal.

I should say.... after messing around a little bit yesterday I have a suspicion that what is acutally causing the issue is 'queues' - basically i'm using single valued queues as a reference value to the data that is being aquired - so it can be used in several other analysis vis. I have a data aquisition VI that runs continuously getting data from the FIFO, analyses it, and then bungs the analysis object into the queue.  The other vis preview the queue element-  to get the data out.  It seems like the 'lossy' enqueue seems to be what causes it to break - ie - when i remote desktop in the enqueue become jittery - and sometimes hangs for 100-200ms - rather than usually ~1-2ms.  - which then causes the FIFO to timeout.

I'm considering re-engineering things - possibly to use datavalue references or something like this - since i've read they are slightly faster - although i'm hesitant since the queue solution seems a nice way of easily passing the data to another vi - only needing to know the queue name.  I guess I am currently using a modified version of the Queued state machine template I got from the community forum - from a few years ago.  I noticed that the newer version of LV has a similiar template - but I haven't checked out the details.

Do you have any thoughts on this?

JP

[wideofthemark]

(Sorry I should add that i'm using windows 7 on both computers - and windows remote desktop).

[ShalimarA]

Hi,

Thanks for all the details. Am I correct in saying, then, that the issue is definitely with losing data rather than generally slowing down the process? 

There are ways to change the priority of an application. You can right click the executable name under 'Processes' in Windows Task Manager, however I am not 100% certain on the way this will affect the remote desktop, I'll continue looking in to that. 

Seeing as you're using the remote desktop to check the status of your VI, can I suggest implementing an email sender within your code? It is quite simple to implement and will allow your code to send you an email regularly (you determine how regularly) with it's status and current data (if required). Would this be of interest? 

[wideofthemark]

Hi,

Yes - and no.  It is the slowing down that causes the data loss - ie i have a vi which is aquiring data from the FPGA.  If the vi slows down then it won't be able to keep up with the amount of data that comes in.  The FIFO DMA times out, and the vi has to restart. 

I did try a little with using task manager to bump up the priority of labview - but it didn't seem to make too much difference.  Like i said I have a feeling that there is something to do with how i am using queues that doesn't like remote desktop.  I was wondering if maybe I am doing something like not clearing up references properly - which is fine when i run it locally - but screws up when I'm remote.

Thanks for the email idea- I guess as a last resort this is possible - though it's not ideal - I guess like treating the symptom but not the cause.  Also I need a little more than just a status code to know it's running well in all situations.  I did set up an email report at the end of a measurement a while back - but I ended up removing it since they came so often that it was difficult to use usefully.  If you have up an up to date example that would be interesting...

In the mean time - (fingers crossed) I've done a little re-engineering of the template, which seems to cause less of a hang.  I've also increased the FIFO DMA buffer size, and made it so the vi can recover from a FIFO overflow - and restart many times without closing down. (although this again isn't ideal - since it doesn't really stop the problem.)  At the moment I'm up against a deadline, so I'm not really able to completely redesign things, so a patch up will have to do.  If I manage to work out what the issue with the queued data in the future I'll let you know.

JP

[ShalimarA]

Hi,

Unfortunately Windows is not deterministic, so the process of remote desktop will have several factors that would be considered a higher priority than LabVIEW. Does your FPGA target require communication with the host? This will cause a loss of determinism.

I know you were uncertain about remote front panels but that could be a potential alternative as it was designed for this sort of purpose. Have you seen this article? It's quite useful in talking you through remote front panels:

Developing Remote Front Panel LabVIEW Applications

Network streams are also an alternative worth looking in to. They would transfer your data to the host without losses and are ideal for high-throughput data. More information here:

Lossless Communication with Network Streams: Components, Architecture and Performance

Queue's are the best way for communicating with FIFO's so I don't recommend moving away from them, rather you'd need to consider the best ways to communicate between the FPGA and the Host. If you analyse the data from the FPGA and display on the Host, you can ensure then that your data does not get lost and only view the information you need to, on the host, via the remote front panel/desktop. 

[wideofthemark]

Thanks,

You've given me some things to think about.  I guess I'll have a play around.

JP

[ShalimarA]

Good luck! 

If you have any more questions don't hesitate to ask. 

[wideofthemark]

Hi again.... I don't want to jinx myself but I think(?) I've found what the problem was.... I'm not sure how applicable it will be to other people but just in case....

Essentially I managed to kill myself in terms of speed, by using a benchmarking VI which i started using a long time ago for development which had a call to a windows DLL, for a higher resolution system clock.  This is exceedingly useful for troubleshooting + speeding up code in development - BUT i made the mistake of making it a general part of my code, forgetting what was happening on the inside.  Seems like when windows is getting busy it prioritises other things over talking to DLLs.  So my useful benchmarking vis - which i was using to see what was going wrong were actually part of the problem!  The more problems i had the more I added the benchmarkers to see what was going on - the more problems I had - vicious circle etc.  So the moral of the story is to avoid using unecessary DLL calls in time critical code, and the sub moral is know (+remember+document) what your vis are doing.

I found this out in a round about way - in that there was another less time critical part of my code that was making a dll call - passing a large amount of data to a device.  It seemed like this was causing the same issue, and it was because i guess two dll calls were trying to be made at the same time.

I have solved the guts of my problem for the moment....I guess one question that now occurs to me, is it possible to make more than 1 dll call from labview at a time - or is one all you get?

JP