After verifying the problem by reproducing it (the LAN in question was gigabit), but the throughput numbers were more akin to 10 Base-T), I blew through all the usual suspect, quick ‘n dirty, first line ruling out of points of failure:
— Testing his patch cable (at port and switch),
— Made sure his port on the switch was configured for 1000 Base-T,
— Verified all Server-Side configs for this user’s account.
— Logged into another User Account — was NOT able to reproduce the problem.
So I’ve isolated the anomaly to his User Account. What was throwing me off however, was that when logged back into the problem user account, I found I *WAS* able to mount OTHER network shares (such as my own laptop with File Sharing enabled) with normal (gigabit speeds) throughput.
So… it’s now down to just HIS user account, on HIS machine, logging in ONLY to his share point on his company’s File Server–other networked share points were normal. (AppleTalk was disabled on all clients, and he / they were all talking to their File Server over TCP/IP).
A protocol analysis was the only other logical Systematic Fault Isolation Procedure left that I could think of, so I launched my open-source packet sniffer, Wireshark, (formerly Ethereal) to analyze his machine’s packet flow, and BINGO!
I discovered immediately, that his machine was talking to the server (and NOT the other network share points), with SSH encryption (my bad, as while troubleshooting another issue with this user’s machine a few days earlier, I had selected “Do not allow communication over clear text”, in the “Connect To Server” options box in his AFP client’s console, and had inadvertently forgotten to UNcheck after I was done). Thus, everything the user was doing, that was Server related, was getting bottlenecked by the encryption process. Clearly, the fix was simply to UNcheck the checkbox to “Do not allow communication over clear text” options button in “Connect to Server” console / client.
