Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

NFS Pull - 5520-24T

Status
Not open for further replies.

goodingsd

Technical User
Feb 13, 2003
20
CA
We've run up against a very odd problem where a 100Tx client, with an NFS automount / soft mount, to 1000Tx server gets extemely slow transfer times on test files that normally take less than ten seconds.

Client & server both at 100Tx or 1000Tx - no prob

Client & server both on 450-24T switches - no prob

All other transfers OK such as FTP

Test scenario was with a single 5520-24T and we've tried a number of things:
- BOSS 4.1, 4.2 & 4.2.1
- QueueSet & BufferingCaps settings - QueueSet2 & med BufferingCaps works best / no diff
- AUTO or hard coded 1000Tx - no diff
 
Tough to tell from your post, but I would guess that it is slow when transferring 1000 to 100. 1000 to 1000 is fine, 100 to 100 is fine, and 100 to 1000 is fine.

If so, this is directly a result of the crappy buffer alloction on the 5500 series switches.

You are fine on the versions of code the 5500's are on...and your queue set is fine. (no issues in 1-4), but set your buff size to max.

With buff set to max, you can use queue sets 1-4 and have no issues with 1000 to 100 with a 65000 byte TCP window size. I guarantee it.

Even with buff set to max however, you will run in to issues with queue sets 5-8 if you use large TCP windows for your transfers. As a sidenote, all new Macs with OSX by DEFAULT have a 65000 byte TCP window size...whereas Windows clients have a sliding window size...and is generally not succeptible to the issue.
 
Thanks Jynxx, the specific issue is having an NFS client switch port connected at 100M FD pulling data from a server that is swicth port connected at GIG FD - extremely slow (20 min vs 5 sec). NFS client configured to use UDP. This happens 100% of time when server & client are on the same test 5520.

What confused the matter was thinking it was simply a 5520 L2 problem because all teh same devices with the same configs had no issues running on 450 connected client pulling data from a GIG connected server on an 8600 core.

I was looking at the QueueSet & BufferingCaps settings on the 5520 due to another thread related to GIG issues. This thread suggested that going to QueueSet4 & max BufferingCaps fixed GIG related issues. Didn't do anything for my issue.

Did a foolish thing and opened a case with Nortel TAC who actually came back with something very useful -- basically the NFS using UDP is working the way it is designed to. The 5520 is also functioning the way it is supposed to. The issue is that with UDP, requiring no acknowledgement, would continue spitting out data that the 5520 had no place to put due to small switch buffer size. CHange NFS client to TCP and should have no more problems.

Nortel also referenced a Microsoft knowledge base article on similar point -- KB831908 -
 
Ah yes. Makes sense...never thought about the fact that UDP is connectionless...

You may want to play with the queue sets...maybe try queue set 1 and max buff size. If that doesn't work you will have no choice but to convert to TCP...and if that doesn't work...the 5500's are probably not going to be your solution.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top