Can SSDR utilize more than 4 processors in the Intel I7 CPU?

Peter K1PGV

<quote>
What do you think?
</quote>

I'd be happy to participate, and lend whatever expertise I may have.

Peter
K1PGV

Walt - KZ1F

@Peter, you and I, potentially, disagree on that one. Yes, SSDR will use them, as there is no way to pin cpu affinity. It totally remains to be seen whether it would run any better. I am not convinced it would. It would take more instrumentation that SSDR currently has to determine that.  SSDR does not utilize thread pooling so it is difficult to tell what the actual CPU load is. Further, there is no way to know to what degree any thread is waiting for a CPU to become free, or it's time slice, or waiting for some external event. In the later case more processors aren't going to make the wait any less. And, as I said, too many threads cause excess context switching which actually hurt performance.

Those electing to purchase a Dell PowerEdge likely aren't doing it for SSDR. However, if they are runing SSDR along side Folding@home, then yes, the computer will run better with more cores, to a point. What I perceived to be the question was will SSDR run better with more than 4 processors. The wrinkle comes in if those four cores were running at 2.6GHz rather than 3.6GHz. It all comes down to queueing theory, which I highly recommend as a course people should take.

In, well, what I am writing, yes, there wil be more parallelism to utilize more processors. My assessment was, however, based on how SSDR is currently written. But, it is totally ok for us to disagree as, with the existing SSDR, neither can prove their point nor disprove the opposing viewpoint. "Up to some limit"...sure, I maintain that limit, with the existing SSDR, is around 4. So, in that sense, I think we are almost in complete agreement. Another factor is the presence and speed of the GPU(s) which is ancillary to SSDR but does speak to how quickly the physical screen is drawn.

In UX work, the rule of thumb was, don't know if it still is, if response time isn't twice as fast (or 1/2 depending on how you count it) it is imperceptible. At the end of the day, perception is reality. So how much perceived performance improvement would be gleaned from a bigger processor complex vs. a faster video card?

Joe, KQ1Q

I believe you can pin a thread to a CPU core using the Win32 API SetProcessAffinityMask(): https://msdn.microsoft.com/en-us/library/windows/desktop/ms686223%28v=vs.85%29.aspx

However as you said, it's generally not beneficial from a performance standpoint. The OS thread dispatcher will automatically do a good job and is more flexible.

SmartSDR can use whatever number of CPU cores exist, however it is not CPU-bound so additional cores won't translate into noticeable UI performance improvements. This can be seen in the below Perfmon data I captured from SmartSDR. 

Comments:
- CPU activity is relatively low, so additional CPU resources (either per-core or number of cores) would not produce improvement
- One thread consumes more CPU time, but is well within the capability of this system, a 4Ghz i7-875K Lynnfield CPU from 2010.
- Horizontal scrolling of the panafall display causes CPU spikes on a few threads, but is well within the capability of this system.
- SmartSDR display rate makes a significant difference in CPU consumption, but even at 30 frames/sec it's not that high.

SmartSDR per-thread CPU activity at varying frame rates: http://joema.smugmug.com/photos/i-gpJZG8z/0/XL/i-gpJZG8z-XL.jpg

SmartSDR per-thread CPU activity during horizontal scrolling: http://joema.smugmug.com/photos/i-rz9ZcCV/0/XL/i-rz9ZcCV-XL.jpg

Walt - KZ1F

Good to know Joe, about the Win32 SetProcessAffinityMask.  I would likely never use it as I think that could cause more harm than good. I run SSDR on a Dell XPS 15Z laptop. I run it with HRDLog, DDUtil, DM-780. I don't believe the CPU has ever gone to 100%. It does have an I7 with turbo-boost to 3.5Ghz. Way back when when Al and I were discussing passmark or whatever that thing was, that ranked the computer, not the app, I did get some interesting figures from perfmon. I was awed by the huge count of threads running in the system. For instance, there are separate threads allocated for TCP and UDP. Having more cores will not make the packets arrive faster, esp when the TCP traffic is running as a result of user input. Get it working, get it working correctly, and if, and only if, there is a performance problem, optimize the code hotspots.   Ultimately, SSDR will never run faster than the UDP data arrival rate. If the inter datagram latency is longer than the processing and drawing tasks, one CPU would suffice. If the store clerk can ring out a customer before the next customer arrives, a second opened register is not beneficial.