home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / linux / 22553 < prev    next >
Encoding:
Internet Message Format  |  1993-01-03  |  1.8 KB
  1. Path: sparky!uunet!stanford.edu!rutgers!igor.rutgers.edu!geneva.rutgers.edu!hedrick
  2. From: hedrick@geneva.rutgers.edu (Charles Hedrick)
  3. Newsgroups: comp.os.linux
  4. Subject: Re: real time
  5. Message-ID: <Jan.3.14.03.48.1993.27545@geneva.rutgers.edu>
  6. Date: 3 Jan 93 19:03:48 GMT
  7. References: <1993Jan3.054159.11008@umr.edu>
  8. Organization: Rutgers Univ., New Brunswick, N.J.
  9. Lines: 26
  10.  
  11. quandt@cs.umr.edu (Brian Quandt) writes:
  12.  
  13. >What can anyone say about linux and real time support?  Same
  14. >question applies to 386bsd.  I tend to believe that this concept
  15. >would not be possible.  The reason being is that this (I believe)
  16. >is a fundamental design change in how the kernal works.  However,
  17. >if anyone has information to the contrary please let me know.
  18.  
  19. It depends upon what level of real time you want.  Linux isn't
  20. designed to do real-time, so if you need specific facilities (e.g.  a
  21. scheduler that tries to guarantee latencies) you'll be in trouble.
  22. However some applications probably don't require that.
  23.  
  24. As you probably know, depending upon your application, real time can
  25. involve latencies anywhere between 1 usec and 1 msec.  Linux has good
  26. enough interrupt latency to handle fairly high speed serial I/O.  I
  27. could do 9600 bps reliably on a 386sx under 0.12.  I can do at least
  28. 19200 on a 486 now.  This is with chips that require an interrupt for
  29. each character.  So you should be able to get latencies from several
  30. hundred usec to 1 msec.  I don't think you could do much better than
  31. this.  The limit used to be the hard disk, though I think Linus has
  32. been working on that.  If you configured a system with a RAM disk and
  33. ran entirely from there, maybe you could do a little better.
  34.  
  35. I'm assuming that the code for which latency is critical would be
  36. linked into the kernel, presumably as a device driver.
  37.