Netware 6.5. NDPS not printing all pages to hp printers. Also, long term cache hits only at 56%

Note that EE has a NetWare-specific TA --> https://www.experts-exchange.com/Networking/Netware/

1) That is a bit low, but there are a number of possible causes beyond the usual prime suspect of insufficient RAM (4 GB is great, but if you're running 50 apps on the box, might still be too little - you haven't specified what you're running on the box). See 3) below.

2) Are you using the HP-supplied NDPS Gateway, or are you using Novell's NDPS Gateway? You should be using the latter. Even HP says so.

3)

a) You have NetWare v6.5 yet you left your SYS: Volume as a Traditional/FAT filesystem? Is there are particular reason why?

b) Note that NSS and Traditional/FAT filesystems use separate Caches. IIRC, in a mixed filesystem environment, the stat you're looking at refers to the Traditional/FAT cache hits, *not* the NSS hits. It sounds like you're followed a good practice of keeping user data off of SYS:, and if that's the case, then the LTCH percentage is not indicative of cache used to meet most user requests.

c) Also, what Support Pack level are you at? Latest is SP4a.

Recommendations: Move SYS: to NSS, make sure you're at least at SP3, if not 4a, and keep an eye out for Post-SP NSS patches. Don't get hung up on the LTCH percentage until you're sure you're looking at the right cache.

1.  I'm only running ndps, imanager, and file and print.  
2.  Yes, I'm using the HP gateway and I saw the tid saying I need to migrate.  However, I moved one over to the Novell gateway and got the same problem of not all pages printing.
3.  I have traditional on sys because it was an upgrade and I added nss volumes.  I'd thought I may have to change the traditional to nss, but I've only read that I would need to backup the server, format it, then create nss for the sys, then restore.  I haven't seen that you can convert it.  Can you?
4.  I'm running the latest Service Pack 5.  4a is old.  

I'm looking at LTCH for the conventional sys volume, is that correct?  I'm looking at nss /cachestats for the nss volume info...

FYI, I couldn't find the netware category under OS to submit the question.

Thank you for your help.  

I forgot to say I do have about 15 apps running, but they are not large.  

What type of print server cards?
If HP,are they flashed to the latest and greatest BIOS?
If you set up straight IP printing from a workstation (bypass NDPS)and print the jobs,do you get complete printouts?
If you log into the printserver (Jetdirect)do you see any errors?

Also ,how much RAM in the printers?

HP jet direct
Yes, I've upgraded the firmware
I haven't done ip direct printing recently, but I've never had a problem in the past.  I'll run a test.
Ram: it happens even on a printer with 16meg.  Have you heard that Netware 6.5 requires more on the printer side?
I'm ordering another 4 gig of ram for a total of 8.  Please let me know how best to utilize the ram over 4 gig with a conventional sys volume with nss volumes.
I'll run some checks for errors on the jet direct cards.

Thank you.  
 

Can you be more specific as to which JetDirect flavor and the exact firmware version?

NetWare is merely a way-station, mediating communications between the client and the printer. The printer takes what it wants from the NetWare server, the server is not force-feeding the printer, so there's no way for NetWare's printing subsystem to overflow the printer's RAM. Also, NetWare's printing sub-system doesn't change the print job itself, merely holds it for a little while, so a print job printed via NetWare's printing subsystem doesn't need more printer resources than any other printing subsystem would need. The printer resources needed for a given print job are dictated by the contents of the job itself.

If you are printing from Windoze workstations, in the printer's Properties page, be sure to select "Print Directly to Printer". There's no reason to have Windoze spool the print job just so NetWare can spool it again, and no sense giving Windoze a chance to mangle things.

If you plan to retain SYS: using the Traditional/FAT filesystem, there are some tweaks you can do. First, make sure any SWAP files do *not* reside on SYS:. Put SWAP on NSS, the performance will be much better. Second, the default NetWare configuration, even as late as NetWare v6.5, tends to favor Traditional/FAT filesystems over NSS on a server that has both. Check out the NSSCACHEBALANCE parameter in the NSS subsystem - you may want to shift the percentage to favor NSS.

Are you using straight NDPS, are are you using NDPS with Legacy Print Queues behind the scenes?

HP 2200, 16meg ram, ndps straight, not using queues, Jet direct internal card - J3110a.  Firmware version: G.08.49.

I bumped the timeout setting way up to 1200 in the hp gateway and it seems to be working unless there are a huge amount of print jobs.  Why would this help?  I tried the NDPS gateway, but I get the same problem.

What about ram over 4 gig on the server?  

Stats on server for memory:
nss /cachestats
*****  Buffer Cache Statistics *****  
Min cache buffers:          512      
Num hash buckets:           524288    
Min OS free cache buffers:  256      
Num cache pages allocated:  186502    
Cache hit percentage:       80%      
Cache hit:                  163695203
Cache miss:                 40792524  
Cache hit percentage(user): 55%      
Cache hit(user):            49746591  
Cache miss(user):           39992910  
Cache hit percentage(sys):  99%      
Cache hit(sys):             113948612
Cache miss(sys):            799614    
Percent of buckets used:    15%      
Max entries in a bucket:    4        
Total entries:              86162    

nss /cachebalance set to 40%

Stats on LTCH, etc for traditional:
Utilization:                              5%
Server up time:                   2:14:36:36
Online processors:                         8
Original cache buffers:              916,353
Total cache buffers:                 465,178
Dirty cache buffers:                       0
Long term cache hits:                    55%
Current disk requests:                     0
Packet receive buffers:                  500
Directory cache buffers:               1,408
Maximum service processes:             1,000
Current service processes:                12
Current MP service processes:            368
Current connections:                     198
Open files:                              529


Thank you.

Well, the stats you gave show a server uptime of only about 2 and a half days. The server needs to have been running for a solid work-week before the stats you provide can be used to determine what you might need to do.

At first blush, these stats catch my attention (remember however that the stats could change significantly with a longer uptime):

NSS

1) The "Min Cache Buffers" are only 512, but the system consumes a lot more. I suspect part of the reason the "Cache Hit Percentage (user)" is at 55% is because it took a lot of cache misses forcing a buffer allocation before the NSS subsystem could really begin to benefit from cache. Try increasing in Min Cache Buffers for NSS to 102400 (NSS will have to be re-initialized for the change to take effect, and the easiest way to do that is down the server and then bring it back up).

2) The "Cache Hit Percentage (sys)" at 99% while the "Cache Hit Percentage (user)" is at 55% is not unreasonable or necessarily a problem. It depends on the nature of the file being served, and the population to which they are served. Printing, in particular, drives down the "(user)" hit percentage.

Traditional/FAT

1) Since your only FAT Volume is SYS:, assuming there's no user data or much in the way of regular file activity beyond logging, the cache hit percentages here don't mean much. If anything, you should probably reduce the amount of cache used by this filesystem type.

Ok.  I'll bump up the min cache buffers.  Thank you.  
However, I still don't know what may be causing the printing problem of not printing all pages.  Therefore, you think it's not related to a memory shortage on the server or configuration?  The server memory seems to be ok, then?  When I bump up the timeout for the hp gateway printers extremely high, 1200, it usually works, but not always.  I tried the novell gateway and got the same problem.  Any ideas?

Thank you for your help.  

I would look for CRC errors on the Jetdirect card .
Because you are running TCP/ IP you need to check duplex settings on the card itself.
If you are running switched ethernet and have your switches set to manual full duplex,the duplex settings on some Jetdirect cards will default back to auto if not configured through the Webadmin utility.
Using the front panel to set duplex will cause the card to default back to auto once in goes into energy save mode.
This is a known bug in the HP firmware and has never gotton fixed.

I think pgm554's ideas are a good place to start. I really don't think the problem you're having is related to the server's RAM. How is the LRU Sitting Time? If its not under 15 minutes, then the server isn't thrashing, and the RAM is adequate.

The more likely culprits are the JetDirect cards themselves (as pgm554 suggested) or the HP Gateway NLM.

I'm testing the Jet direct's now.  However, I never had a problem before I upgraded from Netware 5.1 to Netware 6.5.

NDPS isn't servicing que's is it?
I have had corrupted que's do that.

We have NDPS servicing about 5 queues out of about 80 printers.  No problems with those 5 that I've heard.  Could one messed up queue cause it the printing problems?  

Maybe.
I ran into this many moons ago on a 3.12 server.
I deleted the queues and recreated them and the problems went away.

Let me get this straight,only certain printers are affected with the issue of incomplete printing,not all?

All that try to print multiple page documents.  If it's many documents, it gets worse.  Even our large hp8100 printer with 24meg ram fails with large docs.  

Ok. I'll check that, too.  But again, I didn't have any problems before upgrading from Netware 5.1 to 6.5.  Thank you.  

I have bumped up the timeouts on the hp gateway from 50 to as high as 1200 if needed and everythings seems to be working now.  I will try upgrading the ram as soon as I get a chance to see if that helps.  You can close out this ticket.  Thank you for all your help.