Talk:Hard disk drive/Archive 10

This is an archive of past discussions about Hard disk drive. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 5

←

Archive 8

→

The real history of computing

The Capacity measurements section has the statement.

Since 2¹⁰ is within a few percent of 1000, computer scientists in the early days of computing referred to a computer with 2¹⁰ bytes of memory as having a kilobyte of memory even though the prefix kilo- properly refers to precisely 1000.

If we are being pedantic here, this statement is wrong. Many early computers came with 4K, 8K, 12K or 16K words of memory. Computers like the IBM 1401 used decimal addressing so 4K was 4000 words and 16K was 16,000 words. The K was exactly 1000, not 1024. The 1401 was the most successful commercial computer in the early 1960s with over 10,000 system installed. (IBM received 5200 orders in the first five weeks, an early iPhone frenzy.) Computers with binary addressing became the dominate architecture by the late 1960s. -- SWTPC6800 (talk) 06:14, 24 April 2011 (UTC)

Thank you very much, SW. I also see at this outside article The ENIAC story, that the most famous early computer—the ENIAC, which featured the blinking panel of lights that became the iconic symbol for computers in SciFi and other genres throughout the ‘50s and ‘60s—was equipped with 100 words of static magnetic-core memory (picture) in 1953.
I am quite certain you are right; I know you specialize in this sort of thing in real life. I see that our IBM 1401 article asserts in a footnote that “K” equals exactly 1000 but I see no citation. Also, this Columbia University article is silent about the distinction. I’ll take a stab at correcting per your teachings and would greatly appreciate it if you reviewed and revised as you see necessary.
By the way, my friend has some magnetic core memory in his garage. The ferrite rings are so small, it looks like a bed of cloth. Greg L (talk) 15:10, 24 April 2011 (UTC)

P.S. Done. I didn’t cite it, SWTPC6800. I bet you can do a better job than I. That paragraph might not even need citations since I proxy-cited by merely internally linking to our own articles on the IBM 1401 and dynamic random-access memory, both of which buttress their assertions well enough. We can apparently blame guys with narrow black ties in 1969 at Intel for referring to 1024 as “1K”.
Here is a convenience link to the Capacity section of the article. Greg L (talk) 15:46, 24 April 2011 (UTC)

SWTPC6800: I read your link to how IBM received 5200 orders for the IBM 1401 in the first five weeks after its introduction. According to our IBM 1401 article, monthly rental started at $2500 in 1959. Today, that is $19,200 per month ($230,000 per year). The machine paid for itself quickly considering the alternatives in 1959 for storing, retrieving, organizing, and updating information. My parents ran a computer programming school in the late 60s and early 70s. They had a punch card-based (picture for the youngsters here who don’t know what “Don’t fold, spindle, or mutilate” means) IBM computer in the school. When they wanted to enhance its functionality around 1973, they paid a pile of extra rental per month for a little white plastic gear that enabled a punch card sorter-dumper function. My mother said “XXX bucks per month for that little gear!?!” He replied, “It’s not what the gear costs to make, it’s what it does for you.”

Here is a link showing the die of the Intel 1102: Online Archive of California: Intel® 1102 RAM Memory Die, 1970. Greg L (talk) 16:33, 24 April 2011 (UTC)

IBM 1401 core memory matrix

The IBM 1401 had 4000, eight-bit words-worth of magnetic-core memory.

There are 12 factor pairs of 4,000:

4000 = 1 x 4000
4000 = 2 x 2000
4000 = 4 x 1000
4000 = 5 x 800
4000 = 8 x 500
4000 = 10 x 400
4000 = 16 x 250
4000 = 20 x 200
4000 = 25 x 160
4000 = 32 x 125
4000 = 40 x 100
4000 = 50 x 80

None of these is a square. The memory could have been divided into ten frames, each with 400 bits, in which case the eight factors for 400 are…

400 = 1 x 400
400 = 2 x 200
400 = 4 x 100
400 = 5 x 80
400 = 8 x 50
400 = 10 x 40
400 = 16 x 25
400 = 20 x 20

I’m guessing it was 8 banks, each with 10 core panels, each panel comprising 400 (20 × 20) ferrite beads (32,000 bits of 8-bit words = 4000 words total). Anyone know for sure? Greg L (talk) 17:47, 24 April 2011 (UTC)

Non-“digressions” that are actually the point

Woodstone: I don’t agree at all with this edit nor the reasoning as outlined in your edit summary: simplify by removing digressions. Simplifying is fine; I spent a lot of time streamlining and simplifying my own text. But that sentence you tried to strip out told of the early days of computing with magnetic core memory and how—unlike today—it was in decimal form so “1 KB” of memory truly meant 1000 bytes. That is not something our typical readership would know and a full and proper exposition of the subject matter is is the whole point of an encyclopedia.

Thus, that sentence and the information it conveys is highly germane to the discussion of how past practices with terminology and capacity measurement (the very topic of that section) morphed and diverged through time to the present state of affairs. It also doesn’t hurt that the sentence ought to actually be interesting to much of our readership on a subject that can be rather dry at times. How about more “typey-typey” and less “deletey” while we’re “building the project”?

As for the footnote: that’s where “digressions” belong; particularly when they explain a glaring inconsistency: why some of the quoted examples given in the body text (like “1KB”) don’t have spaces between their values and their symbols whereas other body text and the table does have spaces. Thus, the footnote is a germane digression and a footnote is precisely where that explanation belongs. The footnote might also help avert drive-by-shootings as I.P.s try to “fix” these inconsistencies by making some uppercase “K”s into lowercase ones… because they’re in 5th grade and just learned about the SI and how the symbol for kilo- is k.

I was careful to not disturb Diego’s intervening edits as they all made perfect sense to me. Greg L (talk) 14:40, 25 April 2011 (UTC)

K was used as a binary 1024 as early as 1959

The hard disk article should explain why a new 1 TB drive only shows 931 GB. However the dual use of K for 1000 and 1024 did not start in 1969 with the Intel 1102 DRAM. This date is off by a full decade. Early computers used one of two addressing methods to access the system memory; binary (base-2) or decimal (base-10). For instance, the IBM 701 (1952) used binary and could address 2,048 36-bit words, while the IBM 702 (1953) used decimal and could address 10,000 7-bit words. The use of K in the binary sense as in a "32k core" can be found as early as 1959.

Real, P. (September 1959). "A generalized analysis of variance program utilizing binary logic". ACM '59: Preprints of papers presented at the 14th national meeting of the Association for Computing Machinery. ACM Press: pp. 78-1 – 78-5. doi:10.1145/612201.612294. On a 32k core size 704 computer, approximately 28,000 datum may be analyzed, … without resorting to auxiliary tape storage. {{cite journal}}: |pages= has extra text (help)

The IBM 704 core memory units had 4096 36-bit words. Up to 32,768 words could be installed.

The dominate computers in the early 1960s used decimal addressing and calculations. The Winter 2010 issue of the IEEE Solid-State Circuits Magazine (Digital Object Identifier 10.1109/MSSC.2009.935295) has a 12 page article on the 50th anniversary of the IBM 1401 Data Processing System. Here are a few quotes.

"The 1401 was very successful. By 1965, half of the approximately 26,000 computers in the world were 1400-family machines—models 1401, 1410, 1440, 1460, and 7010. The total number of 1400-family computers peaked at about 15,000 systems in 1967."

"The 1401 processor sequentially processed 6-bit characters or decimal digits. A single character or digit was stored per memory position, and strings of characters or digits could be arbitrarily long (up to the size of memory)."

"Memory ranged in capacity from an entry-level system with 1,400 positions to a maximum of 16,000 positions, with each position holding 8 bits: a 6-bit character or digit, a variable-length data and variable-length instruction flag called the 'word mark', and a memory 'check bit' with odd parity."

"Given its digit-serial arithmetic, 50 cycles, or approximately 0.5 ms, were required to add two positive 20-digit numbers. Today’s 4-GHz PC can add two 64-bit numbers about a million times faster."

Honeywell built a clone in 1963. "The H200 was offered with so-called 'Liberator' software that could run 1401 programs unmodified and more quickly than a 1401."

The binary addressed IBM 360 replaced the 1400 family but it included hardware that could emulate the 1401 instructions so customers could continue to run their existing software. You can see a 1401 up running at the Computer History Museum in Mountain View CA. Rebuilding the IBM 1401. -- SWTPC6800 (talk) 02:45, 26 April 2011 (UTC)

Thank you very much. I knew you, being an ~~old~~ experienced computer expert and the sleuth you are, would be able to dig up material like this. I tried to revise the text to accommodate the above and also be less specific and more generic so it avoids terminology like “first used”. I also tried to watch my booleans to make sure nothing is falsely implied. Greg L (talk) 05:11, 26 April 2011 (UTC)

A plea for sanity

The capacity measurement section has evolved into a miniature version of the Binary Prefix article written IMO from the POV of the proponents of the use of conventional binary prefixes in the use of reporting HDD capacity. This is an HDD article not a RAM article or the Binary Prefix article. Most of the added stuff lends nothing to the article (I agree with the editor who tagged much of it with "why"). I think I have made it into a fairly concise and neutral article including reliable sources for most of what I added. Some specific reasons behind my changes:

There were all sorts of different ways of saying the same thing, i tried to standardize on powers of xxxx which seems to have consensus although I would personally prefer something like decimal/binary
I don't think TB is an approved JEDEC standard nor is it used by an OS, so it is gone from binary.
The issues is the reporting of capacity by the OS and utilities, somehow that got lost. There was a great debate in the Binary Prefix discussion as to why the OSes started using conventional binary prefixes instead of IEC decimal prefixes, the CNET quote i cite is a reliable source which avoids the why but puts the consequences into perspective.

Since this has nothing do to with IEC Binary Prefixes I hope the thought police will discuss this rather than reflexively reverting my edit. Tom94022 (talk) 22:52, 26 April 2011 (UTC)

Ditto

Reply. Without expressing any view on the substance of Tom's suggestion, I -- for one -- am disturbed by his suggestion that sanity should reign here. Certainly, any such suggestion, not made in formal RFC format, with a 30-day comment period, is not appropriate. There is simply no room for sanity on this page. Nor common sense. Nor consensus. Instead, this is the padded room for those who wish to engage in non-consensus editing, dressed up as wp:bold and "new" suggestions, where less-than-fortunate souls have been sent to perform pennance for their prior un-speakable misdeeds.--Epeefleche (talk) 00:02, 27 April 2011 (UTC)

The text you deleted, Tom, had been worked for many days now by five editors Greg L, Woodstone, Diego Moya, A.di M., and SWTPC6800, who spent much-valued time researching the facts and providing background here on this talk page and provided citations. As such, it was the product of a collaboration. Your allegation that the section had been written IMO from the POV of the proponents of the use of conventional binary prefixes in the use of reporting HDD capacity is false; it was written by proponents of giving an encyclopedic treatment of the facts. As for your baiting and posturing with I hope the thought police will discuss this rather than reflexively reverting my edit, you’ve made your views abundantly clear and obviously haven’t had a change of mind. Moreover, for whatever reason, you elected to stay off of Wikipedia for nearly three days and not participate in discussing the way this section was going nor help craft the section. You have once again managed to conduct your collaborative efforts in just about the least collaborative manner. Reverted. Since your assertion that this has nothing do to with IEC Binary Prefixes doesn’t even pass the “grin test” given your persistent conduct and everything you’ve written on this page, I think I will take a page from your playbook: I hope you will discuss this rather than reflexively reverting my restoring the article to the community’s consensus text. Greg L (talk) 00:53, 27 April 2011 (UTC)

P.S. I suggest you, Tom, give this a careful read: if you want to participate again on this article, do not stay off of Wikipedia for three days, march back and undo a bunch of collaborative writing by five editors who all have a consistent record of being able to work in a collaborative writing environment to produce balanced, encyclopedic text, and then come to this talk page to weigh in with more of your incendiary baiting like thought police.

Have you stopped for even two seconds to ponder what it must look like to outsiders looking in at your writings when they see an editor write thought police while undoing a section on which five other editors had labored for several days??? Were you actually thinking the community would see some sort of *unassailable truth in your arguments* using those tactics???

The next time you disrupt like this, you will likely not be pleased with the outcome. It’s time to take a close look at “Tendentious characteristics” and for you to then drop the stick and walk away from the dead horse. Greg L (talk) 01:06, 27 April 2011 (UTC)

Greg you don't WP:OWN, this article and your tone is bordering on incivility. The section had grown far too long and I agree with Tom that this subject can be far better covered by the binary prefix article.

RH--I would suggest an immediate redaction by you, via cross-out in your above missive. Either of the "n't" that you wrote. Or of the "not". Otherwise, sanity shall never reign here, because people will never know what you are trying to say.--Epeefleche (talk) 03:59, 27 April 2011 (UTC)

Fixed the double negative.--RaptorHunter (talk) 04:59, 27 April 2011 (UTC)

Yes, RaptorHunter, *I* don’t own the article, the community does and when five editors with the buy-in from several other editors have crafted text over several days, that’s the community consensus. You ought to fully well know that. Greg L (talk) 15:08, 27 April 2011 (UTC)

I advise User:Tom94022 to follow the wp:BRD cycle and copy his proposed version here at the talk page now that it has been reverted from the article. Diego Moya (talk) 08:34, 27 April 2011 (UTC)

Tom94022 The TB and therefore terabyte has certainly been used in the binary sense to talk about memory sizes by reliable sources, especially since 64 bit processors have become common. It doesn't have to be mentioned by a standard to be used in this article. Glider87 (talk) 09:26, 27 April 2011 (UTC)

My two cents: Greg L's text goes into a lot of unnecessary detail about 20th century history which could IMO be cut down, but in no way can I see how it is “from the POV of the proponents of the use of conventional binary prefixes”: it just describes the situation, and it doesn't advocate or criticize anything. On the other hand, Tom94022's text is a bit shorter, but commentary like “[t]here is really no reason for this difference besides it just being convention to use powers of 1024 in reporting memory size” and “[a]ltering this practice to use conventional powers of 1000 could have been done at any time, including from the beginning; however, for some reason it just stuck this way for most of the computing industry” definitely doesn't belong here. Given that this article is supposed to be about f***ing hard disks rather than RAM, units, or anything else, my preference would be to stick with Greg L's text but with the paragraph about 1953–76 history reduced to a couple of sentences (to the effect of “both those sets of units have decades of precedent”) or even removed altogether. ― A. di M._plé^dréachtaí 12:10, 27 April 2011 (UTC)

I support this reduction - elaborating the specific models that originated each convention is too detailed for a Capacity measurements section. IMHO a link to Binary_prefix#Disk_drives would be advisable as the subject is treated as on-topic there. Another option is to split the section in two - one half for the technical details on how capacity is measured (including the math description), the other for its historical evolution (origins, changes in operating systems, and the proposal of unique prefixes). This way succinctness would not be crucial and each section could digress a little more. Diego Moya (talk) 13:07, 27 April 2011 (UTC)

I completely agree with ~~Diego~~ A. di M.’s sentiments when he wrote …but in no way can I see how it is “from the POV of the proponents of the use of conventional binary prefixes”: it just describes the situation, and it doesn't advocate or criticize anything. Of course that’s the case and Tom94022’s edit and accusation that the community is POV-pushing and acting like the “thought police” to promote the conventional binary prefixes are beyond-absurd rants.
SWTPC6800 is a long-time unbiased editor with lots of experience in the computer field and he did an great job researching past practices in the computing field. If we over-scrutinize that section and start second-guessing ourselves while under the pressure of absurd rants, we could trim the article down to just 30% of what’s there. Would it still convey information if so trimmed? Sure, but there is not only no need to, we don’t want to because doing so would harm that section; what’s there now is well crafted, crisp, accurate text that provides concise account of the following:

Topic: How the measure of binary capacity is confusing and even lead to lawsuits

The hard drive industry uses zeros in their measure of HDD capacity whereas other areas use 1024-based measure
That practice isn’t something new and has its roots in the earliest days of computing
The early days of computing also used 1024 math in computing and used the conventional prefixes for that too
The 1024 convention stuck for RAM and other and decimal math stuck for hard drives
This lead to and still leads to confusion and lawsuits
Now two dominant OS vendors have two different practices for measuring HDD capacity (further increasing confusion)
A standards body tried to address the confusion with new prefixes but they largely ignored by the computing world.

Just the facts ma’am. What’s there sticks to that outline, is crisp, accurate and concise, is actually interesting reading (a too-rare thing on Wikipedia) because of SWTPC6800’s help, was the product of a good handful of editors laboring on it over many days, and needs nothing at most but the the standard tweaks here and there that any text that was the product of collaborative writing needs. We can do that tweaking process without looking over our shoulders worrying whether the IEC-prefix proponents can find fault with allegations that we’re “POV-pushing” and “promoting things” and accusations that the community here is acting like “thought police”. Greg L (talk) 15:08, 27 April 2011 (UTC)

Greg L's summary is close to what I tried to write with one crucial and several minor distinctions, as follows:

Topic: How the reporting of HDD ~~measure of binary~~ capacity is confusing ~~and even lead to lawsuits~~

The hard drive industry uses ~~zeros~~ powers of 1000 in their measure of HDD capacity whereas ~~other areas use~~ the memory industry uses a powers of 1024-based measure
~~That practice isn’t~~Neither practice is something new and has its roots in the earliest days of computing
~~The early days of computing also used 1024 math in computing and used the conventional prefixes for that too~~
[Note: No one uses or has ever used 1024 math in computing; such prefixes are used in stating capacity in articles, product literature, etc. This bullet appears to me to be redundant to the above so rather than reword, I struck it.]
The powers of 1024 convention stuck for memory~~RAM and other~~ and powers of 1000~~decimal math~~ stuck for hard drives
~~This lead to and still leads to confusion and lawsuits~~ There was no confusion until OSes and/or utilities began reporting HDD capacity using the memory capacity convention, that is powers of 1024.
Altering this practice to use conventional powers of 1000 could have been done at any time, including from the beginning; however, for some reason it just stuck this way for most of the computing industry.
Now two dominant OS vendors have two different practices for reporting~~measuring~~ HDD capacity (further increasing confusion)
A standards body tried to address the confusion with new prefixes but they largely ignored by the computing world.

Just the facts sir. What I proposed sticks to the above outline, is crisp, truly accurate and concise, is actually interesting reading (a too-rare thing on Wikipedia). This is an HDD article not the Binary Prefix article. It seems to me that as written it has an overwhelming emphasis on the powers of 1024 usage in computing which is POV but it is also TMI. Greg L gives away his bias in the title of his summary, "How the reporting of binary capacity is confusing ..." The article is about HDDs and the confusion comes from the unfortunate practice of OSes using binary prefixes for reporting HDD capacity. That is the crucial point missed!

FWIW, I note that many of the changes I made should not be controversial, such as standardizing on the powers of xxxx' language or removing the excess justification of binary prefixes (as proposed by A. di. M and Diego Moya). Instead of trying to further improve the article Greg L simply reverted as I expected. The only really controversial points I suspect are 6 and 7 in my summary, as opposed to 5 in GregL's summary. This could have been discussed rather than throwing the whole thing out. I further note that my proposed revision reduced the size of the article by about 600 bytes while adding substantial new reliably sourced material. Lets see what happens now Tom94022 (talk) 16:20, 27 April 2011 (UTC)

If you want to contribute, Tom94022, just don’t sit back, allow five editors to work on something for a week, and then come back after a three-day off-wiki absence and throw much of it out and substitute it with your own. What were you thinking?? That we’d all go “OK, he threw out all our work so let’s *discuss* it after the fact”? You’ve argued and argued for weeks here and have agitated beyond all comprehension that the table ought to have the IEC prefixes in it. Your bias is clear with regard to those IEC prefixes and your contempt for the way the world really works is palpable. The clear consensus here is not aligned with your wishes. You are overruled. Then five editors collaboratively work on that section for days and and then you tried that little stunt of yours and proclaimed some sort of victory because you were prescient that you’d be reverted, which was a Well, DUH outcome given how inappropriate your move was.

Please just give it up. The consensus is not in agreement with you. We find that there is no POV-pushing to promote the standard prefixes going on here. Period. What you think is *truly* accurate is not what the rest of us think, which underlies why you aren’t getting your way… because Wikipedia operates by consensus.

As I mentioned above, what’s there sticks to the above-mentioned outline, is crisp, accurate and concise, is actually interesting reading (a too-rare thing on Wikipedia) because of SWTPC6800’s help, and was the product of a good handful of editors laboring on it over many days. The last thing we need now is wholesale deletion of passages by someone who stayed away during the collaborative writing process and comes back alleging that the article had been taken over by biased “thought police” trying to push a particular industry practice. That sort of allegation is just utterly absurd. Greg L (talk) 17:14, 27 April 2011 (UTC)

My edits moving Greg's content to footnotes are by no means perfect, but IMO show a better reading flow of the whole section. Maybe we should explore placing them at a separate subsection?Diego Moya (talk) 17:35, 27 April 2011 (UTC)

I can live with a footnote but I think a link to the Binary prefix article where this and more is disclosed would be best; after all this is an HDD article and why do we have all this memory history and little or no HDD histoy? Tom94022 (talk) 17:48, 27 April 2011 (UTC)

I’m fine with the general direction you’re taking, Diego. Your solution best preserves the efforts of the others so I can imagine you might get buy-in from them also. Tom94022’s suggestion that what has now been moved to footnotes ought to be expunged because it is “best” covered in an article where both he and RaptorHunter are quite active (edit history of the article), doesn’t withstand scrutiny. His agenda is abundantly clear here, which he has amply illustrated with his arguments and demands on this talk page. Greg L (talk) 18:15, 27 April 2011 (UTC)

P.S. I’ve already reverted one of his attempts at expunging, which now that you, Diego, moved to footnotes made it seemingly easier for “oopsy-little deletions” to go unnoticed. No, they get noticed. Again, that text was the product of five editors over three days. Deletion of it is without consensus. And no, wading through an entire Binary prefix is no substitute for reading simple facts here in citations that buttress points made in the body text.

I’m beginning to wonder if the Binary prefix article truly reflects the wider community consensus or is unduly influenced by just two editors over there… Greg L (talk) 18:22, 27 April 2011 (UTC)

I'm a little tired of GregL threats and misrepresentations, but this one is easy. Of the last 500 edits to the Binary Prefix article I have contributed 18 and RH 12. The most prolific editors there are Kbrose, Shreevatsa and Jeh who have made 162 of the last 500 edits. So I suggest GregLs concerns are just more smokescreen. Tom94022 (talk) 18:54, 27 April 2011 (UTC)

Why isn't this POV pushing

Some of my fellow editors do not see POV pushing in this article. Please look carefully at these two adjacent sentences from my recent edit already reverted by GregL:

The HDD Sentence

The practice of using prefixes assigned to powers of 1000 within the hard drive industry dates back to the early days of computing.

versus

The Memory Sentence

Likewise, the practice of using prefixes assigned to powers of 1024 within the memory industry dates back to the early days of computing; other computers with up to 32,768 words of memory referred to them as “32k words.”^{[20][21][22][23][24]}

Why does the Memory Sentence require an example and five footnotes while the HDD Sentence has neither an example nor any footnotes. We could easily add an example and 5 or more footnotes to the HDD Sentence to get to a balanced section or drop them all and point to the Binary Prefix article. IMO, the unbalanced and heavy emphasis on examples of conventional binary prefixes in an HDD article is pushing the POV that reporting HDD capacity using such prefixes is somehow justified. Tom94022 (talk) 18:25, 27 April 2011 (UTC)

Once again, I have real life to attend to and don’t have time for jihad over binary prefixes. Whatever Diego agrees to today, is fine by me. Greg L (talk) 18:34, 27 April 2011 (UTC)

But I can't take 3 days off of editing for my real life and then rejoin? Why not? Tom94022 (talk) 18:58, 27 April 2011 (UTC)

I didn’t say that. You may not take three days off and then undo heavily-worked-on consensus text. I was perfectly clear on this and your acting innocent and clueless does not impress. Greg L (talk) 21:23, 27 April 2011 (UTC)

Poor logic Tom94022. It's got nothing to do with how long someone takes off; it's got to do with the undesirable blasting back in and undoing the work collaboratively constructed by many editors. Schoolboy debating logic (at best). GFHandel. 22:27, 27 April 2011 (UTC)

As I looked at the edit history I did not see much attention paid to the changes I made and in the end most of them have now been accepted, so I find your characterizing them a "blasting back" not very helpful. Did you bother to look at them or just accept GregLs reversion? Since you purport to be a hard working editor, I would appreciate your comments on the issue raised in this section rather than the unhelpful characterizations of my logic. Do you think the two sentences are balanced and appropriate to an HDD article? Do you think the variant two advocated by GregL (including the non-sequitor) are balanced and appropriate to an HDD article? Either way, I'd like to see some discussion and reasoning instead of I just don't like it.Tom94022 (talk) 16:19, 28 April 2011 (UTC)

Calling someone "the undesirable" is a personal attack GFHandel. You should know better.--RaptorHunter (talk) 22:30, 27 April 2011 (UTC)

Ahem. I don't think "undesirable" is a noun in this context, but an adverb, referring to "in and undoing the work collaboratively constructed by many editors." I admit I'd have difficulty diagramming the sentence, but, still.... — Arthur Rubin (talk) 22:36, 27 April 2011 (UTC)

"Calling someone "the undesirable" is a personal attack..."—that's a keeper; but thanks for giving us all a laugh. GFHandel. 22:49, 27 April 2011 (UTC)

And I see you insist on getting your way at deleting material that five other editors labored over. This is your final warning, Tom94022. As I wrote in my edit summary when I last reverted you: Tom94022, you’ve been warned twice today about editing against consensus. I suggest you get buy-in from Diego today before you really run afoul Greg L (talk) 18:39, 27 April 2011 (UTC)

And I hope you will wait for other editors to comment. I believe I have gone overboard to explain my edits whereas all you do is revert and threaten. 18:58, 27 April 2011 (UTC)

Politely advising that you are editing against consensus doesn’t seem to be sufficiently persuasive to you. Explaining that your arguments are circuitous and obviously not gaining traction with the others here is also not changing your conduct. You are now the subject of an ANI here. Greg L (talk) 19:09, 27 April 2011 (UTC)

Capacity measurement split in sections

This is how the section looks when split in subsections. Thoughts? Diego Moya (talk) 21:18, 27 April 2011 (UTC)

Fabulous! Outstanding work, Diego. Greg L (talk) 21:21, 27 April 2011 (UTC)

Are there any early usages of powers of 1024 in the storage industry other than in the memory segment? I don't think so. So I think the first sentence should read:

The practices of using prefixes assigned to powers of 1000 within the hard drive industry ~~(storage)~~ and prefixes assigned to powers of 1024 within the memory ~~and storage~~ industry both date back to the early days of computing.

At least three of us agreed that the history of conventional binary prefixes was unnecessary, even confusing, and we then all agreed to move it to footnotes. I don't understand how we now improve the article by bring it back. Also, this material is all about memory; if we are going to have lots of memory history shouldn't we have an equal amount of HDD history? IMO, neither are particularly helpful, but I will be happy to find five or more HDD examples to add to the early history section. Tom94022 (talk) 22:06, 27 April 2011 (UTC)

BTW, the first section title, Early discrepancies is also probably inappropriate. None of the examples illustrate any discrepancy but instead illustrate the development of two different meanings of the same symbols. Each example has a consistent usage. To illustrate a discrepancy should you find an example of an HDD being described with powers of 1024 prefix or a memory being described with a powers of 1000 prefix. You might find some of the latter early say a 64 Kbit memory being described as a 65 kbit memory but I doubt if you will find any HDD examples until the 1980s. Tom94022 (talk) 22:15, 27 April 2011 (UTC)

I didn't actually think it was unnecessary, only that it was too long to be placed properly at the middle of the section. In my proposed split this is no longer a concern, so if we make that change I think it can be expanded to include some well-sourced examples of 1000-prefixed descriptions of HDDs. Maybe the section could be called Early examples or any other appropriate description of what content is included in it. What more would you add to this history section? Diego Moya (talk) 08:35, 28 April 2011 (UTC)

If you take a careful walk through the Timeline of binary prefixes I think you will find that the memory industry was inconsistently used kilo or k (or K) and mega or M in either sense into the 1970s but has been pretty much consistent since then. You will also find that the HDD industry has always used mega or M, giga or G and tera or T in a decimal sense. There are no examples of M being applied to an HDD in a binary sense until the 1980s. I don't think there are any example of k (or K) ever being applied to a disk drive, the first one was 5 million characters. One of the first storage examples in the early 1980s is with FDs when Apple starting using K (binary) to describe the SA400 which was specified in decimal units. I think all of this early history is irrelevant to the HDD article and at most should be footnoted but if we are going to summarize the history it out to truly depict the whole history and not just some memory aspects thereof. Tom94022 (talk) 22:52, 27 April 2011 (UTC)

Seven editors seem to be happy with what five editors did, one of whom was Diego, and another of whom was me. I for one am still happy with the consensus text and find your arguments, Tom94022, to be unpersuasive. I support Diego’s efforts here and it is clear he understands the intent of the consensus editors. Greg L (talk) 23:00, 27 April 2011 (UTC)

I have a problem with the attempt to trace the use of decimal numbers to measure hard drive capacity to core memory practice, in particular the IBM 702 (which employed Williams tubes, not core, by the way). The 702 and its core successor, the 705, used decimal addressing. It was in the binary addressed machines, like the 701,704, 709, series where power-of-two memory capacity was the norm and where the practice of K meaning 1024 arose. In any case, core memory has little to do with hard drives. The first hard drive, the IBM 350, part of the IBM 305 RAMAC stored exactly 5 million characters. Then, as now, the capacity of a hard drive is the number of active disk surfaces X the number of sectors per surface X the number of storage elements per sector. This rarely comes out as a power of two. --agr (talk) 01:16, 29 April 2011 (UTC)

Some recent reverts

I think the recent reverts by Tom94022 and RaptorHunter did not improve the article and are against consensus. I have reverted. Glider87 (talk) 08:53, 28 April 2011 (UTC)

Those two were clearly tag-teaming against consensus. Diego has the right attitude, understands Wikipedia’s rules, policies, and guidelines, and is doing good work here. He has no agenda other than to produce, good, clear, factual, balanced, encyclopedic text. I can easily work with him. Greg L (talk) 16:30, 28 April 2011 (UTC)

As agr eloquently states directly above, there is "a problem with the attempt to trace the use of decimal numbers to measure hard drive capacity to core memory practice, in particular the IBM 702 (which employed Williams tubes, not core, by the way). ... In any case, core memory has little to do with hard drives." The sentence in question is a non-sequitor in linking HDD capacity to the 702 and my edit is an attempt to improve the article by moving the memory practice history footnotes to the second sentence where they are apropos and eliminating the reference to the inappropriate 702. This has not been discussed at all so any assertion that this is against consensus is really I just don't like it. If the IEC Binary Thought Police really cared about producing good, clear, factual, balanced and encyclopedic text they would discuss the change here rather than simply reverting and claiming consensus where none really exists. So I am going to revert, once again, and hope we can have some discussion along the lines started by agr above. Tom94022 (talk) 19:17, 2 May 2011 (UTC)

I have to side with Tom at this one. He was asked to explain his edits, which he has made just now. Let's concentrate at the quality of edits and the arguments supporting them, instead of who made them or what alliances they might have. While making sides is a natural inclination in every human endeavor, all editors here would do well to review the always present fourth pillar of Wikipedia WP:CIVIL and act accordingly. WP:COOL and WP:AGF are also highly relevant at this point. Diego Moya (talk) 22:04, 2 May 2011 (UTC)

Well, regarding civility: I'm surprised that you haven't realized that using a phrase such as "the IEC Binary Thought Police" is unlikely to lead to any worthwhile discussion. GFHandel. 22:06, 2 May 2011 (UTC)

Well regarding discussion, I'm disappointed that you chose to revert rather than discuss. Do you have any reason for your revert other than sometime in the past there might have been consensus? Tom94022 (talk) 22:42, 2 May 2011 (UTC)

Not so fast there. Can we all assume that you are apologising and taking back your nasty "thought police" allegations? GFHandel. 22:52, 2 May 2011 (UTC)

I am indeed sorry if my shorthand description for the actions of three editors has somehow prevented a discussion of this matter. I am sorry you feel it to be nasty, and if you look back at history I think you might find it a reasonably accurate description of the collective behavior of GregL, Glider and Fnag. Sorry if that offends you. Tom94022 (talk) 23:11, 2 May 2011 (UTC)

Tom94022: Please don’t come back fresh off of ducking an ANI for editing against consensus and being disruptive by coming straight back here with more “*Edit First / Discuss Later*.”
Over at that ANI, I even correctly predicted (my 16:26, 28 April 2011 post) the amount of time (four days) you would lay low, trying to avoid the ANI, before going back to your old ways. Now…
There you go with your allegations that those who don’t agree with you as being “thought police.” It’s not the way a dissenting voice wins over others to his way of thinking. I reverted your edit. First off, what you had there wasn’t even remotely grammatically correct. Secondly, you raise no new arguments (“thought police”, “I don’t like it”, and other tedious ramblings) so per Wikipedia:Disruptive editing, the community is not required to respond.
Since you and RaptorHunter are the odd men out here with a 7:2 consensus against you, you need to discuss your desires first and not make edits with an edit summary of “Let's see if this can be discussed”. Indeed let’s *discuss* it. You wrote an unconvincing post on this thread that comes up short of being persuasive. Try coming up with something new to say though, otherwise you may safely assume that the consensus view is not in alignment with your wishes. Moreover, if you would like to get the consensus view to change, you might consider another tactic that doesn’t involve 6th-grade-style name calling. Grownups have to (*sigh*) and leave yet another response here to your disruption. Woodstone, Diego Moya, A.di M., SWTPC6800, Fnagaton, GFHandel (sorta), and I are happy with what’s there. That’s a consensus. Greg L (talk) 22:11, 2 May 2011 (UTC)

P.S. If you can get Diego to agree that there is a non-sequitur to the current text, I’ll go along with his judgement. That should really give you, Tom94022, a homework assignment here in the art of persuasive writing. Try skipping the “Binary Thought Police” part, and Diego might be better able to see your point(s). Oh… and try writing to Diego here on this talk page. Do your best to omit allegations of nefarious motives by others and just lay out a logical argument based in facts that are citable. Greg L (talk) 22:16, 2 May 2011 (UTC)

Poor grammar is a poor excuse to revert. Why don't you just fix it?

Rather than being the odd man out, you are the only editor who appears to dislike the improvement to the article but rather then discuss you simply revert.

Since it seems to impede discussion,t I will use the term usual suspects instead of IEC Binary Thought Police hereinafter because I do feel the need for a shorthand description of the collective actions of GregL, Glider and Fnag.

Tom94022 (talk) 22:35, 2 May 2011 (UTC)

At this point it appears that Diego Moya and agr agree that the part of the section in question can be improved and not one of the editors of the so-called consensus has commented. I wish [[User:Greg L|Greg L] would stop reverting and start discussing. BTW, just because a number of editors worked on a section doesn't mean there is a consensus on everything in the work product, and if it there were, it doesn't mean an article can't be improved. Under [[User:Greg L|Greg L]s reasoning I could not change the clearly incorrect "suffix" into "prefix" (as I did) without first proposing such a change on the discussion page. So it would really be nice to see some discussion instead of reversions and assertions of consensus where it really doesn't exist. Tom94022 (talk) 22:35, 2 May 2011 (UTC)

Again, if you want to start convincing people around here of anything stop attacking others, stop accusing those who disagree with you as being “Binary Thought Police”, and start writing a cogent, logical explanation founded in actual facts of what you propose. Given the difficulty you seem to be having today in proofreading and correcting grammatical nonsense and obvious typos like “[[User:Greg L|Greg L]”, it will probably be a good exercise for you to take your time and take a deep breath in order to explain to Diego, GFHandel, and me precisely what is on your mind (again, without all the vitriol and allegations that other wikipedians who inhabit this place have nefarious motives). Greg L (talk) 23:54, 2 May 2011 (UTC)

Again you could help by suggesting grammatically correct revisions without the Ad hominum attacks. Tom94022 (talk) 01:09, 3 May 2011 (UTC)

sigh

Why it needs to be improved

As agr eloquently states directly above, there is "a problem with the attempt to trace the use of decimal numbers to measure hard drive capacity to core memory practice, in particular the IBM 702 (which employed Williams tubes, not core, by the way). ... In any case, core memory has little to do with hard drives." The sentence in question is a non-sequitor in linking HDD capacity to the 702 and my edit is an attempt to improve the article by moving the memory practice history footnotes to the second sentence where they are apropos and eliminating the reference to the inappropriate 702. This has not been discussed at all ...

To which I will again state it seems unbalanced in these two sentences of an HDD article to have 5 or 6 footnoted examples of the early usage of powers of 1024 measurements of memory and no footnotes regarding the early usage powers of 1000 measurements of HDDs. It would be nice now to see some discussion ~~as opposed to Ad hominem attacks and circular reasoning~~. Tom94022 (talk) 01:09, 3 May 2011 (UTC)

Very good. That the 702 used Williams tubes needs to be fixed. I see no problem—and certainly no non-sequitor—mentioning how the very earliest days of computing used the term “K” or “k” to denote both 1000 and 1024. It lays the foundation for the entire basis as to how the measuring convention for hard drive capacity ran afoul with the expectation of computer users because of the commonly understood value of 1024. It is not only not a non-sequitor, such a discussion speaks straight to the heart of what that section is about. Greg L (talk) 03:47, 3 May 2011 (UTC)

Thank you - by splitting the sentence you removed the non-sequitor. The second sentence is irrelevant TMI since it does not cite the use of prefixes of either sort, this has not be discussed hereinbefore on this discussion page. You did not discuss the lack of balance in this paragraph and to date hereinbefore there has been no discussion of balance or the lack thereof. I will be addressing both problems in a soon to be done edit. You frequently make the point that consensus arises from discussion and the merits of the arguments made. Since there has been no discussion there is no consensus either way and any reversion by you asserting "editing against consensus" will be at best disingenuous and possibly subject to sanctions. Please let others look at and think about this future edit before you disruptively revert. Tom94022 (talk) 18:47, 3 May 2011 (UTC)

Sorry, I just can't see the point of mentioning Williams tubes and whatnot in that section. There's Binary prefix#History for those readers who give a damn about that stuff. ― A. di M.^plé_dréachtaí 15:09, 4 May 2011 (UTC)

I agree that Williams tubes have no place in this article, its cite doesn't even use prefixes! As I said TMI. But want to bet what happens if I delete the sentence as redundant TMI? Tom94022 (talk) 18:11, 4 May 2011 (UTC)

Some perspective

There seems to be a bit of unnecessary wiki drama going on here. I'm late to the party, but would like to try to calm things down. I've been involved with electronics and computers since the late 1950s. Here is my version of what happened. We can see if others have a different recollection and also what we can source to meet wikipedia standards for inclusion.

The use of the letters k and K to mean 1000 was universal in the electronics industry since before Wold War II. Frequency was measured in kilocycles (kc), high levels of power were in kilowatts, (KW), and resistances above 1000 ohms were listed on schematics as just K. Also resistance values generally quoted were approximate. High quality resistors had a ± 5% tolerance. Consumer grade was ± 20%.
Memory on the earliest computers was small, too small perhaps to bother abbreviating. The binary Whirlwind I had 2048 words. The decimal IBM 650 (the one I first learned on) had 2000 words of drum memory (50 words of core was an option).
The use of K was only potentially ambiguous in discussing memory size of binary machines. In that context, it had two possible meanings: approximate size to the nearest thousand, and multiple of 1024. It is important to note that this distinction has no effect for powers of 2 until 2^16 = 65536, which becomes either 65K or 64K depending on which was meant. There are examples of both usages. Binary memory sizes this big did not become common until the early 1960s. The IBM 704/709/7090/7040 series, which were the most popular large binary machines until the mid-1960s, only had 15 bit addresses. The IBM 7030 STRETCH had a larger address space, but few machines were built.
IBM was very formal in it documentation and avoided slang usage. Hardware manuals I have give storage sizes exactly in decimal (e.g. 32,768 words). I believe the use of abbreviations like 8K or 16K come in with IBMs software documentation, particularly when giving the minimum memory size needed to run a program or system.
The earliest commercial hard disk drive, on the IBM 305 had exactly 5 million characters. The capacity of hard disk drives (then and now) come from a formula: the number of active disk surfaces times the number of tracks per surface times the number of sectors per track times the number of memory elements per sectors. In most cases numbers in the formula were not powers of two. I'm not aware of any tradition in the IBM world, which invented hard drives and dominated the early market for them, of expressing disk memory sizes in binary multiples. The use of binary sizes for hard drives seems to have surfaced when hard drive were first used on personal computers. --agr (talk) 18:31, 4 May 2011 (UTC)

Welcome to the discussion. I agree with everything you say, most of which is said in the Binary prefix article but perhaps not as well or as succinctly. To clarify one of your points there is no record of application of binary prefixes to HDDs until the middle 1980s when it was most likely first done by Apple with an early MAC OS. Prior to the MAC, as best I can discover all OSes and/or their utilities reported capacity in long strings of decimal digits, often without commas.

IMO, the current wording of this article places much too much emphasis on the history of conventional binary prefixes in memory and both ignores the history of decimal prefixes in HDD capacity and the timing of this change in reporting. Unfortunately every attempt I have made to improve the article has been shouted down with the canard that I am editing against consensus. The points you and I raise have not been discussed so editing them into the article is not against any consensus, but that doesn't stop the shouting. Tom94022 (talk) 19:27, 4 May 2011 (UTC)

Maybe we can put the past behind us and AGF, etc. I'd like to hear from the others why they think addressing on a decimal machine is relevant here.--22:13, 4 May 2011 (UTC)

Can I broaden the question to ask why is any history is relevant here? And as a follow up. if we mush have history in this article why isn't the history of HDD capacity measurements the only relevant history in an HDD article? Tom94022 (talk) 22:29, 4 May 2011 (UTC)

/* Power consumption */

adjusting spin speeds according to transfer rates is a semi-regularly repeated myth, but I am pretty certain it is just that. All modern hard disks spin at a constant angular velocity (after initial spin-up from standing). Confusion on this matter began a few years ago when a HDD manufacturer made a vague claim that one of their upcoming drives would change velocity to save power - this was either marketing puff or talking about a semi-sleep mode with the platter spinning slowly but with the head moved off the platter (to avoid a head crash due to the lack of required air-flow to float the head above the platter surface). Variable angular velocities would lead to obvious audible pitch changes (which I have never heard or heard of in practise), and could not be done both quickly and accurately at the same time, due to the intertial input requirement to change velocity and the precise control of RPMs required for in-flight head position and read/write timing calculations. Feel free to correct me on this, but I've never seen or heard of this. —Preceding unsigned comment added by 94.195.131.27 (talk) 03:38, 5 May 2011 (UTC)

I am pretty sure that the Western Digital drive's IntelliPower algorithm varies the rotational speed between 5400RPM and 7200RPM and that Seagate and Toshiba have similar capabilities with other names. Technically with drives already implementing zone bit recording this shouldn't be too difficult since all it means is tweaking the data separator's lock range and tracking capabilities. Slow change is actually better and you won't hear a thing. Obviously there is a limit to the range but with modern negative air bearing heads the flying height doesn't change much, if at all, within a fairly large RPM band (as indeed it doesn't change much from inner to outer tracks) Tom94022 (talk) 18:09, 5 May 2011 (UTC)

"Enterprise disk drive" redirects here.

In my opinion, this sentence has absolutely no use for the reader. Moreover, why choose to indicate this particular redirection, when there is lots of them ? Freewol (talk) 08:27, 6 May 2011 (UTC)

I agree. Legitimate information about the topic is improper use: Hatnotes are meant to reduce confusion and direct readers to another article they might have been looking for, not for information about the subject of the article itself.

The other hatnone ("Hard drive" redirects here) is useful because "Hard drive" has ambiguous meaning with several topics using that term. This is not the case with "Enterprise disk drive" nor the other redirects. Diego Moya (talk) 10:59, 6 May 2011 (UTC)

I "Today most drives are made by Seagate, Western Digital and Toshiba" needs sources. —Preceding unsigned comment added by Johnakabean (talk • contribs) 15:47, 20 May 2011 (UTC)

Balance

In my latest edit there are three basic changes to the Capacity measurements section of the article:

Balance

I believe the section is unbalanced in that it has too much information on the history of binary prefixes to describe memory and none on the history of decimal prefixes to describe HDDs so in order to balance the article I added information on usage of decimal prefixes to describe HDD capacity.

Thanks to edits by Diego the section is now balanced, although it should be improved by moving the main memory history to footnotes as is the HDD history Tom94022 (talk) 17:08, 25 May 2011 (UTC)

Dubious

Moved discussion to new section, Usage of Binary K

New Material

~~I added from a reliable source a paragraph on the lack of a basis for using powers or 1024 in reporting HDD capacity.~~

I accept Diego's edit to this new material, although I do think the fact that the confusion did not appear until the 1980s is material, so I will look for a way to add it without citing Wikipedia. Tom94022 (talk) 15:39, 26 May 2011 (UTC)

Please do so, though I'm afraid that will be difficult. The source you find will have to state that some usage of binary prefixes in HDD was the first one and/or that confusion appeared about those years. Diego Moya (talk) 15:58, 26 May 2011 (UTC)

On the whole, I would rather eliminate all of this history from this article but if we must have history then I suggest an HDD article should at least have HDD history.

I hope no one reverts this edit on the basis of "editing against consensus." I would note that this edit is added material and two dubious tags; none of this has been discussed before so it is not possible for there to have been any consensus since there has been no discussion. Tom94022 (talk) 21:45, 21 May 2011 (UTC)

See below. I reverted in large part because the result was very poor technical writing and nothing but more of your POV-pushing. As regards this amazing leap of logic of yours: so it is not possible for there to have been any consensus since there has been no discussion, you confuse the community not being interested in further entertaining your tendentiousness and your flogging a dead horse as being equivalent to acquiescing with your arguments; that was your goof here. Greg L (talk) 21:59, 22 May 2011 (UTC)

POV-pushing (again)

This edit (∆ edit 430257023) by User:Tom94022 was more of the same old POV-pushing and I reverted it. The result (here) was tediously long, poorly written and clearly was a step backwards from the previous version which was tight, pithy, and spoke to the point; and was the product of a smooth, collaborative effort of a handful of experienced and accomplished editors. I reverted (∆ edit here) to the last good version, which was after I.P. 193.210.145.13 made a contribution, and after Tom94022 reverted the addition of a graphic by User:Cmglee, which indeed wasn’t a helpful graphic and was an edit by Tom94022 with which I agree. Greg L (talk) 21:46, 22 May 2011 (UTC)

P.S. Your insisting to get your way with this edit summary: GregLs opinion is not sufficient to revert new material is not true. You did not add “new” material; you replaced consensus text with more of the same stuff you’ve long POV-pushed over. Please don’t edit against consensus. I restored the consensus text. Greg L (talk) 04:11, 23 May 2011 (UTC)

Tom -- suggestion ... this just appears to be an effort to continue the tendentious edit warring cycle, and we all know where that will lead if it continues. I'm not seeing a basis for your revert that sways me to see it as appropriate. Nor does the revert itself look anything other than tendentious. We're sort of tired of seeing this at AN/I. How about giving it a break, unless you have a credible rationale for such an edit? Best.--Epeefleche (talk) 06:01, 23 May 2011 (UTC)

Since this is all new material it is hard to see how it is either a "tendentious edit" or an "edit against consensus" so I am really not worried about AN/I - in fact I would like to see a discussion of GregL disruptive editing. I note that the first part of my edit has been essentially accepted by Diego - I have no problems with moving most of the material to footnotes. I am now going to restore the second two parts of my edit and see what would happen. You could help if you wanted to help perhaps you might explain why this new material does not add to the article. Under GregL and apparently your interpretation anything that has be worked on by a number of editors cannot be added to or even changed - that's nonsense. Tom94022 (talk) 00:11, 25 May 2011 (UTC)

To understand why it is a tendentious edit, one might look through the above edits on this talkpage and those discussed at AN/I. One can engage in tendentious editing by continuing the same pattern, even if one does it in new material, and even frankly if one engages in the same pattern across different articles. Given the history of tendentious editing here, I would suggest that it might be best to err on the side of discussion before making edits that one can expect will be viewed as "more of the same". Just a suggestion -- it can't harm you, and it can only benefit all concerned.--Epeefleche (talk) 21:20, 25 May 2011 (UTC)

You are entitled to you opinion, but I have carefully read WP:TE and it is pretty clear to me that my few edits have not been tendentious. I noted that "Making accusations of tendentious editing can be inflammatory and hence these accusations may not be helpful in a dispute." Actually if you read the record instead of accepting the inflammatory and incorrect statements on this talk page you will find that I have gone out of my way to discuss my points but have been met with repeated revisions without meaningful discussion. Also if you carefully examine the section, you will also find that almost all of the edits I have attempted to make have now been incorporated into the section. Unless there is yet another reversion the only remaining issue is that two of the sentences relating to main memory history appear to me to be dubious. I tagged them so, and stated my reasons in this discussion page but expect that they will be reverted yet again. Please tell me why I am being tendentious while the reverting editor is not disruptive? Tom94022 (talk) 21:42, 25 May 2011 (UTC)

It was all a bunch of utter nonsense. The “citations” you had to buttress wild allegations actually said no such thing. Pure garbage. Reverted. Greg L (talk) 01:53, 25 May 2011 (UTC)

I agree with Greg L's revert. Text like "There is really no reason for this difference besides..." is subjective, folksy, and inappropriate for an encyclopaedia. GFHandel. 02:15, 25 May 2011 (UTC)

The language GregL reverted is a ~~quote from the~~ paraphrase of a reliable source; instead of agreeing to revert, why don't you suggest more encyclopedic language? Tom94022 (talk) 17:22, 25 May 2011 (UTC)

So now you're copying text from a source—without indicating that it is a quote? GFHandel. 20:06, 25 May 2011 (UTC)

Sorry for my imprecise language. Wouldn't your time be better spent adding to the article? Tom94022 (talk) 20:20, 25 May 2011 (UTC)

Ah "paraphrase" was it? So now we're back to "subjective, folksy, and inappropriate for an encyclopaedia". GFHandel. 20:26, 25 May 2011 (UTC)

Subjective statements like "folksy, and inappropriate for an encyclopaedia" don't help anyone. If you had bothered to read the original document you would have seen how much was my work and how much was the original author. Then you could have helped by improving the section and that way we could see whether your subjective opinion about my paraphrase has any merit. But instead you sit aside and criticize. Wouldn't your time be better spent adding to the article? Tom94022 (talk) 20:37, 25 May 2011 (UTC)

So you really believe that labelling "There is really no reason for this difference besides..." as "folksy, and inappropriate for an encyclopaedia" is subjective? Fascinating. Incidentally, I'm not the only one who thinks so and thankfully the text you thought appropriate has been reworked by another editor. GFHandel. 20:43, 25 May 2011 (UTC)

Yes I do. Wouldn't your time be better spent adding to the article? Tom94022 (talk) 21:44, 25 May 2011 (UTC)

BTW, the fragment you don't like is from the citation. Tom94022 (talk) 22:53, 25 May 2011 (UTC)

So then we're back to: "So now you're copying text from a source—without indicating that it is a quote". The beginning of your text and the article text is "There is really no reason for this difference besides it just being convention to use powers of". Not only is that poor language in an encyclopaedia, but it is lazy work to simply copy the text. I can't believe you are still going on with this. Admitting that you made a mistake is always an option (a mistake now corrected by an independent editor). GFHandel. 23:33, 25 May 2011 (UTC)

Wouldn't your time be better spent adding to the article? Tom94022 (talk) 00:11, 26 May 2011 (UTC)

It was all a bunch of utter nonsense. The “citations” he had to buttress wild allegations actually said no such thing. It started out with this: There is really no reason for this difference besides it just being convention to use powers of 1024 in reporting memory size. The computer itself does not internally represent the HDD (or memory) capacity as being in powers of 1024. Pure garbage, as was much of the rest of what followed it. That CNet article isn’t an RS—it was a review of Apple’s Snow Leopard. You just can’t seize upon the first article you come across written by just anyone and whatever they say becomes fact—particularly not when you are just trying to POV-push again. The citation that a computer itself does not internally represent HDD capacity as powers of 1024 is also nonsense: Unix has powers of 1024 encoded right into the kernel so trying to say that a CNet review of Snow Leopard—even if it is true—somehow equates to what all operating systems work is absurd. Reverted.
To Tom94022: Please stop editing against consensus and replacing indisputable fact with a bunch of fantasy garbage (perma-link). User:Epeefleche was trying to explain something to you and you ignored his advise. And now User:GFHandel is trying to talk sense to you too. Try taking a clue this time around. You can’t claim you are “adding new material” because that is simply a lie. The simple reality is you are replacing consensus text (the product of a half dozen experienced and competent editors) with non-truthful, POV-pushing material of your own making for which there is no consensus. You may absolutely not do this; you never may replace consensus text with text that is wildly against consensus and circumvent this by claiming it is *new* material.
Now, ample electronic white space is provided below for you to rant about how your material is *new* (which must make the previous text *old*, in your book) but you must first see a consensus develop here for you to do so. Greg L (talk) 02:24, 25 May 2011 (UTC)

I really wish you would discuss issues rather than attack me. Can you provide any reliable source for you statement that "Unix has powers of 1024 encoded right into the kernel" As best I know, internally HDD capacity is represented by a binary string of the number of blocks and a word with the block length. BTW, this is a added paragraph, not discussed at all during the development of your so-called consensus so your requirement that I get agreement here is a plain violation of all the Wikipedia stand for. Again I am going to revert, but I will try to make the language a bit more encyclopedic? Tom94022 (talk) 17:22, 25 May 2011 (UTC)

DMahalko's Edit

While I appreciate DMahalko's trying to smooth it all over by an intro to the capacity section, summarizing all the many possible size discrepancies I think the material doesn't add very much and in many ways is incorrect. A short summary might help, but this long list appears to me to be too much. Some issues

The total number of sectors and the size of the sectors

There is no ambiguity here

computer filesystems must allocate space for tracking disk sector usage, storing file names, and keeping track of a directory structure

True, but that is the difference between gross and net, no ambiguity here

Absolute physical characteristics such as areal density are not reliable for determining storage capacity, and actual capacity is usually lower:

Its true but so what. There is no reliable way to determine capacity from areal density based upon manufacturers published numbers.

Do we try to fix or should we just revert. I would prefer to revert. Tom94022 (talk) 01:12, 26 May 2011 (UTC)

I also would revert. GFHandel. 01:19, 26 May 2011 (UTC)

A short introduction and changing the subsection title to something like Different measuring units, powers of 1000 vs powers of 1024 might make sense but that is an awfully long title. Another thing I didn't like is the introduction of binary vs decimal after we had standardized on one terminology. Tom94022 (talk) 01:30, 26 May 2011 (UTC)

Nope, didn't really expect that to stop this squabbling that has been going on for over two months now. I am certain this is going to end up on the wp:lamest edit wars page eventually. It'd be nice if this topic could just be split off completely onto a separate article so you can all fight it out somewhere else instead.

Revert and carry on.... you will anyway. DMahalko (talk) 01:57, 26 May 2011 (UTC)

Actually I think you have a good idea, but it needs improvement, so I tried. Sections 3.1 and 3.2 now follow from a brief introduction. Haven't figured out what to so about section 3.3, it seems out of place. Perhaps just a retitle to "Capacity reporting?" This isn't squabbling, it's that what this is all about! Tom94022 (talk) 05:43, 26 May 2011 (UTC)

Usage of Binary K

I marked two of the historical examples of binary prefixes as dubious for the following reasons:

The Sept 59 article by P Real of Westinghouse is a mathematical paper and does not explicitly link his usage of 32k to k=1024. As was practice in that time period the author could have been truncating 32,768 to 32k. This obscure first instance of k possibly in a binary sense in the Timeline of binary prefixes hardly supports the generalization, "computers were said to have 32k words." A far better example would be the Amdahl or Bell papers of 1964.

BTW, I would point out that this sentence derives from GregL's original editing and therefore he should be careful about violating WP:Own. Tom94022 (talk) 22:50, 25 May 2011 (UTC)

With regard to the 1102 [or 1103], there is no evidence that Intel ever "marketed it as a “1K” or 1 kilobit chip". The Intel 1973 Memory Handbook does not use any form of k or kilo in a binary sense and I have not been able to find any contemporaneous evidence of such usage. The two footnotes are tangential to this dubious sentence. It's not clear when the Semiconductor industry began using binary prefixes - we may have to go to 64 kbit chips circa 1979.

To further explain my point I did a search in IEEE Xplore (1968-1975) looking for "(1k or 4k or 16k) and memory" and got 104 hits with the earliest semiconductor example being "The set of memory boards is partitioned into modules of 4K words by 32 bits" from Megabit bipolar LSI memory systems: IV, 1970 IEEE International Solid-State Circuits Conference. Digest of Technical Papers, Feb 1970, from Fairchild. The earliest Intel cite is 1973. It is difficult to prove a negative, on the other hand there is simply no evidence to support this sentence.

BTW, I would point out that this sentence derives from GregL's original editing and therefore he should be careful about violating WP:Own.

Tom94022 (talk) 22:50, 25 May 2011 (UTC)

Here is my proposed revision to the several sentences regarding main memory history. I replaced the two questionable citations with better ones, moved them to footnotes and shortened the whole thing.

Likewise, the practice of using prefixes assigned to powers of 1024 within the industry also traces its roots to the early days of computing The practice of using the prefix “K” to denote 1024became common in the late 1960s and early 1970s particularly with introduction of semiconductor memory As memory sizes grew the computer industry adopted the prefixes “M” for mega and “G” for giga denoting 1,073,741,824 and 1,099,511,627,776 bytes of memory respectively.

Tom94022 (talk) 17:19, 26 May 2011 (UTC)

The use of uppercase K to denote 1000 was common in the electronics industry before computers were invented. Look at any schematic diagram from the period. Standardizing on lowercase k was initiated by the introduction of SI in 1960 to avoid confusing with the symbol for Kelvin. SI was adopted by NBS in the US in 1964 (NBS Administrative Bulletin 64-6 issued Feb 1964, per NASA SP-7012) and took many years to gain wide acceptance. Same for the space between number and unit. One publisher I work with insists on no space. In any case, this issue does not belong in an article on hard disk drives. Also people using K for memory, as in 16K or 32K, were mostly using it as an approximation, as was common in the electronics industry for other values, such as resistance or voltage. The distinction begins to get serious at 64K (or is it 65K, both were used). It became very important for the System/360 architecture with its 24 bit address space. (128K vs 131K, 256K vs 262K, etc.) Amdahl may have been the first to make the 1K=1024 statement explicit. And all this precedes solid state memory. I would suggest the following wording (note corrected values for M and G):

Likewise, the practice of using prefixes assigned to powers of 1024 within the industry also traces its roots to the early days of computing Using the prefix “K” to denote 1024 became common in the late 1960s and early 1970s particularly with introduction of main memory larger than 32,768 addressable units. As main memory sizes grew, the computer industry adopted the prefixes “M” for mega and “G” for giga denoting 1,048,536 and 1,073,741,824 bytes of main memory respectively.

--agr (talk) 22:21, 26 May 2011 (UTC)

Hi Arnold: I have no problem with dropping footnote 2 regarding k vs K as TMI; I'd already cut it back from the original edit by GregL. I am less certain about changing the second sentence from semiconductor advent to main memory size as the driver to making K meaning 1024 common. Perhaps both. And perhaps the threshold should be 64 KiB since it absent a qualifier such as in the Amdahl article it is simply not clear whether by K an author meant nK = n * 1034 or nK ~ n * 1000. Tom94022 (talk) 23:32, 26 May 2011 (UTC)

I took a look a Phister, Data Processing Technology and Economics - he shows the average memory size on both IBM and other computers in 1969 as 60 kB (decimal) so that occurs long before semiconductor usage. This suggests semiconductor is at least as important as memory size. Or maybe both are just coincidence. We may be getting close to OR here as is indeed the original sentence. Tom94022 (talk) 00:33, 27 May 2011 (UTC)

I don't think average memory size has any relevance here. Then as now there were many more small machines than big ones. It was the capacity of large machines that drove the K/M usage. When IBM announced the 360 in 1964, they spoke of core storage memory up to 8,000,000 characters see [1]. In 1969 the 360/65 at MIT's computation center had 256 or 512 K of core memory. Semiconductor memory had nothing to do with it. And even semiconductor memory was not consistent in usage. I have some 64K memory chips whose part numbers use "65" to indicate size. This is in the early 80s. --agr (talk) 03:42, 27 May 2011 (UTC)

It may not. I think in an edit now archived you made the point that IBM was very careful in its documentation and didn't use the terms K or M in any sense, preferring either to state an exact decimal number to whatever digits necessary or using thousand and/or million. I think that's true. So when and what led to first the "common" use of "K" in a binary sense and then "M"? As near as I can tell it was not "common" until sometime in the 1970s certainly a long time after "introduction of main memory larger than 32,768 addressable units" - that is long after 1964. BTW I looked at the original PDP8 manual, mainly used 4,096 with a few 4Ks. Intel didn't use "K" on the 1103. When did it become "common"? Perhaps the whole sentence needs work. Tom94022 (talk) 04:49, 27 May 2011 (UTC)

First of all, remember we are talking about mostly informal usage. The was no overarching committee telling everyone what to do (any more than there is now). I'm sure IBM did have strict style guides for customer documentation, but more technical stuff got more leeway. Note that the 360 announcement I link to above talks about "8,000,000 characters", when the actual number is 8,388,608. The usage K=1024 was common in the IBM 360 era and that starts well before 1970. And IBM dominated the computer industry then. A couple of examples: 1. http://bitsavers.org/pdf/ibm/360/fortran/Y28-6601-1_FORTRAN_E_PLM.pdf from 1966, Appendix J page 137: "Figures ... reflect the main storage allocation associated with each successive phase/interlude as it performs its functions, when only a minimal amount of storage (15K bytes, where K =1024) is available for compilation." 2. http://www.columbia.edu/acis/history/#timeline Dec 1968: "IBM 360 equipment at the end of 1968 consisted of [24]: * Model 75 CPU 2075 with 2.5 million bytes of memory. * Two processor storage units 2365 (512K total) ..." Remember the 360 changed two things, it increased address space to 24 bits and used byte addressing. An IBM 7090 introduced in late 1959, maxed out at, and typically came with, 32,768 words of 36-bit core memory. If that size memory is converted to byte addressing, it would already be at 128K or more. So the issue of what K meant came up in common usage as soon as higher end 360s (e.g. the 65 and 75) started shipping. And these were core machines. This usage for K was not universal. I found a DEC PDP 11 Peripherals and Interfacing Handbook from 1971 that says on p.63: "Disk systems range from the RC11/RS64 which has a basic storage of 65K words (expandable to 262K)..." Later on the page it makes clear that 65K and 262K mean 65,536 and 262,144. But IBM had huge clout and, in my opinion, esthetics were on their side. Numbers like 131K, 262K, and 524K conveyed less meaning to programmers than 128K, 256K and 512K. And again, none of this has anything to do with solid state memory.--agr (talk) 19:50, 27 May 2011 (UTC)

The proposed sentence uses the term common not informal. Actually I think you have made the case that neither the advent of semiconductor memory not address sizes > 32 KiB has any correlation to the common usage of K meaning 1024 much less correlation. So I think we are best served with a sentence that reads something like:

Using the prefix “K” to denote 1024 became common in the 1970s

If you agree we can look for good examples Tom94022 (talk) 21:35, 27 May 2011 (UTC)

The 15K example I gave was from a System/360 internal document. It simply shows IBM adopted the K=1024 convention for the 360, with its large address space and quadrupling of addresses for the same physical memory. In any case, "became common in the 1970s" is problematical for several reasons. First, it suggests the usage wasn't common before then (which isn't true), second it needs qualification as to with whom it was common, certainly not the general public, and third, it is drawing a WP:OR conclusion from a few examples. I would not object to "The prefix “K” was used to denote 1024 by computer professionals in the late 1960s" or "Using the prefix “K” to denote 1024 was common among computer professionals by the early 1970s." --agr (talk) 17:30, 29 May 2011 (UTC)

I can live with, "Using the prefix “K” to denote 1024 was common among computer users by the early 1970s." I would point out that the qualification "among computer users" probably applies to the whole article with regard to customary binary prefixes. I would also point out that while there is anecdotal evidence of some usage in the 60s and perhaps earlier, it really doesn't appear to be all that common. It is a long reach from an appendix of an obscure Fortran manual to a common IBM corporate practice. So far I have found very few IBM usages of K until the late 70s. Tom94022 (talk) 19:38, 29 May 2011 (UTC)

By way of example of non usage in the 60s, neither the IBM System/360 Principles of Operation nor the System/360 Announcement Letter uses any binary prefixes. So I have a hard time thinking K meaning 1024 was common in IBM in 1964.Tom94022 (talk) 20:06, 29 May 2011 (UTC)

If I chase through the IBM mainframe product line announcements looking for any binary usage the earliest I have found so far is the 1972 M158/168 announcements one of which stated ... (main) storage of up to four megabytes was available in a single Model 158. So I think the early 70s is the earliest we can talk about common usage. Unfortunately this is binary mega not binary kilo. Tom94022 (talk) 20:15, 29 May 2011 (UTC)

Finally I would note that the 1974 edition of the S/360 Principles has 11 instances of K used in a binary sense including the qualifier (K = 1024, so we can bound the IBM transition as some time between the 1964 first edition and the 1974 thirteenth edition. Tom94022 (talk) 20:28, 29 May 2011 (UTC)

The example I remember most from the late 60s was the Fortran G and H manuals. They both used 128K and 256K respectively to indicate the minimum machine configuration on which their compilers ran. Unfortunately, Bitsavers only has digitized the more obscure program logic manuals, not the ubiquitous Programmer's Guides. But we seem close to agreement. I'm not comfortable with "computer users" as that covers a much broader group, most of whom were unfamiliar with technical issues. "Programmers" or "engineers" would be acceptable.--agr (talk) 21:15, 29 May 2011 (UTC)

How about:

Likewise, the practice of using prefixes assigned to powers of 1024 within the industry also traces its roots to the early days of computing^[1] By the early 1970s using the prefix “K” to denote 1024 was common within the computer industry.^[2]^[3]. As memory sizes grew the industry adopted the prefixes “M” for mega and “G” for giga denoting 1,048,536 and 1,073,741,824 bytes of memory respectively.

^ G. M. Amdahl; et al. (1964). "Architecture of the IBM System/360". IBM JRD. 8 (2). Capacity 8 bit Bytes - 1K = 1024 {{cite journal}}: Explicit use of et al. in: |author= (help)
^ IBM System/360 Operating System: Storage Estimates (PDF), IBM Corp., 1971, p. 21, GC28-6551-12, Model 40 with 64K bytes of storage and storage protection {{citation}}: Unknown parameter |month= ignored (help) This document contains approximately 468 usages of K meaning 1024
^ PDP11/05/10/30/40 Processor Handbook (PDF), Digital Equipment Corp., 1973, p. 1-1, ... direct addressing of 32K 16-bit words or 64K 8-bit bytes (K = 1024) This document contains approximately 80 instances of K meaning 1024.

Tom94022 (talk) 22:11, 30 May 2011 (UTC)

I can live with that. One minor suggestion, I'd add "12th ed," to the IBM System/360 Operating System: Storage Estimates reference. (It would be interesting to see how an earlier edition presents the same data. The Computer History Museum has a first edition from 1966, but it's not online. http://www.computerhistory.org/collections/accession/102665291)--agr (talk) 02:11, 31 May 2011 (UTC)

Done Tom94022 (talk) 05:00, 1 June 2011 (UTC)

For the past 30 some odd years the computer industry has been at odds as to what the "K" stood for. Some represent it as 1000 time while others use 1024 to make their calculations. As for a table, there is already a good table here: http://en.wikipedia.org/wiki/Kilobyte so why create a new/different one which only confuses the issue.

No standard has come about in the past 30 years even though for the past 12 years or so, the computer world has tried to come up with a standard... they cannot agree on much. Microsoft and many other disk manufacturers continue to use 1000 as the basis for K rather than the 1024 while others stick to the 1024 method. The semiconductor industry has standardized on the 1024 use while disk mfgrs around the world continue to follow Microsoft's use of 1000 instead of 1024. That's why when you format a disk per the 1000 scheme, you end up with some extra bits hanging around as unused space.

If somebody used 1000 back in the 1960's or 1970's, then mention that this is not consistent with the current 1024 usage, but then again, even though more and more people are using the 1024 in the computer world, some still cling to the 1000 as the converter.

It's been the same headache for over 30 years now and will probably continue to be for quite some time. Thus debating it won't make it a standard any quicker. Until everybody comes together with a single conversion method, there will continue to be variations and anomalies. Denote them as such and leave older articles be. At least Wikipedia should come to a single standard to use from now on and ensure that everybody follows that noting quote of older information need a footnote mentioning the differences. — Preceding unsigned comment added by Wbenton (talk • contribs) 06:43, 19 August 2011 (UTC)

To Wbenton:

Microsoft and many other disk manufacturers continue to use 1000 as the basis for K rather than the 1024 while others stick to the 1024 method. Microsoft is not a disk manufacturer, but more important, MS's operating systems use K=1024, M=1,048,576, G=1,073,741,824, etc., in displays of disk size and file size as well as for RAM size. Disk manufacturers universally do use decimal prefixes; this is not a matter of "many other".

That's why when you format a disk per the 1000 scheme, you end up with some extra bits hanging around as unused space. Completely wrong, I'm afraid. You can't "format a disk per the 1000 scheme", whatever that means; the disks come in capacities that are multiples of either 512 or 4096 bytes - the sector size. When you put, for example, a 500 GB disk (500,000,000,000 bytes, that is 976,562,500 sectors of 512 bytes each) on a Windows machine, you get to use all 500,000,000,000 bytes. Really, you do. Oh, sure, the OS does report it as 465 GB, but because the G there means 1024³, that still equates to 500,000,000,000 bytes; there is no "unused space." (Check it. Multiply 465x1024x1024x1024. The discrepancy between the result and 500 billion is literally due to a rounding error.) If you look at the drive properties you will indeed see 500,000,000,000 bytes reported as the total size. And almost that much will be available, minus a tiny, tiny amount for partition structure and file system overhead (that will be nowhere near the 35GB "missing" from the 465GB figure). Jeh (talk) 03:08, 27 September 2011 (UTC)

I am sorry, but this still clears up 0 to me. Using a certain Binary system goes back as far as the C=64. 1024 for one meg, 1024 Megs/1 Gig. A proper Gig by this system would be 1,024,000 or 1,024,000,000 bytes. It would not amount to 500,000,000,000 bytes. You would end up at 512,000,000,000. Also, windows doesn't allow you to use it all either. Sometimes as much as 12 GB is used by windows for (??) Indexing? I prefer the 1024 method, obviously. So where did the 1000 one over come from? I only have theories, and that is, that Hard Drive manufactures did it because it just sounds good. If you find the correct reason... anyone, please delete my Dumb Theories, And Then Place Them Here. — Preceding unsigned comment added by 71.254.120.46 (talk) 00:01, 27 October 2011 (UTC)

Proposal to Split off "Disk drive performance characteristics"

I would like to propose that we split off the section on Performance characteristics for the following reasons:

The current Hard disk drive article is already very long (too long based on other articles which have been split at this length).
The existing articles for access time & seek time are vastly lacking sources and information.
The article latency (engineering) is vastly lacking specific information on disk drives.
Anyone reading any of these three articles should understand all three elements as a whole to lessen confusion. The single article would serve that purpose very ~~sell~~well.

Once we have this section split off we can further expand it and properly source the material (which it is currently lacking on the specific descriptions and operations from my recent quick review. Any unique information in the access and seek time articles can be merged into this new one.

Then we can redirect the current articles on access time and seek time to this new article. The latency article can have a section on disk drives which points to the new article. The HDD article can then provide some basic information with an initial direct to the new article.

I propose we call the article Disk drive performance characteristics. Other proposals are certainly welcome.

I did not want to make any of these changes without consensus from the highly active editors in this article. § Music Sorter § (talk) 05:55, 29 June 2011 (UTC)

I can go along with this, particularly if the new article is generic to all disk drives, floppy, optical and hard and thereby allows us to reduce the content of all three primary articles. There are other areas that could be improved, for example the interface section probably could be cut in half. Tom94022 (talk) 05:21, 1 July 2011 (UTC)

As I started thinking through the new article and how we can incorporate all the data from the current related sections in the proposed other articles I realized the HDD article includes sections that I would not think are typically associated with "performance".

Performance characteristics
- Access time
  - Interleave
  - Seek time
  - Latency
  - Data transfer rate
- Power consumption
  - Power management
- Audible noise
- Shock resistance

I propose the new article only cover the items currently listed under Hard disk drive#Access time above and also everything pertinent from the articles:

Access time {unref}
Seek time {2 ref}
Latency (engineering) {1 ref} (the section related to drives)
Rotational delay {unref} (what is not already covered under latency)

I expect we will have comments about how optimizing power can cause delays in response time in the new article. I suppose we can decide later if Power, Noise, and Shock should be in a different section in the HDD article. I will not make that change at this time.

Once I finish the first cut at the new article, what steps do we take on the articles we incorporated? Do we put merge notices on them to the new article, or do we simply redirect that article title to the new one since we will already have all that content? § Music Sorter § (talk) 03:19, 2 July 2011 (UTC)

Ah. After reading those other sections in more detail I can see the connection. In the new article I will propose a slight modification to that content to put them as sub sections on latency since they result is slower spindle speeds. That might also help the flow a bit. I will likely focus those sections on the performance related aspects of those sections, so we will likely need to keep something on them here for the other contextual portions. Either way a work in progress over the next week or so and I am open to any recommendations if I raise any concerns. § Music Sorter § (talk) 03:57, 2 July 2011 (UTC)

I don't have any problem with a broad definition of "performance" and a narrow definition would diminish the effectiveness of this edit in reducing the size of the article. BTW, interleave is pretty obsolete and probably should be a footnote to latency. Tom94022 (talk) 05:21, 2 July 2011 (UTC)

Sounds good on both. For "footnote" do you mean literally cram all that into a single note, or rather make it a sub section under latency (which would make more sense to me). § Music Sorter § (talk) 08:25, 2 July 2011 (UTC)

It's way too long and maybe we can hack it into a footnote. Something like, In some early PCs the internal bus was slower than the drive data rate so sectors would be missed resulting the loss of an entire revolution. To prevent this sectors were interleaved to slow the effective data rate preventing missed sectors. This is not a current problem." But I would have to find a reference, which is more than I can say for the current article. Actually now that I've written something I guess it goes into data rate more than latency. Tom94022 (talk) 06:01, 3 July 2011 (UTC)

That looks pretty good. I will try to remember to pop that in before we are done. You might be right about the category now that you mention it. We need more subsections/information in the data rate category anyway. § Music Sorter § (talk) 09:43, 3 July 2011 (UTC)

OK. I have completed the major work on creating Disk drive performance characteristics based on the sections here and the sections on SSDs. I have not done any extensive integration of these performance characteristics from the optical drive article(s) and only a little from the floppy article. Before I start making major changes from this article I wanted to get some other editors to look, review, modify as they deem necessary. We should discuss specific changes to the performance article on that talk page and only cover here what may be missing from here or how we want to integrate it. § Music Sorter § (talk) 06:22, 9 July 2011 (UTC)

[1] G. M. Amdahl; et al. (1964). "Architecture of the IBM System/360". IBM JRD. 8 (2). Capacity 8 bit Bytes - 1K = 1024 {{cite journal}}: Explicit use of et al. in: |author= (help)

[2] IBM System/360 Operating System: Storage Estimates (PDF), IBM Corp., 1971, p. 21, GC28-6551-12, Model 40 with 64K bytes of storage and storage protection {{citation}}: Unknown parameter |month= ignored (help) This document contains approximately 468 usages of K meaning 1024

[3] PDP11/05/10/30/40 Processor Handbook (PDF), Digital Equipment Corp., 1973, p. 1-1, ... direct addressing of 32K 16-bit words or 64K 8-bit bytes (K = 1024) This document contains approximately 80 instances of K meaning 1024.

[1]

[2]

[3]