Getting a unique id from a ChromeOS machine

[asharif]

I noticed that running "hostid" on a ChromeOS machine seems to always return the same string. Is there a way to get a unique ID from a ChromeOS machine which would persist across re-imaging, etc.?

[Bill Richardson]

No.

On Mon, Nov 5, 2012 at 3:26 PM, asharif <ash...@chromium.org> wrote:

I noticed that running "hostid" on a ChromeOS machine seems to always return the same string. Is there a way to get a unique ID from a ChromeOS machine which would persist across re-imaging, etc.?

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en
 
 
 

--

Art for Art's Sake

Engineering for Money

[Luigi Semenzato]

Bill is being short here because this is something we avoid for
privacy issues. However, it cannot be helped that the wifi hardware
has a unique MAC address.

[Chris Masone]

You must never, ever use such an identifier in any data that is sent to any server anywhere.  It's best to avoid using such a thing in the internals of your code to avoid even the accidental disclosure of such information.  Our users' trust is everything, and we take their privacy extremely seriously.

If you think you require such an identifer in your code, please forward your design doc to chromeos-security@ and the team will help you engineer around that requirement.

[Chris Sosa]

Well what's it for? Given previous discussions from asharif he might want to add something on his own Chromium OS test or developer images he's creating and running in his own environment and he doesn't want to duplicate something that already exists.

-Sosa

[asharif]

It's a long story, but this isn't going into any product that will be on a ChromeOS image.

The toolchain team does a lot of autotests, and we have a tool built on top of run_remote_tests.sh, etc. that runs autotests and stores the results locally (in your home drive). These are then used for doing incremental runs (like you specify 10 iterations of BootPerfServer... oops it's too noisy, so let's do 20 re-using the old 10).

Earlier we thought that as long as the CPU and memory of the target machine matched, we could re-use the stored runs for doing incremental testing, but we were wrong. We have observed some machine-to-machine variation (which is bad news because the changes we are testing cause a very small change in performance).

So now when we store the autotests, we plan to store the hwid with the result so it will only be re-used when the machine hwids match. This will allow us to do incremental testing without worrying about using results that were run on a different machine.

[Chris Masone]

On Tue, Nov 6, 2012 at 11:05 AM, asharif <ash...@chromium.org> wrote:

It's a long story, but this isn't going into any product that will be on a ChromeOS image.

The toolchain team does a lot of autotests, and we have a tool built on top of run_remote_tests.sh, etc. that runs autotests and stores the results locally (in your home drive). These are then used for doing incremental runs (like you specify 10 iterations of BootPerfServer... oops it's too noisy, so let's do 20 re-using the old 10).

Earlier we thought that as long as the CPU and memory of the target machine matched, we could re-use the stored runs for doing incremental testing, but we were wrong. We have observed some machine-to-machine variation (which is bad news because the changes we are testing cause a very small change in performance).

Did you root cause that?  That seems like it'd be a fundamental problem.

[asharif]

On Tue, Nov 6, 2012 at 11:08 AM, Chris Masone <cma...@chromium.org> wrote:

On Tue, Nov 6, 2012 at 11:05 AM, asharif <ash...@chromium.org> wrote:

It's a long story, but this isn't going into any product that will be on a ChromeOS image.

The toolchain team does a lot of autotests, and we have a tool built on top of run_remote_tests.sh, etc. that runs autotests and stores the results locally (in your home drive). These are then used for doing incremental runs (like you specify 10 iterations of BootPerfServer... oops it's too noisy, so let's do 20 re-using the old 10).

Earlier we thought that as long as the CPU and memory of the target machine matched, we could re-use the stored runs for doing incremental testing, but we were wrong. We have observed some machine-to-machine variation (which is bad news because the changes we are testing cause a very small change in performance).

Did you root cause that?  That seems like it'd be a fundamental problem.

+cc: glotov@ who was using our tool and observed this variation.

No, I did not root cause it. When we roll out the hwid feature, we can do more thorough experiments to confirm the machine-to-machine variation.

[Denis Glotov]

My case is simple. I have 2 alex devices: one is Alex proto, another is production Alex. CPU and memory size is the same. But bootperf metrics seems to be slightly different. Maybe it is caused by different firmware.

--
Thank you,
Denis

[Chris Masone]

Why is anyone spending time running performance tests on heterogeneous hardware?  It sounds like the right solution is to have a pool of homogeneous devices and skip the HWID/MAC stuff

[Chris Masone]

On Tue, Nov 6, 2012 at 12:39 PM, Richard Barnette <jrbar...@google.com> wrote:

On Nov 6, 2012, at 12:11 PM, Denis Glotov wrote:

> My case is simple. I have 2 alex devices: one is Alex proto, another is production Alex. CPU and memory size is the same. But bootperf metrics seems to be slightly different. Maybe it is caused by different firmware.
>

Some of the early Alex units had a slower clock speed than later
units.  There may have been other CPU differences, too.  Also,
different Alex SKUs have different 3G modems, which have been
suspected in affecting boot time.

Basically, for performance purposes, two units are different if they
have a different SKU, even if they look like the same model.

Regrettably,  I think deriving the SKU from the hardware can be
hard.  In general, a different SKU has a different HWID; unfortunately
there are lots of different HWID values for any single SKU, so you
can't easily use HWID to tell whether two units are truly different.
You might be better off just taking an inventory of the observable
hardware, including CPU, network devices,  3G modem, memory
size, and storage type.

Of course, if your pool of systems is small enough that you don't think
there's much, if any, duplication, an identifier like serial number would
be a simpler answer.

Wouldn't getting a pool of homogeneous hardware be the simplest answer?

 

-- jrb
Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.
    Samuel Beckett - "Worstward Ho"

[asharif]

On Tue, Nov 6, 2012 at 12:41 PM, Chris Masone <cma...@chromium.org> wrote:

On Tue, Nov 6, 2012 at 12:39 PM, Richard Barnette <jrbar...@google.com> wrote:

On Nov 6, 2012, at 12:11 PM, Denis Glotov wrote:

> My case is simple. I have 2 alex devices: one is Alex proto, another is production Alex. CPU and memory size is the same. But bootperf metrics seems to be slightly different. Maybe it is caused by different firmware.
>

Some of the early Alex units had a slower clock speed than later
units.  There may have been other CPU differences, too.  Also,
different Alex SKUs have different 3G modems, which have been
suspected in affecting boot time.

Basically, for performance purposes, two units are different if they
have a different SKU, even if they look like the same model.

Regrettably,  I think deriving the SKU from the hardware can be
hard.  In general, a different SKU has a different HWID; unfortunately
there are lots of different HWID values for any single SKU, so you
can't easily use HWID to tell whether two units are truly different.
You might be better off just taking an inventory of the observable
hardware, including CPU, network devices,  3G modem, memory
size, and storage type.

Of course, if your pool of systems is small enough that you don't think
there's much, if any, duplication, an identifier like serial number would
be a simpler answer.

Wouldn't getting a pool of homogeneous hardware be the simplest answer?

It's simpler than using HWID, etc. but homogenized hardware may not have the same performance results. This is something no one has investigated and I suspect we will see differences across machines.

[Chris Masone]

On Tue, Nov 6, 2012 at 1:02 PM, asharif <ash...@chromium.org> wrote:

On Tue, Nov 6, 2012 at 12:41 PM, Chris Masone <cma...@chromium.org> wrote:

On Tue, Nov 6, 2012 at 12:39 PM, Richard Barnette <jrbar...@google.com> wrote:

On Nov 6, 2012, at 12:11 PM, Denis Glotov wrote:

> My case is simple. I have 2 alex devices: one is Alex proto, another is production Alex. CPU and memory size is the same. But bootperf metrics seems to be slightly different. Maybe it is caused by different firmware.
>

Some of the early Alex units had a slower clock speed than later
units.  There may have been other CPU differences, too.  Also,
different Alex SKUs have different 3G modems, which have been
suspected in affecting boot time.

Basically, for performance purposes, two units are different if they
have a different SKU, even if they look like the same model.

Regrettably,  I think deriving the SKU from the hardware can be
hard.  In general, a different SKU has a different HWID; unfortunately
there are lots of different HWID values for any single SKU, so you
can't easily use HWID to tell whether two units are truly different.
You might be better off just taking an inventory of the observable
hardware, including CPU, network devices,  3G modem, memory
size, and storage type.

Of course, if your pool of systems is small enough that you don't think
there's much, if any, duplication, an identifier like serial number would
be a simpler answer.

Wouldn't getting a pool of homogeneous hardware be the simplest answer?

It's simpler than using HWID, etc. but homogenized hardware may not have the same performance results. This is something no one has investigated and I suspect we will see differences across machines.

 

In this thread, what's been discussed is that someone's using a prototype device and an MP device and getting different results.  It sounds like you haven't tried using a pool entirely made up of MP devices, or at least you have not indicated that you have.  Wouldn't it make sense to characterize that, first, as that's what our users have?