If you notice spammers in the forum, please notify Bas ON5HB, so they can be removed and banned. Give a link in the chatbox or send a PM to me. Thanks.

Plutoplus sdr - Performance issue

Started by F5OEO, Nov 21, 2024, 06:44 PM

Previous topic - Next topic

F5OEO

Hi,

I running PhantomSDR+ on ubuntu 22.04 LTS with i7-9700 CPU @ 3.00GHz.
I have also a Quadro P2200 with opencl.

Pluto+ is able to transmit IQ CS8 over gigabit at around 30MS with a custom firwmare.
Using a ./plutorx -o 8  |pv >/dev/null give me a stable 60Mbytes/s.

As soon as I pipe it to phantomsdr, ethernet bitrate dropping to 45Mbytes/s.

With CPU : cpu usage 60%
With opencl : cpu usage around 20%

Result on the web interface is choppy as some samples are dropped regularly.
Wonder if is a related to my machine (cpu or opencl) or if it could be related to other process or buffering issue with piping.

Here is my config-pluto.toml if thre is anything wrong with it ?

Best
Evariste F5OEO

[server]
port=9002 # Server port
html_root="frontend/dist/" # HTML files to be hosted
otherusers=1 # Send where other users are listening, 0 to disable
threads=1

[websdr]
register_online=false # If the SDR should be registered on https://sdr-list.xyz then put it to true
name="ChangeThis" # Name that is shown on https://sdr-list.xyz
antenna="ChangeThis" # Antenna that is shown on https://sdr-list.xyz
grid_locator="ChangeThis" # 4 or 6 length Grid Locatlr shown on https://sdr-list.xyz and for the Distance of FT8 Signals
hostname="" # If you use ddns or something to host with a domain enter it here for https://sdr-list.xyzv


[limits]
audio=100
waterfall=100
events=100

[input]
sps=30000000 # Input Sample Rate
fft_size=65536  # FFT bins
fft_threads=1
brightness_offset=0 # Waterfall brightness offset. Reduce to negative if you see black regions in the waterfall
frequency=120000000 # Baseband frequency
signal="iq" # real or iq
accelerator="opencl" # Accelerator: none, cuda, opencl
audio_sps=48000 # Audio Sample Rate
waterfall_size=2048
smeter_offset=0

[input.driver]
name="stdin" # Driver name
format="s8" # Sample format: u8, s8, u16, s16, u32, s32, f32, f64

[input.defaults]
frequency=118500000 # Default frequency to show user
modulation="AM" # Default modulation


 

Bas ON5HB

Few issues.

1: Server threads, set them to 2 instead of 1.
2: FFT threads, set them to 4.
3: The fft-bin size is way too little, for 60MSPS it's fft_size=8388608, you may need halve of that.
4: Audio_sps should be 12000

Not sure if the Pluto does iq or real.

My opinion, you have too little threads on both and too little bins.

Try and let us know.
Best regards,

Bas ON5HB

Ps. the Community Edition can be found here: https://github.com/ny4qphil/PhantomSDR-Plus

Phil - NY4Q

Something else Bas mentioned in another thread was disabling hyperthreading in BIOS to help with the real time computing.

F5OEO

Thanks..set with parameters you mentionned : same.
Pluto does iq 16 bits normally, but I set a special mode to output complex S8.

Using a fifo seems to help, which means it is probably related to some burst write/read.

mkfifo buf
./build/spectrumserver --config config-pluto.toml > /dev/null 2>&1 <buf &
 ~/prog/tezuka_fw/app/plutorx86 -o 8 > buf &

See http://yuzuparapente.fr:9002/ at 20Mhz


F5OEO

With a very dirty hack, I have now 30Mhz band from pluto+.
In the current code, reading buffer input is done by fft size chunk . With high samplerate, you need to increase fft size in order to read big chunks and avoid too much read overlap.

Dirty ack is done by reading chunk with 10x fft size. Now all is working even a small fft.

int FileSampleReader::read(void *arr, int num) {
    //fprintf(stderr,"Request %d\n",num);
    static int idx=0;
    static uint8_t *Buff=NULL;
    if(Buff==NULL)
    {
        Buff = (uint8_t*)malloc(num*10);
    }
    if(idx==0)
    {
        int size=fread_unlocked(Buff, sizeof(uint8_t), num*10, f);
        memcpy(arr,Buff,num);
        idx++;
    }   
    else
    {
        memcpy(arr,Buff+idx*num,num);
        idx++;
        if(idx==10) idx=0;
    }
    return num;   
}

Best should be to separate input buffer read size and fft size more cleanly.
Result :


Powered by EzPortal