home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / 3b1 / 3830 < prev    next >
Encoding:
Text File  |  1992-11-15  |  2.5 KB  |  58 lines
  1. Newsgroups: comp.sys.3b1
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!rpi!psinntp!psinntp!monymsys!sonyd1.Broadcast.Sony.COM!hico2!kak
  3. From: kak@hico2.westmark.com (Kris A. Kugel)
  4. Subject: Disableing the phone to gain speed (was: Re: 3b1 Magic POKE?)
  5. Message-ID: <Bxrr1w.BM8@hico2.westmark.com>
  6. Summary: Do we have to wait for the source?
  7. Keywords: phone device driver 3B1 unixpc att7300 on-board modem
  8. Reply-To: kak@hico2.westmark.com
  9. Organization: High Country Software
  10. X-Newsreader: Tin 1.1 PL5
  11. References: <1992Oct16.221844.14874@cbnewsc.cb.att.com>
  12. Distribution: usa
  13. Date: Sun, 15 Nov 1992 17:53:54 GMT
  14. Lines: 42
  15.  
  16. Craig M. Votava (cmv@looney.att.com) wrote:
  17. : |>         My motivation for asking this is to inquire whether you 
  18. : |> have found any "magic pokes" that can enhance the present system in 
  19. : |> the tradition of the "serial.pat" adb script.  As I recall you 
  20. : |> folks mentioned that the 3b1 polled the status of the /dev/ph 
  21. : |> devices every clock tick (60Hz on the 3b1), and you theorized that 
  22. : |> a gain could be gotten by disabling this polling.
  23. : 
  24. : Yes, in fact one of the guys who was on customer support for the unix-pc
  25. : kernel told me that a total rewrite of the phone polling code to make it
  26. : interrupt driven would save quite a bit of processing time.
  27.  
  28. If we could get good speedups if the phone code was
  29. that interrupt-driven rather than polled, shouldn't
  30. we be able to do something even before the source code
  31. becomes available?  (which, after all, may be never)
  32.  
  33. What I THINK the questioner was asking, (and what I'd
  34. be interested in hearing) was if a kernel patch could
  35. be developed that would disable the phone handling altogether.
  36.  
  37. Personally, having invested in a worldblazer, I'd rather
  38. my worldblazer be able to process at 1600cps, rather
  39. than have a second phone available at 120cps.  Given that
  40. tradeoff, I'd just as soon disable anything having to do
  41. with that on-board modem, or at least prior to a new kernel
  42. with a less-costly modem processing scheme.
  43. And I'd guess the phone polling slows EVERYTHING down,
  44. not just the serial port.
  45.  
  46. It seems to me like a patch to replace the (hypothical)
  47. call to the phone-status checking routine with a no-op
  48. would do the trick.  At least it SOUNDS easy.
  49.  
  50. So let me add some additional encouragement for somebody (Craig?)
  51. to look into this.  The first step would be to see what the entry
  52. points into the phone polling code are, and if they are separate
  53. enough to disable easily.  I'd bet on some (a) easily disabled
  54. subroutine call(s).
  55.  
  56. Kris A. Kugel    908-842-2707
  57. hico2!kak    kak@hico2.westmark.com
  58.