I'm trying to use the android emulator coming with Android Studio (4.0) on Mint 18. Unfortunately as soon as I run a device, my disk sees heavy workload and I can't really tell why - it must be many small writes as I can see in nmon. This renders the whole emulation completely useless as the emulated device is not really responding any longer. It does not depend on which device I'm trying to emulate (Pixel/Pixel2/own HW).
What I can't see is, which files are affected and why. Even iotop only tells me that qemu-system-i386 is putting some workload on the disk but not where (of course).
The only thing I can tell is that all magic disappears if I start the device from commandline with the "-read-only"-Argument - then everything runs fine and fast.
But that's not a solution anyway because it doesn't preserve changes on the emulated device.
Any ideas?
I totally agree with Raman's comment: too much disk write. When I am using the android studio( "version": "dev build","buildNumber":"203.7717.56.2031.7678000",) emulator, the process with highest real time "disk write" value in gnome's system monitor, can reach 40 or 50 MB/s, which is quite astonishing. 40 or 50 MB/s not only in the start or end of emulation, it also happens as long as I make any operation in virtual device(i.e., swiping, clicking, opening apps). (BTW, ubuntu 20.04, ryzen 4800h, 16GB 3200 ddr4 dual channel RAM, emulating pixel 4, android 11 x86 with google play). I am also trying to find out why.
May be you could reduce the "disk write" by disable quickboot snapshot? I disabled automatic snapshot, and take a snapshot manually. Then disabled the quickboot, and set the default boot option from "quickboot" to "boot from one specific saved snapshot". Please remember, after setting the cconfiguration, you must reboot your PC to validate the settings, otherwise the settings may or may not take effect, or you simply could not open emulation unless reboot.
After rebooting, the "disk write" value drops down from 40 or 50 MB/s to a normal range, less than 1 MB/s in most of times. However, after rebooting, I could not read articles from official accounts in wechat app(from tencent company) in emulated android device. The articles are just stuck in loading status after clicking. So this setting may also affect some of normal functionalities.
https://developer.android.com/studio/run/emulator#snapshots
https://developer.android.com/studio/run/emulator#quickboot-troubleshooting
"Loading or saving a snapshot is a memory-intensive operation. If you do not have enough RAM free when a load or save operation begins, the operating system may swap the contents of RAM to the hard disk, which can greatly slow the operation. If you experience very slow snapshot loads or saves, you may be able to speed these operations by freeing RAM. Closing applications that are not essential for your work is a good way to free RAM."
For your description, "But that's not a solution anyway because it doesn't preserve changes on the emulated device." You could simply take a snapshot manually when you need to save, and set it as your boot snapshot.
I noticed it happened quite much for emulated devices with Google Play or Google Api images. Also, after waiting quite a while (let say 10 minutes), the phenomenon stops. What I do is to use, whenever possible, devices with low API levels, then with no Google Play image, and better, no Google Api at all. I also try to allocate quite a lot of ram to the emulated device (at least 3G). It is really astonishing how an emulated Android device with api level 15 is fast compared to a api level 30 or 31.
Related
I installed the latest version of the HoloLens 2 Emulator (10.0.20348.1501) on my Windows 10 Pro machine. I have 32GB of RAM, 11th Gen Intel 8 Core CPU, Nvidia 3080 (mobile) graphics card.
Initially I thought that the HoloLens emulator was super slow (an input such as trying to move the pointer can take 10, 20, 30 seconds to show up and sometimes doesn't even show up).
But upon testing some more, I've realized that my inputs are going through immediately (as I can tell from the sound feedback), it's just the visual feedback which is not updating. This testing is just inside the OS (without trying to launch an app I developed).
Any ideas what could be going on? In the performance monitoring tool, everything looks fine.
In the end, the only way to fix it, was to disable graphics switching in the BIOS, and set to Discrete only - despite the fact that the Nvidia GPU Activity shows that the GPU turns on when I launch the emulator.
If the emulator takes 10 seconds to update the graphic, there should be configurations issues. Based on my test, though I cannot say it works fluently in my PC, the HoloLens 2 emulator runs at around 15 fps. There is delay but should be work fine for testing. (I am running it with Nvidia 1080 (mobile), with a much older CPU than yours.)
Please check the document on Using the HoloLens Emulator - Mixed Reality | Microsoft Docs and make sure you have configured your computer properly.
In BIOS
Intel VT -> enabled
Intel VT-d -> disabled
Hardware-based Data Execution Prevention (DEP) (or any Intel data protection related feature, display name could be varied) -> disabled
In Windows
After BIOS configuration is done, completely shut down your PC, then boot. (Directly reboot may not apply changes).
Run dxdiag to check:
DirectX 11.0 or later (12.0 in my PC)
WDDM 2.5 graphics driver or later (3.0 in my PC)
Hyper-V Checking
Enable it if it is not. Reboot is required.
If it is already enabled. Disable it -> reboot the PC -> enable it again -> reboot
Others
For the laptop, make sure the power supply is plug-in and it is not in power-save mode. Check the GPU payload (around 36% in Nvidia 1080 mobile)
Then you may run the emulator again to see if this issue still exists.
I am trying to run two AVDs side by side. The thing is that whichever AVD I open second, runs MUCH slower than the first one. It's not CPU or RAM, there is enough overhead.
Any ideas?
I was also experiencing the same issue where the 2nd emulator was slow as molasses. I did some research on this and I think I have found a pretty decent solution. I am assuming that you have already installed Intel HAXM. If not, then please do so.
For best performances, it is advised that you allocate atleast half of the system RAM to Intel HAXM. This has been mentioned on the Intel HAXM page here under the Tips & Tricks section.
I allocated about 6 GB RAM to Intel HAXM and after that the performance of the 2nd emulator improved by a great deal. I would highly recommend you do the same. If you have already installed Intel HAXM, then please uninstall it and install it again with the amount of RAM as suggested on the above mentioned page.
Increase the memory that can be allocated to HAXM. When you install it you will notice a line in the final screen:
Note: The memory reservation setting can be changed by running this installer again.
Navigate to AndroidSDKDirectory/extras/intel/Hardware_Accelerated_Execution_Manager
Run the installer (not the silent installer) and manually adjust the HAXM memory limit on this screen:
At the time of this writing a stock Pixel (XL) emulator uses 1536 MB memory by default. So if you want to have enough memory available to HAXM to run 2 of these emulators, allocating ~4096 MB (a third more than necessary) is a safe bet.
I'm trying to figure out where my memory leak is coming from since lately i'm experiencing a lot of performance drop when just opening a new tab on my browser FireFox ver.51
Just to be sure I've disabled all non-Microsoft startup services in msconfig even after reboot it still gets stuck on this.
Looking up on the vendors updates for this machine then it would be up to date on the drivers, i do occasionally check for Intel Chipset and onboard Graphics drivers (stable versions only) myself that are a few years newer then the vendor.
MS Resource monitor
MS Taskmgr Perfomance monitor
In the Taskmgr Performance monitor you can see I'm barely using any CPU and I/O leaving out any form of I/O wait issues due to swapping.
When looking in the Resource monitor actual physical RAM in is about 6.3GB while Cached is only 1.6GB making it roughly 4GB RAM missing where it's usage is coming from.
So i did do a offline MemTest (oh yes the old blue gorgeous BIOS screen) and all checks were passed, luckily it's only 8GB RAM so the downtime is manage-able ;)
Any ideas or other handy tools I can use to find the culprit?
Already fixed it, seems like my pagefile is storing too much cached memory for some reason, will look into it myself why it stores so much memory
I'm running embedded Linux (Debian on ARM/X86_64). Since it is very much like a full OS, with some hardware differential and a different platform, you may consider it as a regular machine. So, this will be used in the robotics field where the computer will ALWAYS be hard reset by turning off power. It would disqualify me to use a UPS so I would need to make the system infallible.
I'm running some processor-intensive tasks, like OpenCV and OpenNI and OpenKinect. How do I use an uber-powerful filesystem, like ZFS to mirror the entire disk on the SSD for error correction? Does ZFS perform well in Linux? I'm still kinda a newbie in Linux so I don't understand it's internal workings.
My list of possible platforms are:
--Debian#RaspberryPi
--kUbuntu#ODROID-X2
--Ubuntu#PandaBoard
--Ubuntu#NUC-i3/5.
Also, how can I make sure the filesystem doesn't get damaged during reset? I need the computer to start in good time, A.K.A, <3 minutes for the competition.
I will probably be using a 32GB SSD, so I guess a 16GB partition mirrored 2x works or 12 # 3x. I only need to get an OpenCV install working because the code will be downloaded from a SAMBA NFS automatically!
Thanks for your help and good luck ;)!
ZFS is not suited for low memory systems. It do perform well on system with 4GB of RAM and more.
I plan to develop a nice little application that will run on an arm-based embedded Linux platform; however, since that platform will be battery-powered, I'm searching for relevant information on how to handle power save.
It is kind of important to get decent battery time.
I think the Linux kernel implemented some support for this, but I can't find any documentation on this subject.
Any input on how to design my program and the system is welcome.
Any input on how the Linux kernel tries to solves this type of problem is also welcome.
Other questions:
How much does the program in user space need to do?
And do you need to modify the kernel?
What kernel system calls or APIs are good to know about?
Update:
It seems like the folks involved with the "Free Electrons" site have produced some nice presentations on this subject.
http://free-electrons.com/services/power-management/
http://free-electrons.com/docs/power
http://free-electrons.com/docs/optimizations
But maybe someone else has even more information on this subject?
Update:
It seems like Adam Shiemke's idea to go look at the MeeGo project may be the best tip so far.
It may be the best battery powered Embedded Linux project out there at this moment.
And Nokia is usually kind of good at this type of thing.
Update:
One has to be careful about Android since it has a "modified" Linux kernel in the bottom, and some of the things the folks at Google have done do not use baseline/normal Linux kernels. I think that some of their power management ideas could be troublesome to reuse for other projects.
I haven't actually done this, but I have experience with the two apart (Linux and embedded power management). There are two main Linux distributions that come to mind when thinking about power management, Android and MeeGo. MeeGo uses (as far as I can tell) an unmodified 2.6 kernel with some extras hanging on. I wasn't able to find a lot on exactly what their power management strategy is, although I suspect more will be coming out about it in the near future as the product approaches maturity.
There is much more information available on Android, however. They run a fairly heavily modified 2.6 kernel. You can see a good bit on the different strategies implemented in http://elinux.org/Android_Power_Management (as well as kernel drama). Some other links:
https://groups.google.com/group/android-kernel/browse_thread/thread/ee356c298276ad00/472613d15af746ea?lnk=raot&pli=1
http://www.ok-labs.com/blog/entry/context-switching-in-context/
I'm sure that you can find more links of this nature. Since both projects are open source, you can grab the kernel code, and probably get further information from people who actually know what they are talking about in forms and groups.
At the driver level, you need to make sure that your drivers can properly handle suspend and shut devices off that are not in use. Most devices aimed at the mobile market offer very fine-grained support to turn individual components off, and to tweak clock settings (remember, power is proportional to clock^2).
Hope this helps.
You can do quite a bit of power-saving without requiring any special support from the OS, assuming you are writing (or at least have the source code for) your application and drivers.
Your drivers need to be able to disable their associated devices and bring them back up without requiring a restart or introducing system instability. If your devices are connected to a PCI/PCIe bus, research which power states they support (D0 - D3) and what your driver needs to do to transition between these low-power modes. If you are selecting hardware devices to use, look for devices that adhere to the PCI Power Management Specification or have similar functionality (such as a sleep mode and a "wake up" interrupt signal).
When your device boots up, every device that has the ability to detect whether it is connected to anything needs to do so. If any ports or buses detect that they are not being used, power them down or put them to sleep. A port running at full power but sitting unused can waste more power than you might think it would. Depending on your particular hardware and use case, it might also be useful to have a background app that monitors device usage, identifies unused/idle resources, and acts appropriately (like a "screen saver" for your hardware).
Your application software should make sure to detect whether hardware devices are powered up before attempting to use them. If you need to access a device that might be placed in a low-power mode, your application needs to be able to handle a potentially lengthy delay in waiting for the device to wake up and respond. Your applications should also be considerate of a device's need to sleep. If you need to send a series of commands to a hardware device, try to buffer them up and send them out all at once instead of spacing them out and requiring multiple wakeup->send->sleep cycles.
Don't be afraid to under-clock your system components slightly. Besides saving power, this can help them run cooler (which requires less power for cooling). I have seen some designs that use a CPU that is more powerful than necessary by a decent margin, which is then under-clocked by as much as 40% (bringing the performance down to the original level but at a fraction of the power cost). Also, don't be afraid to spend power to save power. That is, don't be afraid to use CPU time monitoring hardware devices for opportunities to disable/hibernate them (even if it will cause your CPU to use a bit more power). Most of the time, this tradeoff results in a net power savings.
One of the most important things to think of as a power aware application developer is to avoid unnecessary timers. If possible use interrupt driven solutions instead of polled solutions. If a timer must be used then use as long poll interval as is possible.
For example if something special should be done at a certain room temperature it is unnecessary to check the temperature every 100 ms since temperature in a room changes slowly. A more reasonable polling interval is could be 60 s.
This affects the power consumption in several ways. In Linux the CPUIDLE subsystem takes the CPU (SOC) to as deep power saving state as possible depending on when it predicts the next wakeup to occur. Having a lot of timers in a system will fragment the sleep making it impossible to go to the deeper sleep states for longer periods. A typical deep sleep state for CPUIDLE turns the CPU off but keeps the RAM in self refresh. When a timer triggers the CPU will boot and serve the timer of the application.
It's not actually your topic, but it might come in handy to log your progress: i was looking for testing / measuring my embedded linux system. chris desjardins from this forum recommended me this:
I have successfully used bootchart in the past:
http://elinux.org/Bootchart
Here is a list of other things that may also help:
http://elinux.org/Boot_Time