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

A hyperthreaded core is about equivalent to 1.2 times the number of processors. Standardly an I5 has 4 non hyperthreading cores. And I7 has 4 cores but also supports hyperthreading so while the OS thinks it is 8 it is really about 5. But it good for the ego. They come in incredibly handy when running fully virtualized. Without paravirtual drivers there is a fair amount of spin loops to simulate internal timing. If you overcommit threads you can start a VM so the hyperthreads come in handy to allow the system to run when it otherwise would seize up.

It is very deceptive how much of an I7 will actually get used. There are two main reasons for this:
1) processors > 1 are of no help if there is no parallelism in the program.
2) if 1 processor is handling a thread that performs a lot of IO, even when there is parallelism occurring in the program, if the program is IO bound (a lot of IO compared to computing) the processor that handles the interrupts is free to handle computing.
3) a thread (not to be confused with hyperthread) is a separately dispatchable unit of work in the program, This separately dispatchable unit of work in the program is, essentially, either running or waiting. If you define too many threads your program can actually slow down, it passes the point of diminishing returns. Every time a processor switches from one thread to another it is called a context switch. Context switching is not free. When I had 4 panadapters running (1 slc each) there were around 30-40 threads in the system. 

In an earlier post I mentioned there are a lot of laws in computer science. I think it was Amdahl's law that attempts to show the relationship between threads, processors, and the IO-ness of a program.
People with I5's with 4GB have had outstanding results. So comparing that to a business class machine with 20 processors, 20GB or error correcting memory, there is likely not a whole lot of difference beyond bragging rights.

So really, think about what SSDR actually does.
1) it sends English commands to the radio, as a result of you clicking something (how often does that occur?)

2) it receives English status messages from the radio in response to, primarily, the English commands sent. Not a lot happening here requiring business class machines.

3) It receives an incredible amount of bps for all the UDP traffic, meters, waterfall(s), spectrum display(s), digital audio. For every UDP datagram received SSDR creates a corresponding Vita-49 packet from it, from which the actual payload is subsequently removed from it. I am not sure how much of the CPU required to create the Vita-49 packets is really 'productive'. That would be an interesting experiment to quantify that.

4) from that data it draws the SWR meter, Power meter, Signal strength meter, spectrum display and, optionally, waterfall. The actual drawing generally is done on your video card.

I think you'd be hard pressed to find a duo core Intel these days but, from the above, I don't know that there is much to be gained beyond an I5 chip with 4GB.

I don't disagree Peter. The distinction I wanted to make was core count vs thread count. You are absolutely right, at least earlier SSDR's would launch over 30 threads. That is a heck of a lot of context switches in one application. I can't speak to WPF but in JavaFX and Android there is a UI thread and, yes, I'd dedicate a core to that. However, as a counterpoise you have a whole pantload of UDP packets arriving, which take very little cpu. One could probably argue that the core handling the I/O could do dbl duty in processing the initial building of the view, to be drawn by the UI thread. With the exception of tablets and phones I think one would be hard pressed to find a current CoreDuo Intel box, but I suspect 2 cores could probably handle SSDR nicely. And then, as you point out, there is DM780 or FLdigi or CW Skimmer etc. This is why I said an I5 with reasonable memory, 4GB is reasonable, would suffice nicely.

There are some that would say, "I have a Dell PowerEdge T540 with 20GB of memory and 20 core dual Xeon procesors and ECC memory and SSDD and SSDR flies". Well, of course it does. And I tell those people they could put Hyper-V on it and rent time and still SSDR would fly.

As far as the title of this question, short of  defining processor affinity, yes, SSDR would run on all 20 procesors if you had a PowerEdge but the correct question would be does it need more than 4 cores and the answer is no. For those that watch their CPU utilization and see it at 50% that means that on a 4 core machine, on avg 2 of them are idle at any given time. They have 100% excess capacity. Even if with HRD and CWSkimmer if that pushes the CPU utilization to 85% that still is almost 20% excess capacity (15% / 85%).

If the thread processing the raw data into a spectrum view or waterfall view prior to handing over to the UI thread can do that faster than the FFT data arrives, more and/or faster cores are not necessary for that function. So long as the raw UDP packets are unmarshalled faster then they arrive more and/or faster cores will add no value. It is totally acceptable to have a dispatchable unit of work (thread) waitng for data to arrive.  What is, perhaps, less acceptable is to have a dispatchable unit of work waiting for an available core.

The other distinction I wanted to make was between faster processors verses more processors. Even in a multi-threaded application, i.e. SSDR, if thread 2 requires thread 1 to complete, then what they are doing is serial, not parallel. In the list of activities I made previously, tasks 1 and 2 occur solely by virtue of the user pressing a button or sliding a slider. Neither happen a lot or are time critical. Task 4 is completely dependent on task 3. You can't draw something that hasn't arrived yet.

task 1 depends on user input
task 2 depends on task 1
task 3 depends on UDP data from the radio (box).
task 4 depends on task 3.

However, if the software is designed properly task 3 can be processing datagram n+1 while task 4 is processing datagram data n. If the application is designed properly there is some parallelism between tasks 3 and 4. Prior to 1.4 they were serial. Now they are loosely coupled where task 3 (producer) populates a queue and task 4 consumes the queue. So long as task 3 can produce faster than task 4 can consume, task 4 wil stay busy and operate, largely, independent from task 3.

This presents an interesting queuing issue. On a locally attached network, task 3 can keep data available for task 4 such that task 4 never has to stop and wait for data. However, in a WAN environment it is not clear that will be the case, and likely won't be, task 4 may be faster than task 3. If task 4 is faster than task 3 the 'system' is once again serial. What does that mean? It may mean you don't necessarily want to be drawing a waterfall. At the end of the day, the bandscope (spectrum) doesn't draw many pixels. The waterfall, however, draws all of them.

So Howard? How am I doing now? ;-) (inside thing between Howard and me).

Ken, and all: While, given the waterfall packets arrive at all,  the majority of time spend processing waterfall data is physically drawing, which is what happens when you pul the spectrum over the waterfall, it would be WAY faster to never see the waterfall packets at all. Consequently the ideal solution is for FRS to add a switch to eliminate even sending the packets to the SSDR. You can't draw what you don't see. If someone wants to see them, great, they should but for someone running from a hotel room with bad wifi, it would be nice to selectively turn the waterfall off at the radio.

The data for the waterfall is still sent, whether it is a fast network (20Gbs) or a slow type B or G or N or AC wifi network. Data arrives serially. If good data has to wait in line behind 'bad' data that slows everything down.

The data is still processed, datagram packets need to be un-marshalled before it can be determined they are waterfal packets.

The data is still 'drawn' in the software. When the actual canvas work is done the data isn't being physically displayed yet.

Basically what you'd save is the scroll time. Scroll time is fast as the GPU physically does that in the video buffer on the video card.

If the data is never sent from the radio, that is the biggest dent possible in performance, verse just covering up the viewport.

Even to this day Ken, what I most enjoy is learning things I didn't previously know. I also enjoy teaching and mentoring. To be sure, there are many things in CS I do not know. As mentioned previously, on a good day I can spell .NET. Since I am now retired and don't like Microsoft's business practices, I don't have much need to. There are things you've said Ken that I hadn't previously known, so it works both ways!