VERY Slow data transfer from Novell Server yet Windows Server is fast on same connection!

What is the exact version/sp of the NetWare server?  What is the exact version/sp of the Novell client32?  Was the client installed Custom, selecting only the additional services that you have installed, especially deselecting the NMAS client?  Is File Caching off and File Commit on, in the client properties Advanced tab?  Is the UNC filter on in the client properties Advanced tab?  Is the move being done using mapped drives or UNC?  What is the directory path depth of this folder?  Is compression on, on the NetWare volume?  What are the NetWare CPU usage and disk access stats looking like? (monitor.nlm)

Dumb question - why move the folder through a client PC if the Win2K server has the NetWare client?

There are many causes for slow access to a NetWare (Novell is the company that produces NetWare) server.  Most of them are Windows-specific.  I have covered most of the NetWare-specific ones in the first set of questions.  Depending on the answers to those, I might have a set of questions regarding your XP PC and what services might be running or settings set.

A side question - why move files to (old) Windows from (older) NetWare anyway?  Win2K isn't a whole lot better than WinNT4 as a file server platform, and Win2K3 is only incrementally better than Win2K server.  If you want the best file serving security and performance, along with the best license model, modern NetWare is the best choice, hands down.

You may think otherwise for some reason, but moving from NetWare 5 to Win2K Server isn't an upgrade.  An upgrade would be moving from NetWare 5 to NetWare 6.5/OES.  Plus, doing the move the way you're doing it loses all of your filesystem security settings (trustee rights, ownership, extended attributes) for the data being moved.

To your question - first half, what's going on depends so much on the specifics of your environment it's impossible to answer without asking a whole lot of questions back.  I suspect it might be a combination of file compression on the NetWare server and WinXP-specific issues.

Second half of the question:  first tool should be MONITOR.NLM.  Looking at the "general information" screen, you'll see things like utilization, original cache buffers, total cache buffers, dirty cache buffers, long term cache hits, current disk requests,  packet receive buffers, directory cache buffers, etc.  

The ones to look at first are utilization (is it high - over 90%, pretty busy - 40-90%, moderately busy - 20-40%, low - 0-20%, changing a lot, pretty steady?)  dirty cache buffers (is it getting above the single-digit range?) current disk requests (what does the activity look like?).  What are the values for the other entries?

Next, select the Connections menu option, and look for your connection.  It will have your login name, without an asterisk.  Select it, and see what kind of activity statistics you're getting.

Hello ShineOn... I think you might have misunderstood my question. The problem is strictly on the Win XP workstation and its connection to the Novell Server. Monitor.nlm is always running on my Novell server as default and it doesn't reveal anything about individual workstations that would clue me into the real problem.

This problem is only occurring on this one workstation. It would be much easier to solve if it were slow for all networking but in this case, it is just very slow with the Netware connection. I am now on day 3.5 of this 2Gb folder move!


I shall answer your questions but keep in mind that this is only a problem on this one workstation.

>What is the exact version/sp of the NetWare server?
 6a (OS5PT2a)

> What is the exact version/sp of the Novell client32?
4.90 SP2  (2.20040617)

>Was the client installed Custom, selecting only the additional services that you have installed, especially deselecting the NMAS client?
No NMAS of course.

> Is File Caching off and File Commit on, in the client properties Advanced tab?  
Confirmed!

>Is the UNC filter on in the client properties Advanced tab?
It is ON

> Is the move being done using mapped drives or UNC?  
Both are UNC.

>What is the directory path depth of this folder?  
Nothing unusual. At its max... probably about 75 chars. deep

>Is compression on, on the NetWare volume?  
Yes. Although I should turn that off.  

>What are the NetWare CPU usage and disk access stats looking like? (monitor.nlm)
Nominal. Never greater than 35%.

>Dumb question - why move the folder through a client PC if the Win2K server has the NetWare client?
I know it would be faster to move the folder directly. I could not have done it that way because the W2K server does not have permissions to that Netware folder.

> A side question - why move files to (old) Windows from (older) NetWare anyway?
Easy... the volume space on the W2K server is cheaper! I needed to free up space on the Netware server because this is the "workhorse" of the company. The W2K server now hosts all the archives (little used files).  

You assumed too much. :-)

>The ones to look at first are utilization (is it high - over 90%, pretty busy - 40-90%, moderately busy - 20-40%, low - 0-20%, changing a lot, pretty steady?)  >dirty cache buffers (is it getting above the single-digit range?) current disk requests (what does the activity look like?).  What are the values for the other >entries?

Dirty cache buffers hardly ever exceeds 5 (there are occasional jumps from 20-70)
Current disk requests: usually low (0-6) with occasional spikes up to 80.

Here are two random snapshots:
Utilization:                      42%                   37%
Server up time:              10:07:56:45        10:07:58:53
Online processors:          1                        1
Original cache buffers:    130,472              130,472
Total cache buffers:        88,132                88,130
Dirty cache buffers:         5                        1
Long term cache hits:      92%                   92%
Current disk requests:     0                        0
Packet receive buffers:    200                    200
Directory cache buffers:   500                    500
Maximum service processes:  500              500
Current service processes:     101              101
Current connections:              47                47
Open files:                            95                99

Activity on slow connection:
 Status:                                          Normal
 Network address:                         192.168.1.16:0
 Connection time (DD:HH:MM):       2:19:35
 Requests:                                    1,211,141
 Kilobytes read:                             3,241,956
 Kilobytes written:                          48

See... not much to look at.  But the connection time seems low.  I thought this process was running to 3.5 days?  My mistake! Still, in 2 d 19h, it has only moved 3Gb of data.

I need a tool that will provide more detail on packet errors, crc errors, re-transmits, etc.  What is going on?

Thank you,
Doug  

>"IP only client" but it's part of my thought process

I understand what you are thinking.... IP and IPX together is a bad idea. I encountered that problem a few years ago. This workstation problem reminds me of that time!
I wonder if IPX is activated but hidden?

I would use Ethreal except that it requires pcap and pcap requires a reboot.  I should have been more clear.... I would like to know what tool(s) are available to SEE what is going on right now (without rebooting). Either some tool that can be installed without a reboot... or by looking at this workstation from another computer.

This XP workstation is on SP1.

> Distributed File Tracking?
Never seen this one. Where is this located?  I have long since disabled QoS, Network Location Awareness, and a few others.

Well.... this is all moot now because in the process of looking for "Distributed File Tracking" I caused a reset of the NIC!  So... I might as well install Ethereal and reboot.  I'll write back shortly.

Doug

You could load Ethereal on another computer, as long as you can get on a "promiscuous mode" switch port or use a dumb hub, you should be able to capture all the traffic and filter out for the workstation in question.

Actually it's "distributed LINK tracking."  Sorry.  It has to do with keeping track of where a file is no matter where it gets moved within the NTFS "distributed file system" which hardly anyone uses.

> You could load Ethereal on another computer, as long as you can get on a "promiscuous mode" switch port
Right... I could have done that!

I've rebooted and restarted the move procedure from Explorer (yes, I know xcopy is faster).

The results after the first 50 minutes?
Folder size (before): 2.68Gb, 30023 files
Folder size (after): 2.72Gb, 30644 files

Something is STILL seriously wrong here if only 4Mb is transferred in 50min!

After a few minutes of package capturing with Ethereal, I found a large number of malformed packets but I am not sure how to interpret that at this moment.
Apx. 99% of the traffic is IP (obviously IPX is not the issue).

Ethereal Statistics:
Capture time: 296 seconds
Packets: 44563
Avg. packets/sec: 150
Avg. packet size: 514
Bytes: 22942055
Avg. bytes/sec: 77505
Avg. MBit/sec: 0.620

Correct me if I am reading this wrong but according to these stats... over 200Mb should have been moved in 50 mins.  Even that is [very] slow for 100mbs but better than 4Mb in 50 mins.

Any new suggestions ShineOn (et al).

BTW, this is not a mission critical computer and the moving process can take as long as it wants.... rather this has become an educational pursuit for me (and anyone that wishes to join in). I just want to know why this computer is behaving like this.  Had this been an emergency, I might have rebuilt the network interface, plugged it another NIC or changed the switch port, or rebuilt the computer (worst case senario)... or... ask my boss but the problem is he often zips through this stuff and assumes I know more than I do... great guy though (if he reads this -- :-).

Actually, most import is the process of discovery leading to the solution. I am hoping that you (ShineOn) or others knowledge will rub off on me.

Doug

Just for kicks (if it don't work - kick it!) try mapping a drive letter to the NetWare volume this folder is on, using Novell Map Network Drive, to see if it fares better with a mapped drive vs. UNC.  You could also try mapping a drive letter to the share, if you want.  That may make no difference on the Windows side though.

Did you do right-click/cut and right-click/paste, or did you do the click-and-drag method.  For some odd reason, that seems to make a difference.

Is the slowness in the move truly on the NetWare side of the equation, or is it possibly on the part where the WinXP box is sending the files to the Win2K server?  You could test that by copying to the XP box's local drive, and then moving the files from the XP local drive to the Win2K box.

Do you have indexing turned off on the XP box?  How about the Win2K box?

How about the old standard, full duplex vs half-duplex vs auto, on the NICs and switch ports?  

Here's an odd thought.  Vinit_K got me thinking with the comment regarding SLP vs NetBIOS...

NetWare 5, even at SP6A with the OS5PT2a, is still NetWare 5.  It is sufficiently close enough to IPX-based systems that you might actually fare better with this activity if the connection to NetWare were IPX rather than IP.  I was never really happy with IP access until later SP's of NetWare 5.1.

What the heck.  If it's still going at a snails pace, what've you got to lose?  Try using IPX only on the Novell client32 connection to NetWare.  If that works better, then we know it has something to do with your IP configuration on NetWare and/or the client.  An NCP call >should< work the same over IP or IPX, but it wasn't exactly perfect yet over IP on NetWare 5.0, in my opinion, and we know it has been solid pretty much forever on IPX.

Makes sense ShineON. I just realised that this is a Netware 5 server running IP (Guess IP is just bound) and not other protocol. Also it depends if the client was installed default, it may have bound IPX (IPX and IP mode) and good ol netware client is using IPX as the default and using IP as the fall back. Honestly, I agree that IP is not the best protocol to use for an Netware 5.x server. But then why is it working from other computers and only this PC (as I read it) has the problem. Maybe others are not XP, maybe the client was installed differently.

The question of antivirus didn't come up before but should have.  Good call, Vinit_K.  This does sort-of sound like it could be behavior you might see with a real-time virus scan on the workstation, or perhaps a real-time scan of writes on the Win2K server.  Like I said, it might not be a read-from-NetWare issue but a write-to-Windows issue.  Hard to say from what info we have here...

Vinit_K:
Anti-virus no.... that was one of the first things I tried. I currently using Sophos (soon to be replaced) and it is terrible for slowing down file operations. I immediately shut it off but unfortunately it was not the cause in this case. Also provider order is always set for Novell being first but that setting would not account for the slowness I was experiencing. File caching was off.

ShineOn: "Try using IPX only on the Novell client32 connection to NetWare. "
You might have forgotten that the problem appears on one workstation only. Besides, IPX is disabled on the Novell server (which I why I can no longer configure ArcserveIT - it is a good thing it running in an automated mode!).

Vinit_K: I think you might be correct. As I suspected in the beginning... although IPX is not visable (either through an ethereal trace or in the network installed protocols).... it may still be there... Is that actually possible?  Perhaps by reinstalling all network related components I might solve this problem?

BTW, thank you for all the suggestions. :-)

I haven't forgotten.  It's a troubleshooting step suggestion specific for this issue - I wasn't recommending that you switch all clients to IPX. You wouldn't have to keep it available long-term, either - you can load/bind IPX on the server and on the one client on-the-fly (at least on the server side...) and unbind IP from the Novell client on the PC, and later unbind IPX from the server and uncheck IPX/SPX protocol on the client when you're done.

You might want to have it available as an option anyway, so if you do have to configure AS you can, just by binding the protocol on both the server and a single client.

As far as it being on one workstation only - if you try the exact same operation on another workstation, does it go lightning-fast?  I don't believe you said one way or another.  You said other things on other workstations didn't have problems, but you didn't mention if you tried this exact move operation on another client.

I know you have probablly thought of this, but have you tried a new cable from the Novell server to the HUB and possible a different port on the HUB.  I have had both come up to be the problem after tring everything else.

Good luck

Thank you for your assistance everyone.  By rebuilding the computer, the problem no longer exists.

I graded this one based on your efforts!  Thank you again.