Re: [LAU] i5 Hyper-Threading, BIOS settings and Arch n00b pointers

On Thu, 28 Aug 2014 23:40:01 +0000 Kaza Kore <dj_kaza(a)hotmail.com> wrote: I changed email address on this list about a week ago, and posted the following msg, seems it's didn't get through so I'll send an improved version :) AFAIK there are 2 points to be considered. 1. SMT (at least as implemented on iX cpus) break the entire concept of realtime. You do get an estimated increase in CPU throughput of about 25%, at the possible cost of stealing CPU time (thus latency) from your realtime threads. In effect a lower priority thread thread can run on the sibling CPU (same core) stealing CPU time from your realtime thread. 2. I suspect that the CPU cache is too small. and that SMT can also cause cache depletion, which would explain some xruns I have seen while torture testing the system doing real lowlatency audio and running hackbench at the same time. Reloading the cache cam take significant time. Speedstep was already covered by someone else. CPU management is a thorny question. That setting is probably related to System Management Interrupts (SMIs), which can be very bad indeed. Normally used for fan control and other functions by the BIOS. The really bad thing is that they block execution and there is nothing the kernel can do about it. if it's only for a few usecs, it's probably not a problem, but if it's milliseconds, it is.. There is a program called hwlatdetect in the rt-tests package that can be used to determine how big the problem is. It consists of a kernel module and a python script to start it and to report the results back to the user. What is it does is basically to stop all kernel execution and then to loop reading TSC timestamps. If it finds breaks in the data stream they will have been caused by SMIs. -- Joakim