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 |
|
Cliff
Ruben,
toggle quoted message
Show quoted text
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
|
|
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,
|
|
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. |
|
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... |
|
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) |
|
If you only need rig control
then you should be using flrig.
toggle quoted message
Show quoted text
David On 10/20/22 07:51, RubenD wrote:
LOL! Karl!❓ |
|
Thank you very much Dave!! I understand!
73 Ruben NB4R |
|
That Dave! He ACTUALLY reads this stuff we post! He is so reachable and actually responds! DAVE! We appreciate your creation and your participation!
|
|
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? |
|
toggle quoted message
Show quoted text
Hello, |
|
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.
toggle quoted message
Show quoted text
David On 3/13/23 19:36, Dave wrote:
https://sourceforge.net/p/fldigi/fldigi/ci/master/tree/ |
|
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" |
|
Did you look at the Source Forge git repository?
toggle quoted message
Show quoted text
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, |
|
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 |
|
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.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. |
|
on6ab
Many thanks for your good advise and for the file Dave.
I'll try a few things out ;-) 73, Bruno ON6AB |
|