What are the advantages and disadvantages of using the SMBIOS (as opposed to the PIT) for getting the external bus frequency in order to know what values to write into the local APIC timer?
It seems at first glance that the SMBIOS approach would provide greater accuracy. Perhaps a hybrid approach would be best in order to make sure the values from both are actually sane.
On a side note, is SMBIOS likely to be supported on all modern x86-64 systems (i.e, can I rely on it)?
SMBIOS for calibrating the local APIC timer
Re: SMBIOS for calibrating the local APIC timer
Hi,
It was never intended for any OS initialisation purposes (there are other standards/techniques that are designed for that, like ACPI). Using SMBIOS to determine local APIC's frequency (by making random assumptions like "local APIC frequency = bus frequency") is a little bit like using a hammer to spread jam on your toast even though a normal knife (that is the right tool for the job) is easier to find than a hammer.
Of course even for its intended purpose SMBIOS is relatively awful (e.g. provides no information on anything that isn't built into the motherboard, suffers from "design by committee" problems, etc), and because it's only really used by large companies the information it provides is often dodgy anyway (especially for cheap/home/gamer systems that aren't used by large companies).
Cheers,
Brendan
Imagine you're maintaining a network of many computers, the accountancy department wants various information (for insurance purposes, etc), you want to keep relevant spare parts in storage, and sometimes you want to know what is in each computer on the network (to order replacement parts and upgrade parts) without actually finding the computer and walking all over a large building to where the computer might be. You might have tools built into the OS on every computer to provide the information, network protocols (CIM, WBEM, SNMP) and an application or database somewhere. This is what SMBIOS is intended for - to provide information to an asset management system.hexcoder wrote:What are the advantages and disadvantages of using the SMBIOS (as opposed to the PIT) for getting the external bus frequency in order to know what values to write into the local APIC timer?
It seems at first glance that the SMBIOS approach would provide greater accuracy. Perhaps a hybrid approach would be best in order to make sure the values from both are actually sane.
It was never intended for any OS initialisation purposes (there are other standards/techniques that are designed for that, like ACPI). Using SMBIOS to determine local APIC's frequency (by making random assumptions like "local APIC frequency = bus frequency") is a little bit like using a hammer to spread jam on your toast even though a normal knife (that is the right tool for the job) is easier to find than a hammer.
Of course even for its intended purpose SMBIOS is relatively awful (e.g. provides no information on anything that isn't built into the motherboard, suffers from "design by committee" problems, etc), and because it's only really used by large companies the information it provides is often dodgy anyway (especially for cheap/home/gamer systems that aren't used by large companies).
It's very likely that it will exist on all "PC compatible" 80x86 computers made in the last 20 years or so (but "exists" isn't quite the same as "reliable").hexcoder wrote:On a side note, is SMBIOS likely to be supported on all modern x86-64 systems (i.e, can I rely on it)?
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Re: SMBIOS for calibrating the local APIC timer
Okay, thanks for the information.
Guess I'll just use the PIT then. I was just hoping for a more 'accurate' method, but I suppose this'll do. I'll also update the wiki to emphasise what you said.
Guess I'll just use the PIT then. I was just hoping for a more 'accurate' method, but I suppose this'll do. I'll also update the wiki to emphasise what you said.