NDPS and Netware 6 printing issue

Running Netware 6 SP2 in a location of 650 users with NDPS.  Printing stops every day between 7:00 AM and 9:30 PM and 4:00 PM to 5:30 PM.  Novell is engaged but progress is slow.  Anyone seen this?  Server utilization and network appear to be fine.  Do not have anything unusual going on other than login and logouts in those time windows.
Who is Participating?
The reason the ones doing direct-IP printing were "fine" is that they were not using NDPS.  An installation your size should not be doing direct IP printing from the desktop.  That's an unmanageable setup in the most basic definition of the term.  Although those users can print, they are losing the additional benefits of NDPS, and rather than promoting independence, it is promoting anarchy.  My opinion.

The problem is the spinlock issue, from what I read into what you just posted.  Do the SP5 and post-SP patches before anything else, as Novell TS and I agree you should do.

Had I known this was a cluster, I'd have been more insistent on you getting your SP and patches up-to-date, rather than nicely asking you to.    Once you are patched current, you will be in a much better position to determine whether you are overtaxing your cluster by not having enough physical servers in it to handle that volume of printing.  I used to kill twice as many trees as you do, but that was printing from a mainframe to a single, 120-IPM big-honkin' Xerox 9700.  In your situation, the big-iron volume is being distributed among your relatively large user base over IP (whether NDPS or direct) and should be afforded adequate infrastructure to handle it.  

There's no way, given how far behind you are on patches, to tell whether you really do need to throw more hardware at it, but since Novell software is very hardware-thrifty, if Novell TS is saying you should throw hardware at it, it's definitely something to consider.
NetWare v6.0 SP2, or v6.5 SP2 ??

How many printers?

Describe your network infrastructure. Token-Ring? Ethernet? 10Mb/s? 100Mb/s? Shared? Switched?

IPX? IP? Novell Client 32? M$ client for NetWare?
DanUditisAuthor Commented:
Infrastructure is a mix T/R and etherenet.  Server is 100M ethernet.  100 plus printers. Netware 6.0 SP2.  It's all IP.  Combination of NDPS and 'queue' printing.
Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

DanUditisAuthor Commented:
IP printing appears to be fine.  Novell is stating 7000 packets per second and the server is having issues handling the volume.  Server NIC is set for 100 full
*sigh* This is going to take a lot longer the more questions that have to be asked to drag a detailed description of your environment out of you.

1) You said "IP printing appears to be fine." OK, so what is the problem? First you say its slowing down and now you say its fine. I don't understand.

2) Is the slowdown on

    a) T-R
    b) Ethernet
    c) both?

3) How does the server talk to the Ethernet side? Is it directly-connected (with an Ethernet NIC in that broadcast domain inside the server), or does it go thru a router?

4) How does the server talk tot he Token-Ring side? Is it directly-connected (with a T-R NIC in that riung inside the server), or does it go thru a router?

5) Is the Ethernet environment switched or shared?

6) Is the T-R environment flat or switched?

7) Is the T-R environment

    a) 16Mb/s
    b) 4 Mb/s
    c) something else (Specify:               )

8) Are the printers

   a) all Ethernet
   b) all T-R
   c) mix of T-R and Ethernet
DanUditisAuthor Commented:
I understand your confusion as I'm involved only intermittently.  The issue with slowness when it occurs is only when printing via NDPS.  Users that are printing via IP print are fine.   That's 1.

2.  BOth
3. Router
4. Ethernet NIC in the server.  Talks to T/R via a router
5. Switched.
6. No sure
7. 4 M
8. All ethernet.

Late news.  Sniffer traces are indicating that the server is some type of routing even though it's configured not to.  More to come.
Ah. OK.

9) Some some print via NDPS and some via IPP? Is that right?

10) Are any of the NDPS users on IPX?

11) Has the router been eliminated as a source of the slowdown?

Yes, the server can route IP and IPX between the Ethernet and T-R NICs in it. It has to do this if somone on the T-R side is using IP to print directly to a printer on the Ethernet side (well, that assumes the NetWare server is between the router and the rest of the Ethernet - the topology still isn't 100% clear).

To disable IPX routing (if it is enabled), unload IPXRTR.NLM.

To disable TCP/IP routing, load the TCP/IP stack with the "FORWARD=NO" parameter (e.g. "LOAD TCPIP FORWARD=NO") or turn off forwarding in INETCFG (if you use that).
Where are the NDPS printers set up to spool  - SYS: or a data volume?  (Should NOT be SYS:)

Is the volume the NDPS printers are spooling to traditional or NSS?  Is the spool directory set to no salvage?  If NSS, what are the NSS settings (NSS STATUS on console, I believe.)  What are the server settings for the NDPS broker/agent server - specifically, network settings?  Are there other services provided by the NDPS server - file, database, ZEN inventory, etc?  How much physical RAM is in the NDPS server?
Also, is there any chance of getting more reasonably current with the support pack - NW6.0 SP2 is quite old - the current SP is NW6SP5, and there are post SP5 patches besides.  One of the first debugging questions Novell TS always used to ask is "Are you current on your patches?" - and if you weren't they'd say -"Get current, and if it still happens, call us back."   I'm quite surprised that, if Novell is involved in this, they haven't already mentioned your SP level as a possible cause.
DanUditisAuthor Commented:
More data on the config:  There are 16 volumes on the cluster that are configured as vitrual servers each with its own IP address.  That's where the routing confusion entered the picture.  It is not routing however the traces looked like multiple IP address with the same MAC which is actually by design.  Novell is indicating by a core dump that there was an issue with 'Spin Lock'.  Suggestions from Novell include SP5 and post patches as ShineOn suggested and adding two more servers to the cluster isolating NDPS on two of the four nodes.   However, I'm not sure that's the issue.  When the printing issue arose, users that were not printing with NDPS were fine.  Those trying to print via NDPS were locked or waiting.  Printing via pure IP worked without issue.  We're moving more users to IP for now.   We do have a very heavy printing load on this cluster, approx. 1,000,000 pages per month across 74 printers.  Not sure if there is a threshold for NDPS but it has caused enough issues to crash the servers.
ShineOn is right - the fact that this is a Cluster, especially a NetWare v6.0 Cluster,  is of crucial importance to resolving this problem. As he indicated, you should apply the latest SP and patches prior to changing anything else.
Also, I would not recommend Clustering NDPS until you're on Cluster Services v1.7 (NetWare v6.5). You have Cluster Services 1.6 now (altho given how far behind you are on SPs, it might be 1.01).
DanUditisAuthor Commented:
Thanks for the assistance.  Here's where we stand.  

Zen was removed during the printing issue and issue cleared.  It remained clear for two days and then Zen was turned back on.  When Zen began distribution, bang, NDPS printing stopped.  "Experts" are saying we need two more servers in our cluster as the volume is too much for the NIC card to handle.  We are going to upgrade to 6.5 with appropriate patches, add two servers and distribute communications across multiple NICs.  I am concerned we're masking an isse by throughting hardware at it.  Updates will follow as we make the changes.
If they think that the traffic volume is too much for the NIC to handle, why not simply do NIC teaming? Stick a second NIC in the box and have them work together. See http://www.novell.com/documentation/nw6p/index.html?page=/documentation/nw6p/tcpipenu/data/aet7rip.html

This does, of course, assume that you have a switch Ethernet infrastructure that supports Teaming, but most modern ones do.

Anyway, seems that increasing the NetWare server's communications capability is a lot easier/cheaper than throwing a whole box at it.

Also, how is RAM on this server? Is it running low? Have you tried increasing parameters such as MAXIMUM PENDING TCP CONNECTION REQUESTS, MAXIMUM PACKET RECEIVE BUFFERS, and/or MAXIMUM INTERRUPT EVENTS.

Also, it might do to turn on some NCP troubleshooting, using the DISPLAY NCP BAD COMPONENTS WARNINGS and DISPLAY NCP BAD LENGTH WARNINGS in case the router is mangling things.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.