High CPU Load


RubenD
 

I have a question that I've been looking for an answer for a long while. It must not be a common problem because searches turn up very little in the direction of a good answer. 
Or, it may be something that is obvious. I use Fldigi along with FUDP as a means of rig control only. It runs in Windows 11 on a motherboard with 16 Gb of memory and an Intel i7 9700 CPU.
I have it running between an Anan 7000DLE MKII transceiver and a Palstar HF Auto tuner. In Task Manager, at idle the SDR transceiver is utilizing 8% CPU load. FLDigi idles at between 19 and 23%. I have read extensively and have found no help. I have tried, as a matter of testing, many things to see if I can lower the CPU Load. The best I've accomplished is by stopping the 
waterfall and setting the op mode to SSB or Null. It now idles between 12 and 15%. 

I've been a ham for 7 years and am new to FLDigi. Do you think this is the best I can expect? Am I expecting too much? The only problem it may be contributing to is occasional audio artifacts when transmitting. I do like low latency. I don't think I am pushing the Sample rates and buffer size too hard. If I kill FLDigi any audio artifacts disappear. I don't contest. Mostly ragchew. I'm still reading and experimenting. Thank for any ideas you may provide. 

73
Ruben
NB4R


Cliff
 

Ruben,

That sounds high for that CPU, but I don't run Windows so can't say what the issue may be. Be sure the waterfall is running at it's normal rate. Running fldigi & flrig on my Raspberry Pi shows only 17% and you've got a lot more horsepower than I have.

73,
Cliff, AE5ZA

On Oct 17, 2022, at 11:21, RubenD <rbduck1@...> wrote:

I have a question that I've been looking for an answer for a long while. It must not be a common problem because searches turn up very little in the direction of a good answer. 
Or, it may be something that is obvious. I use Fldigi along with FUDP as a means of rig control only. It runs in Windows 11 on a motherboard with 16 Gb of memory and an Intel i7 9700 CPU.
I have it running between an Anan 7000DLE MKII transceiver and a Palstar HF Auto tuner. In Task Manager, at idle the SDR transceiver is utilizing 8% CPU load. FLDigi idles at between 19 and 23%. I have read extensively and have found no help. I have tried, as a matter of testing, many things to see if I can lower the CPU Load. The best I've accomplished is by stopping the 
waterfall and setting the op mode to SSB or Null. It now idles between 12 and 15%. 

I've been a ham for 7 years and am new to FLDigi. Do you think this is the best I can expect? Am I expecting too much? The only problem it may be contributing to is occasional audio artifacts when transmitting. I do like low latency. I don't think I am pushing the Sample rates and buffer size too hard. If I kill FLDigi any audio artifacts disappear. I don't contest. Mostly ragchew. I'm still reading and experimenting. Thank for any ideas you may provide. 

73
Ruben
NB4R


Renee Culver
 

It is way high for Windows. CPU  utilization  needs  tracked down with finer resolution.

Renee KC3NG

 

From: winfldigi@groups.io <winfldigi@groups.io> On Behalf Of Cliff
Sent: Tuesday, October 18, 2022 10:29 PM
To: winfldigi@groups.io
Subject: Re: [winfldigi] High CPU Load

 

Ruben,

 

That sounds high for that CPU, but I don't run Windows so can't say what the issue may be. Be sure the waterfall is running at it's normal rate. Running fldigi & flrig on my Raspberry Pi shows only 17% and you've got a lot more horsepower than I have.

 

73,
Cliff, AE5ZA



On Oct 17, 2022, at 11:21, RubenD <rbduck1@...> wrote:

 

I have a question that I've been looking for an answer for a long while. It must not be a common problem because searches turn up very little in the direction of a good answer. 
Or, it may be something that is obvious. I use Fldigi along with FUDP as a means of rig control only. It runs in Windows 11 on a motherboard with 16 Gb of memory and an Intel i7 9700 CPU.
I have it running between an Anan 7000DLE MKII transceiver and a Palstar HF Auto tuner. In Task Manager, at idle the SDR transceiver is utilizing 8% CPU load. FLDigi idles at between 19 and 23%. I have read extensively and have found no help. I have tried, as a matter of testing, many things to see if I can lower the CPU Load. The best I've accomplished is by stopping the 
waterfall and setting the op mode to SSB or Null. It now idles between 12 and 15%. 

I've been a ham for 7 years and am new to FLDigi. Do you think this is the best I can expect? Am I expecting too much? The only problem it may be contributing to is occasional audio artifacts when transmitting. I do like low latency. I don't think I am pushing the Sample rates and buffer size too hard. If I kill FLDigi any audio artifacts disappear. I don't contest. Mostly ragchew. I'm still reading and experimenting. Thank for any ideas you may provide. 

73
Ruben
NB4R

 


Renee Culver
 

It  is a common malady that few  people are likely to  notice. Someone  who really understands windows should  enjoy  the problem. It’s a tempting problem. Much can be learned by using  the taskmanager.

Renee

-------------

 

From: winfldigi@groups.io <winfldigi@groups.io> On Behalf Of RubenD
Sent: Monday, October 17, 2022 12:21 PM
To: winfldigi@groups.io
Subject: [winfldigi] High CPU Load

 

I have a question that I've been looking for an answer for a long while. It must not be a common problem because searches turn up very little in the direction of a good answer. 
Or, it may be something that is obvious. I use Fldigi along with FUDP as a means of rig control only. It runs in Windows 11 on a motherboard with 16 Gb of memory and an Intel i7 9700 CPU.
I have it running between an Anan 7000DLE MKII transceiver and a Palstar HF Auto tuner. In Task Manager, at idle the SDR transceiver is utilizing 8% CPU load. FLDigi idles at between 19 and 23%. I have read extensively and have found no help. I have tried, as a matter of testing, many things to see if I can lower the CPU Load. The best I've accomplished is by stopping the 
waterfall and setting the op mode to SSB or Null. It now idles between 12 and 15%. 

I've been a ham for 7 years and am new to FLDigi. Do you think this is the best I can expect? Am I expecting too much? The only problem it may be contributing to is occasional audio artifacts when transmitting. I do like low latency. I don't think I am pushing the Sample rates and buffer size too hard. If I kill FLDigi any audio artifacts disappear. I don't contest. Mostly ragchew. I'm still reading and experimenting. Thank for any ideas you may provide. 

73
Ruben
NB4R


Karl
 

I read this whole exchange twice and still have NO IDEA what you all are saying! My problem, not yours! I am just another caveman trying to emerge from primitive....

Will read quietly for more learning...


RubenD
 
Edited

LOL! Karl!❓

I haven't responded to any of the help offered due to a lack of understanding. I do appreciate the attempts to help me. I may have solved the issue , but don't have a clue how.
I will restate the original issue to , hopefully, avoid misunderstandings.  

For the past long while I have noticed , in the Task Manager screen, that FLDigi was utilizing 19 to 20% CPU capacity. This was during a period of time when FLDigi should have been sitting in a complete resting state. At this time in the hobby, I am only using FLDigi for rig control and nothing else. I have tried a number of things to get this CPU load down without success.

When I happened across this forum I thought I might try asking once more for help. 

After the post I thought I would revisit the problem and see if could find a figure something out. First, I found the latest version of FLDigi and installed it. I went back through the 
app, page by page, to see if there was something I may have missed in the past. I didn't notice a thing that I may have missed set up incorrectly. What I did do was go through and purposely make some settings that I know is incorrect. I saved the settings. I closed the app and rebooted the PC. I then went back through and changed the settings back to what I was thought was correct and booted the system again.

After the reboot and restart of the app I saw no improvement. This morning I noticed there have been several responses to my original post. I read them. Several times.
Then, I went back in to Task Manager to check on the FLDigi app. To my surprise, I found the app was only using 2% or less of CPU utilization. At this point I thought I would 
go about business while keeping a watch on FLDigi in Task Manager for a while. Again, to my surprise, I found the app was still utilizing very low CPU utilization. 

I'm not sure what I may have done to make this marked improvement. I will take it at face value. FLDigi is a very useful app that can do many different things. Maybe I had some conflict that was causing a rise in CPU usage. It is working well now and I am satisfied with that. 

Thank you all for your time and comments. Karl, I am right there with you in the confused state. I will keep watch and report here if there are any further changes in the way FLDigi is operating. Have a great day all and thanks again!!! 

(If I didn't describe the issue I was having clearly, I do apologize. Sometimes when I get in a rush I tend to make this mistake)


Dave
 

If you only need rig control then you should be using flrig.

David

On 10/20/22 07:51, RubenD wrote:

LOL! Karl!❓

I haven't responded to any of the help offered due to a lack of understanding. I do appreciate the attempts to help me. I may have solved the issue , but don't have a clue how.
I will restate the original issue to , hopefully, avoid misunderstandings.  

For the past long while I have noticed , in the Task Manager screen, that FLDigi was utilizing 19 to 20% CPU capacity. This was during a period of time when FLDigi should have been sitting in a complete resting state. At this time in the hobby, I am only using FLDigi for rig control and nothing else. I have tried a number of things to get this CPU load down without success.

When I happened across this forum I thought I might try asking once more for help. 

After the post I thought I would revisit the problem and see if could find a figure something out. First, I found the latest version of FLDigi and installed it. I went back through the 
app, page by page, to see if there was something I may have missed in the past. I didn't notice a thing that I may have missed set up incorrectly. What I did do was go through and purposely make some settings that I know is incorrect. I saved the settings. I closed the app and rebooted the PC. I then went back through and changed the settings back to what I was thought was correct and booted the system again.

After the reboot and restart of the app I saw no improvement. This morning I noticed there have been several responses to my original post. I read them. Several times.
Then, I went back in to Task Manager to check on the FLDigi app. To my surprise, I found the app was only using 2% or less of CPU utilization. At this point I thought I would 
go about business while keeping a watch on FLDigi in Task Manager for a while. Again, to my surprise, I found the app was still utilizing very low CPU utilization. 

I'm not sure what I may have done to make this marked improvement. I will take it at face value. FLDigi is a very useful app that can do many different things. Maybe I had some conflict that was causing a rise in CPU usage. It is working well now and I am satisfied with that. 

Thank you all for your time and comments. Karl, I am right there with you in the confused state. I will keep watch and report here if there are any further changes in the way FLDigi is operating. Have a great day all and thanks again!!!


RubenD
 

Thank you very much Dave!! I understand! 

73
Ruben
NB4R


Karl
 

That Dave! He ACTUALLY reads this stuff we post! He is so reachable and actually responds! DAVE! We appreciate your creation and your participation!


RubenD
 

Again, Thank you Dave. One think I had forgot to mention. Along with FLDigi I am using a small app named FLDigi UDP helper app. It is a requirement due to the fact I am using 
FLDigi to control not only the transceiver, but the associated Palstar HF-Auto tuner. Is it possible to use FLDigi UDP along with Flrig?


on6ab
 

Hi, 
Here too, my PC suffers from high flDigi CPU load.
When starting the app, CPU load is around 3 to 5% but then it gradually increases with time.
After 15 minutes or so, the flDigi CPU load is around 20 to 25% and the waterfall starts stuttering a bit.
I tried changing a lot of settings but nothing helped.

Finally, I tried out a lot of flDigi versions to see if there was any difference between them.
What I found out is that with all flDigi version starting with 4.1.x.x , the CPU problem is present.
However, all 4.0.x.x versions are working fine. That is: the CPU load is around 3 to 5 % and it remains like that.

Going from 4.0.x.x to 4.1.x.x ( I think in practice it was from version 4.0.18 to version 4.1.01) sounds like there was a major upgrade at that time, but I can't find out what  really changed between these versions.
Is there anybody who can enlighten me on this?

Many thanks,


Mike Black
 

What mode are you usijng?




On Monday, March 13, 2023 at 05:32:49 PM CDT, on6ab <bruno.beckers@...> wrote:


Hi, 
Here too, my PC suffers from high flDigi CPU load.
When starting the app, CPU load is around 3 to 5% but then it gradually increases with time.
After 15 minutes or so, the flDigi CPU load is around 20 to 25% and the waterfall starts stuttering a bit.
I tried changing a lot of settings but nothing helped.

Finally, I tried out a lot of flDigi versions to see if there was any difference between them.
What I found out is that with all flDigi version starting with 4.1.x.x , the CPU problem is present.
However, all 4.0.x.x versions are working fine. That is: the CPU load is around 3 to 5 % and it remains like that.

Going from 4.0.x.x to 4.1.x.x ( I think in practice it was from version 4.0.18 to version 4.1.01) sounds like there was a major upgrade at that time, but I can't find out what  really changed between these versions.
Is there anybody who can enlighten me on this?

Many thanks,


on6ab
 

Hello,

It is a general observation, it seems to be mode independant as changing the mode does not  change the CPU load dramatically.
Take PSK31 for instance...
Is there somewhere a "revision history" where all version changes are listed?


Dave
 

Hello,

It is a general observation, it seems to be mode independant as changing the mode does not  change the CPU load dramatically.
Take PSK31 for instance...
Is there somewhere a "revision history" where all version changes are listed?


Dave
 

Testing 4.1.25.07 for 4 hours on a low end Celeron running Windows 11.  CPU % for fldigi never exceeds 6 % decoding mode CW.  Xcvr control via flrig interface to a FLEX1500.

David

On 3/13/23 19:36, Dave wrote:

https://sourceforge.net/p/fldigi/fldigi/ci/master/tree/

On 3/13/23 19:19, on6ab wrote:
Hello,

It is a general observation, it seems to be mode independant as changing the mode does not  change the CPU load dramatically.
Take PSK31 for instance...
Is there somewhere a "revision history" where all version changes are listed?



on6ab
 

Hello Dave,

Many thanks for your test.
I presume on most systems flDigi 4.1.x.x just works fine.

What I find strange is that all goes well here with ALL 4.0.x.x. versions and screws up with ALL 4.1.x.x versions (and I tested a lot of them).
I just try to find out why.
A revision history would help or at least steer me in the right direction.
What were the main changes going from 4.0 to 4.1. "That's the question"


Dave
 

Did you look at the Source Forge git repository?

https://sourceforge.net/p/fldigi/fldigi/ci/master/tree/

The complete revision history since conception is contained therein.

Dave

On 3/13/23 21:55, on6ab wrote:

Hello Dave,

Many thanks for your test.
I presume on most systems flDigi 4.1.x.x just works fine.

What I find strange is that all goes well here with ALL 4.0.x.x. versions and screws up with ALL 4.1.x.x versions (and I tested a lot of them).
I just try to find out why.
A revision history would help or at least steer me in the right direction.
What were the main changes going from 4.0 to 4.1. "That's the question"



on6ab
 

Ah, thanks a lot Dave, I overlooked that.
However, the list of changes from 4.0.18 to 4.1.0 as described is rather complicated if you're not involved writing the program.
I think I'll stick with 4.0.18 ;-)

Many thanks for your help though!

73,

Bruno


Dave
 

Here's a few things to try.

Keep the 4.1.25.xx code testing completely separate from the 4.0.18 testing.  That will insure that there is no issue with using the earlier configuration files with the most recent executable.
The desktop launch icons should already be labeled with the version number.
Open the properties dialog for the 4.1.25.xx launcher and add to the Target control:
--config-dir C:\Users\<username>\fldigi-test\
Close the properties dialog and try launching fldigi using that desktop icon.  You will have to perform a new configuration.
Make sure that you configure the fonts for both the Rx and Tx controls.  Select a FIXED WIDTH font such as Consolas.  Some proportional fonts can cause creeping cpu usage such as you describe.

A way to check to see if the font is an issue is to clear the Rx control (right click and select from pop up menu) when the cpu % is high.  If it reduces almost immediately the font is most likely the cause.

I posted a diff file that has all of the code changes from Version 4.0.18 to Version 4.1.00 at http://www.w1hkj.com/temp/

V4.0.18-v4.1.00.diff

diff files contain incremental changes listed by source file.

Dave

On 3/13/23 23:01, on6ab wrote:
Ah, thanks a lot Dave, I overlooked that.
However, the list of changes from 4.0.18 to 4.1.0 as described is rather complicated if you're not involved writing the program.
I think I'll stick with 4.0.18 ;-)

Many thanks for your help though!

73,

Bruno


on6ab
 

Many thanks for your good advise and for the file Dave.

I'll try a few things out ;-)

73,

Bruno
ON6AB