home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / biz / sco / general / 4899 < prev    next >
Encoding:
Internet Message Format  |  1992-12-31  |  2.0 KB
  1. Path: sparky!uunet!olivea!gossip.pyramid.com!decwrl!world!apl
  2. From: apl@world.std.com (Anthony P Lawrence)
  3. Newsgroups: biz.sco.general
  4. Subject: Re: time command
  5. Message-ID: <C04GJt.9KB@world.std.com>
  6. Date: 31 Dec 92 11:43:04 GMT
  7. References: <1992Dec31.043015.28653@netcom.com>
  8. Organization: The World Public Access UNIX, Brookline, MA
  9. Lines: 38
  10. X-Newsreader: Tin 1.1 PL3
  11.  
  12. gerg@netcom.com (Greg Andrews) writes:
  13. : 
  14. : I see it differently.  Running a 386 box from a terminal is a primitive
  15. : form of "client/server" computing.  Running it from the console is not.
  16. : 
  17. : With a terminal, your application simply shoves its output to the
  18. : terminal.  The terminal does the work of placing the character into
  19. : the screen buffer, moving the cursor to the next position (which can
  20. : include wrapping to the first column of the next line), and scrolling
  21. : the screen if you're on the last line.
  22.  
  23. Yes, from the point of view of freeing up the cpu to do other work,
  24. you (and 'time') are quite correct.  That wasn't exactly my point,
  25. though (and as usual I did a lousy job explaining what I was driving at).
  26.  
  27. In the first place, in the context of evaluating a terminal, the job
  28. isn't done until the output is complete.  That's obvious, and it's
  29. also obvious that 'time' can't help us there.
  30.  
  31. But more in line with what I was thinking about is this: Suppose we
  32. have a verrry sloooow disk drive.  Something that takes, oh, 20 seconds
  33. to write a track (I said sloow!).  Now suppose we front-end it with
  34. a very fast 100 megabyte buffer.
  35.  
  36. That buffer is going to make the drive look real good for simple tests
  37. like writing less than 1 track in any 20 second period.  But the
  38. minute you exceed that rate, the performance is gone.
  39.  
  40. So what I was fumbling at last night was the fact that you really
  41. need to be aware of the nature and size of any buffering before
  42. trying to run tests to compare the speed of things.
  43.  
  44.  
  45.         Tony   apl@world.std.com
  46.  
  47. Lawrence & Clark, Inc        (617) 762-0707    (206) 323-2864
  48. Xenix/Unix support,etc           Boston         Seattle
  49.        Kevin Clark is embarrassed by most of what I say.
  50.