Hashrate eventually drops to half when utilizing L4 Cache

[nsummy]

I don't know if this is specific to the L4 usage or not, as I don't have a similar environment to compare to. Running the low power mode x5 on 8 threads will produce between 600-617 H/S. Eventually this number will drop down to the 300s and 200s. Its not a throttling issue as I can stop the miner and immediately restart it and hashrate returns to normal. I can confirm with someone else using a similar processor that the same thing is happening to him. The amount of time it takes to happen varies but can be anywhere between 6 - 24 hours. Is there a good way to troubleshoot this and narrow down the cause?

Please provide as much as possible information to reproduce the issue.

# Basic information

• i5-5775R

# Compile issues

• Which OS do you use? Ubuntu Server 17.10

  add all commands you used and the full compile output here cmake .. -DCUDA_ENABLE=OFF -DOpenCL_ENABLE=OFF

run cmake -LA . in the build folder and add the output here

CMAKE_AR:FILEPATH=/usr/bin/ar CMAKE_BUILD_TYPE:STRING=Release CMAKE_COLOR_MAKEFILE:BOOL=ON CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/c++ CMAKE_CXX_COMPILER_AR:FILEPATH=/usr/bin/gcc-ar-7 CMAKE_CXX_COMPILER_RANLIB:FILEPATH=/usr/bin/gcc-ranlib-7 CMAKE_CXX_FLAGS:STRING= CMAKE_CXX_FLAGS_DEBUG:STRING=-g CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG CMAKE_C_COMPILER:FILEPATH=/usr/bin/cc CMAKE_C_COMPILER_AR:FILEPATH=/usr/bin/gcc-ar-7 CMAKE_C_COMPILER_RANLIB:FILEPATH=/usr/bin/gcc-ranlib-7 CMAKE_C_FLAGS:STRING= CMAKE_C_FLAGS_DEBUG:STRING=-g CMAKE_C_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG CMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG CMAKE_EXE_LINKER_FLAGS:STRING= CMAKE_EXE_LINKER_FLAGS_DEBUG:STRING= CMAKE_EXE_LINKER_FLAGS_MINSIZEREL:STRING= CMAKE_EXE_LINKER_FLAGS_RELEASE:STRING= CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO:STRING= CMAKE_EXPORT_COMPILE_COMMANDS:BOOL=OFF CMAKE_INSTALL_PREFIX:PATH=/home/nsummy/xmr-stak/build CMAKE_LINKER:FILEPATH=/usr/bin/ld CMAKE_LINK_STATIC:BOOL=OFF CMAKE_MAKE_PROGRAM:FILEPATH=/usr/bin/make CMAKE_MODULE_LINKER_FLAGS:STRING= CMAKE_MODULE_LINKER_FLAGS_DEBUG:STRING= CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL:STRING= CMAKE_MODULE_LINKER_FLAGS_RELEASE:STRING= CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO:STRING= CMAKE_NM:FILEPATH=/usr/bin/nm CMAKE_OBJCOPY:FILEPATH=/usr/bin/objcopy CMAKE_OBJDUMP:FILEPATH=/usr/bin/objdump CMAKE_RANLIB:FILEPATH=/usr/bin/ranlib CMAKE_SHARED_LINKER_FLAGS:STRING= CMAKE_SHARED_LINKER_FLAGS_DEBUG:STRING= CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL:STRING= CMAKE_SHARED_LINKER_FLAGS_RELEASE:STRING= CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO:STRING= CMAKE_SKIP_INSTALL_RPATH:BOOL=NO CMAKE_SKIP_RPATH:BOOL=NO CMAKE_STATIC_LINKER_FLAGS:STRING= CMAKE_STATIC_LINKER_FLAGS_DEBUG:STRING= CMAKE_STATIC_LINKER_FLAGS_MINSIZEREL:STRING= CMAKE_STATIC_LINKER_FLAGS_RELEASE:STRING= CMAKE_STATIC_LINKER_FLAGS_RELWITHDEBINFO:STRING= CMAKE_STRIP:FILEPATH=/usr/bin/strip CMAKE_VERBOSE_MAKEFILE:BOOL=FALSE CPU_ENABLE:BOOL=ON CUDA_64_BIT_DEVICE_CODE:BOOL=ON CUDA_ATTACH_VS_BUILD_RULE_TO_CUDA_FILE:BOOL=ON CUDA_BUILD_CUBIN:BOOL=OFF CUDA_BUILD_EMULATION:BOOL=OFF CUDA_CUDART_LIBRARY:FILEPATH=CUDA_CUDART_LIBRARY-NOTFOUND CUDA_CUDA_LIBRARY:FILEPATH=CUDA_CUDA_LIBRARY-NOTFOUND CUDA_ENABLE:BOOL=OFF CUDA_GENERATED_OUTPUT_DIR:PATH= CUDA_HOST_COMPILATION_CPP:BOOL=ON CUDA_HOST_COMPILER:FILEPATH=/usr/bin/cc CUDA_NVCC_EXECUTABLE:FILEPATH=CUDA_NVCC_EXECUTABLE-NOTFOUND CUDA_NVCC_FLAGS:STRING= CUDA_NVCC_FLAGS_DEBUG:STRING= CUDA_NVCC_FLAGS_MINSIZEREL:STRING= CUDA_NVCC_FLAGS_RELEASE:STRING= CUDA_NVCC_FLAGS_RELWITHDEBINFO:STRING= CUDA_PROPAGATE_HOST_FLAGS:BOOL=ON CUDA_SDK_ROOT_DIR:PATH=CUDA_SDK_ROOT_DIR-NOTFOUND CUDA_SEPARABLE_COMPILATION:BOOL=OFF CUDA_TOOLKIT_INCLUDE:PATH=CUDA_TOOLKIT_INCLUDE-NOTFOUND CUDA_TOOLKIT_ROOT_DIR:PATH=CUDA_TOOLKIT_ROOT_DIR-NOTFOUND CUDA_VERBOSE_BUILD:BOOL=OFF CUDA_cublas_LIBRARY:FILEPATH=CUDA_cublas_LIBRARY-NOTFOUND CUDA_cublasemu_LIBRARY:FILEPATH=CUDA_cublasemu_LIBRARY-NOTFOUND CUDA_cufft_LIBRARY:FILEPATH=CUDA_cufft_LIBRARY-NOTFOUND CUDA_cufftemu_LIBRARY:FILEPATH=CUDA_cufftemu_LIBRARY-NOTFOUND HWLOC:FILEPATH=/usr/lib/x86_64-linux-gnu/libhwloc.so HWLOC_ENABLE:BOOL=ON HWLOC_INCLUDE_DIR:PATH=/usr/include MHTD:FILEPATH=/usr/lib/x86_64-linux-gnu/libmicrohttpd.so MICROHTTPD_ENABLE:BOOL=ON MTHD_INCLUDE_DIR:PATH=/usr/include OPENSSL_CRYPTO_LIBRARY:FILEPATH=/usr/lib/x86_64-linux-gnu/libcrypto.so OPENSSL_INCLUDE_DIR:PATH=/usr/include OPENSSL_SSL_LIBRARY:FILEPATH=/usr/lib/x86_64-linux-gnu/libssl.so OpenCL_ENABLE:BOOL=OFF OpenCL_INCLUDE_DIR:PATH=OpenCL_INCLUDE_DIR-NOTFOUND OpenCL_LIBRARY:FILEPATH=OpenCL_LIBRARY-NOTFOUND OpenSSL_ENABLE:BOOL=ON PKG_CONFIG_EXECUTABLE:FILEPATH=/usr/bin/pkg-config XMR-STAK_COMPILE:STRING=native XMR-STAK_CURRENCY:STRING=all

# Issue with the execution - Do you compiled the miner by our own? Yes

run ./xmr-stak --version-long and add the output here

Version: xmr-stak/2.2.0/2ae7260/master/lin/cpu/aeon-monero/20

# Stability issue - Is the CPU or GPU overclocked? No - Is the Main memory of the CPU or GPU undervolted? No

[JerichoJones]

Its not a throttling issue as I can stop the miner and immediately restart it and hashrate returns to normal.

Check your actual temps.

[OverActiveBladderSystem]

I have the i7 model of this CPU, same problem, but I can confirm its not a temperature issue, at first I naturally assumed it was, it made sense since it slowly happened over time (although a much shorter time frame than the above guy, literally just minutes for me), so I disabled the PWM fan mode and ran the fan at 100% speed, and was able to confirm 55c temperatures as a maximum using several utilities including the intel extreme tuning program which doesn't get much more accurate... its not a heat issue, which is what baffled me as thats the only logical guess I had, there is more to it...

my system was the television box I use, Gigabyte BRIX GB-BXi7-5775 but in Windows 10 pro... and like I mentioned, I went into the bios and modified the fan settings to ensure it wasn't heat, boy does that thing make a lot of noise when you run the fan at full bore in order to keep temperatures

[DrStein99]

I,have 4 of my systems running xmr stak 24/7 . Just one of them, a core i5 2400 winds down too. I so not know why yet. It only has 4 gb memory, on ubuntu 16.04 server. It only gets 192 h/s, but I use it to test pools on small scale before I switch over the larger rigs.

I keep changing pools, mess with the 4 or 5 config parameters, but it still kind of dies out. One thing I did notice difference is my hash rate per thread is 64 h/s x 3 threads, vs 35-45 or my larger machines (40+ threads)

[OverActiveBladderSystem]

@JerichoJones and @nsummy

I have done some more tinkering with this, using my i7-5775r on windows 10 pro I was able to show the likely reason why hashes are dropping over time... when I originally was trying this out, I was on the local console and using the onboard graphics, the more I used graphics (hitting H to see hashes and pulling up new screens to monitor this that and the other) the more the performance dropped, and faster...

so today I decided to remote into this machine to try again, and with the remote console using next to nothing for graphics and barely updating me when the screen changes, it sustained the hashes for a much longer time, and just to test this, I would have long pauses between checking hashes or anything else, and then brief periods where I would really use the graphics, and it seems to confirm results...

so the way I see it, when I use all 8 threads at 5x memory that consumes 80MB bringing me almost to the 128MB limits of my eDram... so anything beyond that gets dumped to system memory, which would explain why it happens when I use the graphics which begins to force data out into system ram, forcing all future calculations into system ram and cascading into a spiral down to what is essentially "base" performance... however it never seems to recover once it hits the bottom, the memory never gets released, which is the only thing I can't really figure out. (I would expect the cache to clear up eventually, if left alone as new data enters eDram and forces out the old data, this doesn't seem to happen)

I hope this helps shed some light, and perhaps you can try to replicate this yourself to confirm this likely is the reason why on your own OS and setup,the more onboard graphics you use, the more gets reserved by the system until eventually it forces you out of the eDram and into system ram... maybe I am wrong, but this seems to be the only thing I can recreate exactly every single time, its not temperatures, its simply using too much eDram and/or the OS not releasing that memory set aside when not needed...

P.S. I have no way to add a secondary gpu to this mini system to test if disabling onboard graphics will help mitigate or eliminate this issue, but if you have that ability with yours, give it a try...