I was wondering what the CIFS overhead for a NetApp filer would be.
Let's say for instance a Windows Server to Windows Server transfer on the same switch, same subnet, GIG copper interconnects, no TOE card, etc gets me up to about 50% utilization (500Mbps).
Should that same server to a Netapp Filer see a 20-30% degradation in TX/RX speeds because of CIFS overhead?
What should I expect for data rates in this type of scenario? Are there any tweaks anyone knows of to decrease this gap?
(same results using static link aggregation, and LACP for the VIF)
Thanks
Lock
Typically, you shouldn't see any performance decrease - rather, you should get better performance.
Are you seeing some sort of decrease?
What I can point out: with some things (Excel\Word to be specific), MS will implement stuff that's not really documented for the file open\discovery which can cause problems, but I doubt that's what you are running into given the speed you are speaking of. Likewise, using Windows NLB (LB not HA) doesn't always go very well given the fact that it's not the best technology and sometimes can display interop problems with other vendors (not just NetApp).
What exactly are you doing for your test?
Glenn
________________________________
From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Langdon, Laughlin T. (Lock) Sent: Tuesday, March 27, 2007 2:33 PM To: toasters@mathworks.com Subject: CIFS overhead with Netapp Filers
I was wondering what the CIFS overhead for a NetApp filer would be.
Let's say for instance a Windows Server to Windows Server transfer on the same switch, same subnet, GIG copper interconnects, no TOE card, etc gets me up to about 50% utilization (500Mbps).
Should that same server to a Netapp Filer see a 20-30% degradation in TX/RX speeds because of CIFS overhead?
What should I expect for data rates in this type of scenario? Are there any tweaks anyone knows of to decrease this gap?
(same results using static link aggregation, and LACP for the VIF)
Thanks
Lock
I'm doing a straight drag and drop using UNC paths with a single 1.5gig zip file and a 2.2Gig binary File. If I add more streams (aka start more than one copy on more than one server the filer happily provides more bandwidth)
From Windows server to windows server I get 500 Mbps
From Windows server to a Netapp 6030 Filer running DOT 7.2.1 I get about 250 Mbps
I've tried TCP windows size, Flow Control, LCAP, Static Link Aggregation, Singe port on the filer (no vif), straight crossover cable.
From: Glenn Walker [mailto:ggwalker@mindspring.com] Sent: Tuesday, March 27, 2007 5:15 PM To: Langdon, Laughlin T. (Lock); toasters@mathworks.com Subject: RE: CIFS overhead with Netapp Filers
Typically, you shouldn't see any performance decrease - rather, you should get better performance.
Are you seeing some sort of decrease?
What I can point out: with some things (Excel\Word to be specific), MS will implement stuff that's not really documented for the file open\discovery which can cause problems, but I doubt that's what you are running into given the speed you are speaking of. Likewise, using Windows NLB (LB not HA) doesn't always go very well given the fact that it's not the best technology and sometimes can display interop problems with other vendors (not just NetApp).
What exactly are you doing for your test?
Glenn
________________________________
From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Langdon, Laughlin T. (Lock) Sent: Tuesday, March 27, 2007 2:33 PM To: toasters@mathworks.com Subject: CIFS overhead with Netapp Filers
I was wondering what the CIFS overhead for a NetApp filer would be.
Let's say for instance a Windows Server to Windows Server transfer on the same switch, same subnet, GIG copper interconnects, no TOE card, etc gets me up to about 50% utilization (500Mbps).
Should that same server to a Netapp Filer see a 20-30% degradation in TX/RX speeds because of CIFS overhead?
What should I expect for data rates in this type of scenario? Are there any tweaks anyone knows of to decrease this gap?
(same results using static link aggregation, and LACP for the VIF)
Thanks
Lock
I'm doing a straight drag and drop using UNC paths with a single 1.5gig zip file and a 2.2Gig binary File. If I add more streams (aka start more than one copy on more than one server the filer happily provides more bandwidth)
Are you using Windows explorer to make the copy? Your statement regarding drag and drop indicates that you're using explorer, but I'd like to confirm.
What version of Windows are you running?
Is performance slow with just writes? or Read / writes?
Native CIFS or NetBIOS/SMB over TCP/IP?
Regards, Max
From Windows server to windows server I get 500 Mbps
From Windows server to a Netapp 6030 Filer running DOT 7.2.1 I get about 250 Mbps
I've tried TCP windows size, Flow Control, LCAP, Static Link Aggregation, Singe port on the filer (no vif), straight crossover cable.
From: Glenn Walker [mailto:ggwalker@mindspring.com] Sent: Tuesday, March 27, 2007 5:15 PM To: Langdon, Laughlin T. (Lock); toasters@mathworks.com Subject: RE: CIFS overhead with Netapp Filers
Typically, you shouldn't see any performance decrease - rather, you should get better performance.
Are you seeing some sort of decrease?
What I can point out: with some things (Excel\Word to be specific), MS will implement stuff that's not really documented for the file open\discovery which can cause problems, but I doubt that's what you are running into given the speed you are speaking of. Likewise, using Windows NLB (LB not HA) doesn't always go very well given the fact that it's not the best technology and sometimes can display interop problems with other vendors (not just NetApp).
What exactly are you doing for your test?
Glenn
From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Langdon, Laughlin T. (Lock) Sent: Tuesday, March 27, 2007 2:33 PM To: toasters@mathworks.com Subject: CIFS overhead with Netapp Filers
I was wondering what the CIFS overhead for a NetApp filer would be.
Let's say for instance a Windows Server to Windows Server transfer on the same switch, same subnet, GIG copper interconnects, no TOE card, etc gets me up to about 50% utilization (500Mbps).
Should that same server to a Netapp Filer see a 20-30% degradation in TX/RX speeds because of CIFS overhead?
What should I expect for data rates in this type of scenario? Are there any tweaks anyone knows of to decrease this gap?
(same results using static link aggregation, and LACP for the VIF)
Thanks
Lock
Sorry used to talking in the windows world :)
The files are being copied using command line parameters, but drag and drop in explorer garners about the same results Copy /b <filename_local> <location>
Reads are faster than writes but both are slower server<->filer than server<->server
I'm a little confused on the CIFS/SMB discussion. I assumed I was using SMB, but since it seems Windows CIFS/SMB are the same thing I don't know. Is there a way to find out for sure?
I've rebooted the servers to make sure it's not a cache issue.
-----Original Message----- From: Max Reid [mailto:max.reid@saikonetworks.com] Sent: Wednesday, March 28, 2007 9:39 AM To: Langdon, Laughlin T. (Lock) Cc: Glenn Walker; toasters@mathworks.com Subject: RE: CIFS overhead with Netapp Filers
I'm doing a straight drag and drop using UNC paths with a single
1.5gig
zip file and a 2.2Gig binary File. If I add more streams (aka start more than one copy on more than one server the filer happily provides more bandwidth)
Are you using Windows explorer to make the copy? Your statement regarding drag and drop indicates that you're using explorer, but I'd like to confirm.
What version of Windows are you running?
Is performance slow with just writes? or Read / writes?
Native CIFS or NetBIOS/SMB over TCP/IP?
Regards, Max
From Windows server to windows server I get 500 Mbps
From Windows server to a Netapp 6030 Filer running DOT 7.2.1 I get
about
250 Mbps
I've tried TCP windows size, Flow Control, LCAP, Static Link Aggregation, Singe port on the filer (no vif), straight crossover
cable.
From: Glenn Walker [mailto:ggwalker@mindspring.com] Sent: Tuesday, March 27, 2007 5:15 PM To: Langdon, Laughlin T. (Lock); toasters@mathworks.com Subject: RE: CIFS overhead with Netapp Filers
Typically, you shouldn't see any performance decrease - rather, you should get better performance.
Are you seeing some sort of decrease?
What I can point out: with some things (Excel\Word to be specific),
MS
will implement stuff that's not really documented for the file open\discovery which can cause problems, but I doubt that's what you
are
running into given the speed you are speaking of. Likewise, using Windows NLB (LB not HA) doesn't always go very well given the fact
that
it's not the best technology and sometimes can display interop
problems
with other vendors (not just NetApp).
What exactly are you doing for your test?
Glenn
From: owner-toasters@mathworks.com
[mailto:owner-toasters@mathworks.com]
On Behalf Of Langdon, Laughlin T. (Lock) Sent: Tuesday, March 27, 2007 2:33 PM To: toasters@mathworks.com Subject: CIFS overhead with Netapp Filers
I was wondering what the CIFS overhead for a NetApp filer would be.
Let's say for instance a Windows Server to Windows Server transfer on the same switch, same subnet, GIG copper interconnects, no TOE card,
etc
gets me up to about 50% utilization (500Mbps).
Should that same server to a Netapp Filer see a 20-30% degradation in TX/RX speeds because of CIFS overhead?
What should I expect for data rates in this type of scenario? Are
there
any tweaks anyone knows of to decrease this gap?
(same results using static link aggregation, and LACP for the VIF)
Thanks
Lock
The files are being copied using command line parameters, but drag and drop in explorer garners about the same results Copy /b <filename_local> <location>
Reads are faster than writes but both are slower server<->filer than server<->server
I'm a little confused on the CIFS/SMB discussion. I assumed I was using SMB, but since it seems Windows CIFS/SMB are the same thing I don't know. Is there a way to find out for sure?
The Concept of "Native" CIFS (CIFS without Netbios overhead) was introduced in Windows 2000. Distinguishing characteristic is that it runs natively on TCP/IP over port 445 (IIRC) and does not ride on top of the legacy Netbios over TCP/IP layer (which encapsulated the SMB request in a Netbios packet which was then stuffed into a TCP/IP packet.)
What version of windows are you running? Windows 2000 or Windows 2003?
Regards, Max
2003 R2
-----Original Message----- From: Max Reid [mailto:max.reid@saikonetworks.com] Sent: Wednesday, March 28, 2007 3:04 PM To: Langdon, Laughlin T. (Lock) Cc: max.reid@saikonetworks.com; Glenn Walker; toasters@mathworks.com Subject: RE: CIFS overhead with Netapp Filers
The files are being copied using command line parameters, but drag and drop in explorer garners about the same results Copy /b <filename_local> <location>
Reads are faster than writes but both are slower server<->filer than server<->server
I'm a little confused on the CIFS/SMB discussion. I assumed I was
using
SMB, but since it seems Windows CIFS/SMB are the same thing I don't know. Is there a way to find out for sure?
The Concept of "Native" CIFS (CIFS without Netbios overhead) was introduced in Windows 2000. Distinguishing characteristic is that it runs natively on TCP/IP over port 445 (IIRC) and does not ride on top of the legacy Netbios over TCP/IP layer (which encapsulated the SMB request in a Netbios packet which was then stuffed into a TCP/IP packet.)
What version of windows are you running? Windows 2000 or Windows 2003?
Regards, Max
A quick crawl on NOW provided the following: http://now.netapp.com/Knowledgebase/solutionarea.asp?id=ntapcs675
if CIFS performance is slow after investigating performance issues, modify the filer's CIFS negotiated buffer size.
1. Verify that hardware or software problems do not exist within the filer, network and client. 2. Record the CIFS negotiated buffer size by capturing the output of the filer command: options cifs.neg_buf_size 3. Enter the following filer commands: a. cifs terminate b. options cifs.neg_buf_size 16644 c. cifs restart 4. If the buffer size in step 3b does not improve performance, try the following buffer sizes: a. Use '17424'. Note: Starting with Data ONTAP 6.0.X, allow the buffer size to exceed 17424; therefore, upgrade to a release that fixes bug 33396 only if performance does not improve. b. Use '33472' for environments mixed with Windows NT and Windows 2000. c. Use '65340' for Windows 2000 only environments. 5. If performance remains slow: a. Re-confirm that hardware or software problems do not exist within the filer, network and client. b. Restore the original CIFS negotiated buffer size (refer to steps 2 and 3). c. During a performance interruption, capture a packet trace between the filer and Windows client. d. Send the packet trace to Network Appliance Technical Support for analysis.
On Mar 28, 2007, at 8:33 AM, Langdon, Laughlin T. ((Lock)) wrote:
I’m doing a straight drag and drop using UNC paths with a single 1.5gig zip file and a 2.2Gig binary File. If I add more streams (aka start more than one copy on more than one server the filer happily provides more bandwidth)
From Windows server to windows server I get 500 Mbps
From Windows server to a Netapp 6030 Filer running DOT 7.2.1 I get about 250 Mbps
I’ve tried TCP windows size, Flow Control, LCAP, Static Link Aggregation, Singe port on the filer (no vif), straight crossover cable.
From: Glenn Walker [mailto:ggwalker@mindspring.com] Sent: Tuesday, March 27, 2007 5:15 PM To: Langdon, Laughlin T. (Lock); toasters@mathworks.com Subject: RE: CIFS overhead with Netapp Filers
Typically, you shouldn’t see any performance decrease – rather, you should get better performance.
Are you seeing some sort of decrease?
What I can point out: with some things (Excel\Word to be specific), MS will implement stuff that’s not really documented for the file open\discovery which can cause problems, but I doubt that’s what you are running into given the speed you are speaking of. Likewise, using Windows NLB (LB not HA) doesn’t always go very well given the fact that it’s not the best technology and sometimes can display interop problems with other vendors (not just NetApp).
What exactly are you doing for your test?
Glenn
From: owner-toasters@mathworks.com [mailto:owner- toasters@mathworks.com] On Behalf Of Langdon, Laughlin T. (Lock) Sent: Tuesday, March 27, 2007 2:33 PM To: toasters@mathworks.com Subject: CIFS overhead with Netapp Filers
I was wondering what the CIFS overhead for a NetApp filer would be.
Let’s say for instance a Windows Server to Windows Server transfer on the same switch, same subnet, GIG copper interconnects, no TOE card, etc gets me up to about 50% utilization (500Mbps).
Should that same server to a Netapp Filer see a 20-30% degradation in TX/RX speeds because of CIFS overhead?
What should I expect for data rates in this type of scenario? Are there any tweaks anyone knows of to decrease this gap?
(same results using static link aggregation, and LACP for the VIF)
Thanks
Lock
That would be my recommendation as well: TCP window size is the most likely culprit.
Windows (newer versions) will negotiate a very large window size which can help. The filer's default has been 17424 for some time, which will make things slower.
As for the SMB vs CIFS thing, they're essentially the same. If you're using Windows, you're using CIFS (unless you've loaded services for unix, but I'm pretty sure you'd realize if you were utilizing NFS by accident).
Glenn
________________________________
From: Shane Garoutte [mailto:sgaroutte@gmail.com] Sent: Wednesday, March 28, 2007 3:29 PM To: Langdon, Laughlin T. ((Lock)) Cc: Glenn Walker; toasters@mathworks.com Subject: Re: CIFS overhead with Netapp Filers
A quick crawl on NOW provided the following:
http://now.netapp.com/Knowledgebase/solutionarea.asp?id=ntapcs675
if CIFS performance is slow after investigating performance issues, modify the filer's CIFS negotiated buffer size.
1. Verify that hardware or software problems do not exist within the filer, network and client.
2. Record the CIFS negotiated buffer size by capturing the output of the filer command:
options cifs.neg_buf_size
3. Enter the following filer commands:
a. cifs terminate
b. options cifs.neg_buf_size 16644
c. cifs restart
4. If the buffer size in step 3b does not improve performance, try the following buffer sizes:
a. Use '17424'.
Note:
Starting with Data ONTAP 6.0.X, allow the buffer size to exceed 17424; therefore, upgrade to a release that fixes bug 33396 only if performance does not improve.
b. Use '33472' for environments mixed with Windows NT and Windows 2000.
c. Use '65340' for Windows 2000 only environments.
5. If performance remains slow:
a. Re-confirm that hardware or software problems do not exist within the filer, network and client.
b. Restore the original CIFS negotiated buffer size (refer to steps 2 and 3).
c. During a performance interruption, capture a packet trace between the filer and Windows client.
d. Send the packet trace to Network Appliance Technical Support for analysis.
On Mar 28, 2007, at 8:33 AM, Langdon, Laughlin T. ((Lock)) wrote:
I'm doing a straight drag and drop using UNC paths with a single 1.5gig zip file and a 2.2Gig binary File. If I add more streams (aka start more than one copy on more than one server the filer happily provides more bandwidth)
From Windows server to windows server I get 500 Mbps
From Windows server to a Netapp 6030 Filer running DOT 7.2.1 I get about 250 Mbps
I've tried TCP windows size, Flow Control, LCAP, Static Link Aggregation, Singe port on the filer (no vif), straight crossover cable.
Glenn Walker [mailto:ggwalker@mindspring.com] Sent: Tuesday, March 27, 2007 5:15 PM To: Langdon, Laughlin T. (Lock); toasters@mathworks.com Subject: RE: CIFS overhead with Netapp Filers
________________________________
size=2 width="100%" align=center>
owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Langdon, Laughlin T. (Lock) Sent: Tuesday, March 27, 2007 2:33 PM To: toasters@mathworks.com Subject: CIFS overhead with Netapp Filers
On Mar 28, 2007, at 5:04 PM, Glenn Walker wrote:
As for the SMB vs CIFS thing, they’re essentially the same. If you’re using Windows, you’re using CIFS (unless you’ve loaded services for unix, but I’m pretty sure you’d realize if you were utilizing NFS by accident).
Due to the fact that it would be faster with less overhead? Oh wait, this is windows... nm ;)
jk
MS's implementation of NFS? Less overhead? Highly doubtful ;)
I'm pretty sure that MS would make CIFS faster by making NFS slower...
________________________________
From: Shane Garoutte [mailto:sgaroutte@gmail.com] Sent: Wednesday, March 28, 2007 8:28 PM To: Glenn Walker Cc: Langdon, Laughlin T. ((Lock)); toasters@mathworks.com Subject: Re: CIFS overhead with Netapp Filers
On Mar 28, 2007, at 5:04 PM, Glenn Walker wrote:
As for the SMB vs CIFS thing, they're essentially the same. If you're using Windows, you're using CIFS (unless you've loaded services for unix, but I'm pretty sure you'd realize if you were utilizing NFS by accident).
Due to the fact that it would be faster with less overhead? Oh wait, this is windows... nm ;)
jk
One more seemingly decent article:
http://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb8130
On Mar 28, 2007, at 8:33 AM, Langdon, Laughlin T. ((Lock)) wrote:
I’m doing a straight drag and drop using UNC paths with a single 1.5gig zip file and a 2.2Gig binary File. If I add more streams (aka start more than one copy on more than one server the filer happily provides more bandwidth)
From Windows server to windows server I get 500 Mbps
From Windows server to a Netapp 6030 Filer running DOT 7.2.1 I get about 250 Mbps
I’ve tried TCP windows size, Flow Control, LCAP, Static Link Aggregation, Singe port on the filer (no vif), straight crossover cable.
Wouldn't the Windows Server to Windows Server file transsfer also use CIFS? How are the 2 Windows servers logically connected? Mapped drive? Network Place? IN either case they would also be using CIFS as their file transfer protocol. Remember, CIFS is a Windows protocol not a Netapp protocol. We simply implement it on our storage controllers (filers).
I would expect performance to be as good or better.
Paulb
From: Langdon, Laughlin T. (Lock) [mailto:Langdon.Lock@Mayo.EDU] Sent: Tuesday, March 27, 2007 2:33 PM To: toasters@mathworks.com Subject: CIFS overhead with Netapp Filers
I was wondering what the CIFS overhead for a NetApp filer would be.
Let's say for instance a Windows Server to Windows Server transfer on the same switch, same subnet, GIG copper interconnects, no TOE card, etc gets me up to about 50% utilization (500Mbps).
Should that same server to a Netapp Filer see a 20-30% degradation in TX/RX speeds because of CIFS overhead?
What should I expect for data rates in this type of scenario? Are there any tweaks anyone knows of to decrease this gap?
(same results using static link aggregation, and LACP for the VIF)
Thanks
Lock
I'm assuming the windows to windows xfer is actually SMB not CIFS
From: Brosseau, Paul [mailto:Paul.Brosseau@netapp.com] Sent: Wednesday, March 28, 2007 7:16 AM To: Langdon, Laughlin T. (Lock); toasters@mathworks.com Subject: RE: CIFS overhead with Netapp Filers
Wouldn't the Windows Server to Windows Server file transsfer also use CIFS? How are the 2 Windows servers logically connected? Mapped drive? Network Place? IN either case they would also be using CIFS as their file transfer protocol. Remember, CIFS is a Windows protocol not a Netapp protocol. We simply implement it on our storage controllers (filers).
I would expect performance to be as good or better.
Paulb
From: Langdon, Laughlin T. (Lock) [mailto:Langdon.Lock@Mayo.EDU] Sent: Tuesday, March 27, 2007 2:33 PM To: toasters@mathworks.com Subject: CIFS overhead with Netapp Filers
I was wondering what the CIFS overhead for a NetApp filer would be.
Let's say for instance a Windows Server to Windows Server transfer on the same switch, same subnet, GIG copper interconnects, no TOE card, etc gets me up to about 50% utilization (500Mbps).
Should that same server to a Netapp Filer see a 20-30% degradation in TX/RX speeds because of CIFS overhead?
What should I expect for data rates in this type of scenario? Are there any tweaks anyone knows of to decrease this gap?
(same results using static link aggregation, and LACP for the VIF)
Thanks
Lock
AFAIK SMB and CIFS is quite the same. SMB is the old name and CIFS is the rebrand :D
Regards
Jochen
________________________________
From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Langdon, Laughlin T. (Lock) Sent: Wednesday, March 28, 2007 5:34 PM To: Brosseau, Paul; toasters@mathworks.com Subject: RE: CIFS overhead with Netapp Filers
I'm assuming the windows to windows xfer is actually SMB not CIFS
From: Brosseau, Paul [mailto:Paul.Brosseau@netapp.com] Sent: Wednesday, March 28, 2007 7:16 AM To: Langdon, Laughlin T. (Lock); toasters@mathworks.com Subject: RE: CIFS overhead with Netapp Filers
Wouldn't the Windows Server to Windows Server file transsfer also use CIFS? How are the 2 Windows servers logically connected? Mapped drive? Network Place? IN either case they would also be using CIFS as their file transfer protocol. Remember, CIFS is a Windows protocol not a Netapp protocol. We simply implement it on our storage controllers (filers).
I would expect performance to be as good or better.
Paulb
From: Langdon, Laughlin T. (Lock) [mailto:Langdon.Lock@Mayo.EDU] Sent: Tuesday, March 27, 2007 2:33 PM To: toasters@mathworks.com Subject: CIFS overhead with Netapp Filers
I was wondering what the CIFS overhead for a NetApp filer would be.
Let's say for instance a Windows Server to Windows Server transfer on the same switch, same subnet, GIG copper interconnects, no TOE card, etc gets me up to about 50% utilization (500Mbps).
Should that same server to a Netapp Filer see a 20-30% degradation in TX/RX speeds because of CIFS overhead?
What should I expect for data rates in this type of scenario? Are there any tweaks anyone knows of to decrease this gap?
(same results using static link aggregation, and LACP for the VIF)
Thanks
Lock
Either way our performance is in the dirt ;)
From: Willeke, Jochen [mailto:Jochen.Willeke@wincor-nixdorf.com] Sent: Wednesday, March 28, 2007 9:09 AM To: Langdon, Laughlin T. (Lock); Brosseau, Paul; toasters@mathworks.com Subject: RE: CIFS overhead with Netapp Filers
AFAIK SMB and CIFS is quite the same. SMB is the old name and CIFS is the rebrand :D
Regards
Jochen
________________________________
From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Langdon, Laughlin T. (Lock) Sent: Wednesday, March 28, 2007 5:34 PM To: Brosseau, Paul; toasters@mathworks.com Subject: RE: CIFS overhead with Netapp Filers
I'm assuming the windows to windows xfer is actually SMB not CIFS
From: Brosseau, Paul [mailto:Paul.Brosseau@netapp.com] Sent: Wednesday, March 28, 2007 7:16 AM To: Langdon, Laughlin T. (Lock); toasters@mathworks.com Subject: RE: CIFS overhead with Netapp Filers
Wouldn't the Windows Server to Windows Server file transsfer also use CIFS? How are the 2 Windows servers logically connected? Mapped drive? Network Place? IN either case they would also be using CIFS as their file transfer protocol. Remember, CIFS is a Windows protocol not a Netapp protocol. We simply implement it on our storage controllers (filers).
I would expect performance to be as good or better.
Paulb
From: Langdon, Laughlin T. (Lock) [mailto:Langdon.Lock@Mayo.EDU] Sent: Tuesday, March 27, 2007 2:33 PM To: toasters@mathworks.com Subject: CIFS overhead with Netapp Filers
I was wondering what the CIFS overhead for a NetApp filer would be.
Let's say for instance a Windows Server to Windows Server transfer on the same switch, same subnet, GIG copper interconnects, no TOE card, etc gets me up to about 50% utilization (500Mbps).
Should that same server to a Netapp Filer see a 20-30% degradation in TX/RX speeds because of CIFS overhead?
What should I expect for data rates in this type of scenario? Are there any tweaks anyone knows of to decrease this gap?
(same results using static link aggregation, and LACP for the VIF)
Thanks
Lock
-
Brosseau, Paul -
Glenn Walker -
Langdon, Laughlin T. (Lock) -
Max Reid -
Shane Garoutte -
Willeke, Jochen