Talk:Channel I/O

From Wikipedia, the free encyclopedia
Jump to: navigation, search
          This article is of interest to the following WikiProjects:
WikiProject Computing  
WikiProject icon This 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.
 ???  This article has not yet received a rating on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
 
WikiProject Computer science  
WikiProject icon This article is within the scope of WikiProject Computer science, a collaborative effort to improve the coverage of Computer science related articles 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.
 ???  This article has not yet received a rating on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
 

Diagram of Basic Principles Section[edit]

A diagram could help clarify and remove ambiguity. I feel unclear about what components there are, and the relationship between them, or the physical connections between them. Rsamot (talk) 03:21, 12 June 2012 (UTC)

First channel[edit]

The first channel is usually considered to be the IBM 709's model 766 data synchronizer, shipped in about 1957. The 7090, announced in 1958 and shipped in 1969 supported the 766 and also the more advanced 7607 channel and 7606 multiplexor. These both significantly predate the 6600 which didn't ship until 1964. See http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP7090B.html John L 20:36, 16 September 2007 (UTC)

Odd question[edit]

I encountered an odd question embedded in a comment within the article that would have been better put on the talk page. The comment read:

huh|date=April 2008 … it doesn't use main memory? why?

Independent processors and coprocessors can't use main memory as scratchpad because it would interfere with the operation of programs already in main memory. They have to have independent counters and memory for addressing that doesn't conflict with the main unit.

However, DMA controllers will read the desired data directly into main memory or write the indicated data directly from main memory.

Does that clarify?

regards, --UnicornTapestry (talk) 02:28, 7 January 2009 (UTC)

It was my question. The article states that all I/O channels have their own memory ("on-board", whatever it supposed to mean, for me implies it's a private memory). All of them, not some of them. Pretty strong assertion and it seems very doubtful. All coprocessors (and especially I/O channels) could easily use areas of main memory for all their needs, on the condition that OS manages the memory properly. Coprocessor does not need to rewrite all the main memory, ever, if that's what you mean by "scratchpad". Since I don't want to introduce WP:OR, I left the mark in the article. I kindly ask to remove that mark only after the thing is either (1) explained or (2) corrected. --Kubanczyk (talk) 11:26, 8 January 2009 (UTC)
I see. The original author used coprocessor as an analogy, although in my opinion that was an inadequate explanatory shortcut and subprocessor is a more accurate term. That could be better written. IBM often referenced the term 'subprocessor' and CDC used both that term and a more inclusive term, 'peripheral processor'.
"Scratchpad memory" is working storage, and your use of 'private memory' is accurate in that it's separate from main memory. In channel design, it's not easy or appropriate to share main memory, especially as only a few bytes are involved.
To clarify, channels have access to main memory, but they don't use main memory, if you follow me. It's easier and more robust to separate. Indeed, trying to carve a chunk of working storage out of main memory could invoke numerous design problems. (We're not including mention of the CAW and CSW here.)
"Onboard", as used in the article, means that memory is packaged with the subprocessor. Usually, you see 'onboard' used when memory is included as part of a chip, but the author didn't mean that narrowly.
Introducing cite and WP:OR aren't appropriate here. The engineering involved is reasonably consistent and well understood (although not explained in detail). The original author does imply channels contain their own memory (as needed), and I have to agree in that I'm unaware of channel designs that utilize main memory rather than internal storage. (We're not discussing early personal computer designs that set aside part of main memory for video– that's entirely different.)
I'll be glad to answer further questions if I can.
--UnicornTapestry (talk) 12:41, 8 January 2009 (UTC)
Thanks for explanations. Could you enrich this article with one sentence explaining the fact that channel processor needs working ("scratchpad") memory, and the reason it is easier to implement scratchpad outside of main memory? I'm unable to do it. --Kubanczyk (talk) 21:29, 12 January 2009 (UTC)
Hi. I took run at it. Let me know what you think.
I recently came across a PDF of architecture by Gene Amdahl and Fred Brooks that discussed channel design. It was a part of a larger article, but I found it interesting they underlined the architectural independence of the channels.
best regards, --UnicornTapestry (talk) 07:42, 14 January 2009 (UTC)
It's perfect. Thanks. --Kubanczyk (talk) 22:20, 14 January 2009 (UTC)

Too IBM Specific?[edit]

IMO Sections 4 thru 6 of this article has recently become too specific to IBM Channels as opposed to I/O Channels in general, e.g. recent edits by User:Peterh5322. Perhaps the simple thing to do is make these three current sections into subsections of one new Section "4. IBM Channel I/O as an example". Tom94022 (talk) 18:25, 23 December 2014 (UTC)