VS 2010 Switch

[JP Rosevear]

Hi,

There are two motivators to switch to VS2010 these days:
1) General browser performance improvements
2) Installed on 64 bit builders so we can access 4GB of virtual memory
for PGO on our 32bit builds

The main downside for switching to VS2010 has been that we will need to
drop support for Win2k, XP RTM and XP SP1. We'd be doing this with
16-18 weeks of notice.

We could get the benefits of 2) by rolling out VS2005 on the 64bit
builders, this could take some time (I'll let releng chime in here).

We could also just switch to VS2010 starting tomorrow, assuming Asa
doesn't find any data contrary to this today. The benefit is we start
shaking down the compiler. The downside is that as we collect the AUS
pings through the FF9 launch over the next couple of weeks, we may find
the Win2k, XP RTM and XP SP1 numbers to be too high to drop. If we work
out something with MS we still may be able to get support, otherwise we
may have to go back to VS2005, causing some churn. We are not in a
position to build in parallel on VS2010 and VS2005 to mitigate this.

If we are going to switch to VS2010 I think its best to turn it on
tomorrow to maximize testing of the compiler in the FF12 cycle.
Thoughts?

Thanks,

-JP
--
JP Rosevear <j...@mozilla.com>
Mozilla

[John Hopkins]

On 11-12-20 04:27 PM, JP Rosevear wrote:
> Hi,
>
> There are two motivators to switch to VS2010 these days:
> 1) General browser performance improvements
> 2) Installed on 64 bit builders so we can access 4GB of virtual memory
> for PGO on our 32bit builds
>
> The main downside for switching to VS2010 has been that we will need to
> drop support for Win2k, XP RTM and XP SP1. We'd be doing this with
> 16-18 weeks of notice.

I'd personally like to see users running Win2k, XP RTM and XP SP1
presented with a dialog or tab that tells them they're on an unsupported
platform and lets them know what they can do about it. If I'm not
mistaken, the current UX is that the user would never again receive an
update and wouldn't be aware of the cause.

By presenting these users with these instructions, we could keep more
people on the latest Firefox instead of having to let them all stagnate.

This would require some client-side intelligence (the user-agent string
doesn't contain all the necessary info) so we'd need to ship a
compatible update containing this logic before ending support.

John

[Kyle Huey]

>
> If we are going to switch to VS2010 I think its best to turn it on
> tomorrow to maximize testing of the compiler in the FF12 cycle.
> Thoughts?
>

As you might know, I'm a booster of moving to VS 2010 ;-). I support this,
with one caveat:

The longer trunk is built with 2010, the more risky reverting will become.
We have some patches that we know work only with 2010 (e.g. bz's selector
parallelization patches) and we probably have some more that we don't know
work only with 2010. Since we don't have the bandwidth to maintain builds
and tests in parallel we'll be effectively blind on these issues until we
need to revert. Because of this, I think we should only pull this trigger
if we're reasonably confident that we won't need to roll back the compiler.

- Kyle

[Ehsan Akhgari]

Just out of curiosity, what causes those patches to require VS 2010?

--
Ehsan
<http://ehsanakhgari.org/>

> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>

[Kyle Huey]

On Tue, Dec 20, 2011 at 6:48 PM, Ehsan Akhgari <ehsan....@gmail.com>wrote:

> Just out of curiosity, what causes those patches to require VS 2010?
>

Boris can add details (if he's not on holiday yet) but they hit an internal
compiler error on 2005 that they don't on 2010. I believe he tried to
rework the relevant part of the patch without success.

- Kyle

[James May]

There's also an effort underway to patch the VS2010 CRT to run on
SP1/RTM/2k. I don't think there's a bug on file.

IIRC there's only two missing function.

On 21 December 2011 08:27, JP Rosevear <j...@mozilla.com> wrote:

> Hi,
>
> There are two motivators to switch to VS2010 these days:
> 1) General browser performance improvements
> 2) Installed on 64 bit builders so we can access 4GB of virtual memory
> for PGO on our 32bit builds
>
> The main downside for switching to VS2010 has been that we will need to
> drop support for Win2k, XP RTM and XP SP1. We'd be doing this with
> 16-18 weeks of notice.
>

> We could get the benefits of 2) by rolling out VS2005 on the 64bit
> builders, this could take some time (I'll let releng chime in here).
>
> We could also just switch to VS2010 starting tomorrow, assuming Asa
> doesn't find any data contrary to this today. The benefit is we start
> shaking down the compiler. The downside is that as we collect the AUS
> pings through the FF9 launch over the next couple of weeks, we may find
> the Win2k, XP RTM and XP SP1 numbers to be too high to drop. If we work
> out something with MS we still may be able to get support, otherwise we
> may have to go back to VS2005, causing some churn. We are not in a
> position to build in parallel on VS2010 and VS2005 to mitigate this.
>

> If we are going to switch to VS2010 I think its best to turn it on
> tomorrow to maximize testing of the compiler in the FF12 cycle.
> Thoughts?
>

> Thanks,
>
> -JP
> --
> JP Rosevear <j...@mozilla.com>
> Mozilla
>

[Brian Smith]

JP Rosevear wrote:
> We could also just switch to VS2010 starting tomorrow, assuming Asa
> doesn't find any data contrary to this today. The benefit is we start
> shaking down the compiler. The downside is that as we collect the AUS
> pings through the FF9 launch over the next couple of weeks, we may
> find the Win2k, XP RTM and XP SP1 numbers to be too high to drop.

There is another potential disadvantage: we may find some (non-obvious) bug that only occurs when built with VS2010, but not find it for a long time. I just read a comment today on reddit or news.yc that said Google has not been able to switch to VS2010 because of some bug(s). I don't know how hard they tried or if that report is accurate.

IMO, it would be best to have, at least, VS2010 and VS2005 builds built side-by-side on try and mozilla-central for a while before and after we decide to make the switch.

- Brian

[Not comprehensive]
http://code.google.com/p/chromium/issues/detail?id=107864
http://code.google.com/p/chromium/issues/detail?id=106215
http://code.google.com/p/chromium/issues/detail?id=98260
http://code.google.com/p/chromium/issues/detail?id=97534
http://code.google.com/p/chromium/issues/detail?id=63479
https://groups.google.com/group/gyp-developer/browse_thread/thread/e42c26493bbc525d#
https://connect.microsoft.com/VisualStudio/feedback/details/690486/use-library-dependency-inputs-does-not-respect-link-library-dependency-flag

[Kyle Huey]

On Tue, Dec 20, 2011 at 9:02 PM, Brian Smith <bsm...@mozilla.com> wrote:

> http://code.google.com/p/chromium/issues/detail?id=107864
> http://code.google.com/p/chromium/issues/detail?id=106215
> http://code.google.com/p/chromium/issues/detail?id=98260
> http://code.google.com/p/chromium/issues/detail?id=97534
> http://code.google.com/p/chromium/issues/detail?id=63479
>
> https://groups.google.com/group/gyp-developer/browse_thread/thread/e42c26493bbc525d#
>
> https://connect.microsoft.com/VisualStudio/feedback/details/690486/use-library-dependency-inputs-does-not-respect-link-library-dependency-flag
>

Of these, I think only the second is potentially relevant to us. We don't
use MSBuild or Visual Studio Projects so we will not be affected by those
issues, and it's not at all clear to me that 107864 has anything to do with
the compiler.

Certainly the potential for weird bugs is there, but that potential is
going to exist whenever we move, and we will have to move eventually.

- Kyle

[Ehsan Akhgari]

Patching the CRT is easier said than done since we do not have access to
CRT build scripts. Also, there are more than 2 functions used by the CRT
which are missing from the kernel32.dll shipping with Windows 2000.

Cheers,
Ehsan

On Dec 20, 2011 8:24 PM, "James May" <mo...@fowlsmurf.net> wrote:

> There's also an effort underway to patch the VS2010 CRT to run on
> SP1/RTM/2k. I don't think there's a bug on file.
>
> IIRC there's only two missing function.
>
> On 21 December 2011 08:27, JP Rosevear <j...@mozilla.com> wrote:
>
> > Hi,
> >
> > There are two motivators to switch to VS2010 these days:
> > 1) General browser performance improvements
> > 2) Installed on 64 bit builders so we can access 4GB of virtual memory
> > for PGO on our 32bit builds
> >
> > The main downside for switching to VS2010 has been that we will need to
> > drop support for Win2k, XP RTM and XP SP1. We'd be doing this with
> > 16-18 weeks of notice.
> >
> > We could get the benefits of 2) by rolling out VS2005 on the 64bit
> > builders, this could take some time (I'll let releng chime in here).
> >

> > We could also just switch to VS2010 starting tomorrow, assuming Asa
> > doesn't find any data contrary to this today. The benefit is we start
> > shaking down the compiler. The downside is that as we collect the AUS
> > pings through the FF9 launch over the next couple of weeks, we may find

[JP Rosevear]

On Tue, 2011-12-20 at 18:12 -0500, John Hopkins wrote:

> On 11-12-20 04:27 PM, JP Rosevear wrote:
> > Hi,
> >
> > There are two motivators to switch to VS2010 these days:
> > 1) General browser performance improvements
> > 2) Installed on 64 bit builders so we can access 4GB of virtual memory
> > for PGO on our 32bit builds
> >
> > The main downside for switching to VS2010 has been that we will need to
> > drop support for Win2k, XP RTM and XP SP1. We'd be doing this with
> > 16-18 weeks of notice.
>

> I'd personally like to see users running Win2k, XP RTM and XP SP1
> presented with a dialog or tab that tells them they're on an unsupported
> platform and lets them know what they can do about it. If I'm not
> mistaken, the current UX is that the user would never again receive an
> update and wouldn't be aware of the cause.
>
> By presenting these users with these instructions, we could keep more
> people on the latest Firefox instead of having to let them all stagnate.
>
> This would require some client-side intelligence (the user-agent string
> doesn't contain all the necessary info) so we'd need to ship a
> compatible update containing this logic before ending support.

I wonder if we can use the hotfix extension to do this.

[Gervase Markham]

On 21/12/11 12:58, Ehsan Akhgari wrote:
> Patching the CRT is easier said than done since we do not have access to
> CRT build scripts. Also, there are more than 2 functions used by the CRT
> which are missing from the kernel32.dll shipping with Windows 2000.

I guess this is why it would be useful to get comparative numbers of W2K
vs XP-early-SP. I suspect the latter far outweighs the former, BICBW of
course.

If we could fix it by patching the CRT for early-XP only, I'd still
suggest that's a valid route to pursue.

Gerv

[Gervase Markham]

On 20/12/11 21:27, JP Rosevear wrote:
> The main downside for switching to VS2010 has been that we will need to
> drop support for Win2k, XP RTM and XP SP1.

One important point: users on Win2K are not in the same position as
users on XP RTM/SP1. Win2K users would need to upgrade OS (and pay, if
they wanted Windows again) to get the latest Firefox; users on XP
RTM/SP1 just need to install a long-ago-released, free-to-download,
Microsoft-supported service pack.

Given that, can we use some mechanism (start page? popup?) to educate
users about installing the service pack?

Gerv

[JP Rosevear]

On Tue, 2011-12-20 at 18:31 -0500, Kyle Huey wrote:
> If we are going to switch to VS2010 I think its best to turn
> it on
> tomorrow to maximize testing of the compiler in the FF12
> cycle.
> Thoughts?
>

> As you might know, I'm a booster of moving to VS 2010 ;-). I support
> this, with one caveat:
>
> The longer trunk is built with 2010, the more risky reverting will
> become. We have some patches that we know work only with 2010 (e.g.
> bz's selector parallelization patches) and we probably have some more
> that we don't know work only with 2010. Since we don't have the
> bandwidth to maintain builds and tests in parallel we'll be
> effectively blind on these issues until we need to revert. Because of
> this, I think we should only pull this trigger if we're reasonably
> confident that we won't need to roll back the compiler.

Its at least two weeks before we know about the potentially deprecated
OS, possibly 3. Is 3 weeks enough to get confidence in the new
compiler?

[Boris Zbarsky]

On 12/20/11 6:48 PM, Ehsan Akhgari wrote:
> Just out of curiosity, what causes those patches to require VS 2010?

Aa far as we can tell, VS 2005 just has some bug that we hit in the PGO
build with those patches. It ends up with an internal compiler error on
perfectly reasonable code (a call to the Init() method of a hashtable
member in the constructor of the class that contains that member).

-Boris

[Justin Lebar]

On Wed, Dec 21, 2011 at 7:58 AM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
> Patching the CRT is easier said than done since we do not have access to
> CRT build scripts.

Has anyone tried patching the VS 2005 build system to work with the
2010 sources?

> Also, there are more than 2 functions used by the CRT
> which are missing from the kernel32.dll shipping with Windows 2000.
>

> Cheers,
> Ehsan
> On Dec 20, 2011 8:24 PM, "James May" <mo...@fowlsmurf.net> wrote:
>
>> There's also an effort underway to patch the VS2010 CRT to run on
>> SP1/RTM/2k. I don't think there's a bug on file.
>>
>> IIRC there's only two missing function.
>>

>> On 21 December 2011 08:27, JP Rosevear <j...@mozilla.com> wrote:
>>
>> > Hi,
>> >
>> > There are two motivators to switch to VS2010 these days:
>> > 1) General browser performance improvements
>> > 2) Installed on 64 bit builders so we can access 4GB of virtual memory
>> > for PGO on our 32bit builds
>> >

>> > The main downside for switching to VS2010 has been that we will need to

>> > drop support for Win2k, XP RTM and XP SP1.  We'd be doing this with
>> > 16-18 weeks of notice.
>> >

>> > We could get the benefits of 2) by rolling out VS2005 on the 64bit
>> > builders, this could take some time (I'll let releng chime in here).
>> >
>> > We could also just switch to VS2010 starting tomorrow, assuming Asa
>> > doesn't find any data contrary to this today.  The benefit is we start
>> > shaking down the compiler.  The downside is that as we collect the AUS
>> > pings through the FF9 launch over the next couple of weeks, we may find
>> > the Win2k, XP RTM and XP SP1 numbers to be too high to drop.  If we work
>> > out something with MS we still may be able to get support, otherwise we
>> > may have to go back to VS2005, causing some churn.  We are not in a
>> > position to build in parallel on VS2010 and VS2005 to mitigate this.
>> >

>> > If we are going to switch to VS2010 I think its best to turn it on
>> > tomorrow to maximize testing of the compiler in the FF12 cycle.
>> > Thoughts?
>> >

>> > Thanks,

>> >
>> > -JP
>> > --
>> > JP Rosevear <j...@mozilla.com>
>> > Mozilla
>> >

[Bas Schouten]

On the subject of Windows 2000, it was end of lifed in July 2010[1], over one and a half year ago. That means there have not even been critical security updates for almost one and a half year. If someone is on Windows 2000, they're insecure anyway, with, or without browser updates. It might be sad they'll miss certain new features, but considering how insecure their OS is (I'm sure there have been some new RPC exploits since last year!) I think we'd be doing them a favor telling them to upgrade to some newer OS.

In support of what Gerv said, windows XP SP1 support was end of lifed in 2006[2], we'd be doing people a big favor I think, doing what Gerv suggested and educating them about (or even pushing them towards) more recent service packs.

Bas

[1] http://support.microsoft.com/lifecycle/?LN=en-us&x=15&y=17&c2=1131
[2] http://support.microsoft.com/lifecycle/?c2=1173

[Ted Mielczarek]

On Wed, Dec 21, 2011 at 11:01 AM, Justin Lebar <justin...@gmail.com> wrote:
> On Wed, Dec 21, 2011 at 7:58 AM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
>> Patching the CRT is easier said than done since we do not have access to
>> CRT build scripts.
>
> Has anyone tried patching the VS 2005 build system to work with the
> 2010 sources?

The CRT build system was a horrible nmake mess. Patching it even to do
what we needed for VS2005 was painful. Trying to build an unsupported
newer version seems like a nightmare. I can't see anyone signing up to
try that.

-Ted

[Brian Smith]

Bas Schouten wrote:
> In support of what Gerv said, windows XP SP1 support was end of lifed
> in 2006[2], we'd be doing people a big favor I think, doing what Gerv
> suggested and educating them about (or even pushing them towards) more
> recent service packs.

Some users may be purposefully avoiding SP2 and SP3.

See http://en.wikipedia.org/wiki/Windows_Genuine_Advantage#WGA_in_China

- Brian

[Frédéric Buclin]

Le 21. 12. 11 19:58, Brian Smith a écrit :

> Some users may be purposefully avoiding SP2 and SP3.
>
> See http://en.wikipedia.org/wiki/Windows_Genuine_Advantage#WGA_in_China

Wow, are you saying you want to take care of people using a pirated copy
of Windows? IMO, such users shouldn't be considered.

LpSolit

[Ehsan Akhgari]

Also, the CRT has quite a few additions between the two versions, so using
the old build system would not help even if it was a simple makefile.

--
Ehsan
<http://ehsanakhgari.org/>

[Alex Keybl]

I don't think we can say with any sort of confidence that these users were aware that they were purchasing an unlicensed copy of Windows when they bought their computers. Remember, in China people are many times unknowingly sold pirated software, which is in stark contrast to piracy-download culture of the US, for instance.

Regardless, I don't think that we should base our support on the possible illegitimacy of their Windows licenses. It should only be based upon regional 2000/XP SP1 usage, overall affected population, and engineering benefit.

-Alex

[Karl Tomlinson]

Frédéric Buclin writes:

> Wow, are you saying you want to take care of people using a pirated copy
> of Windows? IMO, such users shouldn't be considered.

Not necessarily. I can understand why many people don't want time
bomb software / antifeatures (whatever you want to call it) on
their computers. This particular form has a known false positive
rate. Potential users/subjects may be afraid of this or may not
know how to tell which "local or online retail store [they can]
know and trust".

[Asa Dotzler]

Yes. And we will be doing that.

- A

[John Hopkins]

> Yes. And we will be doing that.

https://bugzilla.mozilla.org/show_bug.cgi?id=684227

[Mike Hoye]

On 11-12-21 11:15 AM, Bas Schouten wrote:
> One important point: users on Win2K are not in the same position as
> users on XP RTM/SP1. Win2K users would need to upgrade OS (and pay, if
> they wanted Windows again) to get the latest Firefox; users on XP
> RTM/SP1 just need to install a long-ago-released, free-to-download,
> Microsoft-supported service pack.

At this point anyone running Windows 2000 would need to buy a new computer.

Having said that, Windows 2000 was never a consumer-facing operating
system; Windows 98, 98SE and ME were the consumer-accessible operating
systems of that era. Firefox support for them was dropped in 2006, and
the fact that they'd been end-of-lifed by Microsoft figured strongly
into that decision. Win2K had a large corporate install base at a time
when entire home computer market was much smaller, but both sides of
that equation have changed quite a bit in five years.

I don't think it would be possible to get reliable numbers about this -
if I'm right, they're all behind firewalls - but I my informal
observation is that approximately 100% of whatever Windows 2000 machines
are left in the world are controlled by large companies whose core
business is not IT-related. That's not good or bad, it is what it is,
but it's not Mozilla's "human user who can make their own decisions
about their desktop" target market.

The XP/SP1 question is the harder one for various reasons, and I think
that actively soliciting feedback from the international Mozilla
community, particularly in China though elsewhere as well, would help
get a better sense of the impact of that decision.

- mhoye

[JP Rosevear]

On Tue, 2011-12-20 at 16:27 -0500, JP Rosevear wrote:
> Hi,
>
> There are two motivators to switch to VS2010 these days:
> 1) General browser performance improvements
> 2) Installed on 64 bit builders so we can access 4GB of virtual memory
> for PGO on our 32bit builds
>

> The main downside for switching to VS2010 has been that we will need to

> drop support for Win2k, XP RTM and XP SP1. We'd be doing this with
> 16-18 weeks of notice.
>
> We could get the benefits of 2) by rolling out VS2005 on the 64bit
> builders, this could take some time (I'll let releng chime in here).
>
> We could also just switch to VS2010 starting tomorrow, assuming Asa
> doesn't find any data contrary to this today. The benefit is we start
> shaking down the compiler. The downside is that as we collect the AUS
> pings through the FF9 launch over the next couple of weeks, we may find
> the Win2k, XP RTM and XP SP1 numbers to be too high to drop. If we work
> out something with MS we still may be able to get support, otherwise we
> may have to go back to VS2005, causing some churn. We are not in a
> position to build in parallel on VS2010 and VS2005 to mitigate this.

The results are in:

"Our data says half of one percent of our Windows users are on these
older systems and that a disproportionate number of them are on Firefox
3.6."

With so many on 3.6, a lot aren't interested in upgrading anyhow. Asa's
take is that we are ok to be forward looking on the release train. This
seems good since we'll get performance improvements for 99.5% of our
Windows users.

With that in mind, I suggest we turn on VS2010 post Tuesday (next
uplift).

We should get a bug going to notify users affected that support will be
ending.

[Alex Keybl]

I filed 721809 – Ensure that platforms unsupported after the VS 2010 switch are not updated to an unsupported build which should block releasing a build after the VS2010 switch.

-Alex

[Asa Dotzler]

On 1/27/2012 11:47 AM, Alex Keybl wrote:
> I filed 721809 – Ensure that platforms unsupported after the VS 2010 switch are not updated to an unsupported build which should block releasing a build after the VS2010 switch.
>
> -Alex

Do we know what we need to do (or not do) for Windows Server 2003? That
and XP-64 may also impacted by this but their identifiers aren't
separated in our data. As far as I can tell, the Server 2003 and XP-64
are the same identifier. The numbers aren't large, but they are there.

- A

[Ehsan Akhgari]

Bug 684227 has already been filed for this.

--
Ehsan
<http://ehsanakhgari.org/>

On Fri, Jan 27, 2012 at 2:47 PM, Alex Keybl <ake...@mozilla.com> wrote:

> I filed 721809 – Ensure that platforms unsupported after the VS 2010
> switch are not updated to an unsupported build which should block releasing
> a build after the VS2010 switch.
>
> -Alex
>

[Alex Keybl]

Are there any other platforms that we're concerned about being hidden in the supported identifiers list? Once we finalize the list of affected platforms, we can ask QA to verify that the VS2010 build doesn't work on them and RelEng to confirm our understanding of limitations in platform identification. Then we should discuss population sizes and ways to mitigate the issue before flipping the switch.

-Alex

[Daniel Cater]

What was the breakdown of the 0.5% across Windows 2000, XP RTM and XP SP1?

[Daniel Cater]

[Asa Dotzler]

On 1/28/2012 6:28 AM, Daniel Cater wrote:
> What was the breakdown of the 0.5% across Windows 2000, XP RTM and XP SP1?

75% of them were on win2K and 25% on pre-SP2 XP.

- A

[Ehsan Akhgari]

I don't think that those platforms are going to be affected by this
transition.

Cheers,
Ehsan

> ______________________________**_________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/**listinfo/dev-planning<https://lists.mozilla.org/listinfo/dev-planning>
>

[Daniel Veditz]

On 1/27/12 10:33 AM, JP Rosevear wrote:
> "Our data says half of one percent of our Windows users are on these
> older systems and that a disproportionate number of them are on Firefox
> 3.6."

Do we have regional breakdown of that data, or is it pretty
consistent around the globe?

[JP Rosevear]

I'm not sure - Asa or metrics would know better.

[JP Rosevear]

On Fri, 2012-01-27 at 13:33 -0500, JP Rosevear wrote:
> On Tue, 2011-12-20 at 16:27 -0500, JP Rosevear wrote:
> We should get a bug going to notify users affected that support will be
> ending.

Filed:
https://bugzilla.mozilla.org/show_bug.cgi?id=723155
https://bugzilla.mozilla.org/show_bug.cgi?id=723158

[Asa Dotzler]

On 2/1/2012 2:15 AM, JP Rosevear wrote:
> On Sun, 2012-01-29 at 19:30 -0800, Daniel Veditz wrote:
>> On 1/27/12 10:33 AM, JP Rosevear wrote:
>>> "Our data says half of one percent of our Windows users are on these
>>> older systems and that a disproportionate number of them are on Firefox
>>> 3.6."
>>
>> Do we have regional breakdown of that data, or is it pretty
>> consistent around the globe?
>
> I'm not sure - Asa or metrics would know better.

In my preliminary digging (if I've got my queries right) China is
disproportionately high in use of Win2K. The rest of the major languages
I've checked seem about normal proportions.

- A

[chris hofmann]

crash data roughly confirms this if we use number of crashes as a proxy
for usage.

peak crashes for Windows 6.0 happen at about 1800 pacific or 10am Beijing

low point of crashes happens around 6am pacific/9am eastern time which
is also 2200 Beijing

#crashes
time in PST Windows 6.0 crashes per hour/20
931 2012013000...............................................
920 2012013001...............................................
838 2012013002..........................................
803 2012013003.........................................
708 2012013004....................................
629 2012013005................................
581 2012013006..............................
613 2012013007...............................
641 2012013008.................................
716 2012013009....................................
832 2012013010..........................................
871 2012013011............................................
953 2012013012................................................
1103 2012013013........................................................
1162 2012013014...........................................................
1302
2012013015..................................................................

1363
2012013016.....................................................................

1427
2012013017........................................................................

1565
2012013018...............................................................................

1546
2012013019..............................................................................

1477
2012013020..........................................................................

1394
2012013021......................................................................

1288
2012013022.................................................................
1030 2012013023....................................................

This may also have implications for how we get the message out to the
users affected most by this change.

We should probably figure out how to make sure the blog post can get
translated into Asian languages and get that blog post echoed into Asian
press.

-chofmann

[Kyle Huey]

On Fri, Feb 3, 2012 at 5:11 AM, chris hofmann <chof...@meer.net> wrote:

> peak crashes for Windows 6.0 happen at about 1800 pacific or 10am Beijing
>

Isn't Windows 6.0 Vista?

- Kyle

[Ted Mielczarek]

Yes, 5.0 is Win2k.

-Ted

[Chris Hofmann]

On 2/3/12 2:11 AM, chris hofmann wrote:
> On 2/1/12 1:55 PM, Asa Dotzler wrote:

> crash data roughly confirms this if we use number of crashes as a
> proxy for usage.
>

> peak crashes for Windows 6.0 happen at about 1800 pacific or 10am Beijing
>

oops, as kyle and ted pointed out 6.0 is not what we are looking for.
here is a typical curve for win 5.1.

I also forgot about the change over of soccoro to UTC so that changes
things a bit. Just glancing at this I'd say that the crash data
conflicts with Asa's assumption that the concentration is higher in
Asia, and usage from crash data follows a bit closer our world wide
distribution, and a peak of 7am-10am pacific and eastern times in the US.

#crashes
time in UTC/Bejing/Pacific Windows 5.1 crashes per hour/100
3913 2012013000 0800 1600 ........................................
3884 2012013001 0900 1700 .......................................
3761 2012013002 1000 1800 ......................................
3806 2012013003 1100 1900 .......................................
3980 2012013004 1200 2000 ........................................
4567 2012013005 1300 2100 ..............................................
4996 2012013006 1400 2200
..................................................
5818 2012013007 1500 2300
...........................................................
6427 2012013008 1600 0000
.................................................................
6808 2012013009 1700 0100
.....................................................................
7155 2012013010 1800 0200
........................................................................
7641 2012013011 1900 0300
.............................................................................

8311 2012013012 2000 0400
....................................................................................

8643 2012013013 2100 0500
.......................................................................................

9196 2012013014 2200 0600
............................................................................................

9222 2012013015 2300 0700
.............................................................................................

8921 2012013016 0000 0800
..........................................................................................

8457 2012013017 0100 0900
.....................................................................................

8335 2012013018 0200 1000
....................................................................................

7946 2012013019 0300 1100
................................................................................

7210 2012013020 0400 1200
.........................................................................
6356 2012013021 0500 1300
................................................................
5410 2012013022 0600 1400
.......................................................
4527 2012013023 0700 1500 ..............................................

and here is what the curve looks like for all crashes

#crashes
time in UTC all crashes per hour/200

9364 2012013000...............................................
9057 2012013001..............................................
8748 2012013002............................................
8776 2012013003............................................
8547 2012013004...........................................
8980 2012013005.............................................
9584 2012013006................................................
10713 2012013007......................................................
11686 2012013008...........................................................
12379
2012013009..............................................................
13373
2012013010...................................................................

14175
2012013011.......................................................................

15609
2012013012...............................................................................

16649
2012013013....................................................................................

17732
2012013014.........................................................................................

18419
2012013015.............................................................................................

18330
2012013016............................................................................................

17810
2012013017..........................................................................................

17675
2012013018.........................................................................................

17100
2012013019......................................................................................

16121
2012013020.................................................................................

14769
2012013021..........................................................................

12874
2012013022.................................................................
10708 2012013023......................................................

[chris hofmann]

On 2/3/12 6:01 AM, Chris Hofmann wrote:
> On 2/3/12 2:11 AM, chris hofmann wrote:
>> On 2/1/12 1:55 PM, Asa Dotzler wrote:

And here is the curve with Windows 5.1 with service packs 2 and 3 removed
showing even stronger connection to the early morning and mid-day hours
in the
US.

#crashes
time in UTC/Bejing/Pacific Windows 5.1 crashes per hour/5
79 2012013000 8 16 ................
70 2012013001 9 17 ...............
48 2012013002 10 18 ..........
68 2012013003 11 19 ..............
72 2012013004 12 20 ...............
56 2012013005 13 21 ............
107 2012013006 14 22 ......................
115 2012013007 15 23 ........................
175 2012013008 16 00 ....................................
152 2012013009 17 01 ...............................
176 2012013010 18 02 ....................................
185 2012013011 19 03 ......................................
186 2012013012 20 04 ......................................
205 2012013013 21 05 ..........................................
209 2012013014 22 06 ..........................................
267 2012013015 23 07
......................................................
257 2012013016 00 08 ....................................................
241 2012013017 01 09 .................................................
246 2012013018 02 10 ..................................................
262 2012013019 03 11
.....................................................
239 2012013020 04 12 ................................................
172 2012013021 05 13 ...................................
132 2012013022 06 14 ...........................
83 2012013023 07 15 .................

[Robert Kaiser]

chris hofmann schrieb:

> And here is the curve with Windows 5.1 with service packs 2 and 3 removed
> showing even stronger connection to the early morning and mid-day hours
> in the
> US.

What about Windows NT 5.0 which is actually Windows 2000?

Robert Kaiser

[Asa Dotzler]

I'm sorry, I got these numbers wrong. It's Japan that's
disproportionately high.

(They were right next to each other in my table sorted on total ADIs and
I just read too quickly and assumed China. Sorry 'bout that.)

But once again, these numbers are tiny, fractions of a percent of users
in even the highest win2K incidence countries.

- A