MacBook Pro Core 2 Duo hard drive options

On 10/30/06 7:52 PM, "Alexander Hoffman" <ahoffmanAleDev.com> cleverly
wrote:

> I have ordered a new MacBook Pros (and will post about using naturally
> speaking) and would like to confirm with you guys about hard drive
> speed (by which I mean throughput). This is prompted by seeing people
> complain (elsewhere) that they wouldn't get the 200GB option because
> it is only 4200rpm and lamenting the lack of 7200rpm options.
>
> Apple's MBP hard drive options are:
> (a) 120GB 5400 rpm
> (b) 160GB 5400 rmp
> (c) 200GB 4200 rmp
>
> There are other (third party) options out there as well. For example,
> (d) 100GB 7200rmp.

Alex, I'm in the same boat, but the 200 GB size is the deal for me. Even if
it's slower, I've got it on order. I've been living with the 160 gb Momentus
that I put in my 15" Al book, and it's been just fine.

Bruce

Short answer: if you want performance, get the highest RPM.

On 30 Oct 2006, at 20:52 , Alexander Hoffman wrote:
> Of course, we all understand hard drive capacity. They list
> unformatted capacity, not formatted. But what about speed (and I'll
> leave cache and seek time out of this).

It is absolutely stunning to me how often I see this same error.
Even The Screen Savers show on the now dead Geek TV did this all the
time.

The reason that a 200GB drive does not format to 200GB has nothing to
do with 'formatting' it has to do with Hard Drive manufacturers lying
about capacities.

Apple used to hold the line and sold machines with "100MB" drives
that actually held 100MB while other sold the IDENTICAL drive as
"104MB". I even recall having to correct one vacuous windoid
salesman in, if I recall, Computer City<1> who claimed that the
whitebox clone machine had "4MB more hard drive space than the
Apple." (I also pointed out the Apple machine was a far superior
SCSI drive instead of the craptacular MFM drive in the clone box, but
that is a another story for another day)

Here's the math:

   1GB = 1,073,741,824 bytes
200GB = 214,748,364,800 bytes

However, Hard Drive vendors sell a drive that hold 200,000,000,000
bytes as a "200GB" drive. Simple math will show you that a drive
that hold 200,000,000,000 bytes is, in fact, 186.25GB. And when you
format a "200GB" drive you get a drive that holds, amazingly enough,
186.25GB<2>. You didn't lose 14GB, it was never there.

A good way to remember this lie is the so-called "137GB barrier".
You may have wondered at this odd number. It is especially odd in
having anything to do with computer storage since 137 is no where
near a multiple of 2. That's because the old ATA barrier was 128GB
(go on, do the math).

Nothing to do with "formatted capacity" or "unformatted capacity".

<1> Probably not CC. Some predecessor to CC and CompUSA which name
has vanished from my RAM :)
<2> OK, probably not. It is more likely to be slightly more. For
example, my "160GB" drive formats to 152.67GB, but it should only be
149.01.

On 31 Oct 2006, at 07:39, Google Kreme wrote:

> On 30 Oct 2006, at 20:52 , Alexander Hoffman wrote:
>> Of course, we all understand hard drive capacity. They list
>> unformatted capacity, not formatted.

Well, clearly we DON'T all understand hard drive capacity.

> The reason that a 200GB drive does not format to 200GB has nothing to
> do with 'formatting' it has to do with Hard Drive manufacturers lying
> about capacities.

> Here's the math:
>
> 1GB = 1,073,741,824 bytes
> 200GB = 214,748,364,800 bytes

Of course the manufacturers like to present their products in the
best light, but they can argue that they are NOT lying (misleading is
a different question - but hey, that's why they pay the marketers the
big bucks).

The root cause of the problem is that Google Kreme is interpreting
the prefix giga to mean 1,073,741,824 and drive manufacturers are
interpreting it to mean 1,000,000 and guess what - shock! horror! -
the drive manufacturers are strictly correct. The prefixes kilo.
mega, giga are SI Units and are expressed as powers of 10.

Due to the confusion arising the IEC in 1999 introduced the prefixes
kibi-, mebi-, gibi-, etc., and the symbols Ki, Mi, Gi, etc. to
specify binary multiples of a quantity. These are not at all widely
used in the common parlance, but the fact remains that they DO exist
and hence, the drive manufacturers' use of G as 1,000,000 is correct
according to the relevant international standards.

For further details, see the relevant Wikipedia pages:

Binary prefix - http://en.wikipedia.org/wiki/Gibi
SI prefix - http://en.wikipedia.org/wiki/SI_prefix



Niall O Broin

[Google Kreme]
> Here's the math:
>
> 1GB = 1,073,741,824 bytes
> 200GB = 214,748,364,800 bytes

The correct (since January 1999) math is:

1 gibibyte (GiB) = 2^30 bytes = 1,073,741,824 bytes
1 gigabyte (GB) = 10^9 bytes = 1,000,000,000 bytes

Of course, although the IEC and IEEE and many others have adopted the
new names, they're not in common use. However, the hard drive
manufacturers/retailers are correct (according to these standards) in
using 200GB to refer to 200,000,000,000 bytes and not 214,748,346,800
bytes.

Since the prefixes are being adopted by more and more organisations,
Apple should really lead the way here (as they have in other ways),
and display "GiB" (etc) for file sizes (or, I suppose, continue to
use GB, but divide the number of bytes by 1,000,000,000, not
1,073,741,824).

=Tony.Meyer

At 11:39 PM -0800 10/30/06, Luis de la Rosa wrote:
>BareFeats had an interesting article a few months back with the
>first rev of MacBook Pros and they concluded that 7200RPM was only
>worth it if you were doing audio/video editing. The article is at
><http://www.barefeats.com/5472.html> But I'm not so sure - my
>external 7200RPM 2.5" FW400 drive is definitely better for
>everything, including booting and "normal operations".

If they tested with the same capacity drive, but different rpms, then
their data does not address my question. But they don't say anything
about the capacities about the internal drives they tested. I think
that they implies that they are the same capacity, but they don't say
so explicitly.

>Short answer: if you want performance, get the highest RPM.

Well, that's the conventional wisdom, certainly. I wonder if it is
actually true all the time. I don't know, and I am hoping someone on
this list can drop some knowledge on me so I can evaluate it.

To be very specific: would a 100GB/5400rpm drive perform better by
any measure of performance than a 200GB/4200rpm (if they had the same
seek time)?

(I've already ordered the 200GB, but people come to me for advice all
the time, and I'd like to have a better sense of where this answer
comes from, and the limits on its applicability.)

--

=Alex Hoffman
Leadership Policy & Politics
Teachers College, Columbia University

On Oct 30, 2006, at 11:39 PM, Google Kreme wrote:

> The reason that a 200GB drive does not format to 200GB has nothing to
> do with 'formatting' it has to do with Hard Drive manufacturers lying
> about capacities.

Following ISO standards.

At 7:52 PM -0800 2006/10/30, Alexander Hoffman wrote:
>I have ordered a new MacBook Pros (and will post about using naturally
>speaking) and would like to confirm with you guys about hard drive
>speed (by which I mean throughput). This is prompted by seeing people
>complain (elsewhere) that they wouldn't get the 200GB option because
>it is only 4200rpm and lamenting the lack of 7200rpm options.
>
>Apple's MBP hard drive options are:
>(a) 120GB 5400 rpm
>(b) 160GB 5400 rmp
>(c) 200GB 4200 rmp

        I would definitely get 200gb, but I am always out of space,
and adding drives to a laptop is suboptimal compared to a desktop.

>There are other (third party) options out there as well. For example,
>(d) 100GB 7200rmp.
>
>Of course, we all understand hard drive capacity. They list
>unformatted capacity, not formatted. But what about speed (and I'll
>leave cache and seek time out of this).
>
>Clearly, a drive with greater rmp would be faster than one with
>slower rmp at the same capacity. What about the same rmp, but
>different capacities?
>
>A larger capacity hard drive must store data more densely. So, it
>strikes me that (b) above would be faster than (a) above, even though
>they are both 5400rmp. If data is denser, then there would be more
>data per revolution. So, if (b) the same number of revolutions per
>minute with more data per revolution, it would be a faster hard drive
>(in terms of throughput). Is that right?

        Yes, although I wouldn't expect it to matter as much as RPM.
With the same number of platters, a 200gb drive at X RPM might
read/write twice as fast as a 100gb drive at the same RPM. This
assumes that they both have the same number of tracks from inside to
outside, which may not be a good assumption. The more likely way to
double capacity is to add platters, with the same areal (linear)
density.

>If that is right, what is the relationship? Would (c) be faster than
>(d)? Does doubling the data density make for going from 7200rpm to
>4200rpm?

        I doubt it.

>Which then gets to other aspects of speed. Does seek time vary that
>much between 2.5" SATA drives? Enough to matter to me? (ecommence
>sites, major data base work, could care, but should I?) And does the
>meaning of seek time vary with hard drive capacity or rmp? Of course,
>caches matter too, I have no doubt.

        It affects booting (a lot, as this is largely reading from
disk into RAM), patching, and anything that isn't CPU-bound. Not word
processing, which is mostly keyboard/finger bound, but large
reformatting. HTML rendering is likely swamped by download speed, but
not on cached pages...

>Chris Pepper told me that two 5400rmp 2.5" drives can be preferable
>to a single 10,000prm 3.5" drive at the same total capacity, which is
>really interesting to me. So I wonder about all these other aspects
>of drive speed.

        No!!! I wasn't talking about 5400RPM drives; I was talking
about SAS and SFF SCSI (same mechanisms, different connectors),
running at 7200rpm+ (in servers). Two 10kRPM 2.5" 73gb drives will
have much better seeks and excellent read/write performance compared
to a single 10kRPM 146gb 3.5". I don't know if they're faster than a
15k 3.5".

        Also, you get 2 drive busses rather than 1, so if any drive
reaches bus saturation, splitting out to 2 busses would help there.

        For laptops, the trade-offs are different.

>What are the rest of the specs on the Apple options for MBP hard
>drives? Is there a way to get that information?

        Not quite. Apple reserves the right to change models, so once
you hear what someone got in their MBP2 you have a data point, and
can check the vendor's site, but no guarantee Apple will ever use
that mechanism again.


                                                Chris
--
Chris Pepper: <http://www.reppep.com/~pepper/>
                             <http://www.reppep.com/weblog/pepper/>
Rockefeller University: <http://www.rockefeller.edu/>

On 31 Oct 2006, at 10:28 , Johann Beda wrote:
> At 11:39 PM -0800 10/30/06, Google Kreme wrote:
>> Here's the math:
>>
>> 1GB = 1,073,741,824 bytes
>
> Actually, if one is using SI notation, 1 GB = 1,000,000 B

Yes, well, this is another example of academia and committees being
wholly divorced from reality. And in this case, succumbing to
marketing-speak.

> But what do we call 1,073,741,824 bytes? "The IEC recommends that
> this unit should instead be called a gibibyte (abbreviated GiB)"

Yeah. Right. That's going to happen. Er, never.


--
If we get through this alive I'll meet you next week same place same
time

On 31 Oct 2006, at 15:28 , Niall O Broin wrote:
> On 31 Oct 2006, at 07:39, Google Kreme wrote:
>
>> On 30 Oct 2006, at 20:52 , Alexander Hoffman wrote:
>>> Of course, we all understand hard drive capacity. They list
>>> unformatted capacity, not formatted.
>
> Well, clearly we DON'T all understand hard drive capacity.
>
>> The reason that a 200GB drive does not format to 200GB has nothing to
>> do with 'formatting' it has to do with Hard Drive manufacturers lying
>> about capacities.
>
>> Here's the math:
>>
>> 1GB = 1,073,741,824 bytes
>> 200GB = 214,748,364,800 bytes
>
> Of course the manufacturers like to present their products in the
> best light, but they can argue that they are NOT lying (misleading is
> a different question - but hey, that's why they pay the marketers the
> big bucks).
>
> The root cause of the problem is that Google Kreme

And ever OS on the planet, including OS 6-9, Mac OS X, Windows 3.0-
XP, and every flavor of Unix and Linux and Unix-like out there...

> is interpreting
> the prefix giga to mean 1,073,741,824 and drive manufacturers are
> interpreting it to mean 1,000,000 and guess what - shock! horror! -
> the drive manufacturers are strictly correct.

No, they really aren't.

> The prefixes kilo.
> mega, giga are SI Units and are expressed as powers of 10.

Not in computers, where kilo- is ONLY 1024 and NEVER 1000. Ever.
And mega- is not 1,000,000 but 1,048,576. And kilo- and mega- have
always been clearly delineated in computers to mean these specific
powers of 2. It was only with the advent of marketing-speak on the
part of the HD manufacturers that there was ever a confusion
created. A kilometer is 1,000 meters. A kilobyte is 1024 bytes.

> Due to the confusion arising the IEC in 1999 introduced the prefixes
> kibi-, mebi-, gibi-, etc., and the symbols Ki, Mi, Gi, etc. to
> specify binary multiples of a quantity.

Which absolutely no one uses.

  $ ls -ls
206005 -rw-r--r-- 1 kreme kreme 105474457 May 26 09:46 tom waits
- heartattack and vine.rar
$ ls -lsh
206005 -rw-r--r-- 1 kreme kreme 100M May 26 09:46 tom waits
- heartattack and vine.rar

Notice it's not "105M". It never has been. It never will be.

> These are not at all widely
> used in the common parlance, but the fact remains that they DO exist
> and hence, the drive manufacturers' use of G as 1,000,000 is correct
> according to the relevant international standards.

This is what is known in the comic book world as a "retcon".

--
and I swear it happened just like this: / a sigh, a cry, a hungry
kiss / the Gates of Love they budged an inch / I can't say much has
happened since / but CLOSING TIME

On Wed, 1 Nov 2006, Google Kreme wrote:

>> The prefixes kilo.
>> mega, giga are SI Units and are expressed as powers of 10.
>
> Not in computers, where kilo- is ONLY 1024 and NEVER 1000. Ever.
> And mega- is not 1,000,000 but 1,048,576. And kilo- and mega- have
> always been clearly delineated in computers to mean these specific
> powers of 2. It was only with the advent of marketing-speak on the
> part of the HD manufacturers that there was ever a confusion
> created. A kilometer is 1,000 meters. A kilobyte is 1024 bytes.

Kilo- and mega- can have either meaning with respect to computers,
especially in networking - one kilobit-per-second is 1000 bits per second
not 1024; one megabit per second is 1000000 bits per second etc.


--
Alistair Riddell - BOFH
Microsoft - because god hates us

At 1:06 AM -0800 11/1/06, Google Kreme wrote:
>> The prefixes kilo.
>> mega, giga are SI Units and are expressed as powers of 10.
>
>Not in computers, where kilo- is ONLY 1024 and NEVER 1000. Ever.
>And mega- is not 1,000,000 but 1,048,576. And kilo- and mega- have
>always been clearly delineated in computers to mean these specific
>powers of 2. It was only with the advent of marketing-speak on the
>part of the HD manufacturers that there was ever a confusion
>created. A kilometer is 1,000 meters. A kilobyte is 1024 bytes.

        Just because you shout it, doesn't make it so. My minimal searching
seems to indicate that the use of decimal (rather than binary) units was
standard for early computer serially accessed storage media, well before
the common usage of binary units. Clock speeds have always been in decimal
as far as I can tell, as have most other transmission bandwidth statements.

        Standards and usage are both socially constructed and evolve
together. Since 1999 there has been an agreed upon standard for binary
prefixes - replacing the inconsistent usage of decimal and binary forms.
With the intersection of "computers" with "telecom" and all sorts of other
related and unrelated fields - it behoves us all to at least understand
what the agreed upon standards are.

<http://en.wikipedia.org/wiki/Binary_prefix>

        That page states that "Most hard disk manufacturers state capacity
in decimal units. This usage has a long tradition, even predating the SI
system of decimal prefixes adopted in 1960. The decimal-based capacity in
hard disk drives follows the method used for serially accessed storage
media which predated direct access storage media like hard disk drives. As
a stream of data has no inherent chunk or block size, it follows to measure
how many thousands, millions, or billions of bytes have been stored, in the
same way most quantities are measured (rather than multiples of 1,024,
1,048,576, or 1,073,741,824 bytes). When the first hard disk drives were
developed, the decimal measurement continued the tradition of punch cards
and tapes. Thus, today, most devices that are addressed or seen as
"storage" use the decimal system to identify capacity."




--
* Johann Beda - contact link: <http://xri.net/=j-beda> *
* Johann's MostlyMac Computer Consulting - <http://mmcc.beda.ca/> *

On 11/1/06 03:06, "Google Kreme" <gkremegmail.com> wrote:

>> These are not at all widely
>> used in the common parlance, but the fact remains that they DO exist
>> and hence, the drive manufacturers' use of G as 1,000,000 is correct
>> according to the relevant international standards.
>
> This is what is known in the comic book world as a "retcon".

And it is even MORE annoying in "real" life than it is in the comics.

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

On Oct 31, 2006, at 4:28 PM, Alexander Hoffman wrote:

> Well, that's the conventional wisdom, certainly. I wonder if it is
> actually true all the time. I don't know, and I am hoping someone on
> this list can drop some knowledge on me so I can evaluate it.

I think any given drive reads data faster on the first half than the
last half, at any given RPM. I'm not sure about writing, but it seems
that with video capture, which I do regularly, there is a noticeable
difference in reading to or writing from a drive that is less than
half full compared to the same drive if it is 70-80% full. I
generally don't use the last 10% of any drive. I allow backup drives
to approach 90% capacity. I keep open project and system disks at 60%
capacity or less, generally.

>
> To be very specific: would a 100GB/5400rpm drive perform better by
> any measure of performance than a 200GB/4200rpm (if they had the same
> seek time)?

Well, if I were pretty sure I would need 90 of the 100GB on a 5400RPM
drive, I'd probably opt for the 200GB drive and try to keep my usage
under 120GB total if I wanted the best average performance. In other
words, I think that a less than half full 200GB 4200rpm drive would
perform a little better than a 90% full 100GB 5400rpm drive,
especially after a few months of use. Again, this depends a bit on
the types of files used. I would expect that larger files (multi-GB
sized) would be affect performance the most.

(In the 'old days', if I am thinking clearly, we used to have
utilities that allowed us to store some types of data on the insides
of the disk platters, while more speed-sensitive data was kept on the
outside. But I don't know if that is even possible now. But with HD
prices getting down to 20 cents/GB, it's getting relatively painless
to just solve the problem with bigger drives and RAID.)

Regards,
Jeffrey

At 23:39 on 30-10-2006, Google Kreme wrote:
> The reason that a 200GB drive does not format to 200GB has nothing
> to do with 'formatting' it has to do with Hard Drive manufacturers
> lying about capacities.

Disturbingly, this seems to be the trend for DVD-Rs as well. They're
advertised as '4.7GB'. The first few time I used one, when I couldn't
fit more than around 4.3GB on it, I was initially confused. While the
4.7GB designation might be technically correct, it is misleading
because of how CD-Rs have been marketed. Manufacturers use binary for
CD-Rs (700MiB advertised as 700MB) and base 10 for DVD-Rs (4.7GB
advertised as 4.7GB). They can't be so inconsistent and then claim
that they are just 'following standards'. I keep on meaning to write
to the advertising standards agency to see if something can be done,
but haven't had the time yet. :-)

_________________
=> Jolin Warren, Edinburgh, Scotland

At 01:06 -0800 1/11/06, Google Kreme wrote:
>Not in computers, where kilo- is ONLY 1024 and NEVER 1000. Ever.
>And mega- is not 1,000,000 but 1,048,576. And kilo- and mega- have
>always been clearly delineated in computers to mean these specific
>powers of 2. It was only with the advent of marketing-speak on the
>part of the HD manufacturers that there was ever a confusion
>created. A kilometer is 1,000 meters. A kilobyte is 1024 bytes.

With K there's an easy distinction - in SI units, the prefix is k
(lower case), as K (upper case) is the symbol for the unit of
temperature. So computer jargon could get away with using K
(uppercase) as a prefix meaning 1024 without too much confusion.
Unfortunately, Mega, Giga and Tera and M, G and T in SI
abbreviations. So confusion is widespread.

E.g., does Firewire 400 run at 400,000,000 bps or 4,194,304Mbps?

And it's not just HD manufacturers, and it's not recent - the 1.44MB
floppy disk is neither 1,440,000 bytes, nor 1.44*1,048,576 bytes,
it's 1,440*1024 bytes.

What a mess.

Very few people use them now, But I'd be very pleased to see Kibi
(Ki), Mebi (Me), Gibi (Gi), and Tebi (Te) come into common use.

--
Paul Durrant

I'm also conflicted. I want 200 GB, but 4200 RPM sounds slow. However, I don't have any real data on how slow. I remember when 3600 was considered high speed.

I agree with whoever said the biggest speed improvement is maxing out your RAM to 3 GB.

At 2:33 PM -0800 10/31/06, Chris Pepper wrote:
>At 7:52 PM -0800 2006/10/30, Alexander Hoffman wrote:
>>A larger capacity hard drive must store data more densely. So, it
>>strikes me that (b) above would be faster than (a) above, even though
>>they are both 5400rmp. If data is denser, then there would be more
>>data per revolution. So, if (b) the same number of revolutions per
>>minute with more data per revolution, it would be a faster hard drive
>>(in terms of throughput). Is that right?
>
> Yes, although I wouldn't expect it to matter as much as RPM.
>With the same number of platters, a 200gb drive at X RPM might
>read/write twice as fast as a 100gb drive at the same RPM. This
>assumes that they both have the same number of tracks from inside to
>outside, which may not be a good assumption. The more likely way to
>double capacity is to add platters, with the same areal (linear)
>density.

With greater data density raw reads will be faster, that's true. But most disk accesses (video editing aside) are small, and the track to track seek time, and read ahead cache algorithm are also important.

At 12:19 PM -0800 11/1/06, Jeffrey McPheeters wrote:
>I think any given drive reads data faster on the first half than the
>last half, at any given RPM.

It's true that the outer tracks are "faster" that the inner tracks, both because the platter spins faster under the head, so sectors read in faster, and because there are more sectors per track, so you end up seeking less. But you can't control where on the disk any given file is stored, so there's no practical way to take advantage of this.

>I'm not sure about writing, but it seems
>that with video capture, which I do regularly, there is a noticeable
>difference in reading to or writing from a drive that is less than
>half full compared to the same drive if it is 70-80% full. I
>generally don't use the last 10% of any drive. I allow backup drives
>to approach 90% capacity. I keep open project and system disks at 60%
>capacity or less, generally.

This is a key observation. As your disk gets full, it gets more fragmented. So accessing any given file gets slower, simply because the head has to go all over the place.

For the same amount of data, the 200 GB 4200 RPM drive may be competitive with the 160 GB 5400 RM drive simply because it would be so much less fragmented. And this applies even more to the VM backing store file.

--
David

On 01 Nov 2006, at 13:19 , Alistair Riddell wrote:
> Kilo- and mega- can have either meaning with respect to computers,
> especially in networking - one kilobit-per-second is 1000 bits per
> second
> not 1024; one megabit per second is 1000000 bits per second etc.

This is true, at least historically, for serial devices. It was
never the case for memory or hard drives until the Hard Drive
companies started referring to 100MB drives as "104MB". And that is
the point at which it started too, previous drive sizes of 10MB, 40MB
or even 80MB where, in fact, the right size.

I wonder how much space is set aside of a hard drive for the FAT, file allocation tables. I assume it takes alot for big hard drives.

Jack Hodges

I can't remember who first suggested this, but it seems like a good idea to me: refer to the power-of-two units of data as "binary" and the power-of-ten units as "metric" (or maybe "SI" or "ISO"). Backwards compatibility with most existing computing literature appears to demand that unqualified usage should be interpreted as binary in the case of bytes, and metric in the case of bits. In new documents, if you use the units a lot, just note your usage for the reader, e.g. "All units of data (kB, GB, etc.) in this document are metric unless otherwise noted -- e.g. 1 MB = 1,000,000 bytes."

OTOH, for infrequent usage, you can just add the qualifier, e.g. "The hard drive has a capacity of 200 binary GB.", "The bus achieves transfer rates of 500 metric MB per second." Doesn't sound nearly as silly as "mibibyte", does it? ;)

IMHO, storage device advertising should have to list both, equally prominently, so the box should say something like, "Capacity: 200 GB (metric) / 186 GB (binary)".

On Nov 7, 2006, at 7:52 AM, David Shayer wrote:

> I'm also conflicted. I want 200 GB, but 4200 RPM sounds slow.
> However, I don't have any real data on how slow. I remember when
> 3600 was considered high speed.
>
> I agree with whoever said the biggest speed improvement is maxing
> out your RAM to 3 GB.

While RAM is a big help, I would never go back to a 4200 RPM drive.
Despite the lackluster gains in the PPC CPU lines, the hard drives
were actually making even less performance gains in the same period.
Capacity was increasing, but transfer rates were not.

It's too bad Apple removed the 7200 RPM option from the MBP, that's
what I ordered with the rev1. It's a noticeable difference in pep.
With Spotlight and the metadata indexing, and soon to be time machine
processing, there is more and more processing and disk access with
every write to your disk. Disk speed is one of the last remaining
limiting factors in the MBP.

Steve

FYI, something I finally found the answer to recently was the 3GB
limit on the memory. In the current Intel chipset being used, seems
that the PCI bus addresses overlap where the last 720MB of memory
would be. So if you put 4GB in, you'd only end up with 3.2 usable. I
can understand why Apple didn't offer users the chance to buy a 2GB
chip, only to be able to use 1.3 GB of it.

At 4:52 AM -0800 2006/11/07, Paul Durrant wrote:
>At 01:06 -0800 1/11/06, Google Kreme wrote:
>>Not in computers, where kilo- is ONLY 1024 and NEVER 1000. Ever.
>>And mega- is not 1,000,000 but 1,048,576. And kilo- and mega- have
>>always been clearly delineated in computers to mean these specific
>>powers of 2. It was only with the advent of marketing-speak on the
>>part of the HD manufacturers that there was ever a confusion
>>created. A kilometer is 1,000 meters. A kilobyte is 1024 bytes.
>
>With K there's an easy distinction - in SI units, the prefix is k
>(lower case), as K (upper case) is the symbol for the unit of
>temperature. So computer jargon could get away with using K
>(uppercase) as a prefix meaning 1024 without too much confusion.
>Unfortunately, Mega, Giga and Tera and M, G and T in SI
>abbreviations. So confusion is widespread.
>
>E.g., does Firewire 400 run at 400,000,000 bps or 4,194,304Mbps?
>
>And it's not just HD manufacturers, and it's not recent - the 1.44MB
>floppy disk is neither 1,440,000 bytes, nor 1.44*1,048,576 bytes,
>it's 1,440*1024 bytes.

        Note that file sizes are *usually* base 2 (on UNIX, they were
historically based on disk blocks, which are normally 512 bytes, so
1024 is an easy calculation, but 1000 would have normally required
rounding/truncation), and 'wire' speeds (including wireless, I
presume) are normally (rounded) base 10.

        LAN networking is base 10; current stuff is all conceptually
descended from 10BASE-T Ethernet, at 10,000 bits/sec (10,000 Hertz).

        On the other hand, telecom speeds are based around multiples
of some slightly funky 'base' units. A 56kbps serial port actually
runs at 57,600 bits/sec, and I suspect that's the actual max download
speed of a '56k' modem. Note that max upload speed of a '56k' modem
is substantially lower -- not in the 56kbit neighborhood. This goes
back to 300bits/sec serial ports, and all serial port speeds are
multiples of 300bps (yes, I know there were lower serial speeds
before 300baud).

        IIRC, T1s are actually 1,544 bits/sec or something like that.
The telecom rates are similarly multiples of some telecom standard
units.


                                                Chris
--
Chris Pepper: <http://www.reppep.com/~pepper/>
                             <http://www.reppep.com/weblog/pepper/>
Rockefeller University: <http://www.rockefeller.edu/>

At 5:14 AM -0800 11/7/06, Jack Hodges wrote:
>I wonder how much space is set aside of a hard drive for the FAT, file allocation tables. I assume it takes alot for big hard drives.

You can calculate this.

Divide the disk size by the cluster size to get the total number of clusters. (Values are in the boot sector)

There are 128 entries per sector in the FAT table, so divide by 128 to get the number of sectors used for the FAT.

Multiply by 2, because most disks have 2 FATs (you can check in the boot sector).

And now you know how much room the FATs take. QED. :-)

Of course Macs use HFS+, not FAT. HFS+ is a *lot* more complex than FAT. It's described here.

http://developer.apple.com/technotes/tn/tn1150.html
--

David


"Mission Accomplished" - May 1, 2003

On 7/11/06 22:53, "Chris Pepper" <pepperreppep.com> wrote:

> LAN networking is base 10; current stuff is all conceptually
> descended from 10BASE-T Ethernet, at 10,000 bits/sec (10,000 Hertz).

You meant 10,000,000 Hz; but actually 10BaseT's signal is clocked at 20 MHz,
and the basic Manchester encoding used makes effective bit rate only half of
that at 10 Mb/s. That's why descending to the physical layer is perilous,
but marketing departments don't care (see my previous post about Fibre
Channel). :)
And don't assume then that Fast Ethernet's signal is at 200 MHz: it's 125
MHz, for 100 Mb/s effective... The physical layer is different.

> IIRC, T1s are actually 1,544 bits/sec or something like that.

Right, a T1 is formed of 24 DS0 channels (64 kb/s each, enough for one
analog telephone communication) plus 8 kb/s of overhead, for a total of
1.544 Mb/s.

> The telecom rates are similarly multiples of some telecom standard
> units.

Like DS3, OC-3, OC-12, OC-48, etc. for North America, and E1, E3, STM-1,
STM-4, STM-16, etc., for Europe.

-- Thomas Perrier

David Shayer wrote:
> At 2:33 PM -0800 10/31/06, Chris Pepper wrote:
>> At 7:52 PM -0800 2006/10/30, Alexander Hoffman wrote:
>
> At 12:19 PM -0800 11/1/06, Jeffrey McPheeters wrote:
>> I think any given drive reads data faster on the first half than
>> the last half, at any given RPM.
>
> It's true that the outer tracks are "faster" that the inner tracks,
> both because the platter spins faster under the head, so sectors read
> in faster, and because there are more sectors per track, so you end
> up seeking less. But you can't control where on the disk any given
> file is stored, so there's no practical way to take advantage of
> this.
And most "modern" drives put more data on the longer outside tracks than
on the inner tracks.
>
>> I'm not sure about writing, but it seems that with video capture,
>> which I do regularly, there is a noticeable difference in reading
>> to or writing from a drive that is less than half full compared to
>> the same drive if it is 70-80% full. I generally don't use the last
>> 10% of any drive. I allow backup drives to approach 90% capacity. I
>> keep open project and system disks at 60% capacity or less,
>> generally.
>
> This is a key observation. As your disk gets full, it gets more
> fragmented. So accessing any given file gets slower, simply because
> the head has to go all over the place.

Even when this isn't so very large files incur extra seeks to get to
specific places in a file. At least with HFS+ and other similar
implementations.

> For the same amount of data, the 200 GB 4200 RPM drive may be
> competitive with the 160 GB 5400 RM drive simply because it would be
> so much less fragmented. And this applies even more to the VM backing
> store file.

All of this gets very complicated when you look at variable data per
track, 1 head vs 4, etc... A two platter 4 head drive "should" be faster
in some ways than a newer 1 plater 2 head drive as it's much faster to
switch to from one head to another instead of seeking to another track.
But if the newer drive is denser it might appear faster for simple use.
But the CPU in most disk drives is much more capable than a MacII or
later computer and has much more ram and does lots of things in terms of
bad sector remapping, look ahead caching, cache size optimization, etc...

But end the end for a single user machine doing moderately disk
intensive things, rotational speed is the most user noticeable thing.

YMWV

When you receive the new MBP, I would be interested to have some real life data regarding the performance of the hard disks, especially the 4200 rpm 200GB disk. Best would be a direct comparison with the other disks, but short of that, I'd like some timing numbers, such as boot time, Finder copy time for a large file (try a CD image file for example) and for a large directory with many smaller files, opening time for a large text file in TextEdit or large image in Preview, or some such...

Thanks,

JD

Can one get meaningfull numbers on hard disk performance and data transfer speeds from the downoadable utilities like Disk Speed Bench and MBBench?

How does the purported ease of swapping out the HD on a MacBook Pro influence your disk selection decision? I could imagine ordering the lower capacity, faster drive option now, with the expectation that in a few months, for around $100, I will be able to pick up a new drive that is both faster and bigger than any of Apple's current offerings for the MacBook Pro.

Being able to install the new drive myself, if it is as easy as Steve Jobs implied, cuts the cost of upgrading the hard drive to less than half of what the upgrading services charged for putting a bigger drive in a PowerBook or iBook.

derek wrote:
> Can one get meaningfull numbers on hard disk performance and data
> transfer speeds from the downoadable utilities like Disk Speed Bench
> and MBBench?
Yes, but with a HUGE but.

It's like coming up with an automobile review charge and applying it to
everything made by Ford. From farm tractors to sedans to big rigs.

My mother in law thinks of her computer and the Internet as one and the
same. Disk drive speed to her cold drop by half or double in EVERY
metric and she'd likely not notice.

Someone with 10,000 iTunes or iPhoto images will have a very different
experience than someone who works in Word or Excel.

As someone who's done configuration management for both in house setups
and software to be sold for over 20 years, the more you move from
looking at a single very specific application to a broad category of
user, the harder it is to quantify the result of a "better" drive.

Given all of the above there are some broad assumptions most folks can make.

Faster spinning will feel snappier.
(Things load faster.)

More platters will feel snappier.
(You seek less.)

Faster spinning will draw more power.
(Higher performance motor needed.)

Fewer platters will draw more power.
(More seeking will be required.)

More platters will draw more power.
(Bigger motor power to spin things.)

Notice how my last two point contradict each other. It depends on usage.
  I.E. how often will you cause a seek?

But even the above comments break down when comparing drives that are
from different generations, manufacturers, or design lines.



YMWV (Will being the operative word.)

At 11:22 AM -0800 11/9/06, derek wrote:
>How does the purported ease of swapping out the HD on a MacBook Pro
>influence your disk selection decision? I could imagine ordering the
>lower capacity, faster drive option now, with the expectation that
>in a few months, for around $100, I will be able to pick up a new
>drive that is both faster and bigger than any of Apple's current
>offerings for the MacBook Pro.

Extremely easy in a MacBook, where it is a simple user upgradable
part. You can get the drive out without an screw driver. You just
need one to remove the screws that hold the shielding to the drive
(which might only exist so there is something to which the tab you
pull on to remove the drive can be attached).

Not as easy in a MacBook Pro. 19 screws and two ribbon cables to be
careful with.

I don't think that Jobs said anything about drive upgrades in an MBP, did he?

--

=Alex Hoffman
Leadership Policy & Politics
Teachers College, Columbia University

On Nov 10, 2006, at 3:12 PM, Alexander Hoffman wrote:

> Extremely easy in a MacBook, where it is a simple user upgradable
> part. You can get the drive out without an screw driver. You just
> need one to remove the screws [...]

...which, err, is considerably easier with a screw driver :-)

That said, yes, it's a 5 minute task, and of the same complexity as
installing RAM. If you can replace RAM modules, you can replace the
Macbook's hard drive.

Well, okay, putting data on the drive will take longer than 5
minutes. If I'm going to split hairs about the screwdriver, I suppose
someone else will split hairs about my time estimate :-)


--
Chris Devers

--On November 10, 2006 8:31:49 AM -0500 Alexander Hoffman
<ahoffmanAleDev.com> wrote:

>> How does the purported ease of swapping out the HD on a MacBook Pro
>> influence your disk selection decision? I could imagine ordering the
>> lower capacity, faster drive option now, with the expectation that
>> in a few months, for around $100, I will be able to pick up a new
>> drive that is both faster and bigger than any of Apple's current
>> offerings for the MacBook Pro.

My (unreliable) memory is that Steve touted the drive-swapping ease during
last January's MacWorld Keynote, when the MacBook Pro was announced. The
MacBook (Amateur) didn't appear until a few months later, and I don't
remember watching any media event for that, if there was one.

It's ironic that swapping the hard drive in the MBA is so much easier than
in the MBP, since professionals are much more likely to upgrade their
drives.

Derek

At 5:17 AM -0800 11/7/06, Joshua Root wrote:
>I can't remember who first suggested this, but it seems like a good idea
>to me: refer to the power-of-two units of data as "binary" and the
>power-of-ten units as "metric" (or maybe "SI" or "ISO").

        It is always good to be specific about what units are being use -
however one should not specify "186 GB (binary)", rather one should use the
IEC standard term: "186 GiB". Since GiB has no other history of usage,
there should never be any ambiguity when using it. Adding "metric/SI/ISO"
to any usage of GB is probably a good idea.

<http://en.wikipedia.org/wiki/Binary_prefix>
<http://en.wikipedia.org/wiki/Gibibyte>

--
* Johann Beda - contact link: <http://xri.net/=j-beda> *
* Johann's MostlyMac Computer Consulting - <http://mmcc.beda.ca/> *

>--On November 10, 2006 8:31:49 AM -0500 Alexander Hoffman
><ahoffmanAleDev.com> wrote:
>
>It's ironic that swapping the hard drive in the MBA is so much easier than
>in the MBP, since professionals are much more likely to upgrade their
>drives.

And perhaps more adept at making the more difficult installations.

Richard

On Nov 13, 2006, at 8:48 PM, Chris Devers wrote:

> That said, yes, it's a 5 minute task, and of the same complexity as
> installing RAM. If you can replace RAM modules, you can replace the
> Macbook's hard drive.

I replaced the drive in my new MacBook right away with a 7200 RPM
100GB model (Seagate). It was easy, but it requires one more tool
than a simple screwdriver: that is a TORX driver. The screws that
hold the drive to it's carrier are TORX #8 or 9, (sorry can't
remember exactly). Other than that, it was an uneventful experience.

Regards,

Howard

On Nov 13, 2006, at 8:48 PM, Derek Roff wrote:

> It's ironic that swapping the hard drive in the MBA is so much
> easier than
> in the MBP, since professionals are much more likely to upgrade their
> drives.

After watching an instructional video of installing a hard drive in
my MacBook Pro, I ended up shipping mine to TechRestore to have a
160GB drive installed rather than installing one myself. I've done
plenty of hard drive upgrades on desktop Macs and RAM upgrades on
both desktop & laptops, but a MBP hard drive upgrade requires
removing over 20 screws and getting into some very tight spots.

--On 10/30/06 11:39 PM -0800 Google Kreme wrote:

> The reason that a 200GB drive does not format to 200GB has nothing to
> do with 'formatting' it has to do with Hard Drive manufacturers lying
> about capacities.
[...]
> However, Hard Drive vendors sell a drive that hold 200,000,000,000
> bytes as a "200GB" drive. Simple math will show you that a drive
> that hold 200,000,000,000 bytes is, in fact, 186.25GB. And when you
> format a "200GB" drive you get a drive that holds, amazingly enough,
> 186.25GB<2>. You didn't lose 14GB, it was never there.

I know this particular dead horse has been beaten pretty thoroughly over
the past week, but I wanted to add an observation based on the 160GB drive
I bought yesterday...

The fine print on the box says:

"1 GB = 1,000,000,000 bytes. Total accessible capacity varies depending
upon operating environment (typically 5-10% less)."

Now since the actual capacity IS 160 times 10^9 bytes, and since formatting
does NOT really use 5-10% of the space, I think this disclaimer is
basically an admission that the quoted capacity is an exaggeration (or lie)
rather than an argument that the base-10 GB is somehow a more correct unit
than the base-2 GB.

Another thing to note is that as the sizes get bigger, the difference
between base-10 and base-2 grows.

KB: binary = 1.024 * decimal
MB: binary ≈ 1.049 * decimal
GB: binary ≈ 1.073 * decimal
TB: binary ≈ 1.100 * decimal

and so the larger our units the more significant the difference.

Dave Scocca

>On Nov 10, 2006, at 3:12 PM, Alexander Hoffman wrote:
>
>>Extremely easy in a MacBook, where it is a simple user upgradable
>>part. You can get the drive out without an screw driver. You just
>>need one to remove the screws [...]
>
>...which, err, is considerably easier with a screw driver :-)

Give me another piece of shielding with the tape on it, and I can
swap macbook drives without a screwdriver. That is what I was trying
to say.

And so, I maintain that I don't need a screwdriver to remove a macbook drive.
--

=Alex Hoffman
Leadership Policy & Politics
Teachers College, Columbia University

On Nov 14, 2006, at 3:37 PM, Howard Kaufman wrote:

> I replaced the drive in my new MacBook right away with a 7200 RPM
> 100GB model (Seagate). It was easy, but it requires one more tool
> than a simple screwdriver: that is a TORX driver. The screws that
> hold the drive to it's carrier are TORX #8 or 9, (sorry can't
> remember exactly). Other than that, it was an uneventful experience.

Just about every Mac laptop I can remember has used Torx screws in at
least some capacity, and I've owned just about everything from the
500 series on. I believe it's Other World Computing even sells a
little screwdriver with the three types of heads required for mac
laptop work.

Steve

On Nov 14, 2006, at 12:46 PM, Dave Scocca wrote:

> Now since the actual capacity IS 160 times 10^9 bytes, and since
> formatting
> does NOT really use 5-10% of the space, I think this disclaimer is
> basically an admission that the quoted capacity is an exaggeration
> (or lie)
> rather than an argument that the base-10 GB is somehow a more
> correct unit
> than the base-2 GB.

File system creation for NO common* file system costs 5 to 10 %?
Those Unix/Linux file systems which copy the inode tables
periodically across the file system space (for backup) are pretty
greedy now that the inode tables are pretty big.

Plus, some fraction is set aside at formatting time for substitute
sectors. Not sure what fraction these days. One might hope that
those sectors are not counted in the label capacity, but don't bet on
that.

As density increases, so does the amount of substituting going on.
(At least one person I trust asks for the SMALLEST drive he can get
of a given type when he needs a new drive, to try to cut down on the
almost constant error repairs being done by the ECC on modern drives--
which only lead to sparing out in extreme cases.)

   --John

*Actually, even one very uncommon file system would justify the
claim, sort of.

Someone has VERY politely pointed out that I am wrong on the no
screwdriver comment on the MB drive removal.

I had forgetting about the the l-shaped metal thing with the three screws.

So let me be clear here.

1) I was wrong.

2) You DO need a philips head screwdriver even to remove a MB hard
drive. (In addition the the tiny torx screwdriver to change the
drive.)

3) I was really wrong. 100%, even.

(It's amazing that I forgot that, given how many time I removed that,
as it also must be removed to access the RAM, and I did many many RAM
and HD swaps as I was tring to figure out the random crashes and
powerdowns of my pretty black MB over the summer. Perhaps I've
blacked it out to save my sanity? Or perhaps I was just wrong?
Hmmmm...)

--
=Alex Hoffman
Leadership Policy & Politics
Teachers College, Columbia University