home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / dcom / modems / 11342 < prev    next >
Encoding:
Internet Message Format  |  1992-07-28  |  6.5 KB
  1. Path: sparky!uunet!cs.utexas.edu!sun-barr!news2me.ebay.sun.com!exodus.Eng.Sun.COM!appserv.Eng.Sun.COM!oobleck!bender
  2. From: bender@oobleck (Duke of Canterbury)
  3. Newsgroups: comp.dcom.modems
  4. Subject: Re: Serial and Parallel interface ??????
  5. Date: 29 Jul 1992 02:19:15 GMT
  6. Organization: SPARK's R US
  7. Lines: 108
  8. Message-ID: <l7c013INNlh@appserv.Eng.Sun.COM>
  9. References: <1992Jul24.184318.18883@cc.ic.ac.uk>
  10. Reply-To: bender@oobleck.eng.sun.com
  11. NNTP-Posting-Host: oobleck
  12. X-Newsreader: Tin 1.1 PL3
  13.  
  14. vulture@carrion.cc.ic.ac.uk (Thomas Sippel - Dau) writes:
  15. : Intuitively I always knew that the 80xxx series of processors was a bad 
  16. : product, now you give me another nail for the coffin. I can still remeber
  17. : reading in L.A. Leventhal on the 6502 how to write a serial driver that uses
  18. : the V register to shift the bit in from the serial line, no need to pay
  19. : for those expensiv uarts ...
  20.  
  21. What are you talking about?  I'm glad that you have a book written in 1978
  22. that shows you how to make a 300-baud software UART, but the issue at hand
  23. seems to be your claim (that I don't dispute) that your 1981 8088 system can
  24. transfer 256K+bps from your floppy disk drive, while your serial port craps
  25. out at 9600 baud.
  26.  
  27. : Yes, I know, you can only do so much with a processor at a given speed, and 
  28. : when there are 11500 interrupts per second to serve, most will grind to a
  29. : halt. "Modern" "Risc" chips are rather more affected by this if they use a
  30. : stupid "save all registers just in case" interrupt handler, since they have
  31. : so many registers.
  32.  
  33. I suppose that you've worked with many "Modern" "Risc" chips and have written
  34. interrupt handlers for them and determined what interrupt load they can
  35. sustain before they grind to a halt?
  36.  
  37. : But even when the throughput is limited, there is no excuse for dropping 
  38. : bytes as long as the processor has ways to control the total throughput.
  39.  
  40. But if the CPU is so swamped with interrupts, who is going to do the
  41. hardware and/or software flow control?  Transmit (i.e. outgoing) flow control
  42. is easy - the remote device sends an XOFF or drops CTS, and your hardware
  43. can stop sending, with no intervention from the CPU, but implementing receive
  44. flow control in hardware gets a little tricky; when does your hardware tell
  45. the remote device (a modem in this case) to stop transmitting?  When your
  46. UART's FIFO is 1/2 full? Completely full?  Don't forget that many devices
  47. such as modems that support RTS/CTS flow control will still transmit several
  48. bytes AFTER your receiver's RTS line has dropped, so your receiver better be
  49. able to receive several bytes AFTER you drop RTS.
  50.  
  51. : On the mint condition 1981 PC with an 8088 this may mean doing either a
  52. : (floppy-) disk or a serial port transfer, and in particular telling the modem
  53. : to shut up for some time. This does not help nominal throughput, it cannot
  54. : do, as the CPU on the receiving end is the bottleneck.
  55.  
  56. You don't seem to understand that there are two different mechanisims at work
  57. here - your 1981 vintage PC uses DMA to transfer data from the floppy
  58. controller, which, BTW, has already done the clock recovery and
  59. de-serialized the data stream off of the disk and presents it as 8-bit
  60. parallel quantities.  DMA requires no CPU intervention once the transfer
  61. parameters are set up and the DMA controller is triggered by an external
  62. event, in this case, the floppy controller telling the DMA controller that
  63. the former has a byte that it wants the latter to transfer into memory.  The
  64. DMA controller grabs the system bus, transfers the byte from the floppy
  65. controller to memory, and waits for the next byte to become available.  In
  66. the meantime, the CPU can get back on the bus if it needs to.
  67.  
  68. Serial port transfers on the IBM-developed PC architecture on the other hand
  69. are programmed I/O operations - the UART generates an interupt when some
  70. conditions are met (i.e. one or more bytes in receive FIFO, transmit FIFO
  71. empty, modem control signal change, etc...), and the CPU has to go service
  72. that interrupt, which usually means doing some stack manipulation, diddling
  73. with the UART to find the source of the interrupt, getting the data (if it's
  74. an Rx interrupt), stashing the data away, and telling the chip that you're
  75. done handling the interrupt.  This requires a lot of CPU cycles. As was
  76. mentioned in another post, some PC applications continuously poll the UART
  77. to get around the overhead of the interrupt handler and increase the
  78. throughput, but the CPU must be involved much more intimately with the UART
  79. than with the floppy controller duren the course of a normal data-transfer
  80. operation.
  81.  
  82. : However, not obeying flow control will be more expensive, because files or 
  83. : packets have to be retransmitted. We did exactly that here to get early 
  84. : Kermits in binary form: read from the serial port, write to disk, if bytes 
  85. : are lost ask for retransmission. Wasteful, but its get you going.
  86.  
  87. Well, that's true IF you're using some sort of packetizing protocol, but
  88. standard serial data transfer doesn't use anything other than a
  89. user-selectable bit protocol (i.e. 5,6,7 or 8 bits/char :-), with NO
  90. provisions for retransmission of corrupted data.  On a serial port, if you
  91. loose incoming data, and there's no retransmission protocol, it's gone down
  92. the shitter for good.  On a floppy drive, the data is still there and can be
  93. read the next time the sector passes under the head.
  94.  
  95. : But the point is that NO manufacturer I know of has sold machines that 
  96. : dropped bytes in transfers to and from floppy disks, I someone did they 
  97. : certainly did not sell many of those.
  98.  
  99. How do you know this?  Maybe the OS retired the disk read, or maybe the
  100. floppy controller had enough buffering for a sector's worth of data so that
  101. if the DMA controller didn't get around in time to service the floppy
  102. controller, no data would be lost?  There are a lot of disk retries going on
  103. underneath the works that never get reported to the user.  Data loss on a
  104. serial port, however, is must more noticable.
  105.  
  106. : Serial (or parallel) ports should 
  107. : have the same reliablility, and manufacturers should give people *exact*
  108. : ideas what their machines can and cannot do. There is only one way to 
  109. : achieve this: keep pestering them about it.
  110.  
  111. That's because disk drives have traditionally required "high" data transfer
  112. rates, and serial ports were content to plod along at 300-baud FSK dial-up
  113. acoustic-coupled modem speeds until relatively recently.
  114.  
  115. mike
  116.  
  117. --
  118. The IQ requirement for being a phone operator may be pretty low, but the
  119. required IQ for placing a call is just about vegetable level.  That's why
  120. they kill sardines before canning them; if you let them swim around in the
  121. can, it would heat up and explode.
  122.