Jump to content

Suggestion how to prevent discontinuities


jirim100

Recommended Posts

Good day.

 

Here and here was successfully prevented discontinuities by disabling C states of processor in BIOS.

 

But exist methods how to disable C states of processor temporarily programmatically:

OSVERSIONINFO osvi;
memset(&osvi, 0, sizeof(OSVERSIONINFO));
osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);
GetVersionEx(&osvi);
// For Vista and above
if (osvi.dwMajorVersion >= 6)
{
   const GUID processor_idle_disable_guid = {0x5d76a2ca, 0xe8c0, 0x402f, 0xa1, 0x33, 0x21, 0x58, 0x49, 0x2d, 0x58, 0xad};
   GUID *scheme;
   const DWORD DISABLED = 1;
   const DWORD ENABLED = 0;
   DWORD error;
   error = PowerGetActiveScheme(NULL, &scheme);
   error = PowerWriteACValueIndex(NULL, scheme, &GUID_PROCESSOR_SETTINGS_SUBGROUP, &processor_idle_disable_guid, DISABLED);
   error = PowerWriteDCValueIndex(NULL, scheme, &GUID_PROCESSOR_SETTINGS_SUBGROUP, &processor_idle_disable_guid, DISABLED);
   error = PowerSetActiveScheme(NULL, scheme);
}

 

DMS should be, before start recording, save actual power state value (for GUID_PROCESSOR_SETTINGS_SUBGROUP, processor_idle_disable_guid) by functions PowerReadACValueIndex and PowerReadDCValueIndex. Then set new values by PowerWriteACValueIndex and PowerWriteDCValueIndex as showed in the code above.

When no more recording DMS should set old values.

 

More it's discussed herehereherehere.

 

During 10 years of recording and using many brands of USB tuners I still had problem with discontinuities and yesterday I found it's solvable programmatically without changing BIOS settings.

 

Maybe it's applicable to DVBViewer Pro too.

 

If you implement it, you won't have to deal with so many service requests from customers.

 

Not all BIOS has the ability to disable C states of processor. For example BIOS of my Dell Vostro 3550 don't have this.

 

Edited by jirim100
  • Thanks 1
Link to comment

 

Am 3.3.2023 um 18:15 schrieb jirim100:

Here and here was successfully prevented discontinuities by disabling C states of processor in BIOS. (...) DMS should be, before start recording, save actual power state (...) then set new values (...) as showed in the code above. When no more recording DMS should set old values.

 

Thanks for researches and information. This is quite interesting. Integrating it in DVBViewer/DMS may be helpful for people who get discontinuities due to power saving by C-states. However, your suggestion is obviously tailored for your usage scenario. Some remarks:

  • It must be optional, because in the majority of cases it won't be needed. I've just used perfmon to check how many time my  i7-3770 CPU spends in which C-states. Most of the time (more than 90%) C3 is active while I'm writing and DVBViewer is receiving DVB-T2 However, I never experienced trouble with discontinuities on this PC (three USB tuners, 2 Digital Devices PCIe tuners). Same on other PCs, except with certain USB devices whose driver is prone to it (particularly TBS).
  • It won't save support requests, except from people who already know that there is such an option. However, it will probably be easier to help  users who are affected. They can fix it without having to manipulate BIOS settings.
  • It shouldn't be restricted to recordings, but to times when a BDA device is used. There are cases where even playback becomes unenjoyable due to frequent discontinuities. On the other side, there are recordings that won't need it, particularly if a DVBViewer recording is actually a download of an internet stream (I rarely record from BDA tuners. German public broadcasters provide most programs in their "Mediathek" for a certain time. It's easy to determine the URL with the Stream Detector Firefox add-on, enter it in DVBViewer and use the record function to download the stuff).
  • Not so nice: If DVBViewer/DMS crash (e.g. as result of a BDA driver crash) while C-states are disabled, they won't be enabled again.
  • Open question: Do PowerWriteACValueIndex and PowerWriteDCValueIndex require admin/system rights? I couldn't find information about it. If yes, it won't be usable for DVBViewer.

Anyway, in the end it comes down to trying if this is really practical...

 

Link to comment

A short test: This call

 

PowerWriteACValueIndex(NULL, scheme, &GUID_PROCESSOR_SETTINGS_SUBGROUP, &processor_idle_disable_guid, DISABLED);

 

immediately increases the CPU load, as shown by the task manager, on my PC to 100%. So it works (without admin rights), but at what price?

 

Link to comment
7 hours ago, Griga said:

immediately increases the CPU load, as shown by the task manager, on my PC to 100%

Hm. This is not nice. Probably fan speed up to maximum? I did not test the code above. The solution should be without set CPU load to 100%. Maybe other functions.

 

>It shouldn't be restricted to recordings, but to times when a BDA device is used.<

Yes, of course.

 

>Not so nice: If DVBViewer/DMS crash (e.g. as result of a BDA driver crash) while C-states are disabled, they won't be enabled agai<

You are right. But it's nothing that would cause any damage (except power consuption).

Edited by jirim100
Link to comment
vor 21 Stunden schrieb jirim100:

The solution should be without set CPU load to 100%.

 

The call disables all C-States, thus generally preventing the CPU cores from entering an idle state. For avoiding discontinuities, it would probably be sufficient to disable only the highest C-state, as you did it here in the BIOS. But is there any Windows API for doing this?

 

In the extended Windows energy options there is a setting called "minimum processor state". The default value is 5%. It takes influence on how much the CPU clock is lowered if full speed isn't required for a task. The effect can be watched in the task manager. However, I doubt that adjusting it to a higher value for avoiding a low CPU clock will also avoid discontinuities.

 

Someone who has this problem should try...

 

Link to comment

Another interesting GUID is 

const GUID processor_idle_state_maximum = {0x9943e905, 0x9a30, 0x4ec1, 0x9b, 0x99, 0x44, 0xdd, 0x3b, 0x76, 0xf7, 0xa2};

with this GUID should be to able to disable for example only C3, C4... states. Possible values for this GUID are 0 to 20. This value determines what idle states are allowed, ranging from shallow (1) to deepest idle states are allowed (20). A value of 0 means that no limit is imposed on how deep. You can try the following code to see which C-states will be disabled:

PowerWriteACValueIndex(NULL, scheme, &GUID_PROCESSOR_SETTINGS_SUBGROUP, &processor_idle_state_maximum, 1); 

See here.

Link to comment
vor 1 Stunde schrieb jirim100:

with this GUID should be to able to disable for example only C3, C4... states.

 

I've tried the value 1. Windows accepts it quite happily and stores it in the power settings (shown by powercfg /Qh, h stands for "hidden"), but perfmon still indicates that my CPU spends most of its time in C3 state, even after a reboot.

 

The whole thing is a bit confusing, because the C1...C3 states in perfmon are logical, not physical C states. Windows maps the CPU-dependent physical states to logical states. C3 in Windows means "C3 and everything above", as I have read...

 

Link to comment

@Griga try this code:

 

const GUID processor_idle_demote_threshold = { 0x4b92d758, 0x5a24, 0x4851, 0xa4, 0x70, 0x81, 0x5d, 0x78, 0xae, 0xe1, 0x19 };
const GUID processor_idle_promote_threshold = { 0x7b224883, 0xb3cc, 0x4d79, 0x81, 0x9f, 0x83, 0x74, 0x15, 0x2c, 0xbe, 0x7c };
const GUID processor_idle_state_maximum = { 0x9943e905, 0x9a30, 0x4ec1, 0x9b, 0x99, 0x44, 0xdd, 0x3b, 0x76, 0xf7, 0xa2 };
DWORD error;
GUID *scheme;
error = PowerGetActiveScheme(NULL, &scheme);
error = PowerWriteACValueIndex(NULL, scheme, &GUID_PROCESSOR_SETTINGS_SUBGROUP, &processor_idle_state_maximum, 1);  // default is 0
error = PowerWriteDCValueIndex(NULL, scheme, &GUID_PROCESSOR_SETTINGS_SUBGROUP, &processor_idle_promote_threshold, 100); // default is 60
error = PowerWriteDCValueIndex(NULL, scheme, &GUID_PROCESSOR_SETTINGS_SUBGROUP, &processor_idle_demote_threshold, 100); // default is 40
error = PowerSetActiveScheme(NULL, scheme);

 

See here. The code above should disable all C states according to one of the authors of ThrottleStop. I tried it on my PC and checked it in ThrottleStop and in HWInfo-SensorStatus - both show zero values for C3 state and above. It's unclear why PerfMonitor still show nozero C1 time, BUT C2 and C3 time is zero AND processor usage is not 100% in Task Manager.

 

Here is list of all processor GUIDs (search for text "demote_threshold"). 

Promote treshold:  Specifies the lower busy threshold that must be met before promoting the processor to a deeper idle state (in percentage).

Demote threshold:  Specifies the upper busy threshold that must be met before demoting the processor to a lighter idle state (in percentage).

 

Link to comment

That seems to work. I didn't try the code, but made the options visible (and changeable) in the Windows advanced power settings. This can be achieved in the registry (also see here). Go to

 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\54533251-82be-4824-96c1-47b60b740d00

 

where 54533251-82be-4824-96c1-47b60b740d00 is GUID_PROCESSOR_SETTINGS_SUBGROUP. The sub-keys are the GUIDs for the processor options. If you select one of them (e.g. processor_idle_demote_threshold = 4b92d758-5a24-4851-a470-815d78aee119) and change the REG_DWORD Attributes value from 1 to 0, it can be accessed it in the advanced power settings.

 

vor 8 Stunden schrieb jirim100:
// default is 60

 

You can't rely on it. It varies according to the power plan.

 

Link to comment
vor 16 Stunden schrieb jirim100:

It's unclear why PerfMonitor still show nozero C1 time,

 

The logic behind it is a bit odd ;)

 

Obviously my i7-3770 CPU is using 4 physical C states: C0 (the working state, CPU is busy), plus the idle states C1 or rather C1E (Enhanced C1), C3 and C6 (according to ThrottleStop). In perfmon C1, C3 and C6 are mapped to the logical idle states C1..C3. C0 is called "processor time". In the following I refer to the logical C states.

 

The processor idle demote/promote threshold settings influence transitions between idle states. They don't switch them off completely. If C1 would be switched off too, the CPU would be in the working state all of the time. We had this already.

 

Now, what happens if I set the processor idle demote threshold to 100%, with the promote threshold still being 60%, while I'm writing here and the CPU load is very low? It prevents the C3 state! About half of the CPU idle time is covered by C1 and C2 each. I guess it's because there are two contradictory rules: The 100% demote rule, that is almost always fulfilled,  demands to lower the C state, while the 60% promote rule, that is also most of the time fulfilled, demands to increase the C state. So the CPU is steadily switching between C1 and C2.

 

After additionally setting the promote rule to 100%, it demands to not increase the C state anymore, because it is never fulfilled (the CPU is never more than 100% idle). Consistently the C1 state now covers all of the idle time. C2 and C3 are out.

 

After setting the demote rule back to 40%, there is no change. Still C1 is not increased due to the promote rule saying no. However, here is a surprise: After setting both rules back to the default (40% and 60%) and then the promote rule to 100%, C1...C3 are all used, mostly C3! No change compared to the 40%/60% setting. Only after setting the demote rule also to 100% and then back to 40%, I get the "C1 only" state.

 

So it also depends on the order in which the settings are changed. Quite confusing... :wacko:

 

Link to comment

It's interesting. It's a little bit "magic". But for our purposes should be useful to set promote and demote rules both to 100% in ONE step (plus IDLESTATEMAX  to value 1). This always set the CPU to "C1 only" state. I think hardware C1, C1E, C2 states are not problem for recording.

 

One interesting fact about C states is: "As the C-States get deeper, the exit latency duration becomes longer (the time to transition to C0)" see here. And this can be problem for some DVB tuners. 

 

For study purposes here and here is description of C states.

 

>The processor idle demote/promote threshold settings influence transitions between idle states. They don't switch them off completely. <

 

Yes, promote/demote does not disable deeper C states on processor level, but it's method how to prevent deeper C states without Administrator rights.

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

 

>...and change the REG_DWORD Attributes value from 1 to 0, it can be accessed it in the advanced power settings<

Nice. Thanks for the tip.

Edited by jirim100
Link to comment

I've just tried changing the setting on a PC with Windows 7 and a Core Duo E7500 CPU. The results:

  • The idle state maximum setting doesn't exist. It's missing in the registry, so I couldn't make it visible in the advanced power settings.
  • perfmon indicates that only C1 is used.
  • ThrottleStop doesn't offer C state monitoring, so I guess there are no other states but C0 and C1.
  • Changing idle demote/promote threshold settings to 100% doesn't show any effect.
  • Disabling the idle state works. In perfmon C1 state usage drops to 0, ThrottleStop displays an immediately rising CPU temperature (from about 35° to 45°), but the processor time in perfmon and the CPU load in the task manager remain the same (no 100%).

Do you have an opportunity to check the settings with an AMD CPU?

 

P.S. I couldn't make the idle state maximum setting visible in the advanced power settings under Windows 10. It doesn't appear, though the REG_DWORD Attributes value is 0. I just didn't recognize it. Changing the value in the advanced power settings doesn't show any effect either.

 

Edited by Griga
Addition
Link to comment
4 hours ago, Griga said:

Do you have an opportunity to check the settings with an AMD CPU?

Unfortunatelly no.

 

 

4 hours ago, Griga said:

I just didn't recognize it. Changing the value in the advanced power settings doesn't show any effect either.

But this is not the same on my PC (desktop, Win10 64b, Intel i9-10900 2.8GHz). When I have enabled C6 state (and no C3 state) in BIOS and change only IDLESTATEMAX to 1 then in ThrottleStop C6 state time goes to zero. When I have enabled only C3 state in BIOS and change only IDLESTATEMAX to 1 then in ThrottleStop C3 state time goes to zero. Therefore, I recommend set IDLESTATEMAX along with Promote and Demote values. I did this test from Visual Studio 2022.

Edited by jirim100
Link to comment

I did tests on my 10 years old laptop Dell Vostro 3550 with Windows 7 64bits, CPU Intel Core i3-2310M 2.1GHz (tests was made from VS 2019):

Laptop was externally powered:

- In default state: ThrottleStop C states are accessible and window "C states" show nonzero values for C3, C7 (Core C states) and nonzero values for C2, C3, C6, C7, PKG (Package C states). PerfMon show nonzero values for all three C states - for C1, C2, C3.
- When I set PROCESSOR_IDLE_DISABLE =  1: ThrottleStop show C0 = 100%, all other C states (from C2 to C7, PKG) are 0%; Perfmon show zero time for C1, C2, C3. TaskManager don't show 100% loading of CPU (maybe in TaskManager is bug, because my fan increased speed and temperature CPU increased too).

- IDLESTATEMAX does not exist on my PC - trying to set it failed with error 2 (without exception).

- When I set Promote = 100, Demote = 100: ThrottleStop C0 is around 10%, all other C states (from C2 to C7, PKG) are 0%; Perfmon show zero time ONLY for C2 (C1 and C3 are nonzero - maybe bug in PerfMon ? - both has around 50%). 

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

- When I disconnect external power:  When I set Promote = 100, Demote = 100: ThrottleStop - I see only one change: C3 is zero, all other C states are nonzero; Perfmon show zero time for C1, a little bit time for C2, and most of time for C3. I am confused.

 

Conclusion: DVB usb devices with laptop should be used only with connected external power. 

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

Update: here is comment of my test result by the author of ThrottleStop.

 

Edited by jirim100
Link to comment

I've performed another test on a PC with i5-6400 CPU under Windows 10. There was no significant difference compared to the  i7-3770 CPU under Windows 10.

 

Conclusion: The effect of the CPU power settings can be quite different depending on the CPU type and age and the OS. Since we don't know enough about this matter yet, I don't want to offer "Disable deeper power saving states on BDA tuner usage" as official setting in DVBViewer/DMS, because users tend to change settings blindly in case of problems, without really knowing what they are doing and without returning to the defaults afterwards.

 

As it is now, I think a proceeding would be more appropriate, that allows a kind of "filtering" in support situations, so that supporters can decide whether trying CPU power options makes sense or not:

  • A little tool with two checkboxes that only change the idle state maximum and/or  idle demote/promote threshold settings for testing purpose. It can be provided for users (and only users) that get discontinuities, so they can find out if the settings do something about it.
  • A "hidden" DVBViewer/DMS setting, similar to the Microsoft handling, so that users need to know a certain identifier for adding the option with a text editor to the setup.xml / service.xml. They can be informed about it if the test tool shows that discontinuities can be avoided in this way.

 

Link to comment

That sounds reasonable. Something is definitely better than nothing. For example, I would use it if I will be forced to record again on my 10 year old laptop with external power connected (if my main desktop PC will be damaged or needs to be repaired or some long time hardware update).

You can of course argue that anyone can change the power plan themselves according to this discussion using registry entries, but personally I think that the existing hidden independent setting in DMS has its meaning as well. It would only turn on when recording, if not recording then is saving energy - green deal 🙂. The price of energy is expensive.

 

When I was recording on my old Dell, I sometimes had to start DVBViewer to increase the CPU load for avoiding discontinuities. I didn't understand it as much then as I do now.

 

 

Edited by jirim100
Link to comment

The result of further researches:

 

In this case discontinuities were not avoided by disabling C-states, but ASPM (Active State Power Management), which is a PCIe setting. More about it here.

 

P.S. It can be influenced in the PCI Express section of the Windows advanced power settings, as stated here, which means, DVBViewer/DMS could also do it. The sub-group GUID is 501a4d13-42af-4429-9fd1-a8218c268e20, the setting GUID ee12f906-d277-404b-b6da-e5fa1a576df5, the possible values are 0 (no energy saving), 1 (medium), 2 (high).

 

In this case it is  questionable whether C states were involved. Discontinuities were avoided by disabling a "Runtime Power Managment" setting in the HP BIOS. According to this page it is CPU frequency/voltage related.

 

It looks like there are several possible energy-saving related reasons for discontinuities. Your case is the only one up to now, that explicitely avoids discontinuities by disabling C states.

 

However, there are reports in the web describing disturbances due to C states in other kinds of time-critical live streams, e.g. from a camera. Undoubtedly higher C states do increase the system latency. But as already said, on none of my PCs they cause discontinuities in DVB streams (except in case of TBS USB devices, that seem to be prone to it). This may be different in PCs with modern (or notebook) CPUs that are possibly able to operate with even deeper C states.

 

Edited by Griga
addition
Link to comment
23 hours ago, Griga said:

The sub-group GUID is 501a4d13-42af-4429-9fd1-a8218c268e20, the setting GUID ee12f906-d277-404b-b6da-e5fa1a576df5, the possible values are 0 (no energy saving), 1 (medium), 2 (high).

You could also add this guid to that utility (0 - no energy saving). Of course, if you still intend to create this utility.

Link to comment

The minimum processor state (PROCESSOR_THROTTLE_MINIMUM) should also be regarded, in case discontinuities are caused by a CPU frequency that is too low. It determines how much the CPU frequency is allowed to drop as percent of the maximum frequency. 100% means the CPU is always running at full speed. This is the default value in the Windows high performance energy plan.

 

Altogether there are three possibilitis to intervene:

  • Idle demote/promote threshold plus maximum idle state for limiting the C state usage to C1.
  • Link state power management for switching PCIe power saving off.
  • Minimum processor state for limiting how low the CPU frequency can get.

However, it would not be appropriate to use all of them "just in case" in a DVBViewer/DMS "Disable energy saving on BDA tuner usage" option. The user has to try which measure avoids discontinuities and to select which one should be applied.

 

vor einer Stunde schrieb jirim100:

if you still intend to create this utility

 

All options mentioned here are available in the Windows advanced power settings, provided the idle demote/promote threshold and maximum idle state settings are made visible in the registry. So it could be enough to provide a .reg file that makes them visible, plus a tutorial that explains how tests must be performed.

 

Nevertheless a dedicated test tool would make it much easier. It could also transfer the setting(s) that proved to be successful to the setup.xml/service.xml or remove them from there. Writing such a tool is quite a job to do, though ;)

 

Link to comment
1 hour ago, Griga said:

The minimum processor state (PROCESSOR_THROTTLE_MINIMUM) should also be regarded,

Exist two these GUIDs: PROCESSOR_THROTTLE_MINIMUM and PROCESSOR_THROTTLE_MINIMUM_1 (for Processor Power Efficiency Class 1). From definition .h file:

Spoiler
//
// Specifies a percentage (between 0 and 100) that the processor frequency
// should not drop below.  For example, if this value is set to 50, then the
// processor frequency will never be throttled below 50 percent of its
// maximum frequency by the system.
//
// {893dee8e-2bef-41e0-89c6-b55d0929964c}
//
DEFINE_GUID( GUID_PROCESSOR_THROTTLE_MINIMUM, 0x893DEE8E, 0x2BEF, 0x41E0, 0x89, 0xC6, 0xB5, 0x5D, 0x09, 0x29, 0x96, 0x4C );

//
// Specifies a percentage (between 0 and 100) that the processor frequency
// should not drop below for Processor Power Efficiency Class 1.
// For example, if this value is set to 50, then the processor frequency will
// never be throttled below 50 percent of its maximum frequency by the system.
//
// {893dee8e-2bef-41e0-89c6-b55d0929964d}
//
DEFINE_GUID( GUID_PROCESSOR_THROTTLE_MINIMUM_1, 0x893DEE8E, 0x2BEF, 0x41E0, 0x89, 0xC6, 0xB5, 0x5D, 0x09, 0x29, 0x96, 0x4D );

 

 

In my Windows High performance power plan is PROCESSOR_THROTTLE_MINIMUM set to 5% and PROCESSOR_THROTTLE_MINIMUM_1 set to 100%. I don't know what the difference is between them.

Link to comment
vor 18 Stunden schrieb jirim100:

In my Windows High performance power plan is PROCESSOR_THROTTLE_MINIMUM set to 5% and PROCESSOR_THROTTLE_MINIMUM_1 set to 100%.

 

Looks like PROCESSOR_THROTTLE_MINIMUM_1 should be used, if available. However, it is also present in my PC, but hidden. In the high performance power plan both values are 100%.

 

Anyway, the whole thing becomes shoreless... the powercfg /Qh output fills 1420 lines of text here.

 

Link to comment
3 hours ago, Griga said:

Anyway, the whole thing becomes shoreless...

No, only GUIDs which we mentioned in this discussion.

Link to comment
  • 2 weeks later...

Just for concluding this topic:

 

I will not do something about it now in DVBViewer/DMS, because the benefit-cost-ratio is too low. There are only three known cases, each one with a different energy saving measure causing discontinuities. On the other side there are too many potential and partly unexplored possibilities that would have to be handled in DVBViewer, DMS and an additional tool, particularly for up-to-date CPUs like AMD Ryzen. It would finally come down to duplicating several Windows energy options for a special purpose.

 

Anyway, it was quite instructive to explore how modern CPUs put energy saving into effect and how it is exposed in the Windows energy options. I'm sure gaining more knowledge about it will pay off. Maybe I will come back later to the idea of handling it in one or the other way in DVBViewer/DMS.

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...