Talk:DEC 3000 AXP

Use of ambiguous prefixes

A few days ago I tried to introduce an unambiguous explanation of terms like MB. Rilak reverted the changes, making the text ambiguous again. After that, the following discussion took place at Rilak's talk page:

---

Rilak, I gave you a good reason, which is to explain to the reader the meaning of the terms KB, MB, GB. In what sense is that silly?. Thunderbird2 (talk) 13:57, 14 March 2008 (UTC)

There is no need to explain a universal meaning. There are hundreds of computer related articles with KB, MB, GB and so far there are no complaints, with the exception of media such as hard drives, about what the units mean. As stated by editors before in discussions concerning other articles, you are more likely to confuse readers with two alternate units. I also belive that Wikipedia does not use IEEE binary prefixes in any circumstances. For the record, I personally support IEEE binary prefixes and I use it myself when I can, but not when I confuse others or violate MOS. Rilak (talk) 14:18, 14 March 2008 (UTC)

In what sense is it confusing to provide an unambiguous definition? And what part of MOS would it violate to do so? Thunderbird2 (talk) 17:24, 14 March 2008 (UTC)

---

Use of unambiguous units is encouraged by MOSNUM, and the megabyte is named explicitly as an example of a unit requiring disambiguation. What do others think? Should we leave these ambiguous units unexplained? Thunderbird2 (talk) 09:19, 15 March 2008 (UTC)

I am ambivalent as to whether they need to be there, but if they are there, the associated value should not be repeated (i.e., "256 KB (256 KiB)" should be "256 KB (KiB)"). Having the value twice IS confusing. VMS Mosaic (talk) 20:17, 15 March 2008 (UTC)

MOSNUM is very clear on this point. The relevant text reads:

Specify whether the binary or decimal meaning of the units kilobyte, megabyte and similar is intended.

I think VMS Mosaic's suggestion of 256 KB (KiB) is a good way of satisfying this requirement. Thunderbird2 (talk) 21:33, 15 March 2008 (UTC)

Why the sudden interest in this particular article? I don't see an effort to append other computing articles with IEEE binary prefixes. Additionally, provide a quote from MOS that explicitly states that editors should do what you do. From what I read, the units used are KB, MB, GB and so on. Rilak (talk) 15:16, 16 March 2008 (UTC)

I have already quoted the most relevant MOSNUM text. The megabyte and its cousins are ambiguous and MOSNUM requires us to disambiguate. Why should this article be exempt? Thunderbird2 (talk) 15:35, 16 March 2008 (UTC)

Could you please provide the exact line number, not a summary? I can't find it in MOSNUM that states it explicitly. Also, I did not ask for this article to be except. Instead, I should be asking why should other articles be exempt, because as of now, this is what it looks like. This article, I would assume, would not receive much traffic due to it's subject. Articles such as this one are much more heavily viewed yet I cannot find any instance where an editor has appended MiB after MB. Rilak (talk) 15:51, 16 March 2008 (UTC)

I don't know what line number it's on, but if you follow the link and search for "kilobyte", you'll find it.

The article to which you refer contains the following disambiguation footnote:

A gigabyte of memory means 1024³ bytes, i.e., 1 gibibyte

Would you prefer that format? Thunderbird2 (talk) 16:37, 16 March 2008 (UTC)

If the Mac Pro article is acceptable because MB is linked to MB, then why add another dimension of confusion into the article when you could have simply linked the term to its article? Units that have the potential to confuse should be linked to their definition in their appropriate context, not by adding ten zillion different but equivalent units, eg. 1 MB (also 1 MiB and 1 My-Own-Preferred-Unit-for-1,024-kibibytes...) —Preceding unsigned comment added by Rilak (talk • contribs) 17:10, 16 March 2008 (UTC)

The megabyte article starts by pointing out, correctly, that the megabyte is an ambiguous unit. The MOSNUM requirement, which is to explain which of the two (or three in the case of MB) definitions is intended, is therefore not met. It seems to me that there are two serious alternatives: One is to use MiB; the other is to explain (where appropriate) that 1 MB = 1024² B. Can you suggest a better way? Thunderbird2 (talk) 17:24, 16 March 2008 (UTC)

If binary prefixes are used, then others will remove it, as there is no consensus to use binary prefixes in any situation (this is from I have been told and from what I have observed) so what improvements you have made will not be long-lasting. The most appropriate method is to add a note somewhere to define KB = 1,024 bytes and so forth. Rilak (talk) 17:37, 16 March 2008 (UTC)

In my opinion, a footnote would be fine. I don't agree that "there is no consensus to use binary prefixes in any situation". The consensus is that they should be used only when we are sure the MB is used in its binary sense, as in this article. I have invited comment from MOSNUM, so hopefully we will have some other opinions soon. I suggest we wait 24 h before changing anything to give others a chance to comment. Do you agree? Thunderbird2 (talk) 17:47, 16 March 2008 (UTC)

A footnote is acceptable and I will wait for further comments for 24 hours. I have to admit, I have not heard of a consensus to use binary prefixes when the context uses KB/MB/GB in a binary sense. Rilak (talk) 17:56, 16 March 2008 (UTC)

Perhaps the thing to do is to disambiguate with a different method that is also allowed by MOSNUM? For example "256 KB (256×2¹⁰ bytes)". Fnagaton 18:09, 16 March 2008 (UTC)

Regarding the "consensus", MOSNUM is clear on this matter where it says "There is no consensus to use the newer IEC-recommended prefixes in Wikipedia articles to represent binary units." Fnagaton 18:12, 16 March 2008 (UTC)

(unindented)

• All: MOSNUM can be a little like the Bible or the Koran: you can often read what you want into it. Note however, this exceedingly practical policy on MOSNUM at #Which system to use:

“ In scientific articles, use the units employed in the current scientific literature on that topic. This will usually be SI, but not always; for example, natural units are often used in relativistic and quantum physics, and Hubble's constant should be quoted in its most common unit of (km/s)/Mpc rather than its SI unit of s⁻¹. ”

I would argue that Wikipedia should observe whatever practices are observed by the best paid-subscription computer magazines. I am a Mac owner, subscribe to MacWorld, and routinely visit a huge number of Mac-related Web sites—usually daily. I must profess that I haven’t lately perused Windows-oriented magazines so I can’t purport to being an overall authority on computer jargon across all platforms. For instance, the Unix or Linux crowd may be much more precise than Windows/Mac magazines. Having covered myself now with caveats…

I encountered the term “kiB” the very first time on Wikipedia. I correctly surmised it must have had something to do with clarifying the ambiguity with binary and decimal math but had to click the linked unit of measure to figure out which one it meant. I submit that Wikipedia should always follow common practices and not attempt to lead—regardless of the field or article. It takes more than a proposal from an organization like the IEEE to make something an effective way to communicate; the proposal must be widely adopted so the term is well recognized by the intended audience. If scientists in the field of gravimetry routinely use a unit of measure called the gal, then Wikipedia articles should (and do) use than non-SI unit of acceleration in related articles. If Wikipedia didn’t, we would be undermining the fundamental objective of technical writing: to clearly communicate technically oriented information to the intended audience with minimal confusion. Sometimes, we just live with certain shortcomings in units of measure. For instance, the International Union of Pure and Applied Physics once proposed that expressions like ppm (parts per million) be replaced with a new unit called the uno. Notwithstanding that it was arguably a great idea, it was not widely accepted and the principal proponent of the idea withdrew it. Note that the necessary virtue—and the one that was missing with the uno—is “widespread adoption.”

In a nutshell, I am unclear about MOSNUM policy on kB, MB, GB, etc. However if there is a MOSNUM policy that, in an effort to remedy ambiguity, calls for the use of terms that are unfamiliar with the typical reader who would be visiting any given article, then we should fall back to MOSNUM’s one, extremely wise policy that requires adoption of the term that is used in current literature on the subject. If Wikipedia finds itself leading the charge in an effort at correcting an ambiguity when most other publications have not entered the fray, then perhaps the “ambiguity” is more of a perception that a real problem. If “kiB” is well recognized by the Unix community, the Wikipedia articles on Unix topics would be well advised to use “kiB”. And if the term is not well recognized among general-interest computer users (and computer advertisements, brochures, owners manuals, and packaging) then Wikipedia should use whatever terms are common there. This anyway, is my 2¢ on the subject. Greg L (my talk) 20:39, 16 March 2008 (UTC)

Well said. I also linked it on Talk:Binary prefix. FYI, the majority of the Unix community also do not default to using -bi prefixes due to various reasons. Fnagaton 21:02, 16 March 2008 (UTC)

It should be noted that the technical manual (whose horribly long title can be found in the reference section) used to obtain information for this article used KB, MB, GB and so on. Rilak (talk) 22:09, 16 March 2008 (UTC)

The consensus seems to be to disambiguate by means of a footnote, with a preference to do so with reference to explicit numerical values rather than with IEC prefixes. I propose to add two such footnotes. One in the section Description/Memory:

• when applied to computer memory (RAM or cache) the quantities KB, MB and GB are defined as
  • 1 KB = 1024 B
  • 1 MB = 1024 KB
  • 1 GB = 1024 MB

And then another under Description/SCSI interface:

• when applied to data transfer the quantities KB and MB are defined as
  • 1 KB = 1000 B
  • 1 MB = 1000 KB

Thunderbird2 (talk) 18:00, 17 March 2008 (UTC)

You mean "to do so with reference to explicit numerical values than with IEC prefixes" not "without"? Fnagaton 18:10, 17 March 2008 (UTC)

Yes, that's what I meant. I've fixed it now. Thunderbird2 (talk) 18:17, 17 March 2008 (UTC)

Then I agree with the proposed footnote. Fnagaton 18:22, 17 March 2008 (UTC)

Rilak, are you OK with the proposed footnotes? Thunderbird2 (talk) 21:46, 17 March 2008 (UTC)

This is wrong: the bandwidth of a parallel bus (such as SCSI) is obviously in power-of-2 units if the width of the bus is a power of 2 (such as 8 in this case). Letdorf (talk) 11:02, 18 March 2008 (UTC)

Letdorf, when I say I agree with the proposal I mean it is the better choice from a bag of bad options. ;) It's far better than peppering the article with those -bi prefixes everywhere for example. Fnagaton 11:12, 18 March 2008 (UTC)

I don't know where Letdorf gets the binary usage in SCSI data rates but it is wrong to state KB/sec = 1,024 bytes/sec, etc. I changed the footnote to reflect decimal usage. I also suggest it is POV and invention to state that such usage is not consistent with JEDEC - is there a JEDEC standard on data rate - I don't think so? Tom94022 (talk) 17:54, 18 March 2008 (UTC)

The JEDEC definition of the prefix mega- reads

• mega (M) (as a prefix to units of semiconductor storage capacity): A multiplier equal to 1 048 576 (2²⁰ or K² , where K = 1024).

• NOTE 1 Contrast with the SI prefix mega (M) equal to 10⁶ , as in a 1-Mb/s data transfer rate, which is equal to 1 000 000 bits per second.

• NOTE 2 The definitions of kilo, giga, and mega based on powers of two are included only to reflect common usage. IEEE/ASTM SI 10-1997 states “This practice frequently leads to confusion and is deprecated.” Further confusion results from the popular use of a “megabyte” consisting of 1 024 000 bytes to define the capacity of the familiar “1.44-MB” diskette.

I read that as saying that

• the prefix M means 1024² when applied to memory and 1000² when applied to data transfer, and
• the practice of using M to mean 1024² is common but confusing.

I accept that the definition is unclear though, and perhaps the same words can be interpreted in a different way. Any suggestions? Thunderbird2 (talk) 18:09, 18 March 2008 (UTC)

I admit, in my previous comment, I was thinking in bits, not bytes, so I concede that a quoted SCSI bandwidth of, say, 5 Mbyte/s is using M in the decimal sense. However, I don't think the quoted JEDEC document is relevant here, as its definitions specifically cover semiconductor memory only, and merely mentions in passing that the decimal prefix convention may be used in other domains. Letdorf (talk) 21:07, 18 March 2008 (UTC).

Yes, if you read it like that then I accept Tom's point that the (SCSI) footnote is inaccurate (I wasn't pushing a particularly POV - just interpreted the same words differently). How about we replace "inconsistent with the JEDEC standard" with "using the SI prefix for data transfer" or some such?

Everything looks good... But my previous attempt of solving this had KB and MB wikilinked to their articles. Should I remove them since they may confuse and because they are redundant with the footnotes? —Preceding unsigned comment added by Rilak (talk • contribs) 05:35, 20 March 2008 (UTC)

I would prefer the links to stay, since they lead to a more complete definition of these units, and the circumstances in which they used. In doing so they help explain the apparent contradiction between the two footnotes. Thunderbird2 (talk) 07:32, 20 March 2008 (UTC)

Firmware

I was thinking of adding a section on the firmware used in these systems but I've run into inconsistencies in the manuals. Here are my quick 'research' notes:

DEC 3000 Model 500/500S/500X/800/900 AXP Firmware

• 256 KiB of writable console ROM in the CXTurbo graphics subsystem. (page 28) This is referred to as the 'System FEPROM' in Chapter 6 (page 81) and in Chapter 13. (page 195)
• 256 KiB of writable console ROM. It is a part of the I/O subsystem and is connected to the IOCTL ASIC. (page 27). It is also referred to as the 'I/O Board ROM' in Chapter 13. (page 195) According to the Digital Technical Journal article, it is an AMD 27C020 EEPROM, not flash.
• 64 KiB Serial ROM. Chapter 13 (page 195) claims it is part of the SFB subsystem, although it should be connected to the CPU directly. According to Chapter 1, this is a 64 * 8 (64 KiB) UVPROM connected to the CPU, consistent with descriptions of the DECchip 21064.
• 32 * 8 (32 bytes) of Ethernet Station Address ROM. It is part of the I/O subsystem and is connected to the IOCTL ASIC. (page 122)

Both 256 KiB ROMs are flash ROMs according to Chapter 13.

References: DEC 3000 AXP Programmer's Manual

DEC 3000 Model 400/400S/600/600S/700 AXP Firmware

• (#2) 256 KiB FEPROMs connected to the IOCTL ASIC. (Page 18)
• 64 KiB Serial ROM. Chapter 13 (page 195) claims it is part of the SFB subsystem, although it should be connected to the CPU directly. According to Chapter 1, this is a 64 * 8 (64 KiB) UVPROM connected to the CPU, consistent with descriptions of the DECchip 21064.
• 32 * 8 (32 bytes) of Ethernet Station Address ROM. It is part of the I/O subsystem and is connected to the IOCTL ASIC. (page 122)

References: DEC 3000 Model 400/400S Technical Manual, DEC 3000 AXP Programmer's Manual

DEC 3000 Model 300/300L/300X/300LX AXP Firmware

• (#3) 256 KiB FEPROMs connected to the IOCTL ASIC. (Page 20)
• 64 KiB Serial ROM (a Xylinx 1765 PLCC SROM) as claimed by Chapter 13. (Page 195), but Xylinx is not a company and the part number does not exist.
• 32 * 8 (32 bytes) of Ethernet Station Address ROM. It is part of the I/O subsystem and is connected to the IOCTL ASIC. (page 122)

References: DEC 3000 AXP Programmer's Manual

The inconsistencies are a little confusing. Does anyone know the true nature of the firmware in these systems? Rilak (talk) 00:14, 24 March 2008 (UTC)

My copy of EK-D3SYS-PM.B01 is a bit confusing on this topic, but the common theme seems to be one 64KB Serial ROM (containing initial boot code and production test code on all but Model 300s) plus two 256KB Flash ROMs ("System" and "I/O"). "Xylinx" should be Xilinx. Letdorf (talk) 01:24, 24 March 2008 (UTC).

That is the same manual I have, revision B01. I don't think there is a later one. The exact connections seem to be a little confusing as well. The system module ROM is connected to integrated graphics subsystem (I have to add a section for this as well) in Model 500s? I have no idea as to how the systems with multiple ROM chips in the I/O subsystem is connected as well. Are they accessed through separate connections or through chaining multiple flash ROMs together? The differences in component specified is strange as well, was it a flash ROM or an AMD EEPROM? As for Xilinx, I thought they made FPGAs, not memory chips. So many questions! Rilak (talk) 01:51, 24 March 2008 (UTC)

Missing models?

According to this page: http://h71000.www7.hp.com/openvms/hw_supportchart.html, there are 700LX and 900LX models, although I cannot find any other references from anywhere else. Are these very obscure models or is it a result of the confusion from the DEC to Compaq to HP move? Rilak (talk) 07:03, 27 March 2008 (UTC)

They never appeared in the SOC (Systems and Options Catalog) as far as I can tell, but they do show up in a couple SPDs (Google "dec 900lx spd"). I suspect they are very obscure models (possibly put out by CSS (the custom sustems group)). I am making this reply from a DEC 3000 model 700 and I had never heard of the 700LX until today. VMS Mosaic (talk) 17:46, 27 March 2008 (UTC)

Thanks for the prompt reply. I guess that there isn't really a need to mention them in the article, due to their obscurity and lack of references, eg. manuals, catalogs, etc. Rilak (talk) 03:15, 28 March 2008 (UTC)