home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / dcom / modems / 10899 < prev    next >
Encoding:
Internet Message Format  |  1992-07-21  |  2.5 KB
  1. Xref: sparky comp.dcom.modems:10899 comp.sys.ibm.pc.hardware:20048
  2. Path: sparky!uunet!uunet.ca!xenitec!zswamp!geoff
  3. From: geoff@zswamp.UUCP (Geoffrey Welsh)
  4. Newsgroups: comp.dcom.modems,comp.sys.ibm.pc.hardware
  5. Subject: Re: Help on upgrade to 16550A UART
  6. Message-ID: <XgmaoB5w164w@zswamp.UUCP>
  7. Date: Tue, 21 Jul 92 23:06:08 EDT
  8. References: <1992Jul19.112553@mycro.UUCP>
  9. Organization: Izot's Swamp
  10. Lines: 41
  11.  
  12. scott@mycro.UUCP (Scott C. Sadow) writes:
  13.  
  14. >    There is only 1 reason to replace a 8250/16450 with a 16550A -
  15. > interrupt latency.
  16.  
  17.    I'm usually the first to say something like that, but there is one more 
  18. advantage (however slight): you can set the receive interrupt to trigger at 
  19. certain FIFO buffer fill levels, allowing a single interrupt to read up to 16 
  20. bytes and in stead of one interrupt per byte, lowering the CPU overhead of 
  21. going into and out of interrupt service code.  Similarly, you can write 16 
  22. bytes on a transmit hold buffer empty interrupt in stead of just one, with 
  23. similar gains.  So, the per byte average CPU overhead is lowered... on 
  24. multitasking systems you can sometimes feel the difference while high-speed 
  25. transfers are underway and, on single-task systems, you can sometimes measure 
  26. small increases in performance, not to mention that the CPU has more time to 
  27. write incoming data to the screen while it's still pouring in the port, giving 
  28. another small but perhaps measurable increase in the speed of applications.
  29.  
  30. >    My experience has been that a 12 Mhz 80286 is just barely fast enough
  31. > to be able to receive characters at 115,200 baud. At this baud rate, the
  32. > PC is handling roughly 11,520 interrupts/second, so the interrupt handler
  33. > has to be very small and tight.
  34.  
  35.    Utilities like LapLink, FastLynx, etc. use polled, not interrupt-driven, 
  36. mode to do 115 kbps.  Of course, you can only get away with this on single-
  37. task systems. 
  38.  
  39. > Also, any program that switches the 80386/80486 into protected mode and/or 
  40. > virtual 8086 mode will increase the interrupt latency (EMM386 does this)
  41.  
  42.    That's not half as bad as an AT-compatible 286 switching from protected to 
  43. real mode (i.e., after an extended memory access under DOS); the CPU is 
  44. actually reset, and that doesn't happen in a single clock cycle. <grin>
  45.  
  46. >    Should you replace you current UART with a 16550A? I would only do so
  47. > if you are seeing problems like reduced throughput and/or high error rates.
  48.  
  49.    I'm with you 100% on that!
  50.  
  51. Geoffrey Welsh, 7 Strath Humber Court, Islington, Ontario, M9A 4C8 Canada
  52. geoff@zswamp.uucp, [xenitec.on.ca|m2xenix.psg.com]!zswamp!geoff (416)258-8467
  53.