home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / biz / sco / general / 4892 < prev    next >
Encoding:
Text File  |  1992-12-30  |  1.3 KB  |  36 lines
  1. Newsgroups: biz.sco.general
  2. Path: sparky!uunet!world!apl
  3. From: apl@world.std.com (Anthony P Lawrence)
  4. Subject: time command
  5. Message-ID: <C03p7q.9v1@world.std.com>
  6. Organization: The World Public Access UNIX, Brookline, MA
  7. X-Newsreader: Tin 1.1 PL3
  8. Date: Thu, 31 Dec 1992 01:52:38 GMT
  9. Lines: 25
  10.  
  11. There has got to be a simple answer for this, but it's got me
  12. stumped.
  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. Now: I had never thought about the effects of buffering on 'time'.  And
  27. I can't honestly say that I've spent a lot of time thinking about it even
  28. now.  But this simple example shows that 'time' measurements can be 
  29. quite false... and makes me wonder about other 'time'd benchmarks...
  30.  
  31.         Tony   apl@world.std.com
  32.  
  33. Lawrence & Clark, Inc        (617) 762-0707    (206) 323-2864
  34. Xenix/Unix support,etc           Boston         Seattle
  35.        Kevin Clark is embarrassed by most of what I say.
  36.