1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Upgrading the CPU?

Discussion in 'Windows XP' started by Bill in Co, Sep 8, 2010.

  1. Bill in Co

    Bill in Co Flightless Bird

    I was thinking about possibly upgrading my current 1.6 GHz CPU on my Dell
    Desktop with a faster 2.2 GHz CPU (which is compatible and available), but I
    had a couple of general questions:

    Would upgrading the CPU would require some, or perhaps most, apps to need to
    be reactivated again, due to tripping some copy protection features of the
    apps?
    IOW, will apps typically look at that alone and that's enough, or does it
    take 2 or more large changes to the system to normally trigger it?

    Also, when making image backups on my system to my second internal SATA2
    drive, I am now getting a throughput of around 1.5 GBytes per minute. Is
    that max transfer speed limit likely due to my slow CPU speed (I have a 1.6
    GHz CPU), or more likely a limit of the disk drive (or other motherboard
    components)? As I recall, I think the theoretical transfer limit of SATA2
    hard drives is supposed to be around 3 Gbits per second, so I'm not sure if
    the hard drive itself is the primary limit here. If so, then a CPU upgrade
    wouldn't affect that transfer rate either.

    I'm also assuming that the byte to bit conversion is 8 bits per byte, but
    I'm not sure if that's correct (maybe there are some overhead bits, and it's
    more like 10 bits per byte should be used for the conversions?)
     
  2. Bob I

    Bob I Flightless Bird

    In-line

    Bill in Co wrote:
    > I was thinking about possibly upgrading my current 1.6 GHz CPU on my Dell
    > Desktop with a faster 2.2 GHz CPU (which is compatible and available), but I
    > had a couple of general questions:
    >
    > Would upgrading the CPU would require some, or perhaps most, apps to need to
    > be reactivated again, due to tripping some copy protection features of the
    > apps?

    Not likely.

    > IOW, will apps typically look at that alone and that's enough, or does it
    > take 2 or more large changes to the system to normally trigger it?
    >

    As before, not likely

    > Also, when making image backups on my system to my second internal SATA2
    > drive, I am now getting a throughput of around 1.5 GBytes per minute. Is
    > that max transfer speed limit likely due to my slow CPU speed (I have a 1.6
    > GHz CPU), or more likely a limit of the disk drive (or other motherboard
    > components)? As I recall, I think the theoretical transfer limit of SATA2
    > hard drives is supposed to be around 3 Gbits per second, so I'm not sure if
    > the hard drive itself is the primary limit here. If so, then a CPU upgrade
    > wouldn't affect that transfer rate either.
    >


    CPU isn't particularly involved in DMA transfers. (Direct Memory Access)

    > I'm also assuming that the byte to bit conversion is 8 bits per byte, but
    > I'm not sure if that's correct (maybe there are some overhead bits, and it's
    > more like 10 bits per byte should be used for the conversions?)
    >


    Huh?
     
  3. dadiOH

    dadiOH Flightless Bird

    Bill in Co wrote:
    > I was thinking about possibly upgrading my current 1.6 GHz CPU on my
    > Dell Desktop with a faster 2.2 GHz CPU (which is compatible and
    > available), but I had a couple of general questions:
    >
    > Would upgrading the CPU would require some, or perhaps most, apps to
    > need to be reactivated again, due to tripping some copy protection
    > features of the apps?
    > IOW, will apps typically look at that alone and that's enough, or
    > does it take 2 or more large changes to the system to normally
    > trigger it?


    You have apps that needed to be activated?? Or are you talking about XP?
    If the latter, I don't know if changing just the CPU would require a new
    activation or not but if it does it is no big deal.
    _____________

    > Also, when making image backups on my system to my second internal
    > SATA2 drive, I am now getting a throughput of around 1.5 GBytes per
    > minute. Is that max transfer speed limit likely due to my slow CPU
    > speed (I have a 1.6 GHz CPU), or more likely a limit of the disk
    > drive (or other motherboard components)?


    Not the CPU. Drive or program doing the imaging.
    ______________

    > As I recall, I think the
    > theoretical transfer limit of SATA2 hard drives is supposed to be
    > around 3 Gbits per second, so I'm not sure if the hard drive itself
    > is the primary limit here. If so, then a CPU upgrade wouldn't affect
    > that transfer rate either.


    I get 76 MB/sec...4.56 GB/min. My older drive does about 60 of that,
    ____________

    > I'm also assuming that the byte to bit conversion is 8 bits per byte,
    > but I'm not sure if that's correct (maybe there are some overhead
    > bits, and it's more like 10 bits per byte should be used for the
    > conversions?)


    8 bits in a byte. 4 bits in a nybble, 2 nybbles in a byte.

    --

    dadiOH
    ____________________________

    dadiOH's dandies v3.06...
    ....a help file of info about MP3s, recording from
    LP/cassette and tips & tricks on this and that.
    Get it at http://mysite.verizon.net/xico
     
  4. Paul

    Paul Flightless Bird

    Bill in Co wrote:
    > I was thinking about possibly upgrading my current 1.6 GHz CPU on my Dell
    > Desktop with a faster 2.2 GHz CPU (which is compatible and available), but I
    > had a couple of general questions:
    >
    > Would upgrading the CPU would require some, or perhaps most, apps to need to
    > be reactivated again, due to tripping some copy protection features of the
    > apps?
    > IOW, will apps typically look at that alone and that's enough, or does it
    > take 2 or more large changes to the system to normally trigger it?
    >
    > Also, when making image backups on my system to my second internal SATA2
    > drive, I am now getting a throughput of around 1.5 GBytes per minute. Is
    > that max transfer speed limit likely due to my slow CPU speed (I have a 1.6
    > GHz CPU), or more likely a limit of the disk drive (or other motherboard
    > components)? As I recall, I think the theoretical transfer limit of SATA2
    > hard drives is supposed to be around 3 Gbits per second, so I'm not sure if
    > the hard drive itself is the primary limit here. If so, then a CPU upgrade
    > wouldn't affect that transfer rate either.
    >
    > I'm also assuming that the byte to bit conversion is 8 bits per byte, but
    > I'm not sure if that's correct (maybe there are some overhead bits, and it's
    > more like 10 bits per byte should be used for the conversions?)
    >
    >


    Test the hard drive with HDTune, to get a measure of the media (platter)
    limited transfer rate. (The "burst speed" field in the benchmark window,
    gives some idea of the SATA cable rate available to you.)

    http://www.hdtune.com/files/hdtune_255.exe

    The motherboard hard drive controller would normally prefer to use DMA for data
    transfer. That means, when the disk has data to transfer, the motherboard
    controller moves the data immediately into RAM using direct memory access
    on the bus. The hard drive controller then informs the OS, via an interrupt,
    that the transfer is complete, and many sectors may be sitting in a
    RAM buffer. By doing that, the CPU load due to disk transfers, can be
    kept small. The CPU can be off doing other things, until the interrupt
    announce the good news, that the command is complete.

    If you have the misfortune to have a disk running in PIO mode, you'll
    immediately notice the difference the extra work makes. The CPU will only
    manage between 4MB/sec to perhaps 8MB/sec, when in PIO mode. DMA mode
    allows one of my drives here, to bench at 125MB/sec, which shows how
    much better it can be when done via DMA and with less CPU intervention.

    SATA uses 8B10B encoding on the cable. That means 10 bits of data on the
    cable, represent an 8 bit byte. That means the encoding format is 80%
    efficient. If you have a cable operating at 1500Mbit/sec, you end
    up getting 150MB/sec after decoding the data format used on the
    cable. The encoding format has high clock content, DC balance, and
    allows AC coupling of the differential wiring used on the interface.
    They did not choose that particular format for fun - it is a proven
    encoding technique, first used with fiber optic modules years ago.
    It is used for some of the highest speed interfaces inside your computer.

    http://en.wikipedia.org/wiki/8B10B

    (See section "Technologies that use 8b/10b" for a list)

    *******

    Windows activation is described here. Changing the processor is just
    one of the hardware components being monitored.

    http://aumha.org/win5/a/wpa.htm

    "Processor Type"

    The Processor Serial Number, as far as I know, was only supported on
    one processor. Due to customer feedback on the issue, later processors
    didn't support it. So I doubt the serial number accounts for a significant
    number of WinXP re-activations.

    http://en.wikipedia.org/wiki/Processor_Serial_Number#Controversy_about_privacy_issues

    "The Pentium III was the first x86 CPU to include a unique,
    retrievable, identification number, called PSN (Processor Serial Number).

    Eventually Intel decided to remove the PSN feature on Tualatin-based
    Pentium IIIs, and the feature was not carried through to the
    Pentium 4 or Pentium M."

    HTH,
    Paul
     
  5. Bill in Co

    Bill in Co Flightless Bird

    dadiOH wrote:
    > Bill in Co wrote:
    >> I was thinking about possibly upgrading my current 1.6 GHz CPU on my
    >> Dell Desktop with a faster 2.2 GHz CPU (which is compatible and
    >> available), but I had a couple of general questions:
    >>
    >> Would upgrading the CPU would require some, or perhaps most, apps to
    >> need to be reactivated again, due to tripping some copy protection
    >> features of the apps?
    >> IOW, will apps typically look at that alone and that's enough, or
    >> does it take 2 or more large changes to the system to normally
    >> trigger it?

    >
    > You have apps that needed to be activated?? Or are you talking about XP?
    > If the latter, I don't know if changing just the CPU would require a new
    > activation or not but if it does it is no big deal.
    > _____________
    >
    >> Also, when making image backups on my system to my second internal
    >> SATA2 drive, I am now getting a throughput of around 1.5 GBytes per
    >> minute. Is that max transfer speed limit likely due to my slow CPU
    >> speed (I have a 1.6 GHz CPU), or more likely a limit of the disk
    >> drive (or other motherboard components)?

    >
    > Not the CPU. Drive or program doing the imaging.
    > ______________
    >
    >> As I recall, I think the
    >> theoretical transfer limit of SATA2 hard drives is supposed to be
    >> around 3 Gbits per second, so I'm not sure if the hard drive itself
    >> is the primary limit here. If so, then a CPU upgrade wouldn't affect
    >> that transfer rate either.

    >
    > I get 76 MB/sec...4.56 GB/min. My older drive does about 60 of that,
    > ____________


    60? 60 of what? You mean 60% of the 4.56 GB/min?

    Well then, I don't get it. My Dell desktop system (Dell 530 Inspiron)
    isn't too old (dated around 2008), and has two internal SATA-II drives, and
    I can't get anything close to that (using Acronis True Image to make the
    image backups). Instead, it takes around 10 minutes to create a 15 GB
    image (between my two internal SATA-II drives), which is 1.5 GB/min. For
    what you quoted above, it would only take you about 3 minutes, which is
    phenomenal! Wonder why the difference?
     
  6. Bill in Co

    Bill in Co Flightless Bird

    Paul wrote:
    > Bill in Co wrote:
    >> I was thinking about possibly upgrading my current 1.6 GHz CPU on my Dell
    >> Desktop with a faster 2.2 GHz CPU (which is compatible and available),
    >> but I
    >> had a couple of general questions:
    >>
    >> Would upgrading the CPU would require some, or perhaps most, apps to need
    >> to
    >> be reactivated again, due to tripping some copy protection features of
    >> the
    >> apps?
    >> IOW, will apps typically look at that alone and that's enough, or does it
    >> take 2 or more large changes to the system to normally trigger it?
    >>
    >> Also, when making image backups on my system to my second internal SATA2
    >> drive, I am now getting a throughput of around 1.5 GBytes per minute. Is
    >> that max transfer speed limit likely due to my slow CPU speed (I have a
    >> 1.6
    >> GHz CPU), or more likely a limit of the disk drive (or other motherboard
    >> components)? As I recall, I think the theoretical transfer limit of
    >> SATA2
    >> hard drives is supposed to be around 3 Gbits per second, so I'm not sure
    >> if
    >> the hard drive itself is the primary limit here. If so, then a CPU
    >> upgrade
    >> wouldn't affect that transfer rate either.
    >>
    >> I'm also assuming that the byte to bit conversion is 8 bits per byte, but
    >> I'm not sure if that's correct (maybe there are some overhead bits, and
    >> it's
    >> more like 10 bits per byte should be used for the conversions?)
    >>
    >>

    >
    > Test the hard drive with HDTune, to get a measure of the media (platter)
    > limited transfer rate. (The "burst speed" field in the benchmark window,
    > gives some idea of the SATA cable rate available to you.)
    >
    > http://www.hdtune.com/files/hdtune_255.exe


    OK, did that, results below. TNX.

    > The motherboard hard drive controller would normally prefer to use DMA for
    > data transfer. That means, when the disk has data to transfer, the
    > motherboard
    > controller moves the data immediately into RAM using direct memory access
    > on the bus. The hard drive controller then informs the OS, via an
    > interrupt,
    > that the transfer is complete, and many sectors may be sitting in a
    > RAM buffer. By doing that, the CPU load due to disk transfers, can be
    > kept small. The CPU can be off doing other things, until the interrupt
    > announce the good news, that the command is complete.
    >
    > If you have the misfortune to have a disk running in PIO mode, you'll
    > immediately notice the difference the extra work makes.


    I don't think that's happening here, fortunately! (more below)

    > The CPU will only
    > manage between 4MB/sec to perhaps 8MB/sec, when in PIO mode. DMA mode
    > allows one of my drives here, to bench at 125MB/sec, which shows how
    > much better it can be when done via DMA and with less CPU intervention.


    TNX for that info, Paul. OK, so I ran the "HD Tune" program, and got
    results of approx 50 MB/sec and 80 MB/sec for the ave transfer rates of the
    two internal SATA-II drives, and about 170 MB/sec and 146 MB/sec for the
    burst rates.

    So I gather from this that the drives are NOT the limiting factor in my
    case. Because using the lower ave transfer figure of 50 MB/sec (or 50*60
    = 3 GB/min), that's about double what I'm getting using Acronis True Image
    to backup the disk images (which shows me a throughput of around 1.5 GB/min
    or so). (BTW, all of this is done with write caching left OFF on my main C:
    drive, but not the backup drive, this being done by preference to help
    prevent any potential data loss on C: during any operations).

    So the apparent transfer limit I'm seeing is due to some other Intel
    motherboard/bridge limitations on my system, or?? From what I infer,
    you're saying that by using DMA and interrupts, the CPU speed is essentially
    irrelevant here, right? But still, the CPU does get interrupted every so
    often, so I would think that the CPU speed isn't entirely irrrelant. (my
    system has 1 GB of RAM but I'm not sure how that plays in here - is it using
    any of that 1 GB RAM as a buffer for these disk transfers?)

    > SATA uses 8B10B encoding on the cable. That means 10 bits of data on the
    > cable, represent an 8 bit byte.


    OK, now that is interesting!

    > That means the encoding format is 80%
    > efficient. If you have a cable operating at 1500Mbit/sec, you end
    > up getting 150MB/sec after decoding the data format used on the
    > cable. The encoding format has high clock content, DC balance, and
    > allows AC coupling of the differential wiring used on the interface.
    > They did not choose that particular format for fun - it is a proven
    > encoding technique, first used with fiber optic modules years ago.
    > It is used for some of the highest speed interfaces inside your computer.
    >
    > http://en.wikipedia.org/wiki/8B10B
    >
    > (See section "Technologies that use 8b/10b" for a list)
    >
    > *******


    Interesting! Thanks.

    > Windows activation is described here. Changing the processor is just
    > one of the hardware components being monitored.
    >
    > http://aumha.org/win5/a/wpa.htm
    >
    > "Processor Type"


    Right, and that alone (not the CPU serial number) might be enough to trip
    some software reactivation, but as some have said, it's no big deal.

    > The Processor Serial Number, as far as I know, was only supported on
    > one processor. Due to customer feedback on the issue, later processors
    > didn't support it. So I doubt the serial number accounts for a significant
    > number of WinXP re-activations.


    No I was just thinking of the CPU type/version, and not its actual serial
    number.

    > http://en.wikipedia.org/

    wiki/Processor_Serial_Number#Controversy_about_privacy_issues
    >
    > "The Pentium III was the first x86 CPU to include a unique,
    > retrievable, identification number, called PSN (Processor Serial
    > Number).
    >
    > Eventually Intel decided to remove the PSN feature on Tualatin-based
    > Pentium IIIs, and the feature was not carried through to the
    > Pentium 4 or Pentium M."
    >
    > HTH,
    > Paul


    Thanks Paul (with comments above, inline)
     
  7. dadiOH

    dadiOH Flightless Bird

    Bill in Co wrote:
    > dadiOH wrote:


    >> I get 76 MB/sec...4.56 GB/min. My older drive does about 60 of that,
    >> ____________

    >
    > 60? 60 of what? You mean 60% of the 4.56 GB/min?



    Yeah, 60%.
    ___________

    > Well then, I don't get it. My Dell desktop system (Dell 530
    > Inspiron) isn't too old (dated around 2008), and has two internal
    > SATA-II drives, and I can't get anything close to that (using Acronis
    > True Image to make the image backups). Instead, it takes around 10
    > minutes to create a 15 GB image (between my two internal SATA-II
    > drives), which is 1.5 GB/min. For what you quoted above, it would
    > only take you about 3 minutes, which is phenomenal! Wonder why the
    > difference?


    The difference is that I told you what the write speed of my drives is.
    Making an image involves much more than just writing to the drive. Ten
    minutes to image 15GB doesn't sound bad. If you want to know actual disk
    speed, use HDTune.

    http://www.hdtune.com/

    --

    dadiOH
    ____________________________

    dadiOH's dandies v3.06...
    ....a help file of info about MP3s, recording from
    LP/cassette and tips & tricks on this and that.
    Get it at http://mysite.verizon.net/xico
     
  8. Paul

    Paul Flightless Bird

    Bill in Co wrote:

    >> Test the hard drive with HDTune, to get a measure of the media (platter)
    >> limited transfer rate. (The "burst speed" field in the benchmark window,
    >> gives some idea of the SATA cable rate available to you.)
    >>
    >> http://www.hdtune.com/files/hdtune_255.exe

    >
    > OK, did that, results below. TNX.
    >
    > TNX for that info, Paul. OK, so I ran the "HD Tune" program, and got
    > results of approx 50 MB/sec and 80 MB/sec for the ave transfer rates of the
    > two internal SATA-II drives, and about 170 MB/sec and 146 MB/sec for the
    > burst rates.
    >
    > So I gather from this that the drives are NOT the limiting factor in my
    > case. Because using the lower ave transfer figure of 50 MB/sec (or 50*60
    > = 3 GB/min), that's about double what I'm getting using Acronis True Image
    > to backup the disk images (which shows me a throughput of around 1.5 GB/min
    > or so). (BTW, all of this is done with write caching left OFF on my main C:
    > drive, but not the backup drive, this being done by preference to help
    > prevent any potential data loss on C: during any operations).
    >
    > So the apparent transfer limit I'm seeing is due to some other Intel
    > motherboard/bridge limitations on my system, or?? From what I infer,
    > you're saying that by using DMA and interrupts, the CPU speed is essentially
    > irrelevant here, right? But still, the CPU does get interrupted every so
    > often, so I would think that the CPU speed isn't entirely irrrelant. (my
    > system has 1 GB of RAM but I'm not sure how that plays in here - is it using
    > any of that 1 GB RAM as a buffer for these disk transfers?)
    >


    Backup software will generally never work at the flat out transfer
    rate of the disk.

    One reason for this, is file by file transferring, requires consulting
    the file system for details of each file. So the head flies back and
    forth, from data area, to $MFT or whatever. Benchmarks such as HDTune,
    measure smooth movement of the head from cylinder to cylinder, which
    means head movement makes a minimal contribution to the performance
    picture. Real world disk activity can be dominated by head seeks.

    If you want an example of "disappointment" some time, use the Performance
    plugin from the Administrative Tools control panel. Add some counters
    from the PhysicalDisk section. This is something I do quite frequently, when
    doing maintenance on my computer. If I run a defrag, I get around 1MB/sec,
    on a disk that can achieve 130MB/sec sustained. The reason for that,
    is for safety, defrag makes nothing but tiny accesses to the disk. That
    sucks the life out of the disk (and annoys the hell out of me). And that
    is an example of how inefficient access methods, cause poor performance.
    I was shocked, the first time I tried a defrag, left it running overnight,
    and it wasn't finished in the morning. Now that I've had a chance to study
    it further, I just don't use the built-in defrag to fix it any more.

    Defrag is done that way for safety, the idea being, if the power goes off,
    the file system is supposed to remain intact. It's too bad there isn't a flag
    that says "I'm on a UPS with an infinite battery", so that you could throw
    safety to the wind. I'm willing to back up my C: drive first, if it would
    mean a defrag could run faster. I can back up the C: drive, in a fraction
    of the time it takes to get a defrag to complete, so I could be further
    ahead, incorporating a backup and an "unsafe" defrag as a replacement for
    what is available in the OS now.

    Paul
     

Share This Page