In our design we have defined 11 channels for the bands from 160-10m bands. Additionally 1 wspr channel with 15 wspr frequencies. Also 1 channel with the 'noise' frequencies, i.e. WWVB, WWV and CHU frequencies. 

On older laptops this gives insufficient performance. Even on one i5 computer, it will not run reliable. Radiod is quite a heavy program which takes on an medium performance laptop about 50% of the CPU time. The moment that wsprdaemon starts decoding, all cores go to 100%. And dependent of how much channels you have defined, that can go on for several seconds.

We found out that we get drops of data packets, higher latency and hicks in the websdr channel.

So in our design we are going to take three miniPC's, in a local network setting.

One PC is a RYZEN5625, the others are NUC's(Intel i7). We need the following data flows in our network:

The RYZEN (connected to the RX888MKII) is running radiod, and will deliver all the data streams. From there the wspr stream flows into NUC-1, where wsprdaemon (WD) is running. From the RYZEN also the WebSDR data is flowing to NUC-2, where the WebSDR software is running. NUC-1 and 2 need access to the internet, because of the reporting of wsprdaemon, and the client data for the listeners of the WebSDR. But the RYZEN should NOT be connected to the internet, because the 150Mb/s data flow should only go to the two NUC's.

This can be realized with a MTU VLAN switch, see next page.

Our tests have proven that this configuration is working well with the number of channels we want in our design, including additional applications, like GNU radio.

Later on  we will give some practical information of the CPU loads.