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?) 

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?

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

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

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? 

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) 

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

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