[Discuss] Port Scanning

[markw at mohawksoft.com]

>> - virtual machines impose a penalty of 1% or more -- worse when
>>    not optimally configured

That's not even the half of it. I've done a few deep dives in VM
performance and one of the more insidious problems is scheduling multiple
CPUs for a VM. I was having a discussion with another engineer about HUGE
systems with a hundred or so CPUs and the problem is that you can't get
even close to the performance with a VM.

When a VM is scheduled, each CPU that is used in the VM has to be
scheduled at the same time so it appears to be a system. In a
multi-threaded process each thread can be scheduled when it is free. In a
VM, all the CPUs have to be in lock-step.

If you have 32, 64, or however many CPUs, you will never come close to the
performance of raw processes with a VM. This is why containers are such a
win. Each thread in a process in a container is scheduled as any other
thread.

Don't get me wrong, VMs have a very important place and we use them all
the time. It's just that they aren't as efficient.

>>
>> - the mitigations for various speculative execution and memory
>>    hammer attacks can impose 2-30% penalties depending on
>>    specific programs
>>
>> - changes between stable kernel versions can be +/- 15% in some
>>    cases

I think that Intel's hyper-thread crap is a terrible design and many of
their chips can not be made safe. So many exploits, like Row hammer, are a
direct result of this bad design.

In IBM's servers, at least a few years ago, made a decision to disable
hyper-threading all together because the heat from the hyper-thread
processing had the CPU throttling the clock and was causing a net loss in
processing.

Without getting into too much detail, their SVC server product had a
real-time polling process that maintained timers on various processes, if
the processing took too long, the system would "fail-over" to the other
node. They were getting too many timeouts with hyper-threads enabled.