Disable Windows 10 Search Advertising

This post covers two topics which are similar though separate - File Explorer search box suggestions; and Start Button search advertising.

 

In Windows 10, the File Explorer shows suggestion pop-ups when you begin to type in the File Explorer search box. While tolerable, it becomes annoying if you frequently search. If you prefer for the File Explorer search box to return search results after you are done typing, the search pop-up functionality may be disabled.

If you have a Windows 10 version with group policy editor, press the Start Button and type: gpedit Run the Edit Group Policy application as administrator. In the group policy editor, go to User Configuration, Administrative Templates, Windows Components, File Explorer.
 

Edit the entry for "Turn off display of recent search entries in the File Explorer search box". Choose "Disabled" and press OK button.

The setting should now be Disabled.

 

A separate issue with Windows 10 is invasive keystroke monitoring and advertising. Press the Start Button and begin to type a program name or file name. Windows 10 will show matching program names, file names, and also provide search engine results. This is like a mini search engine in the Start Button based on your typing and geo-location. If you type "burgers", not only will it search for local programs and files named "burgers", but you will also get a review of where to locally purchase burgers and a map for local burger shops. Microsoft calls this feature Web search.  Many people call it "intrusive and annoying". There does not appear to be an intuitive and easy way to turn off this advertising.

 
This feature can be turned off with the registry editor. Press the Start Button and type: regedit
Run the Registry Editor application as administrator. The registry key will include Computer\HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Windows. (While it may appear the key Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Explorer can configure this for all users, it doesn't seem to work.)
Confirm this registry key exists, or add it: Computer\HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Windows\Explorer

Right-click on the "Explorer" key, and add a new DWORD 32-bit value with name: DisableSearchSuggestions

Set the value to 1.

Reboot the computer and test that the Start Button advertising functionality has been disabled.

How to mine Monero on Ubuntu Linux

Please refer to the recent post about setting up a Monero pool miner on Microsoft Windows. That post provides some background information along with how to use wallet software.

Now let's focus on running a miner on Linux Ubuntu 20.04. We will use the same public key address as the previous post. We will simply change the identifier in the start file to allow both the Windows and Linux miners to be monitored on the same page at SupportXMR.com. 

Logon to the machine and determine which Ubuntu release is installed.

$ lsb_release -a

No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.3 LTS
Release:        20.04
Codename:       focal

# Create a new unix group and user.

$ sudo addgroup cryp

Adding group `cryp' (GID 1004) ...
Done.

$ grep cryp /etc/group
cryp:x:1004:

$ sudo adduser monero --ingroup cryp
Adding user `monero' ...
Adding new user `monero' (1005) with group `cryp' ...
Creating home directory `/home/monero' ...
Copying files from `/etc/skel' ...
New password:
Retype new password:
passwd: password updated successfully
Changing the user information for monero
Enter the new value, or press ENTER for the default
        Full Name []:
        Room Number []:
        Work Phone []:
        Home Phone []:
        Other []:
Is the information correct? [Y/n] y

# If you want the new monero Linux user to be able to log on to the machine remotely, add user monero to the "AllowUsers" line in /etc/ssh/sshd_config.
$ sudo vi /etc/ssh/sshd_config

# Now edit the config file and add the monero username.
$ grep monero /etc/ssh/sshd_config
AllowUsers install1 minec monero

# Restart ssh to apply the new configuration.
$ sudo systemctl restart ssh

# ssh into the machine as the monero user.
$ whoami
monero

$ groups
cryp

$ id
uid=1005(monero) gid=1004(cryp) groups=1004(cryp)

# Earlier we ran "lsb_release -a" it showed the name "focal" for the Ubuntu release. Get the monero software, with the matching Ubuntu release name, from https://github.com/xmrig/xmrig/releases.

$ wget https://github.com/xmrig/xmrig/releases/download/v6.15.2/xmrig-6.15.2-focal-x64.tar.gz 

$ gzip -d xmrig-6.15.2-focal-x64.tar.gz

$ tar -xvf xmrig-6.15.2-focal-x64.tar
xmrig-6.15.2/
xmrig-6.15.2/config.json
xmrig-6.15.2/SHA256SUMS
xmrig-6.15.2/xmrig

$ ls -l
total 8256
drwxr-x--- 2 monero cryp    4096 Oct  5 10:38 xmrig-6.15.2
-rw-r----- 1 monero cryp 8448000 Oct  5 11:30 xmrig-6.15.2-focal-x64.tar

# Go into the software directory and create a new (or replace the example) config.json.
$ cd xmrig-6.15.2
$ ls -l
total 8256
-rw-r----- 1 monero cryp    2351 Oct  5 10:38 config.json
-rw-r----- 1 monero cryp     150 Oct  5 10:38 SHA256SUMS
-rwxr-x--- 1 monero cryp 8441704 Oct  5 10:38 xmrig

# Put the following into file config.json. Note the "user" public key is on one line.
$ cat config.json
{
"autosave": true,
"cpu": true,
"opencl": false,
"cuda": false,
"pools": [
        {
                "url": "pool.supportxmr.com:443",
                "user": "44YkNzrdJnmAqwoTRMPV2e4fihv3AfZ5vMmrtaWCGQaxKuXp5eiZeRREzhPi9tVqGuA3VBRriNwKa2QxmZmRGmHVTkUSTMc",
                "pass": "runDemoB",
                "keepalive": true,
                "tls": true
        }
        ]
}

# Test it from the command line. Stop the program with ctrl-c after you verify it is working.
$ ./xmrig -c ./config.json

# Create and test a command file which will be used by the Linux process monitor so the miner will be started upon machine reboot.
$ cd ~
$ pwd
/home/monero

# Put these three lines into the command file named startminer.sh. Note the last command is all one line.
$ vi startminer.sh
#!/bin/sh
umask 026
/usr/bin/nice -n 15 /home/monero/xmrig-6.15.2/xmrig -c /home/monero/xmrig-6.15.2/config.json

# Make the file executable.
$ chmod +x startminer.sh

# Test the command file from the command line.
$ ./startminer.sh

# In another terminal window, run "top" and look at the "NI" column. It should be the "nice" value in the command file. This sets the process priority lower, so the machine can more easily prioritize other work (if there is other work).

# Configure the system services so the mining process will automatically start with the machine.
# For the following commands with sudo, log in with a unix account which is in the sudoers file.
$ cd /etc/systemd/system
$ sudo vi monero.service
[Unit]
Description=monero miner
After=network.target
[Service]
Type=simple
User=monero
Group=cryp
ExecStart=/home/monero/startminer.sh
KillMode=mixed
Restart=on-failure
Type=forking
TimeoutStartSec=120
TimeoutStopSec=30
RuntimeMaxSec=infinity
[Install]
WantedBy=multi-user.target

# Enable the service.
$ sudo systemctl enable monero.service
Created symlink /etc/systemd/system/multi-user.target.wants/monero.service → /etc/systemd/system/monero.service.

$ sudo systemctl start monero.service
$ sudo systemctl status monero.service

# Run top or htop to confirm the miner is running with the specified "nice" level.
# Reboot the machine to test the miner will restart automatically.
$ sudo shutdown -r

# After machine restarts, login and run the following to verify the service is running and that it is only running one.
$ top
$ htop
$ ps -fu monero

Let's look into the mining process a little closer, and focus on the number of tasks or processes that are run. From a defensive system administration standpoint, we may want to configure the service so it can not errantly consume thousands of processes.

With the miner running as a service, it is currently using just a handful of processes. This seems to be correct, as one process per CPU core (in this case 4 cores) is reasonable.

$ ps -fu monero
UID          PID    PPID  C STIME TTY          TIME CMD
monero      1046       1  0 15:02 ?        00:00:00 /lib/systemd/systemd --user
monero      1047    1046  0 15:02 ?        00:00:00 (sd-pam)
monero      1145    1043  0 15:02 ?        00:00:00 sshd: monero@pts/0
monero      1146    1145  0 15:02 pts/0    00:00:00 -bash
monero      1471       1  0 15:10 ?        00:00:00 /bin/sh /home/monero/startminer.sh
monero      1472    1471 99 15:10 ?        00:05:38 /home/monero/xmrig-6.15.2/xmrig -c /home/monero/xmrig-6.15.2/c
monero      1517    1146  0 15:12 pts/0    00:00:00 ps -fu monero

$ ps -fu monero | wc -l
9

# In another terminal window with a Linux user which has access to sudo.
$ sudo systemctl status monero.service
● monero.service - monero miner
     Loaded: loaded (/etc/systemd/system/monero.service; enabled; vendor preset: enabled)
     Active: activating (start) since Sun 2021-10-10 15:12:24 MDT; 1min 57s ago
Cntrl PID: 1531 (startminer.sh)
      Tasks: 10 (limit: 18964)
     Memory: 2.2G
     CGroup: /system.slice/monero.service
             ├─1531 /bin/sh /home/monero/startminer.sh
             └─1532 /home/monero/xmrig-6.15.2/xmrig -c /home/monero/xmrig-6.15.2/config.json
Oct 10 15:12:38 d990 startminer.sh[1532]: [2021-10-10 15:12:38.338]  net      new job from pool.>
Oct 10 15:12:38 d990 startminer.sh[1532]: [2021-10-10 15:12:38.338]  cpu      use argon2 impleme>
Oct 10 15:12:38 d990 startminer.sh[1532]: [2021-10-10 15:12:38.341]  msr      msr kernel module >
Oct 10 15:12:38 d990 startminer.sh[1532]: [2021-10-10 15:12:38.341]  msr      FAILED TO APPLY MS>
Oct 10 15:12:38 d990 startminer.sh[1532]: [2021-10-10 15:12:38.342]  randomx  init dataset algo >
Oct 10 15:12:38 d990 startminer.sh[1532]: [2021-10-10 15:12:38.342]  randomx  allocated 2336 MB >
Oct 10 15:12:45 d990 startminer.sh[1532]: [2021-10-10 15:12:45.958]  randomx  dataset ready (761>
Oct 10 15:12:45 d990 startminer.sh[1532]: [2021-10-10 15:12:45.958]  cpu      use profile  rx  (>
Oct 10 15:12:45 d990 startminer.sh[1532]: [2021-10-10 15:12:45.960]  cpu      READY threads 3/3 >
Oct 10 15:13:46 d990 startminer.sh[1532]: [2021-10-10 15:13:46.126]  miner    speed 10s/60s/15m >

$ systemctl show --property DefaultTasksMax
DefaultTasksMax=18964

# Note the service is using 10 tasks of the 18964 limit. It appears it uses the default maximum setting.
# Note the service is using 2.2 GB of memory.
# Since the service is running correctly and the machine has four CPU cores, let's ensure the service does not run away. Limit it to no more than 999 processes.

# Add two lines to the end of /etc/systemd/system/monero.service.
[Service]
TasksMax=999

# Reload the systemd configuration.
$ sudo systemctl daemon-reload

# Restart the mining process.
$ sudo systemctl restart monero.service

# Look at the Tasks limit for this mining process. It should use 999 from the monero.service file.
$ systemctl status monero.service | grep Tasks
      Tasks: 10 (limit: 999)

# Restart the machine to test the configuration.
$ sudo shutdown -r

Go to the SupportXMR.com website to monitor the mining activity. Enter the address from the config file at this website to see your miner activity.

Using top and htop, you may notice with four CPU cores that it seems only three are being used. The load average will be in the 3s rather than 4 (the number of cores). For this example on this four-core CPU, you may edit config.json and add the fourth core to the "rx" line, like this: "rx": [0, 1, 2, 3],

# Then restart the service.
$ sudo systemctl restart monero.service

# If you make this change to use more CPU, closely monitor if more hashes are being calculated. You may find that while more CPU is used, less hashes are performed due to CPU cache issues. Please read this tuning document and consider de-tuning to the prior setup. In short, hyper-threading (more logical processors than cores) usually does not scale CPU-bound processes.

To tune the OS settings, look into huge pages. First, get the current settings and monitor the current miner hash rate so you know the baseline before making tuning changes.

Without tuning, the OS may be configured like this:

$ grep -i huge /proc/meminfo
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
FileHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:               0 kB

Stop the miner process, make temporary changes to OS kernel settings, and restart the miner to determine if the hash rate changes.

$ sudo sysctl -w vm.nr_hugepages=1280

$ grep -i huge /proc/meminfo

AnonHugePages:         0 kB

ShmemHugePages:        0 kB

FileHugePages:         0 kB

HugePages_Total:    1280

HugePages_Free:     1280

HugePages_Rsvd:        0

HugePages_Surp:        0

Hugepagesize:       2048 kB

Hugetlb:         2621440 kB

If the restarted miner process shows an increase in hashing, then make the kernel OS settings permanent.

$ sudo bash -c "echo vm.nr_hugepages=1280 >> /etc/sysctl.conf"

Reboot the machine and check the huge pages setting and the miner hash rate. For this example, the per second hash rate went from 965 to 1381 just by tuning huge pages.

Tuning Microsoft Windows for CPU Cryptocurrency Mining

This post covered setup and basic configuration of a Monero crypto miner on Microsoft Windows.

The PC had 16GB of RAM, and rarely used more than 9GB of RAM. In the Performance tab of Task Manager, under Memory, it shows the amount of RAM in use and the amount compressed. RAM compression uses a small (and typically unnoticeable amount of CPU to compress RAM pages which are not being used. While compressed RAM pages can't actually be used by a process when they are compressed, the idea is that by compressing RAM it may avoid swapping RAM to disk in a low-memory situation. Certainly reading swapped pages from disk should be considerably slower than  using CPU to uncompress RAM pages which are already in memory. For anyone using a machine which is not using all of the RAM, this is an optimization looking for a problem - if the machine is not swapping, then there is no RAM slowdown due to swapping. Compressing RAM when there is not a RAM shortage slightly increases CPU use. While the small additional CPU use may not be noticeable on many workloads, it can be noticeable and detrimental to do this speculative RAM optimization when the CPU is already near 100% usage, as is typical when mining a cryptocurrency on CPUs.

With the machine not in danger of swapping in-memory RAM pages to disk, let's turn off RAM compression. In the worst case if a process takes more RAM than the installed 16GB, some pages will be swapped to disk as has been standard for decades.

In this example with the Monero miner and a web browser and other applications, Task Manager shows the machine had 5.2GB available and 1.6GB compressed of 15.9GB total RAM. Even if the compressed RAM is uncompressed at triple the compressed size, everything should still fit into the real 15.9GB of RAM.

Let's look at the current RAM compression setting. Right-click on the Start Button and choose "Windows PowerShell (Admin)". Then in PowerShell run this command: Get-MMAgent

This shows "MemoryCompression" is set to True. This confirms what can be seen in the Task Manager, that some amount of the memory was "Compressed". Get some statistics with: Get-Process -Name "Memory Compression"

Disable RAM compression with: Disable-MMAgent -MemoryCompression

Reboot so the change will take effect. After reboot, use PowerShell to check that the setting is False with: Get-MMAgent

Run your typical processes, and also run the Monero crypto miner. Look at Task Manager. In this example, Task Manager shows about 7GB of RAM available without using compression. Note that "(Compressed)" is zero.

Presumably the Microsoft Windows 10 developers put considerable effort into optimizing the RAM compression code. When a machine is pushed to limits such as nearly 100% CPU, there may be noticeable performance differences when turning off the speculative RAM compression. In general use, we should expect to find the changes basically unnoticeable from a user interface standpoint. On CPU-bound processes like crypto mining we might be able to see a performance change. I was surprised to find a consistent increase in Monero mining performance (measured via hashes per second) of over 15%. The peak hash per second increased over 20%.

While this dramatic increase was unexpected, it shows the dangers of premature optimization ("let's do RAM compression just because it might be good"). It also shows the benefit of benchmarking before and after a change. Both before and after the change the "huge pages" mining feature was enabled.

October 17 update on Monero miner tuning - it makes a small difference by forcing the miner to avoid using CPU core 0. On the machine in this example, there are four CPU cores. The mining process consistently starts three processes, which leaves one of the cores unused. The unused core was consistently core 3, and cores 0 - 2 were consistently pegged at 100% CPU usage. On a hunch that hardware interrupts may still be serviced by core 0, I used Task Manager to set processor affinity to cores 1 - 3. This had the effect of moving the miner process off core 0.

Task Manager shows a process named "System interrupts". This is more of an indication of interrupts rather than a real process. If a hardware driver is misbehaving, this process could indicate greater than zero CPU usage. In a properly functioning system, interrupts should have nearly zero CPU usage. It is possible that even with low CPU usage, interrupts are causing miner code removal from the core along with possible small CPU cache issues.

The Performance Monitor application allowed viewing of percentage interrupt time. Right-click and choose "Add counters" then look for "Processor information" to find "% Interrupt Time". The first counter in the following graph is the overall interrupt counter and one counter for each of the four CPU cores. The scale on the graph is increased from 1 to 100 to highlight the differences. CPU core zero (colored red) frequently spikes. The overall interrupt (color blue) also spikes though is tempered by the other CPUs. The lines for CPUs 1 - 3 are flatlined against the bottom of the graph. This shows interrupts are being serviced by CPU 0. Therefore, removing the mining process from CPU 0 should provide smoother process execution as measured by better program throughput.

Looking at the hashes per second of the monero miner process, the high-water mark increased about 6% and a day the average hashes per second increased about 3%. On a mining process, a 3% increase in performance at no hardware cost is a nice improvement. A more precise performance measurement would need a dedicated machine running without other programs and measured for several days.

The following line has been added to the command file to set the processor affinity when the miner is started:
start /BELOWNORMAL /affinity E /b E:\tech\crypto\monero\GUIs\xmrig-6.15.1-msvc-win64\xmrig-6.15.1\xmrig.exe -o pool.supportxmr.com:443 -u 44YkNzrdJnmAqwoTRMPV2e4fihv3AfZ5vMmrtaWCGQaxKuXp5eiZeRREzhPi9tVqGuA3VBRriNwKa2QxmZmRGmHVTkUSTMc -k --tls -p runDemoA

While affinity "E" works for this four-core system, it depends on your CPU core count along with available hyper-threads so please view this post to determine the binary number. Then view this website to convert the binary number to hexadecimal to use with the "affinity" flag of the "start" command.

Affinity "E" will put threads on CPU cores 1 and 2 and 3, so use this for a process with three threads - using this with 1 or 2 threads will typically shift the CPU core over time, which can be seen in Task Manager cpu view. Affinity "A" would be two threads on CPU cores 1 and 3. Please verify the number of threads in the program, and match that to specific CPU cores by using the correct hexadecimal value which you can find in the prior links.

Tuning update for CPU hyper-threading:

Hyper-threading allows a CPU core to support, typically, two separate threads. The idea is that usually threads do not use the maximum available CPU on a core (not completely CPU bound) because program code often waits for network or disk or user interaction. During that time of waiting, the other thread can run on the CPU core. If the CPU core is already 100% consumed by a thread then adding another thread does not increase throughput.

BIOS settings can often turn off CPU hyper-threading, though this may not be available in some laptop BIOS. Using BIOS to turn off and on hyper-threading, the miner ran about 2.5% better with hyper-threading off. Throughput went from 826 hashes per second to 846 hashes per second. This was tested on two separate machines of the same make and model, with similar performance improvements on both machines.

This page has instructions on becoming a MS Windows user with Admin privilege to set the "lock pages" feature, which is also known as huge pages. To summarize, run the Local Security Policy editor, choose Local Policies, choose User Rights Assignment, choose Lock Pages In Memory, and double-click and add the user.