5 ms·

Do you have any citations that companies are replacing their intel processors every 2 years? That is not inline with what I have seen.

ams6110 8y ago
More like 5 years, or even longer, where I work. We have some 7 year old Dell servers that are still chugging along, performing their duties as well as ever.
- brudgers 8y ago
  Curious if they are managed with ME.
  - close04 8y ago
    They have the ME and Server Platform Services (SPS) on top of that but I doubt anyone uses that to manage when Dells have DRAC/iDRAC.
- close04 8y ago
  Usually the amortization of such systems is ~ 4 years. But many smaller companies choose to stay with the old systems a little longer, 5, or even 6 years lately. Simply because there is no push performance wise. The main motivation for upgrade is software support (usually for the OS, driven by Microsoft), or failure rates for the older systems. And that's for the desktop side. For servers they tend to be taken out of commission when the service they provide is migrated to a whole new platform and the legacy one goes to a better place along with the metal. Servers are more reliable than your regular desktops, they get better support, and most companies don't upgrade running systems. P.S. I don't know of any enterprise environment where ME is used for managing servers. It's usually ILO, ILOM, DRAC, IMM, RMM. I think ME is mostly for desktops or SOHO, Intel has RMM for servers.
  - oneplane 8y ago
    Also, on servers, Intel has (requires?) SPS: server platform services. It's like an ME, but worse, and without a way to neuter it. Edit: a quick search yields a common core or division at Intel behind the ME and SPS, so that makes a bit of sense. There has been at least 1 exploit in the wild for that SPS, it also lists TXT and ME, so I guess it's a shared (MINIX?) kernel that had the bug.
  - forapurpose 8y ago
    > For servers they tend to be taken out of commission when the service they provide is migrated to a whole new platform Or when the service contract expires or is too expensive to extend. You can't run a server of any importance without a service contract; it can be the difference between all the server's users and services being down for hours or a more than a week, and between IT management keeping their job for hours or longer.
    - mmt 8y ago
      That's just the "enterprise" hardware model. It's overall extremely expensive to begin with and may have made sense back in the days of proprietary hardware, but makes no sense for a commodity hardware installation beyond a trivial size. It's hard to imagine not being able to find a replacement in more than a week, especially if one skipped service contract and just bought a spare or two with a fraction of the savings. It's why moving to cloud infrastructure can be so much cheaper for these shops. Of course, if it is a trivial size, like a single server at a small business, that's a different story.
      - forapurpose 8y ago
        Yes, somehow I thought the GP was talking about small business, but I see there is nothing in the text that says so (at least not now). Yes, of course, with cloud infrastructure or just virtualization and spare hardware, service contracts have much less value. > makes no sense for a commodity hardware installation beyond a trivial size It's not the commodity hardware - x86 servers have been mostly commodity hardware for decades - it's virtualization (or other rapid recovery and migration tech) that makes it work.
samstave 8y ago
extrapolate as you will... https://aws.amazon.com/blogs/aws/ec2-instance-history/ https://aws.amazon.com/blogs/aws/ec2-instance-history/ I didn’t have one, but it seemed like a worthwhile thing to have and so I spent a few minutes putting the following list together (these are all announcement dates): August 2006 – m1.small. October 2007 – m1.large, m1.xlarge. May 2008 – c1.medium, c1.xlarge. October 2009 – m2.2xlarge, m2.4xlarge. February 2010 – m2.xlarge. July 2010 – cc1.4xlarge. September 2010 – t1.micro. November 2010 – cg1.4xlarge. November 2011 – cc2.8xlarge. March 2012 – m1.medium. July 2012 – hi1.4xlarge. October 2012 – m3.xlarge, m3.2xlarge. December 2012 – hs1.8xlarge. January 2013 – cr1.8xlarge. November 2013 – c3.large, c3.xlarge, c3.2xlarge, c3.4xlarge, c3.8xlarge. November 2013 – g2.2xlarge. December 2013 – i2.xlarge, i2.2xlarge, i2.4xlarge, i2.8xlarge. January 2014 – m3.medium, m3.large. April 2014 – r3.large, r3.xlarge, r3.2xlarge, r3.4xlarge, r3.8xlarge. July 2014 – t2.micro, t2.small, t2.medium. January 2015 – c4.large, c4.xlarge, c4.2xlarge, c4.4xlarge, c4.8xlarge. March 2015 – d2.xlarge, d2.2xlarge, d2.4xlarge, d2.8xlarge. April 2015 – g2.8xlarge. June 2015 – t2.large. June 2015 – m4.large, m4.xlarge, m4.2xlarge, m4.4xlarge, m4.10xlarge. December 2015 – t2.nano. May 2016 – x1.32xlarge. September 2016 – m4.16xlarge. September 2016 – p2.xlarge, p2.8xlarge, p2.16xlarge. October 2016 – x1.16xlarge. November 2016 – f1.2xlarge, f1.16xlarge. November 2016 – r4.large, r4.xlarge, r4.2xlarge, r4.4xlarge, r4.8xlarge, r4.16xlarge. November 2016 – t2.xlarge, t2.2xlarge. November 2016 – i3.large, i3.xlarge, i3.2xlarge, i3.4xlarge, i3.8xlarge, i3.16xlarge. November 2016 – c5.large, c5.xlarge, c5.2xlarge, c5.4xlarge, c5.8xlarge, c5.16xlarge. July 2017 – g3.4xlarge, g3.8xlarge, g3.16xlarge. September 2017 – x1e.32xlarge. October 2017 – p3.2xlarge, p3.8xlarge, p3.16xlarge. November 2017 – x1e.xlarge, x1e.2xlarge, x1e.4xlarge, x1e.8xlarge, x1e.16xlarge. November 2017 – m5.large, m5.xlarge, m5.2xlarge, m5.4xlarge, m5.12xlarge, m5.24xlarge. November 2017 – h1.2xlarge, h1.4xlarge, h1.8xlarge, h1.16xlarge. November 2017 – i3.metal. June 2018 – m5d.large, m5d.xlarge, m5d.2xlarge, m5d.4xlarge, m5d.12xlarge, m5d.24xlarge. July 2018 – z1d.large, z1d.xlarge, z1d.2xlarge, z1d.3xlarge, z1d.6xlarge, z1d.12xlarge, z1d.metal, r5.large, r5.xlarge, r5.2xlarge, r5.4xlarge, r5.12xlarge, r5.metal, r5.24xlarge, r5d.large, r5d.xlarge, r5d.2xlarge, r5d.4xlarge, r5d.12xlarge, r5d.24xlarge, r5d.metal.
- mmt 8y ago
  Unfortunately, announcement dates only give one endpoint of the timeline. The other endpoint, retirement date (from even previous-generation availability), is crucial to any anlysis.

ams6110 8y ago

More like 5 years, or even longer, where I work. We have some 7 year old Dell servers that are still chugging along, performing their duties as well as ever.

brudgers 8y ago
Curious if they are managed with ME.
- close04 8y ago
  They have the ME and Server Platform Services (SPS) on top of that but I doubt anyone uses that to manage when Dells have DRAC/iDRAC.
close04 8y ago
Usually the amortization of such systems is ~ 4 years. But many smaller companies choose to stay with the old systems a little longer, 5, or even 6 years lately. Simply because there is no push performance wise. The main motivation for upgrade is software support (usually for the OS, driven by Microsoft), or failure rates for the older systems. And that's for the desktop side. For servers they tend to be taken out of commission when the service they provide is migrated to a whole new platform and the legacy one goes to a better place along with the metal. Servers are more reliable than your regular desktops, they get better support, and most companies don't upgrade running systems. P.S. I don't know of any enterprise environment where ME is used for managing servers. It's usually ILO, ILOM, DRAC, IMM, RMM. I think ME is mostly for desktops or SOHO, Intel has RMM for servers.
- oneplane 8y ago
  Also, on servers, Intel has (requires?) SPS: server platform services. It's like an ME, but worse, and without a way to neuter it. Edit: a quick search yields a common core or division at Intel behind the ME and SPS, so that makes a bit of sense. There has been at least 1 exploit in the wild for that SPS, it also lists TXT and ME, so I guess it's a shared (MINIX?) kernel that had the bug.
- forapurpose 8y ago
  > For servers they tend to be taken out of commission when the service they provide is migrated to a whole new platform Or when the service contract expires or is too expensive to extend. You can't run a server of any importance without a service contract; it can be the difference between all the server's users and services being down for hours or a more than a week, and between IT management keeping their job for hours or longer.
  - mmt 8y ago
    That's just the "enterprise" hardware model. It's overall extremely expensive to begin with and may have made sense back in the days of proprietary hardware, but makes no sense for a commodity hardware installation beyond a trivial size. It's hard to imagine not being able to find a replacement in more than a week, especially if one skipped service contract and just bought a spare or two with a fraction of the savings. It's why moving to cloud infrastructure can be so much cheaper for these shops. Of course, if it is a trivial size, like a single server at a small business, that's a different story.
    - forapurpose 8y ago
      Yes, somehow I thought the GP was talking about small business, but I see there is nothing in the text that says so (at least not now). Yes, of course, with cloud infrastructure or just virtualization and spare hardware, service contracts have much less value. > makes no sense for a commodity hardware installation beyond a trivial size It's not the commodity hardware - x86 servers have been mostly commodity hardware for decades - it's virtualization (or other rapid recovery and migration tech) that makes it work.

samstave 8y ago

extrapolate as you will... https://aws.amazon.com/blogs/aws/ec2-instance-history/ https://aws.amazon.com/blogs/aws/ec2-instance-history/ I didn’t have one, but it seemed like a worthwhile thing to have and so I spent a few minutes putting the following list together (these are all announcement dates): August 2006 – m1.small. October 2007 – m1.large, m1.xlarge. May 2008 – c1.medium, c1.xlarge. October 2009 – m2.2xlarge, m2.4xlarge. February 2010 – m2.xlarge. July 2010 – cc1.4xlarge. September 2010 – t1.micro. November 2010 – cg1.4xlarge. November 2011 – cc2.8xlarge. March 2012 – m1.medium. July 2012 – hi1.4xlarge. October 2012 – m3.xlarge, m3.2xlarge. December 2012 – hs1.8xlarge. January 2013 – cr1.8xlarge. November 2013 – c3.large, c3.xlarge, c3.2xlarge, c3.4xlarge, c3.8xlarge. November 2013 – g2.2xlarge. December 2013 – i2.xlarge, i2.2xlarge, i2.4xlarge, i2.8xlarge. January 2014 – m3.medium, m3.large. April 2014 – r3.large, r3.xlarge, r3.2xlarge, r3.4xlarge, r3.8xlarge. July 2014 – t2.micro, t2.small, t2.medium. January 2015 – c4.large, c4.xlarge, c4.2xlarge, c4.4xlarge, c4.8xlarge. March 2015 – d2.xlarge, d2.2xlarge, d2.4xlarge, d2.8xlarge. April 2015 – g2.8xlarge. June 2015 – t2.large. June 2015 – m4.large, m4.xlarge, m4.2xlarge, m4.4xlarge, m4.10xlarge. December 2015 – t2.nano. May 2016 – x1.32xlarge. September 2016 – m4.16xlarge. September 2016 – p2.xlarge, p2.8xlarge, p2.16xlarge. October 2016 – x1.16xlarge. November 2016 – f1.2xlarge, f1.16xlarge. November 2016 – r4.large, r4.xlarge, r4.2xlarge, r4.4xlarge, r4.8xlarge, r4.16xlarge. November 2016 – t2.xlarge, t2.2xlarge. November 2016 – i3.large, i3.xlarge, i3.2xlarge, i3.4xlarge, i3.8xlarge, i3.16xlarge. November 2016 – c5.large, c5.xlarge, c5.2xlarge, c5.4xlarge, c5.8xlarge, c5.16xlarge. July 2017 – g3.4xlarge, g3.8xlarge, g3.16xlarge. September 2017 – x1e.32xlarge. October 2017 – p3.2xlarge, p3.8xlarge, p3.16xlarge. November 2017 – x1e.xlarge, x1e.2xlarge, x1e.4xlarge, x1e.8xlarge, x1e.16xlarge. November 2017 – m5.large, m5.xlarge, m5.2xlarge, m5.4xlarge, m5.12xlarge, m5.24xlarge. November 2017 – h1.2xlarge, h1.4xlarge, h1.8xlarge, h1.16xlarge. November 2017 – i3.metal. June 2018 – m5d.large, m5d.xlarge, m5d.2xlarge, m5d.4xlarge, m5d.12xlarge, m5d.24xlarge. July 2018 – z1d.large, z1d.xlarge, z1d.2xlarge, z1d.3xlarge, z1d.6xlarge, z1d.12xlarge, z1d.metal, r5.large, r5.xlarge, r5.2xlarge, r5.4xlarge, r5.12xlarge, r5.metal, r5.24xlarge, r5d.large, r5d.xlarge, r5d.2xlarge, r5d.4xlarge, r5d.12xlarge, r5d.24xlarge, r5d.metal.

mmt 8y ago
Unfortunately, announcement dates only give one endpoint of the timeline. The other endpoint, retirement date (from even previous-generation availability), is crucial to any anlysis.