home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / pen / 541 < prev    next >
Encoding:
Internet Message Format  |  1992-08-28  |  1.9 KB
  1. Path: sparky!uunet!cis.ohio-state.edu!rutgers!att!ucbvax!VNET.IBM.COM!lybrand
  2. From: lybrand@VNET.IBM.COM (David Lybrand)
  3. Newsgroups: comp.sys.pen
  4. Subject: PenPoint slow to wake on NCR 3125 ?
  5. Message-ID: <9208281143.AA00565@ucbvax.Berkeley.EDU>
  6. Date: 28 Aug 92 11:33:57 GMT
  7. References: <1992Aug27.212924.20842@morrow.stanford.edu>
  8. Sender: daemon@ucbvax.BERKELEY.EDU
  9. Organization: IBM Corp, Boca Raton, FL
  10. Lines: 31
  11.  
  12. In <1992Aug27.212924.20842@morrow.stanford.edu> Richard Acuff writes:
  13. >
  14. >1. Why does PenPoint take an extra 7 seconds to wake up over DOS?
  15. >
  16. >2. What does PenPoint need to do that takes 11.7 seconds and lots of
  17. >   disk rattling when standing by?
  18. >
  19. >3. Why does the disk have to spin at all for wake-up?
  20. >
  21. PenPoint takes great pains to protect the user from data loss while in
  22. standby, since the user may very well walk away from the machine while
  23. it's in that mode.  Thus it flushes all file-system buffers before entering
  24. standby.  If the disk had spun-down before the attempt to go to standby,
  25. there would be time spent spinning it up before the buffers can be flushed.
  26. I still think the time is a bit longer than you'd expect, and I think that
  27. GO will be investigating these performance concerns SOMEday...
  28.  
  29. The disk spin-up on wake-up is really a function of the MIL.  Probably
  30. that the NCR MIL is automatically doing a spin-up on the resume call
  31. to the disk device.  In all fairness, it's hard for the MIL to decide WHEN
  32. it should spin-up the disk, since the disk had been spun up at suspend
  33. time (going into standby).  Thus it's probably returning it to the same
  34. state it was in prior to the suspend.
  35.  
  36. But it's possible that PenPoint is refreshing it's filesystem buffers
  37. at that time, so this is probably another "safety feature" resulting from
  38. the previous flushing of the buffers.
  39.   DPL
  40. Additionally, PenPoint repaints the screen on resume, which takes a bit
  41. longer than a DOS resume which "assumes" that the VGA memory is intact.
  42.   DPL
  43.