home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / biz / sco / general / 4912 < prev    next >
Encoding:
Internet Message Format  |  1992-12-31  |  3.2 KB
  1. Path: sparky!uunet!shady!kevin
  2. From: kevin@shady.UUCP (Kevin Smith)
  3. Newsgroups: biz.sco.general
  4. Subject: Re: time command
  5. Message-ID: <77@shady.UUCP>
  6. Date: 31 Dec 92 20:54:56 GMT
  7. References: <C03p7q.9v1@world.std.com> <1992Dec31.043015.28653@netcom.com>
  8. Organization: ShadeTree Software, Inc.
  9. Lines: 58
  10.  
  11. In article <1992Dec31.043015.28653@netcom.com> gerg@netcom.com (Greg Andrews) writes:
  12. :>apl@world.std.com (Anthony P Lawrence) writes:
  13. :>>
  14. :>>I'm sitting here playing with a 115K baud terminal. I wanted to
  15. :>>see how it compares to the system console, so I did 'time lr /etc'
  16. :>>on both the console and the terminal.
  17. :>>
  18. :>>The console finishes first, as we would all expect.  But, 'time'
  19. :>>reports LESS real, user and system time for the command run on
  20. :>>the terminal.
  21. :>>
  22. :>>The only rational explanation is that either the multiport card or the
  23. :>>terminal (or both) are doing a lot of buffering so that 'time' thinks
  24. :>>the command is complete when it actually isn't.  
  25. :>>
  26. :>
  27. :>I see it differently.  Running a 386 box from a terminal is a primitive
  28. :>form of "client/server" computing.  Running it from the console is not.
  29. :>
  30. :>With a terminal, your application simply shoves its output to the
  31. :>terminal.  The terminal does the work of placing the character into
  32. :>the screen buffer, moving the cursor to the next position (which can
  33. :>include wrapping to the first column of the next line), and scrolling
  34. :>the screen if you're on the last line.
  35. :>
  36. :>When you're on the console, the computer must handle your command *and*
  37. :>perform all the character and cursor manipulations for the screen.  Thus,
  38. :>the work that normally would be off-loaded to the terminal is seen by the
  39. :>cpu and it leaves that much less available to the rest of the system.
  40. :>
  41. :>-- 
  42.  
  43. As I see it, real time is real time.  Since the real time to the
  44. terminal was shorter than the console or the "observed" time the only
  45. answer is buffering in the serial controller or driver or the
  46. terminal.  The user and system times reflect how much effort the cpu
  47. put into the io.  Interrupt driven dumb serial controllers can kill a
  48. cpu at 9600 baud.  Intellegent controllers can impose a wide range of
  49. loads depending just about everything.  A recent issue of SCO magazine
  50. had a multiport serial controller review that addressed actual CPU
  51. loads from different boards.  Also keep in mind that sending data out
  52. a port is always easier that receiving.  The computational load of
  53. managing the console screen is probably pretty small.
  54.  
  55. You should put a stop watch on it and figure the actual transfer rate
  56. to the screen.  Furthermore you should cat a large file rather than
  57. 'lr' since listing files involves far more cpu and disk processing.
  58. FurtherFurthermore a lot of terminals cannot actually handle continous
  59. input at their rated speed and will revert to some form of handshaking
  60. to moderate their input.  I like to create a huge file of lines of 79
  61. '#'s.  Disable any terminal handshaking and let it fly.  Watch the
  62. output for ragged right margins that indicate data loss.  This is
  63. also good for testing printers.
  64. -- 
  65.         | Email - !shady!kevin uunet!shady!kevin kevin%shady@uunet.uu.net
  66. Kevin Smith | Voice - (+1) (908) 874-7980
  67.         | Mail  - ShadeTree Software, Inc., 192 Capricorn Dr. #10,
  68.         |         Somerville, NJ  08876, USA
  69.