I've got a use-case here where I'm deploying a LabVIEW application to a windows-based single board computer (SBC), running Windows 10 Enterprise LTSC. The SBC is connected to the internet via a LTE router, so I have limited bandwidth.
After monitoring for a day, the SBC has used 500 MB of data! This is crazyness ... and the computer is doing literally nothing. When I look at the data usage on the computer, most is coming from "System", and Windows Error Reporting Service (WerFault.exe), and I've taken steps to disable WerFault, but the issue persists. I've also taken the standard steps to reduce background data transfer - setting metered connection etc, but I still feel as if there are background processes that are running and eating data.
Has anyone run into this issue before? The host target does not require real-time capability, and we need Windows to support the LabVIEW application. What steps have you taken to ensure that your bandwidth is not eaten up by Windows resources running in the background?
Thanks for your reply. My reasoning was that there would be many in the community with this use case - having to deploy a LabVIEW application on a host with cellular internet but having a problem doing so. We might talk about solutions, changes in operating systems, targets, or ways that LabVIEW could be deployed alternately. The thread was meant to provide solutions for those in these circumstances.
In any case, I have been googling on this issue and have come upon some things that have helped ... including the solution that you posted. Here are my thoughts - and if the mods don't see the merit in the thread, they can junk it. I only thought to ask a question, and then provide help.
1. Turn on metered connection on the wifi/ethernet, whatever method of connection you have
2. Monitor the data usage by accessing the data usage utility by typing data usage after pressing on the start button. It will give you a "per app" usage of what's going on. This can also be done more accurately by accessing the task manager, browsing to the Wi-Fi tab, and opening the Resource Monitor. Data being sent/received to/from IP addresses on the WAN are the biggest culprits. I've found that to be System Updates, Windows Error Reporting Service, and Background Intelligent Transfer Service (BITS). These can be disabled by disabling them in services.msc.
I'm still testing but there appears to be a major slow down in consumption - haven't run LabVIEW yet to see if there any component that was disabled that hurt/prevented LabVIEW-specific features, but we'll see.
Should have specified - I mean network usage, specifically, it's eating up the data plan I have for the SIM card on the cellular modem.
From my tests to far, prior to disabling Windows Error Reporting, Background Apps etc ... there was sending/recieving traffic at about 0.5-1.0MB/s on WAN. I've just disabled these services and network traffic has reduced to 0.1 kbps .... but the true test would be the data usage on the cellular provider website. It's showing the same number for the past 3 hours ... I hope it's not just a slow updating one.
Windows update likes to check periodically if there is something to update and if there is, it will simply download it in the background and then offer you at some inconvenient time to restart your computer. 😁
In addition your computer will also want to phone home to tell Microsoft about usage statistics, crash reports, internal errors and what else. Setting your internet connection to be a metered connection is the first thing you should do as it will typically disable most of these "helpful" background tasks.
As to many people using computers with LTE or similar data connections. That is long gone! Most computers I work with are connected to our company network through wired network or Wifi or at home through my ADSL modem. 1GB more or less per day is of little concern with such connected computers.
Thanks roflk - I've found that even on the metered connection, Windows background apps and services would still use between 0.5 - 1GB per day unless I explicitly turned off BITS, Windows Error Reporting etc. But thanks for your suggestions - definitely helps clear things up.
Completely agree with your latter point - most of time I've also worked on company computers with unlimited internet ... but these use cases are for situations where there is no company internet available. Sometimes it's also better to provide your own infrastructure so you don't need to worry about going through the company for networking issues.
As to many people using computers with LTE or similar data connections. That is long gone!
There is definitely an important use case for cellular, especially since LabVIEW is often for measurements. Think of all the remote monitoring stations (weather, seismic, bridge strain, etc.) that are nowhere near any WIFI network and powered by solar. For really (really!) remote stations where the only connection is satellite this is even more serious. Still, it is probably rare that these use Windows 😄 )
Good point! In your estimation then, if we want to stick with LabVIEW but keep the cost of the target down, what non-windows platforms would you recommend?
Currently I'm using a rugged SBC that is Windows-based but they can be expensive ... perhaps I get the one supporting Linux and shave cost? According to this link there is compatibility between LabVIEW and Linux... https://www.ni.com/en-ca/support/documentation/compatibility/20/labview-and-linux-os-compatibility.h...
It really depends what your program does. If it acquires at 1Ms/s and does fancy processing, you need powerful hardware. Just to take a measurement point every 15 minutes and put it on the network, all you probably need is e.g. an arduinio (<<1W!).
Is this a personal hobby project (details)? In this case also things like beaglebone and raspberry pi would come to mind. (~5-10W).
NI also offers very nice single boards with tons of IO and running LabVIEW RT/FPGA under NI Linux. (start reading here). typically they are only sold in bulk, but there was once a very nice sbRIO eval kit. Not sure if it is still available.