home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / novell / 10910 < prev    next >
Encoding:
Internet Message Format  |  1992-12-29  |  3.7 KB
  1. Path: sparky!uunet!crdgw1!newsun!dseeman
  2. From: dseeman@novell.com (Daniel Seeman)
  3. Newsgroups: comp.sys.novell
  4. Subject: Re: Mac freezeups while on Novell server
  5. Message-ID: <1992Dec29.173358.23808@novell.com>
  6. Date: 29 Dec 92 17:33:58 GMT
  7. References: <1992Dec29.161544.25890@elroy.jpl.nasa.gov>
  8. Sender: news@novell.com (The Netnews Manager)
  9. Organization: Novell Inc., San Jose, Califonia
  10. Lines: 79
  11. Nntp-Posting-Host: db.sjf.novell.com
  12.  
  13. In article <1992Dec29.161544.25890@elroy.jpl.nasa.gov> fod@elroy.jpl.nasa.gov (Frank O'Donnell) writes:
  14. >We have a group of Macs in another building at our site
  15. >that log on daily to our office's Novell server.  The
  16. >Macs are in another Appletalk zone and on a different
  17. >subnet on the other side of a couple of routers on our
  18. >site-wide network.
  19. >
  20. >At first things seemed to be running pretty well, but
  21. >during the last few weeks the Mac users have reported
  22. >serious problems with slowdowns and cursor freezing.
  23. >Typically what happens is they will be typing in Word or
  24. >QuarkXPress and the cursor will freeze for 5 to 15
  25. >seconds.  Eventually it comes back, but sometimes some
  26. >of the text is lost, particularly if the user was a
  27. >fast typist.  This has been happening lately once every
  28. >minute or so, so the problem is more than a minor
  29. >annoyance to the users.  Occasionally there are other
  30. >problems, such as mysteriously being logged off the
  31. >server.
  32. >
  33. >We ran a few tests to try to isolate the problem --
  34. >removing cc:Mail's ccNotify init, for example.
  35. >We finally determined that the problem appeared when
  36. >the user was logged into our Novell server.  If they
  37. >dragged the server volume into the trash, the problem
  38. >disappeared.
  39. >
  40. >I gather from reading other messages here that the
  41. >answer might be "You have too much traffic on your WAN."
  42. >However, I'm still trying to determine what can be done
  43. >about it.
  44. >
  45. >For the time being users have adopted the workaround of
  46. >only logging on when they need to, but since these
  47. >folks are heavy server users this means logging on and
  48. >off perhaps 20+ times a day.  Would establishing some
  49. >kind of tunneling to route traffic probably help?  Is
  50. >this an inevitability of the way Macs talk to servers,
  51. >or is there hope in sight for a less delicate protocol
  52. >in the future?
  53. >
  54. >Thanks for any suggestions,
  55. >
  56. >Frank
  57. >frank@jplpost.jpl.nasa.gov
  58.  
  59. Hi,
  60.  
  61. If this performance problem is getting steadily worse and you are not adding
  62. steadily more traffic to your WAN, then I would say traffic is not the problem.
  63. Two possibilities come to mind immediately.
  64.  
  65. First, you may have an intermittent problem on the LAN NIC that supports your
  66. Macintosh clients.  Now, since IPX is quite a bit less "chatty" on the net, DOS
  67. workstations would not necessarily be so sensative to a poorly functioning LAN
  68. NIC.  So, you might try swapping LAN NICs in the server to see if that takes 
  69. care of the problem.
  70.  
  71. NetWare for Macintos v3.0 was shipped with a NOTIFY init (v2.1---I think) and 
  72. this utility was associated with very poor performance on the Macintosh when
  73. logged into the NetWare server.  If NOTIFY is installed on the Macintosh, try
  74. removing it to see if your performance gets better.  If it does, you need to 
  75. upgrade NOTIFY to v2.11.  This version is available on NETWIRE under NOVLIB8.
  76. I believe the file name is something like NOTIFY.SIT.  Just to be safe, download
  77. this "Stuffed" file to your Macintosh and UNSTUFFIT there.
  78.  
  79. Let me know if neither of these suggestions provide you with a solution, and I 
  80. will think of something else.  In this event, it would help to have a complete
  81. network map.
  82.  
  83. Think Peace...
  84.  
  85. Dan Seeman
  86. Novell
  87. Walnut Creek,Ca.
  88.  
  89. ps.  Let us not consider some of the more detailed solutions like IP tunneling
  90. for now as I do not think your transport protocol is the problem source at this
  91. point.
  92.