DUMO drivers` Beta Versions / Undue notifications

[scheff]

don`t want to torture you with questions anymore but always thought that comparing is plain simple - name and version and maybe company as an option... what algorithm u talk about makes me wonder

Your thinking about comparing is naive because you don't want to know if 2 versions are different. You want to know which one is newer for your hardware. This does not always imply higher version numbers!

There are various versioning schemes in the public. Including different manners of driver publishers to handle limitations in versioning schemes of operating systems. One among the most complicated ones to has been referred in another post [https://www.kcsoftwares.com/forum/viewt ... 1464#p3418] of another threat in this forum and is used by Intel.

And drivers usually handle hardware. So there cases that newer versions of a driver exist but are not for your hardware only for hardware of a younger hardware family upgrade with ending support of your older hardware. So in such a case you may have the latest version of the driver which still supports your hardware version even though a newer driver exists for a newer hardware version!

[Kyle_Katarn]

Right !

[scheff]

Hi necros,

don't understand your post. Doesn't sound like native speaker. I'm neither. As you clarify, I assume direct improvement proposals may result. That's why I reply in the form of a reply-post.

do you update your db with direct official software`s sites new version info, or just users submitted data

Indeed I can't find much documentation for the working of DUMo. The software provides a hint that it seems working similarly as SUMo by the button to each other as does the similarity in naming. Although also limited there exists significantly more documentation on SUMo. Accordingly Kyle already answered the latter. And his reply has different meanings.

In contrast to SUMo, I've just seen a few manual user reports for fixing missing or false updates. Nevertheless obviously not all claims of available updates reported by DUMo are correct. It's worth investigating. I already found and reported two reasons accepted into a feature request (not yet implemented) and I'm sure there are more reasons. The standard means for updating the database is not user intervention but the data sent by the local DUMo to the database server when querying if an update exists for that driver detected locally for that operating system. That's also user data but not data the user enters or sends. It's data that the locally running DUMo software automatically sends as long as there are no network problems resp. limitations.

What do you mean by "direct official software's sites new version info"?
Which of these words refers to which other?

Obviously, DUMo uses the software version info of a locally detected driver if there exists one. DUMo usually assumes local drivers as official. Usually a version info of a driver doesn't change without a change of the driver. So an unmodified driver usually doesn't alter its version info and hence there does not exist a new version info for the same driver. An update of that driver results into a new driver with usually a new version info. Do you refer to this change due to local update usually either via Windows Update or by OEM update service?

To which word do you refer in your expression by direct?

What do you mean by official and to does this word relate to any resp. which other word in your expression?

I consider a release declaration and decision by the device manufacturer as official for a given driver. But not always does the device manufacturer also develop or publish one or several drivers for its devices. And sometimes you'll find a community of open source developers developing and releasing drivers as well as original equipment manufacturers (OEM) for the same device with their own official release process, decision and declaration. That's not less official. And the OEM may decide to certify every driver version, some driver versions or no driver versions for one or several Windows operating systems by Microsoft (WHQL certification). Which of these driver versions do you consider official?

The business reality for drivers is even more complicated. I'm writing these lines on a computer with an Intel CPU with integrated graphics GPU and NO dedicated GPU in addition on the main board. It is

• Windows Update service,
• (large computer manufacturer) system integrator OEM support assistant service,
• device OEM (in this case Intel) driver and support assistant service, and
• DUMo service and
• another commercial driver update tool

checking for available updates for this integrated Intel GPU on the Intel CPU. Often they differ in their results on the integrated Intel GPU. Which report and claim do you consider official?
Which report and claim do you consider direct?
And to which version info of the installed and the claimed available driver for that integrated Intel GPU do you refer?

I tell you what each of them consider:
Windows Update service claims the installed driver Intel GPU driver up to date. It does not mention that there exist more recent Intel GPU official drivers for this CPU/GPU combination. The same applies for the computer manufacturer which integrated the system and its support assistant service. The Intel driver and support assistant also claims it up to date and doesn't report available driver updates released by Intel at the standard reporting level. When one year old versions of Intel driver and support assistant were actual, they reported differently even at this level, mentioning the released update by Intel and nevertheless refusing to update and even warning against update with the officially released driver by Intel! The current version of Intel driver and support assistant still has the same information, hidden more deeply. This assistant reports installed and available driver version. If you query this information in that report of this assistant, it provides further details, providing the same information as the former assistant version that there exists an officially released driver update by Intel and warns against updating because the driver installed is detected by the assistant as officially adapted by the original system integrator. This adaptation may be for performance reasons, thermal reasons, power reasons or other. That's one of the reasons why notebooks with same CPU, chipset and several other common components still differ widely in their power consumption. Then Intel driver and support assistant allows even query of further information on this device (GPU). This opens a deep link onto the corresponding release announcement with available update, release information, system requirements, variations and so on for this GPU as well as references to different driver versions and their release informations. DUMo and the other commercial driver update tool both report the available update without providing the warning that Intel as OEM provides. All four are right, all relying on official information. In the past I experience that this large system integrator doesn't seem to provide any updates anymore after two years for another device of the consumer product line and still provides updates for this business line product, taking between two and nine months after Intel releases its driver update. The last update by the system integrator for the GPU was in the last quarter of last year. So all support tools were in sync with up to date for 6-8 weeks. Since, Intel released two further updates while the system integrator did not yet. And concerning the version information, I found it difficult to relate installed version to reported version information as even Intel support assistant uses seamingly different version informations due to device dependency in its product family and release policy. You'll find an explanation in a corresponding SUMo forum post by another user with deeper knowledge of this relationship for Intel driver version and version reporting.

Reality is not quite as simple as the case of Intel above. On the same notebook there are devices onboard where the large device manufacturers claim not to release drivers as they do not do system integration. They claim instead that it's the task of the system integrators to release drivers and that the device manufacturer provide device details, support packages and development kits to these system integrators. For some of them, DUMo reports available updates. I don't have the DUMo Pro. But probably for some of these manufacturers even DUMo Pro provides either a Google search query or a link to the manufacturer home page, not a deep link into the manufacturers support section of its site. Knowing the variety of similar devices of the manufacturer, I probably don't want to update such drivers as long as not provided by the system integrator. So even in DUMo Pro I wouldn't want DUMo to automatically update the corresponding driver. DUMo Pro provides a corresponding configuration option. DUMo and the other commercial driver update tool don't. DUMo let's me execute the Google query without doing any harm and the other tool would automatically update the driver in the professional version of that tool. I've their professional version of the tool on one device, the basic one on another device. I contacted their support with their promise of 24 hour unto a support reaction. But it's now more than 10 days without any reaction. And they have a larger user base and larger driver database than DUMo. So market share does not relate to quality. DUMo detect much less drivers than Windows and than this other commercial driver update tool. But DUMo let's me decide what to do with the report results and doesn't force me into the danger of broken system. And Windows doesn't provide such information nor configuration option and is also more careful on updates than this other commercial driver update tool.

So what's the meaning of "site" in your expression above, especially in such cases where such manufacturers don't distribute to consumers but to system integrators only instead?

According to my understanding software including driver can and should carry version information. And I see that this version information does not necessarily differ between device OEM and system integrator OEM even if the latter is an adapted one based on the former one. So how does DUMo handle such a situation and how should it?

I didn't check what how Intel driver and support assistant detected the adaptation by the system integrator. I can only guess that the driver carries the same version info but with digital signature by the authorized system integrator instead of device manufacturer or unauthorized third party.

And I don't see any version information on device manufactures web sites. When I see version information then it is inside software including drivers and can be queried by the operating system and its management tools. For several device manufacturers I see release announcements for drivers often including a subset of the version information in the driver, but including other information like device dependency, operating system dependency and other requirements. Even if a web site has its own version information, this is not directly related to these driver release announcements nor to the driver version information.

do you update your db with direct official software`s sites new version info, or just users submitted data, if not sumo would be more up to date informer if such auto scripts which check sites will be implemented.

To what kind of auto scripts do you refer?
I don't know such things neither in DUMo nor SUMo.

A consequence of the above described variety of drivers, I don't see a generic method for improving DUMo detection and reporting in a uniform manner. Only for a subset of drivers, it seems possible to do so.

• Does DUMo or DUMo database server check its findings with Microsoft WHQL certification before deciding or handling on database updates?
• What's the relation of considering drivers in beta state if some versions for a given device are WHQL certified while other driver versions are not, even if such checks with WHQL are implemented?

[scheff]

In another post for SUMo, I already asked for the knowledge of user base in the context of undue beta version reporting. But for DUMo that's relevant too.

As far as I know, I don't have neither alpha not beta nor pilot drivers installed. I've the latest release of the operating system installed, not the release candidate which is now more or less released but with rollout still pending, expected by the end of this month. I know that device manufacturer already released driver updates so that their drivers will not block the coming operating system update. Those released driver updates are already installed on my device as far as I know.

Nevertheless I see that there are probably several hundred drivers installed on my system and reported by Windows management tools, not in a list but in several tree like reports. Another driver update tool reports largely more than 100 and largely less than 200 for my system. DUMo reports just a little bit less than 50 drivers. Out of those drivers, almost 10 carry the same version info trunk then the operating system. One third of them DUMo reportes as up to date, one it reports an available update seemingly with a pilot version information of Windows 10 20H1 expected to be released in spring 2020 and the rest with the trunk of the coming operating system update not yet rolled out outside the larger beta test ring. This pilot version trunk corresponds to the April 2019 pilot, none with a version trunk of the May 2019 pilot of a few days ago. So this makes it interesting how many DUMo users are beta testers and why this influences so much DUMo reporting!

For the driver update to the claimed availability of Windows 10 20H1 pilot version, DUMo database reports me almost 60 DUMo users or devices with this device and driver, 5% with the pilot version claimed current by the database (instead of beta or pilot), 7% with the release candidate version of the upcoming operating system update, almost 3/4 with the current operating system release, most others still with the preceeding operating system release of a year ago and 1 DUMo user with the first release of the operating system (already unsupported), none with intermediate versions. This data is not representative as it does only consider DUMo users with the same CPU and the same operating system (independant of release version). So for this subset, about 12% use driver in beta or pilot state and a bit more have either not executed or not finished executing Windows Update yet. You can conclude that more than 10% with the preceeding operating system version either have their Internet conncetion time so limited in the past months that Windows Update could not finish or are users with any professional edition of the operating system and actively configured significant delay for feature update.

Has KC Softwares any further analysis of DUMo user base concerning beta versions and the impact of these users on the database update algorithm?

[Kyle_Katarn]

DUMo having much less users than SUMo does, and having to take into account OS-specific version computation, server algorithm still need some tuning to reach the high level of accuracy of SUMo. Having more DUMo users would help, but i'll definitively work on server side too !

[scheff]

I don't really understand, probably as I didn't ask enough about DUMo user base.

How are the size of user base calculated for SUMo and for DUMo so that you can compare?

You can't know how many users use these tools always offline for inventory purposes instead for update management purposes as they're available for download via various channels outside of your control.

Then you've the users with Internet connection using it irregularly for some kind of update management with only a minority using the Pro editions. So you don't know on how many devices a single user has installed these tools. Do you count every device as user without associating them to real users or do you try to group them to real users?

I'm in favor of counting devices instead of users as the latter cannot be accurate for users which don't run the Pro version nor use the SUMo Online feature. And even with the Pro version you mentioned a marketing case resulting in lack of such association. So counting devices seems accurate while other abstractions can only be indicative and much more unreliable.

Other users already wrote in their forum posts that they have installed multiple editions and versions installed on the same device in a side-by-side manner. Do you count such installations as one device or as many devices as there are installations?

Coming to number SUMo reports me having 2085 devices reporting it installed and 316 having also installed DUMo. DUMo reports me that 3218 devices have running DUMo and Intel Management Engine installed. This does not include users running DUMo with a processor with no need nor support of Intel Management Engine, like Intel processor before introducing such a hardware feature, an AMD or an embedded processor without such an interface. So according to my understanding it seems that your user base of DUMo is larger than your user base of SUMo. It further seems that users using both tools is a considerable minority. What's wrong with my understanding as you claim that the user base of SUMo is much larger than the user base of DUMo?

And how do you count devices on your servers?
I know that you generate a random user number and store it there and locally. But when do you drop this count?
Is there a time limit like 1, 3, 6 or 12 months, that device entries are removed from the count if they didn't connect to the server within this time frame?
Is such a count dropped if a user decides to uninstall the tool and has an Internet connection in order to being able to communicate reasons and inform the server?

[Kyle_Katarn]

"2085" for SUMo is not exactly the user count.... it's the current "buffer" of datum used for the current version computation. See it more like a sliding window based on the last distinct version update request from SUMo users.
I'll remove the "user count" mention, which leads to such confusion.

As a conclusion, only "%" are truly meaningful.

[scheff]

I still don't understand as too few information is yet provided.

See it more like a sliding window based on the last distinct version update request from SUMo users.

I understand your words but can't understand without further information.

I've never seen that term last distinct version update request from SUMo users before. Current version is an evaluation on SUMo server, not on SUMo client. So it relates not directly to version update availability reporting on the side of SUMo clients. If I understand this expression right, it ignores almost all requests of SUMo users unless SUMo found a software version on the client side not yet reported to the server before. So this does also ignore SUMo users requests revealing that for a considered and detected tool the highest version of that user is lower than the highest version already reported by previous SUMo user requests of different SUMo users. Did I understand this right so far?

And of which sliding window are you refering to?
I already asked if it means something like the most recent 1, 3, 6 or 12 months, with no reply yet?

"2085" for SUMo is not exactly the user count.... it's the current "buffer" of datum used for the current version computation. See it more like a sliding window based on the last distinct version update request from SUMo users.

I don't yet understand how these two sentences relate to each other and seems contradicting my understanding of what you wrote in another post in the SUMo forum as it does not take into account for moving the current flag how many SUMo users have the considered version of the considered tool installed nor how large the user base is.

I would have expected something like active users for each version reported within the last 12 months. Version update reports (not requests) by SUMo clients to SUMo server might be evaluated when to move one device from one version to another on the server side in order not to count a single device on several versions if that device updated its version several times within the time frame considered active. With some threshold I would have expected that the current flag may move when a certain level of active users have the highest version detected on their client device, regardless if via update or by users with fresh installation and no prior version installed before.

I'll remove the "user count" mention, which leads to such confusion.

As far as I understand, it is some kind of count or user count although not describing the number of active users not their version updates. But when it is some kind of internal buffer, why don't you move the display of this data to another view of accordingly authorized and identified users while supplying more interesting data for the public of active SUMo users. For those active SUMo users not removing the label but replacing the data by the count of active users is preferrable.

As a conclusion, only "%" are truly meaningful.

As written in other posts, I don't consider % as truly meaningful without providing the base. And due to the algorithm design for SUMo, this base usually becomes an indicator when % become meaningful instead of speculative.

[Kyle_Katarn]

OK, i'll see how to rework the pages to make this even clearer and at least as reliable as SUMo is today.

[DenalB]

Intel(R) Wi-Fi 6 AX200 160MHz

Installed driver: 22.40.0.7
Suggested driver: 22.50.1.1

https://www.kcsoftwares.com/dumo/view.p ... S=10.0&pro

But on Intel.com I only can find version 22.40.0.7.
https://downloadcenter.intel.com/produc ... AX200-Gig-

Maybe a beta driver?