Talk:Asynchronous transfer mode

From Wikipedia, the free encyclopedia
  (Redirected from Talk:Asynchronous Transfer Mode)
Jump to navigation Jump to search
WikiProject Computing / Networking (Rated C-class, Mid-importance)
WikiProject iconThis article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.
Taskforce icon
This article is supported by Networking task force (marked as High-importance).
WikiProject Telecommunications (Rated C-class, Mid-importance)
WikiProject iconThis article is within the scope of WikiProject Telecommunications, a collaborative effort to improve the coverage of Telecommunications on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.

Virtual Channel Identifiers[edit]

This article constantly refers to ATM using virtual circuits. In ATM, "VC" stands for "Virtual Channel", not "Virtual Circuit" (although of course they are an example of the generic concept of virtual circuits). LachlanA 03:15, 31 January 2007 (UTC)

I think it depends on the exact acronym being used. For instance: VCC = Virtual Channel Connection, while PVC = Permanent Virtual Circuit/Connection. The standalone "VC" even seems to be "Virtual Connection" - *smirk*. But you are right, in the case of VCI, it is "Virtual Channel Identifier". (All claims) Based on this Cisco ATM guide. -> See section "VC Merge" 11-8 for a "VC" definition. Regarding "connection" vs "circuit", see page 21: "over virtual connections, sometimes called virtual circuits", so it seems both terms "virtual circuit" and "virtual connection" are ok. However it is highly confusing, the article should use only one style and explain it. Of course claims to abbreviations make only sense when founded on a reliable source.--Methossant (talk) 01:08, 2 June 2011 (UTC)

Cell/payload size[edit]

This seems like a typo, but as I know next to nothing about ATM myself I'm checking here first: The para on the choice of payload size, 32 v. 64, ends with 53 bytes was chosen as a compromise between the two sides - this seems to conflate the payload and total cell size - would it better be "48 bytes was chosen..."? The following text then mentions the 5-byte routing and total of 53 - Royan 22:41, 13 February 2007 (UTC)

The 53 byte cell has a 48 byte payload, and 5 bytes of routing data. As well as I know, the 48 is a compromise between 32 and 64, as suggested by the US and EU, but I don't remember which side wanted which value. In addition, the seven layer ISO model is a compromise between 6 and 8, again US vs. EU, and again I don't remember who wanted which one. Gah4 (talk) 17:00, 7 February 2017 (UTC)

Jitter not the only reason for small fixed-sized packets (cells)[edit]

When engineers were developing X.25 some were already working on digital voice. They realized that time was being lost while the first codec was converting analog data into digial, and that this time loss was proportional to packet size. So the ideal packet size for voice was somewhere between one bit and one byte but the pragmatic demands of the day set it to 128 bytes. Also at that time, pressure from the computer industry demanded larger packets so packet size grew to 4096 (I don't recall it being higher but may be wrong). Jumping back to ATM, certain networks with larger variable-length packets (like Ethernet) made network environments very unpredictable. So just switching to samll fixed size packets (called cells) made ATM networks much more deterministic. Of course, engineers added lots of other stuff to the technology like non-blocking fabrics and QOS to make these networks even more useful. --Neilrieck 13:41, 4 March 2007 (UTC)قاقا باقا

P-NNI is link state but not necessarily shortest-path[edit]

The P-NNI standard specifies the exchange of link state information, similar to what IS-IS and OSPF do. It has more levels of hierarchy, and more metrics, but the basic approach is similar.

However, it does not specify the routing algorithm, i.e., the algorithm that picks the path for a particular destination. The reason is that this is not necessary; SVC setup uses source routing, so there is no need for the switches to agree on what the chosen route will be for a given destination. Connectionless switches require agreement to avoid loops, but ATM SVC setup does not. So the standard leaves this aspect open to implementers' choice.

Obviously, it's to be expected that some algorithm similar to Dijkstra's algorithm will be used to determine the path for a particular connection, but it's not correct to say that the standard "uses the same shortest path algorithm used by OSPF..." Paul Koning 17:01, 2 May 2007 (UTC)

Call admission[edit]

The article says "To admit a call first a VPC has to be established. This will guarantee the correct routing from end to end." This is incorrect. In the signaling for SVC setup, the route is specified (see my comment above on P-NNI). It does not require a pre-existing VPC, for routing or for any other purpose. A call is admitted if the admission control algorithm decides to admit the call, normally because the resources the call asks for (in the signalling messages) are available.

A network implementer can certainly use a VPC as a trunk, and route a new SVC over such a trunk if the source route allows it, but there's no requirement to do so; if a network does that, it's an internal matter that is invisible to the user. Paul Koning 17:06, 2 May 2007 (UTC)

Too technical[edit]

Christ, this article is an extreme example of articles written way too technically. From the lead section alone, I as a layman on the subject cannot even see what the article is about (aside from the word "technology"). SalaSkan 18:08, 8 June 2007 (UTC)

What a stupid comment. This is a technical article. If you're lazy and ignorant it's your fault, not the writer's. —Preceding unsigned comment added by (talk) 23:29, 6 March 2008 (UTC)

See Peter. See Jane. See Jane run. See Peter run. Is this what you're after? If the article has to cover an introduction for numpties then it'll really no longer be much good as an article. Did you get to this page from the "Random article" link or something? —Preceding unsigned comment added by (talk) 09:04, 1 September 2010 (UTC)

Even with elctronics qualifications (old school) I find the introduction needs clarification. See the wood for he trees, guys., etc, ... I m going to stop now before I get rude.Jabberwoch (talk) 13:05, 1 December 2011 (UTC)

If the article wasn't technical it would be of no use to me. Welcome to my world.BurtonReingold (talk) —Preceding undated comment added 22:05, 24 March 2011 (UTC).

Well yes and yes (and please stay civil). It can be technical and still readable. The usual way to do this is to put context and general overview in the lead section, with details in the body. Also a section at the start giving even more context, e.g. time frame and motivation, phone company vs. computer networking mindsets, etc. W Nowicki (talk)

Technical articles are for technically savvy people. If you cannot understand the language, then you're obviously in the wrong place: reading something that you shouldn't or being too much of a novice and aiming too high. If you don't understand some terms, then LOOK THOSE DAMN TERMS UP and learn before proceeding to read the main article, or don't read it at all, since you're apparently not qualified for it. The article isn't meant to provide information for newbies, it simply provides all information about the subject as is using the most fit terms. It should NOT and will NOT have non-savvy readers in mind, remember it firmly. Or do you go to articles on math articles about, say, topology or differential equations, or theoretical physics articles, read it not understanding a word, and complain too? These articles are no different from those highly specialized complex math/physics articles -- either learn all the prerequisite terminology and theory and then proceed to the article, or stay away. End of story. (talk) 05:19, 25 September 2015 (UTC)

There is some use for articles that non-technical people can at least begin reading, but technical people need references, too. For networking technologies that make it into the home, articles should be able to begin with an explanation for home users. For many articles, there is no non-technical place to start. Gah4 (talk) 17:03, 7 February 2017 (UTC)

also operate at OC-192 (STM64) rates[edit]

There doesn't appear to be a clear reason for the statement "ATM switches can also operate at OC-192 (STM64) rates." to be part of a paragraph dealing with ATM over IP and IP routing (not ATM switching). The relevance of this statement should either be qualified with additional information, or if it is indeed dealing with an unrelated issue, put into a seperate paragraph and elaborated upon. I have removed it for the moment. --Het 02:02, 2 October 2007 (UTC)

Golden Standards[edit]

ATM is based on the efforts of the International Telecommunication Union-Telecommunications Standards Section (ITU-T) Broadband Integrated Services Digital Network (B-ISDN) standard. It was originally conceived as a high-speed transfer technology for voice, video, and data over public networks. The ATM Forum extended the ITU-T's vision of ATM for use over public and private networks. The ATM Forum has released work on the following specifications:

•User-to-Network Interface (UNI) 2.0

•UNI 3.0

•UNI 3.1

•UNI 4.0

•Public-Network Node Interface (P-NNI)

•LAN Emulation (LANE)

•Multiprotocol over ATM —Preceding unsigned comment added by Mohanchander (talkcontribs) 06:22, 17 August 2008 (UTC)


I have archived the pre-2007 discussion to Talk:Asynchronous Transfer Mode/Archive 1, not so much because of the volume of the material, but because the discussion was outdated, and the loose format might tend to discourage focused discussions on this talk page. --Bejnar (talk) 20:26, 4 January 2009 (UTC)


Currently this page has a hatnote which reads: Not to be confused with Automated Teller Machine. Since ATM no longer redirects here, is this hatnote still useful, or is it a distraction? --Bejnar (talk) 20:29, 4 January 2009 (UTC)

Lost sentence[edit]

At the end of section Why Cells?, there's an open ended sentence:

5-byte headers were chosen because

Does anyone know where the rest of this sentence has gone, or what it should mean? -- (talk) 12:53, 27 January 2009 (UTC)

No, but as a developer I really want to know, because the 5-byte headers are a pain from a word-alignment point of view! (talk) 15:40, 3 February 2009 (UTC)

Well the sentence now ends, but this whole section needs better citations, especially this 10% claim. W Nowicki (talk) 17:07, 6 May 2011 (UTC)

physical layer[edit]

Other than being multiplexed into SONET, what other choices exist for a PHY layer for ATM? I couldn't find out what standard the NIC in that pic of an ATM NIC follows. I sorta read the ATM standard (UNI 3.1) and it talks about ATM running over STP 150 ohm Token Ring cabling @ 155 with 9 pin DIN connector, FDDI fiber @100, "DS3" at @45, MM fiber with ST connector (BFOC/2.5) @155, and "SONET" STS-3c @ 155 (ANSI T1E1.2/94-002R1) with a reference to ANSI T1E1.2/94-002R1 for what PHY layers those are. Next issue, many things are defined in standards, whether they were commercialized and ever used is a different story, so what are the most common ways to the move an ATM stream other than a DSL modem and multiplexing into SONET? What about P2P non-SONET situations? Patcat88 (talk) 23:48, 14 June 2009 (UTC)

One, I think you're confusing layers 1 and 2. Two, talk pages are for discussing ways to improve the article, not a general forum for conversation about the topic. //Blaxthos ( t / c ) 01:15, 15 June 2009 (UTC)

No 53 T-shirts[edit]

would be nice to have a photo of someone wearing one of those T-shirts with the number 53 in a red circle with red slash (international prohibition sign). AnonMoos (talk) 12:19, 31 December 2009 (UTC)

I suppose useful if you are at an ATM conference, but walking down the street, you will just confuse people. Gah4 (talk) 17
04, 7 February 2017 (UTC)

lowercase correct[edit]

Dgtsyb, you're confused about and confusing several completely different issues in this reasoning of yours: I.150 only uses lower case in the title which is simply ITU-T's house style for titles.

  1. As you can see at the ITU link, asynchronous transfer mode is also used on p.2.
  2. Carefully edited reference works and publications such as Britannica also use lowercase when explaining acronyms like ATM.
  3. Some organizations (including Wikipedia) do not capitalise common nouns in titles, but they never lowercase proper nouns in titles or in text. If something is lowercase in an ITU title, you can be sure it's definitely a common noun, and carefully edited publications like Britannica also lowercase it.
  4. Please do not revert again while the issue is being discussed here. --Espoo (talk) 12:53, 1 January 2010 (UTC)
  • The second page of I.150 is a list of titles. Page i, 1 and 11 (the body of the text) has it capiltalized everywhere. It is a proper noun and it why it was moved on 24 December 2009 from Asynchronous transfer mode to Asynchronous Transfer Mode. I would consider ATM Theory and Applications, part of the McGraw Hill Signature Series on Telecommunications, to be a carefully edited work. The same is true of Integrated Services Digital Network,, Broadband Integrated Services Digital Network, and Public Switched Telephone Network and many other topic areas in the field of communications, a handful of which from your recent edits you appear to wish to somehow make common nouns. For example, your move of Broadband Integrated Services Digital Network, to Broadband integrated services digital network is quite inappropriate: the only cited work in that article capitalizes ISDN, B-ISDN as well as ATM in their long forms throughout.
  • You might find it useful to think whether ATM (or any of these) are properly preceded by any or some. In telecommunications, we neither refer to any ATM nor some ATM; not any B-ISDN and not some B-ISDN. Where it is obvious that we can say any telephone network, or some transport protocol, naturally. Common nouns refer to a class. ATM is not a class. As a counter-example, consider cyclic redundancy code. CRC is not a proper noun. It is a class of algorithms. CRC-32c is a proper noun. Another example: Stream Control Transmission Protocol is a proper noun.
  • Another example: You will see that in the articles and in I.150 on ATM, ATM is written out capitalized as Asynchronous Transfer Mode and yet asynchronous time-division switching is not. Asynchronous time-division switching is a common noun referring to the class of protocols of which ATM is a standardized, specific and particular instance.
  • You appear upset that I reverted your changes. Once ever so often an editor goes stomping though these pages changing all of the proper nouns to lower case, causing an effort to change them all back. To avoid bother, it is common to simply revert these without much comment. Please consider all such changes as controversial and discuss your intended changes before making them to avoid causing unnecessary work for the regular contributors to these articles. Please also consider reducing that work load by reverting your own recent changes to these articles. Thank you. — Dgtsyb (talk) 14:12, 1 January 2010 (UTC)
  1. I.150 would not lowercase "asynchronous transfer mode" anywhere if it were a proper noun. The uppercase use on the other pages is always next to the acronym, as an explanation, and it's a widespread (bad) habit to explain acronyms of common nouns using uppercase. (Bad because it makes people believe these nouns are proper nouns.) Many if not most ITU webpages use lowercase. Even many if not most of those ITU webpages with uppercase are using it when explaining the acronym (and then the non-professional writers/editors, who are only trained as engineers, often get confused and think they should do so elsewhere too). The very fact that carefully edited publications like Britannica use lowercase proves that ATM is a common noun.
  2. Believe me, professional editors of encyclopedias know a lot more about grammar and spelling than engineers, and professional editors of reference works have extensive databases of citations at their disposal, on which they base their decisions. When they see, for example, that engineers use both lowercase and uppercase, professional editors use professional methods not at our disposal to decide which is more common and weight these based on whether these are well-edited "important" texts meant for the public or for internal use / colleagues / other engineers. You're right that some carefully edited technical (and legal) publications follow those professions' predilection for the baroque (18th century) practice of uppercasing Important Words even when they are common nouns, but MOS clearly says to avoid unnecessary capitalisation, in other words when other reliable sources use lowercase. Any attempts to use tests like "any" or "some" to decide whether something is a common noun amount to OR and are hopelessly amateurish. I hope you'll agree that it is quite common in English to uppercase words unnecessarily, even when they are not proper nouns. I hope you'll also agree that it is much less common for even amateur writers to erroneously lowercase proper nouns. This will perhaps help you realise how improbable is the idea that Britannica's editors with their training and huge citation database would erroneously lowercase a proper noun.
This has to be interpreted as an attack on the editors that revert your versions. You certainly don't show this 'professional editor' attribute, as you simply ignore the well founded reasoning that make nouns proper or common in technology. Kbrose (talk) 16:55, 1 January 2010 (UTC)
You are once again defending OR as better than following usage in reliable sources. If these use both uppercase and lowercase, MOS clearly states we should use lowercase, especially when general reference works like Britannica also use lowercase (not to mention most ITU and IEC webpages). Your aggressive removal of information is an attack, not my pointing out that we are not even supposed to try to be professional editors and definitely not try to be above them. (I am a professional editor BTW, but that is not why we should follow what I feel is clearly correct.)--Espoo (talk) 17:09, 1 January 2010 (UTC)
  1. Your comments about some editors "stomping through" and others being "regular" indicate you have not understood one of the main ideas of WP and that you have a tendency to try to own articles. One of the reasons WP is so good is because people who spend a lot of time reading and writing about a topic may be blind to major problems, including general English spelling "rules" (habits) and to usage in general reference works and even on specialist websites like IEC and ITU. Infrequent visitors, especially when they provide reliable sources, should definitely not be simply shrugged off, reverted, and driven out. It's an especially bad idea to remove well sourced info. I would not have been so upset if you'd changed my edits instead of simply reverting all of them and thereby removing the info that ITU, IEC, Wired Magazine, and Britannica use lowercase. --Espoo (talk) 15:57, 1 January 2010 (UTC)

It is quite obvious that User:Dgtsyb is not confused about these issues, as the editor just laid out explicitly and correctly the very good reasons that are used to establish proper and common noun usage not only in telecommunications, but the English language. The editor's explanations also carry weight based on his substantial and knowledgeable contributions to many of these articles. Not following these criteria is absurd and would be controversial no matter what some reference text might use. It should be noted that many publications, for example, also incorrectly don't capitalize Internet out of some principle, but we still insist on proper usage on WP. The capitalization of ATM and ISDN fully spelled out titles is very notable and in-line with all of our proper noun usage on WP. Kbrose (talk) 16:06, 1 January 2010 (UTC)

With your ridiculous comment "no matter what some reference text might use" you just inadvertently disqualified yourself and put your aggressive reverts into an even worse light because WP policy is very clearly that edits are to be based on reliable sources and specifically general reference sources such as Britannica and to a lesser degree on use in specialist literature and not at all on analyses by any editor, no matter how "substantial and knowledgeable" his contributions have been.
Your comments are simply absurd for other reasons too. There may be reasons for using uppercase, but Dgtsyb was clearly confused in using the illogical and erroneous reasoning "lower case in the title which is simply ITU-T's house style for titles." Re-read this a few times:
Some organizations (including ITU and Wikipedia) do not capitalise common nouns in titles, but they never lowercase proper nouns in titles (or in text). If something is lowercase in an ITU title, you can be sure it's definitely a common noun.'
Stop removing valuable, well-sourced information - that's clearly vandalism. If you feel strongly about having uppercase, change that but don't remove reliable sources showing widespread lowercase use by distinguished organisations and publishers. --Espoo (talk) 16:34, 1 January 2010 (UTC)
It is very interesting that you only consider *your* source as reliable. When the proper usage was documented with reliable sources of equal stature you dismissed them with your own interpretation and choice of citation. This documents your attempts of owning the version you like to see. Kbrose (talk) 16:40, 1 January 2010 (UTC)
Actually, I think that the non-introductory university level textbooks published by McGraw Hill and Prentice Hall (pillars with John Wiley in Engineering texts), are more reliable than ITU-T, ISO/IEC and Encyclopedia Britannica. Of these, the text books are, I believe, secondary sources; ITU-T and ISO/IEC, primary sources; Encyclopedia Britannica, a tertiary source: per WP:PRIMARY. The EB entry, as a clear tertiary source cannot be used to support a position on whether the noun is common or proper as that is certainly not the topic of the EB entry. The primary sources cannot be analyzed to determine a part of speech. Therefore, it appears that Espoo's conclusions should be considered original research. I do not believe that the removed mis-cited sources can be considered reliable sources for the conclusions advanced by Espoo. — Dgtsyb (talk) 00:01, 2 January 2010 (UTC)
I specifically did not dismiss the single reliable source provided supporting uppercase. I simply pointed out that reference works like Britannica base their choices on a comprehensive view of usage whereas the editor of the McGraw Hill book is only one person's or a small group's personal preference. And MOS clearly says to avoid unnecessary uppercase, which is clearly the case when both are used by reliable sources. Since your view is fighting the combined windmills of Britannica, ITU, and IEC, the case is especially clear. --Espoo (talk) 16:50, 1 January 2010 (UTC)
Where is Britannica's extensive research on the usage documented? This sounds more like personal research to me. ITU, except in titles which is a different matter (house style), does what other sources on topic do: namely expand it once, capitalized in the introduction and then simply use the acronym throughout the remainder of the document. It saves both paper and ink that way. This is what ITU-T Recommendation I.150 does, as does ATM Theory and Applications, McGraw Hill, ATM Volume III, Internetworking with ATM, Prentice Hall. ISO/IEC does the same thing in, for example, ISO/IEC 13246:1997(E) and ISO/IEC 13247:1997(E). So I don't think that ITU and ISO/IEC documents support your conclusion.
I do recall from earlier working papers on both ISDN and ATM that, before they were standardized, we used to refer to them in all lower case and after standardization in upper case. Perhaps Britannica is following this arcane usage.
The RFC database is a good way to ferret out common usage. In the following RFCs it is always capitalized as Asynchronous Transfer Mode: RFC 1167, RFC 1340, RFC 1391, RFC 1392, RFC 1483, RFC 1539, RFC 1573, RFC 1577, RFC 1599, RFC 1607, RFC 1679, RFC 1680, RFC 1700, RFC 1705, RFC 1709, RFC 1718, RFC 1754, RFC 1821, RFC 1983, RFC 2071, RFC 2225, RFC 2226, RFC 2233, RFC 2299, RFC 2381, RFC 2400, RFC 2502, RFC 2600, RFC 2626, RFC 2684, RFC 2761, RFC 2799, RFC 2863, RFC 2885, RFC 2955, RFC 2999, RFC 3015, RFC 3031, RFC 3035, RFC 3038, RFC 3094, RFC 3116, RFC 3133, RFC 3134, RFC 3175, RFC 3199, RFC 3215, RFC 3292, RFC 3293, RFC 3294, RFC 3295, RFC 3299, RFC 3300, RFC 3336, RFC 3337, RFC 3353, RFC 3355, RFC 3386, RFC 3441, RFC 3471, RFC 3496, RFC 3499, RFC 3525, RFC 3600, RFC 3700, RFC 3809, RFC 3815, RFC 3819, RFC 4048, RFC 4110, RFC 4221, RFC 457, RFC 4294, RFC 4297, RFC 4364, RFC 4365, RFC 4368, RFC 4381, RFC 4447, RFC 4454, RFC 4542, RFC 4553, RFC 4603, RFC 4638, RFC 4679, RFC 4710, RFC 4717, RFC 4766, RFC 4779, RFC 4782, RFC 4803, RFC 4816, RFC 4821, RFC 4840, RFC 4842, RFC 4905, RFC 4906, RFC 4949, RFC 5000, RFC 5070, RFC 5085, RFC 5254, RFC 5287, RFC 5494, and the list goes on... Only once in one RFC that I can find is it referred to as asynchronous transfer mode: RFC 3819, and in that RFC it also appears once as Asynchronous Transfer Mode. This list spans 20 years of common usage. 156 occurrences of Asynchronous Transfer Mode and 1 occurence of asynchronous transfer mode.
The ITU Q-Series breaks down this way: Asynchronous Transfer Mode, Q.1201, Q.2010, Q.2100, Q.2110, Q.2120, Q.2130, Q.2140, Q.2144, Q.2761, Q.2762, Q.2763, Q.2764, Q.2971; asynchronous transfer mode, none. I-Series: Asynchronous Transfer Mode, I.150, I.312, I.326, I.361, I.364, I.365-1, I.365-2, I.365-3, I.374, I.555, I.731, I.751; asynchronous transfer mode, I.321, I.327. Perhaps a confusion to some is that some documents talk of the general aspects of an asynchronous transfer mode. This is because this usage is as a common noun. At the time we knew that an asynchronous transfer mode would eventually be standardized but it was not certain which specific proposals would be adopted. (We didn't even known the cell size, for example). But once the general aspects were decided and all of the specifics standardized, it became commonly referred to as the Asynchronous Transfer Mode, as in the one standardized not a concept of which only the general aspects have been determined.
I don't think I will give it much more effort. I am sorry, but I cannot subscribe to your theory of Britannica throughly researching common usage in this case, or in that of ISDN or B-ISDN for that matter. — Dgtsyb (talk) 21:30, 1 January 2010 (UTC)
A few more additions. ATM Forum documents: CS 107, CS 115, CS 125, CS 126, CS 127, CS 135, CS 140, CS 141, FBATM 139, LANE 38, LANE 112, MPOA 114, MPOA 129, NM 19, NM 27, NM 58, NM 73, NM 95, NM 103, NM 122, NM 184, PHY 43, PHY 79, PHY 86, PHY 110, PHY 128, PHY 130, PHY 133, PHY 134, PHY 138, PHY 142, PHY 143, PHY 144, PHY 162, PNNI 66, PNNI 81, RA 104, RA 105, RA 106, RA 123, RBB 99, RBB PY 101, SAA 108, SAA 109, SAA 124, SEC 100, TEST 30, TEST 42, TEST 44, TEST 51, TEST 52, TEST 67, TEST 70, TEST 90, TEST 137, TEST CSRA 111, TEST CSRA 118, TEST TM 131, TM 121, VTOA 83, VTOA 89, VTOA 113, VTOA 119, VTOA 120, VTOA 132—spelling Asynchronous Transfer Mode, all; asynchronous transfer mode, none. A decade of usage... — Dgtsyb (talk) 22:20, 1 January 2010 (UTC)
One more note: you do not seem to want to consider how the term is used by Engineers and yet the term is not commonly used outside of the field of Engineering. Outside of the field of Engineering, an ATM is a machine out of which you take all your money; inside the field of Engineering, ATM is a machine that takes all your money. ;) — Dgtsyb (talk) 22:01, 1 January 2010 (UTC)

Late to the party, I'm not going to bother responding to all the points above. Suffice to say, in my experience the common usage of Asynchronous Transfer Mode is always capitalized; I see no reason why Wikipedia should be the exception. //Blaxthos ( t / c ) 22:08, 1 January 2010 (UTC)

Take a look at Proper noun. Asynchronous Transfer Mode is a specific standard and can only be thought of as a proper noun and must, therefore, be capitalised. As one cannot guarantee that other authors have correctly followed syntactical requirements, one should not base their argument on common usage. One should instead base their argument on syntactical principals. From this perspective, only capitalised ATM is permissible. This approach may seem contrary to WP philosophy, however, it is the only way to resolve conflicts such as this where common usage is often grammatically incorrect.Internet/internet, as mentioned earlier, being another example. --Spuzzdawg (talk) 22:42, 18 December 2010 (UTC)

This article needs help.[edit]

I added a few references and starting adding inline citations supporting the copy, but didn't make it past the lede. Much of the first part of this article is charged with diverging non-neutral points of view unsupported by the secondary sources I have. Other passages read like an attempt to justify its design. Further passages read like a tutorial or instruction manual for designing networks. Once past those there is a diagram and a few passages and it stops. This article needs a major rewrite from a neutral point of view. It is just too much for me to engage in on my own at the moment. In the mean time, if anyone can clean up some of these passages, I can contribute some secondary sources for them. — Dgtsyb (talk) 14:15, 2 January 2010 (UTC)

IBM Turboways ATM NIC PHY[edit]

Could anyone please tell me what is the PHY (physical layer) protocol used by the depictured IBM Turboways ATM NIC and similar cards by FORE Systems? Could it even be SDH STM-1? (The speed of 155 Mbit/s matches STM-1 exactly.) —Preceding unsigned comment added by (talk) 01:37, 1 November 2010 (UTC)

I don't know this NIC, but there are two 155 Mbps (155 520 kbps) PHY standards given in ITU-T Recomendation I.432.2. One is SDH STM 1 (Sonet STS/OC 3c) and the other is the cell based phy, sometimes called the native ATM phy. This cell based phy has exactly the same cell throughput as STM 1 (149.760 Mbps), because an (extra) idle or PHY layer OAM cell is added after each 26 ATM layer (data) or idle cells. Graham Fountain 14:12, 1 December 2010 (UTC)

Current Uses of ATM[edit]

Can anybody add a section on the uses, particularly current uses, of ATM?

It's my understanding that although it's not become the ubiquitous network standard is was touted as in the 90s (Fast/GB Ethernet did), it's still being used in telecoms infrastructures, and, I have been given to understand, some parts of broadband Internet access.

Put somewhere near the start, this would, I think, be a useful and (possibly) interesting addition to indicate the relevance (or not) of this article. Graham Fountain 14:23, 1 December 2010 (UTC)

You need to come up with a citation for such statements. My understanding is that ATM networks are being decommissioned and no new ATM equipment is being installed or built. --21:43, 4 May 2011 (UTC)
Yes, citations needed. It is used in my DSL modem that I am using to make this edit, and suspect it is still the most common form of Internet access to residences. But the irony is that it has shifted to the edges of the network, out of the backbone, where it was originally envisioned. See below of course. W Nowicki (talk)
I believe is some strange hybrid such as (IP over) Ethernet over ATM. Rich Farmbrough, 01:14, 26 September 2011 (UTC).

ATM (Another Technical Mistake)[edit]

This is to put some humour into the article. I sometime back remember reading a technical magazine and the author called ATM Another Technical mistake. I found it funny and think it could make the article interesting, at least mentioning that people in the technical industry do refer it by that name

ATM (Asynchronous Transfer Mode) or (Another Technical Mistake) - An attempt by the phone industry to turn your networking problem into something they know how to tariff

See this link [[1]] gathima (talk)

Yes, there needs to a section at the end about where it is now in its life cycle. Needs to be well-cited and neutral of course. The source you point out might be included, although it specifically says "Gigabit ATM" and is 12 years ago. But its main point about how packet sizes should scale up is very relevant. Need to link to subsequent technologies that might have been influenced by ATM, perhaps HIPPI, various switched Ethernets over SONET-like PHYs, certainly Ipsilon Networks and Multiprotocol Label Switching. W Nowicki (talk) 17:07, 6 May 2011 (UTC)

Requested move[edit]

The following discussion is an archived discussion of the proposal. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

No consensus to move. Vegaswikian (talk) 06:26, 24 September 2011 (UTC)

Asynchronous Transfer ModeAsynchronous transfer mode

Per WP:CAPS and WP:TITLE: this is a generic, common term, not a propriety or commercial term, so the article title should be downcased. In addition, WP:MOS says that a compound item should not be upper-cased just because it is abbreviated with caps. Matches the formatting of related article titles. Tony (talk) 04:01, 16 September 2011 (UTC)

  • Oppose. See, Talk:Asynchronous_Transfer_Mode#lowercase_correct, above, for previous full discussion. Further discussion would be a waste of time. In this case you could have read the talk page first. This is a good example of what Kbrose was talking about in your last attempt on Talk:OSI_model. I think that the time has come to acknowledge the fact that you appear to have no understanding of these technical terms, how they are used, and whether or not they are proper nouns. — Dgtsyb (talk) 04:40, 16 September 2011 (UTC)
So now we've flushed out another OWNER, who seems to think rudeness is the way to go. Sorry, it is counterproductive. In case you were wondering, WP's house style is not at all unusual:
I trust you will drop the insults and rudeness. Tony (talk) 06:20, 16 September 2011 (UTC)
WP house style is to capitalize proper nouns, of which Asynchronous Transfer Mode is one. It is interesting to note that your ngrams show it capitalized in 1907! It looks like the tool mistakes '07 for 1907, which would skew the results about 2007. Nevertheless, during the mid-90's when it was being developed, we (telecommunications engineers) talked much of the general aspects of the asynchronous transfer mode before it was specified, standardized, and named the Asynchronous Transfer Mode (we might have named it something else). The earlier usage was widely published in working papers of the ITU (that were made into books) and in patent applications anticipating the standard. But, if you read the previous discussion, above, you would have discovered that. Also, as another editor noted, above, even common usage can be in error, so it is better to look to the context of the usage in the article to determine whether it is a proper noun or not. In this case, as it is used in the article, it is a proper noun: it refers to the name of a specific protocol standard and not a generic class of operation. This was identified by most of the editors in the last discussion. Being a proper noun, it must be capitalized according to WP policy. — Dgtsyb (talk) 08:10, 16 September 2011 (UTC)
Thanks for your post: is it owned by a particular company or individual, and is it used by more than one agent, without license, in telecom services? Proper noun says "A proper noun or proper name is a noun representing a unique entity (such as London, Jupiter, John Hunter, or Toyota), as distinguished from a common noun, which represents a class of entities (or nonunique instance[s] of that class) ...". Tony (talk) 08:32, 16 September 2011 (UTC)
In the article it is used predominantly to refer the specific protocol specified in ITU-T Recommendation I.361 (amoung others), and not the general aspects, class of techniques, nor broad technology. The article is about the specific ITU-T standard and therefore the title is a proper noun. In general, all sequences of descriptive words that are used as proper nouns in technology can be used both as a proper noun and as a general description. From one of your ngram hits: "The asynchronous transfer mode (ATM) protocols are still in the process of being "fleshed out" but are anticipated to be of considerable importance in the future." In the quote it is used as a description of a class of protocols using the asynchronous transfer mode technique (as opposed to the synchronous transfer mode approach that the proposals replaced). However, this WP article talks of the bits (specified in ITU-T Recommendation I.361) in the header, such as the HEC bit-field used for error correction, the cell size, and layout, which are specific to the ITU-T Recommendation I.361 standard adopted by the ITU. As such, the article is about the specific ATM protocol adopted by the ITU-T and does not actually describe any of the competing asynchronous transfer mode proposals that led up to the adoption of this specific standard.
You will find this is true of many descriptive phrases which are also the proper names of specific standards. I can talk of the Broadband Integrated Services Digital Network as specified in the ITU-T Q.2900-Series recommendations, or I can talk of the emergence of broadband integrated services digital network technologies, such as the asynchronous transfer mode technique. I can talk of the need for a high-level data link control procedure, or talk of the High-Level Data Link Control (ISO/IEC Standards 3309:1988 and 4335:1988). In general, many articles on WP refer to the specific standard as a proper noun, and experts in a domain that watch these documents for inaccuracy and vandalism get upset when someone (usually with no domain-specific knowledge) tries to down-case them. There are, however, some articles, like Asynchronous communication which are general and don't describe a specific standard. Knowing which, sometimes requires a technology expert, or at least someone that has often used the name in a sentence. — Dgtsyb (talk) 09:33, 16 September 2011 (UTC)
  • Support – although it usually refers to a specific protocol, there's little evidence in sources that it's a proper name. About half of good sources use it in lower case in sentence context. WP style is to do similarly. The lead says ATM is "a technique"; it it's also the name of a specific protocol, we can mention that, and capitalize when we do if there's evidence that it's a proper name, but the article should be kept more general than that. The ITU doc, ref 1, does not capitalize it. Dicklyon (talk) 16:54, 16 September 2011 (UTC)
  • Oppose although this is borderline. The lead implies the article is talking about the general concepts of modes for transfer that are asynchronous. But the article and almost all uses of the term do refer to a specific standard of the ITU-T. Actually a large family of standards, but they are all unified in the 53-byte cell size for example defined in specific documents for B-ISDN. I just downloaded the I.150 document of ref 1. Although it does not use capitals in the title for some reason, it does consistently capitalize in the text (along with all other nouns defined in it, but that is another point). So I would contrast this with digital subscriber line for example, which is the general concept of frequency modulation in bands above voice on telephone lines. I would call the generic technique "cell switching" and indeed that redirects to Cell relay, a generic article in lower case. Put another way, one could argue that the "transfer mode" of Ethernet is not synchronous, so an article about all "asynchronous transfer modes" (lower case) would have to include all those other protocols as well. The specific protocol layer defined in I.150 deserves its own article, and deserves to be a proper name to denote it is this specific one. W Nowicki (talk) 20:48, 16 September 2011 (UTC)
The only places that doc capitalizes "asynchronous transfer mode" is where it is defining the acronym ATM (which it does in 3 places); I'd go with the title. Dicklyon (talk) 21:39, 16 September 2011 (UTC)
  • Oppose. Although asynchronous transfer mode may refer to a general technique, telecommunication folks (including myself) generally refer to it as a specific protocol using the well-known 53-byte cell sizes that is still widely used as a data transport mechanism in the backbone of traditional telephone providers, and which is also implemented in other networks such as satellite communication systems when intended for telephony. As such, it is a proper noun and by our rules should be capitalized. Nageh (talk) 20:51, 20 September 2011 (UTC)
  • Support This is not a proper name, just a term that is commonly up-cased to match the acronym. The MoS does not support that style. Use lower case. Jojalozzo 02:28, 21 September 2011 (UTC)
And what exactly is your rationale? Are you a telecom engineer? Do you have qualification to state this? Or is it just your opinion that you weigh in? I have provided arguments for why this needs to be upper-cased. Where are your arguments? Sincerely, Nageh (talk) 07:42, 21 September 2011 (UTC)
Why would he need qualifications, or need to be a telecomm engineer, to look at sources and comment on this? As I pointed out above, many sources, including the official ITU doc, capitalize it where they define the acronym, and not otherwise. There's no good reason to treat it as a proper name given such usage. Dicklyon (talk) 09:15, 21 September 2011 (UTC)
(edit conflict, and then the phone range before I posted it) Nageh, perhaps Dicklyon's rationale supports what Joja is saying: "About half of good sources use it in lower case in sentence context. WP style is to do similarly." And Dicklyon, who invented what you're holding now, might have some credentials in the field. Tony (talk) 09:21, 21 September 2011 (UTC)
It actually does not require expertise to determine whether a term has a generic meaning or a specific one. Compare the Internet (the global network of networks, which is based on TCP/IP) with an internet (a network of networks). Or a serial bus with the Universal Serial Bus. It is primarily a matter of grammar. If your argument is that ATM as a trademark would be written in lower-case letters that would be a different argument; but then, it is not a trademark but a specific protocol. I think this makes it quite clear; if not, I don't know what I can do to make it more clear. Nageh (talk) 11:14, 21 September 2011 (UTC)
I agree on Internet and Universal Serial Bus, but not on Asychronous Transfer Mode; not even "the asynchronous transfer mode". My disagreement is based on what I find in sources, not on any particular expertise that I might have. Dicklyon (talk) 11:43, 21 September 2011 (UTC)
We all know the lack of adherence to grammar rules by technical documents – as Tony put it, they tend to upper-case every noun in sight. That this standard document does not follow this practice does not mean it is suddenly right. As I said, it is a matter of grammar: if we've got a proper noun it needs to be upper-cased. In this case, ATM refers to a specific protocol standardized by the ITU, and should be upper-cased. The generic meaning of "asynchronous transfer mode" would mean nothing else but "a mode using packet or cell-switched transmission" (in contrast to traditional (from the perspective of telephone operators) synchronous = connection-based transmission). But the generic meaning is not common at all: people say "packet switching", "cell switching", "packet-based transmission", etc. and not "asynchronous transfer". Nageh (talk) 14:31, 21 September 2011 (UTC)
The above discussion is preserved as an archive of the proposal. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Do not capitalize terms just because they are referred to by acronym[edit]

This article up-cases most every term that has an acronym. This is common practice in technical literature but Wikipedia's MoS does not support it. At the least we should match the case here to the usage in the articles we're linking to, though some of those, e.g. virtual channel identifier and virtual path identifier, are probably up-cased incorrectly themselves. Jojalozzo 20:45, 21 September 2011 (UTC)

Yup, and as I mentioned in the move discussion, if this article is about the specific protocol with 53-byte cells, not about the generic technique, then it needs to be written that way too. But also as above some are tough calls, so we should not spend time on brownian motion fighting over case, but perhaps fill out the article with citations, history of adoption, etc. W Nowicki (talk) 18:31, 24 September 2011 (UTC)

Changes made by - Corrections made to spelling and grammar[edit]

The changes made by at 07:58, 26 September 2011, raise a number of questions. I was, initially, tempted to merely revert, but perhaps that would be a bit precipitous. Some of the changes don't matter to me, so I will not comment on them, but the following ones need some consideration:

The change of the one spelling of "queueing" to "queuing" does beg the question of which is correct in this context, regarding the spelling of queueing theory. However, if "queueing" is right there, then some, many, or all of the "queuing"s in this article need to be changed.

I think that the use of "continued" [source line 122] is wrong; though, otherwise, that edit is not contentious.

I think that "potentially redundant" [source line 147] is, potentially, misleading, though I don't much like "discardable" either. However, the intention is more clear than implying that all cells with the CLP set are "potentially redundant" as opposed to "cells which may be discarded [down stream] in congested conditions" (from Cell Loss Priority) [oh no! another capitalized term].

I like "the provisioner must build" in preference to "provisioned", as it more strongly implies an agent in the creation of PVCs and PVPs.

It appears that does not like "build" and "tear down", presumably as jargon. The question is, should the article be written in the common parlance of the technology, unless it is obviously confusing, which it is not.

The use of "which" [source line 153] as a restrictive/defining relative pronoun is anathema to me, and, in my opinion, it really should be "that" or be preceded by a comma as a descriptive/non-defining relative pronoun [see Fowler's Modern English Usage, 1st ed, THAT, REL, p635]. Whatever the correctness of the original, change for the sake of it seems pointless.

Of the ones I said I wouldn't comment on, it was my understanding that it is policy not to go around changing American spelling to British for the sake of it. [Don't start me off on "ise" vrs "ize" or the use of the serial comma though.]

Anyway, any comments?

Graham Fountain 16:07, 26 September 2011 (UTC)

Be bold. I don't see any problem with your proposed changes. — Dgtsyb (talk) 21:38, 26 September 2011 (UTC)

External links modified[edit]

Hello fellow Wikipedians,

I have just modified one external link on Asynchronous Transfer Mode. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

As of February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete the "External links modified" sections if they want, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{sourcecheck}} (last update: 15 July 2018).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 11:33, 20 October 2016 (UTC)

ATM vs. IP[edit]

Some parts of the article sound like it is a competition between ATM and IP, but it seems to me that it ATM makes sense as a networking protocol, it pretty much has to include (encapsulate) IP. That is related to LAN Emulation, and there is some discussion about that. Gah4 (talk) 17:13, 7 February 2017 (UTC)

In the context of future avionic systems, it was more a battle between ATM and packet switched Ethernet than with IP as such (and happened in the late nineteen nineties and early twenty-hundreds [decade]). There was a diversion for F35 into the avionic variant of Fibre Channel (FCAE) - though that diversion had, I think, more to do with the US MIL-Av industry's NIH syndrome, etc.
The battle between ATM and Ethernet for future avionic systems has also been complicated by AFDX and Time Triggered Ethernet. However, they both really need bespoke network interfaces for even reasonably efficeint operation, which entirely misses the point that standard Ethernet interfaces are cheap and, more importantly, have become virtually ubiquitously integrated into computing equipment – just as it was said ATM's would but didn't. Also even 622 Mbps now looks seriously pedestrian in the context of systems that are expected to transport uncompressed HD imagery at video frame rates. Fortunately IEEE 802.1Q and SDN protocols like OpenFlow (v1.3+) add enough to allow Ethernet to meet the real-time data transport requirements (guaranteed reliable delivery within a deadline, i.e. nothing like what TCP gives), which ATM was almost perfectly designed for. However, Ethernet's data frames are still too big and jumbo frames are, for me, just anathema.
So, in that context, I think ATM is dead, buried, and the grass needs cutting already. That is a shame, because ATM really was the better protocol - arguably the best damned PSN protocol there ever was. But its relationship with Ethernet is clearly another example of the verb 'to betamax'.

Graham.Fountain | Talk 08:34, 26 July 2017 (UTC)

External links modified[edit]

Hello fellow Wikipedians,

I have just modified one external link on Asynchronous Transfer Mode. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

As of February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete the "External links modified" sections if they want, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{sourcecheck}} (last update: 15 July 2018).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 05:48, 26 July 2017 (UTC)

ATM vs Ethernet on the backbone[edit]

"Some consider that this makes a case for replacing ATM with Ethernet in the network backbone."

We took the wrong fork in the road when we gave up on ATM. And statements like this (and another I've seen for MPLS emulating ATM in IP) are just stupid.

ATM is truly elegant. Bits show up on one port and through an associative memory like mechanism are directed to the proper output port without any decision making whatever. The path is laid down end to end through the nodes at connection setup time and then unchanged for the life of the connection. This transit of a node can be done in just one clock cycle ... and conceivably with direct gate logic (using FPGA techniques)zero clock cycles. ATM can make thousands of hops in less than a second. On the other hand, IP requires an enormous amount of time at each hop and thus demands a "backbone"-like architecture to minimize hops ... job security for carriers. If we used ATM the entire backbone could be replaced with an amorphous mesh ... and the internet would be multitudes more responsive.

The vast majority of internet traffic is natively connection oriented. The data goes from one sourcing endpoint to one and only one receiving endpoint ... and those endpoints don't change in the session. ATM is naturally connection oriented. IP, on the other hand is natively broadcast oriented. Without kludgey training wheels, IP has to rediscover the connection with each packet/node transit. That's why MPLS was cobbled together ... to deliver one of those training wheels.

Why in the world did they make the choices they made?

I was there when it was happening and I know ... and it was not technological ... it was greed. A simple refinement of dynamic SVC techniques to replace the PVC provisioning employed by the carriers would have been all it would take.

The IP process has become an enormous kludge as it tries to emulate ATM and deliver security and QoS and speed that ATM delivers perfectly naturally.

It is such a shame.WithGLEE (talk) 16:36, 1 August 2017 (UTC)

But then again – why did all the carriers change over to the Ethernet side? Packet switching simply is more cost effective. What your infrastructure can transport is what you can sell. Elegant (sadly) doesn' win the prize. --Zac67 (talk) 17:04, 1 August 2017 (UTC)
The reason Ethernet betamaxed ATM was primarily because of the cost of interfaces, as they are both PSNs. Why ATM interfaces were inherently more expensive than Ethernet ones is to do with the low level ATM functionality that almost necessarily had to be done in hardware, e.g. traffic shaping after SAR. That's somewhat offset by the need of more memory in the Ethernet switches, but memory is cheap and there will always be far fewer switches than network interfaces. Ethernet interfaces, using much simpler hardware, transpose that hardware cost in to a software cost which hits the system performance not the purchaser's pocket. But as the purchaser only ever found out about the performance hit, if they ever did find out, after they'd bought the system, and by then it was too late to ask for their money back, it was a no brainer for the manufacturer/vendor. And then the economies of scale kicked in. Once that happened, the cost of switches fell dramatically, and Ethernet will never ever have to look back.
That does not change the fact that ATM was (IMNSHO) a much better PSN protocol than Ethernet. But neither does that change the fact that complaining about it will do no good.
As for MPLS, VLANs are better, even though you have to support the Ethernet frames over any other interconnecing physical layer - Ethernet over X - to preserve the IEEE 802.1Q tags. It would be better if the VLAN Id were longer than 12-bits, but Q-in-Q gets round that.
Graham.Fountain | Talk 08:28, 2 August 2017 (UTC)

A Terrible Mistake[edit]

Some call this protocol "A Terrible Mistake". See Emersion (talk) 11:17, 15 December 2017 (UTC)

Well, it is 20 years old (note the comment on the upcoming gigabit ethernet). But otherwise, ATM was designed for telephone companies, not for LAN or WAN use. VoIP isn't quite closing down the telephone companies yet, though. But yes, LANe isn't a good way to run a LAN. Leave ATM to the phone companies. Gah4 (talk) 14:31, 15 December 2017 (UTC)

Requested move 4 June 2018[edit]

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: page moved. -- Ed (Edgar181) 11:51, 11 June 2018 (UTC)

Asynchronous transfer mode (ATM)Asynchronous transfer mode – No need for parenthetical. Why use this strange name? (talk) 03:54, 4 June 2018 (UTC)

I might be for a change, but one should say the change(s) suggested. Also, what is the meaning of the strange red link. Why a link to page moving? Gah4 (talk) 04:47, 4 June 2018 (UTC)
It seems that the suggested new name is why use this strange name?, which I believe is not very descriptive of the page. Also, there should be a why= parameter, explaining the reason for the suggested move, and there isn't one. For those reasons, I vote against the change. Gah4 (talk) 04:52, 4 June 2018 (UTC)
  • Support the proposal as I revised it (it was malformed before, as the above comments point out). Dicklyon (talk) 05:02, 4 June 2018 (UTC)
  • Support as above and the acronym could easily confuse the reader, as normally an ATM is an Automated Teller Machine, so the acronym would confuse a reader if they only read the title (if they then read the lead they could see the context around the acronym).

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.