Stephane Bentebba | 1 Apr 2004 11:17
Picon

Re: joining FAS 270 to samba 3.0 domain

this is a samba issue :
logon to a win domain during the authent process can be made by two 
slight different manners :
crypt the password in unicode
crypt the password not in unicode

currently samba doesn't support correctly the unicode (3.0a)
and currently the netapp support only unicode
althought windows client support both...

so, when the netapp try to speak with samba, they can't understand each 
other

you still can't integrate a Filer in a domain managed with samba
unicode support for authentification is in the roadmap of samba
it was planned to work with 3.0 (6 months ago) but doesn't work in fact
we have to wait

Tom Schuetz wrote:

>Hi,
>
>We are trying to join a FAS 270 to a domain controlled by and OS X server
>running Samba 3.0.
>
>We choose to do it NT4-style.
>
>When we do this, the following happens:
>***************************************************************************
>Wed Mar 31 13:45:55 PST [rc:info]: Starting DC address discovery for
(Continue reading)

Jack Lyons | 2 Apr 2004 15:40

AntiVirus Solutions

We are looking for a virus scanning solution for our FAS960 with 350 users
accessing via CIFS.

Trend Micro is a little cheaper than McAfee but we are a McAfee shop.  But I
have also heard that Trend Micro is better for NetApp but I can't find any
specifics?

Can anyone share their experience with either product?

Thanks
Jack

This email and its contents may be confidential.  If it is and you are not
the intended recipient, please do not disclose or use the information within
this email or its attachments.  If you have received this email in error,
please delete it immediately.  Thank you.

Palmer, Jason (EMEA | 2 Apr 2004 18:29
Picon

RE: AntiVirus Solutions


Hi Jack,

We are currently using both vendors.  In my view, a mixture of the both allows for coverge, if one of the vendors are a bit slow in reacting and releasing an update to cover a new virus type.

The latest offering from Trend allows for one scanner to scan more than one NAS Appliance, which was a restriction that was becomming a pain to live with.  I have had not seen McAfee for NetApps in action, but from reading the documentation it behaves in a similar way.

Generally we run McAfee on Local client machines and Trend on Servers, and currently we are serving a user base of 5000+ users accross EMEA and have had no problems.

Regards,

Jason
-----------------------------------
Jason Palmer <Team Leader>
Messaging & Storage Implementation
MCI [EMEA]
-----------------------------------
[e]:  jason.palmer <at> uk.mci.com
[i]:   http://www.mci.com/uk
-----------------------------------


-----Original Message-----
From: owner-toasters <at> mathworks.com
[mailto:owner-toasters <at> mathworks.com]On Behalf Of Jack Lyons
Sent: 02 April 2004 14:41
To: 'toasters <at> mathworks.com'
Subject: AntiVirus Solutions


We are looking for a virus scanning solution for our FAS960 with 350 users
accessing via CIFS.

Trend Micro is a little cheaper than McAfee but we are a McAfee shop.  But I
have also heard that Trend Micro is better for NetApp but I can't find any
specifics?

Can anyone share their experience with either product?

Thanks
Jack



This email and its contents may be confidential.  If it is and you are not
the intended recipient, please do not disclose or use the information within
this email or its attachments.  If you have received this email in error,
please delete it immediately.  Thank you.

Tim Driggers | 2 Apr 2004 18:59

CIFS performance Issue

Hi All,

I have been playing with an F760 with ONTAP 6.4.1 for about thirty days. I
am having a problem understanding a CIFS transfer rate difference I am
seeing between writing to and from the NetApp.

First, a little background:

The F760 has a X1025B gigabit card (SX fiber) in it, connected to an Extreme
BlackDiamond 6808. The BlackDiamond does -not- have jumbo frames enabled at
this time. The NetApp has full flow control configured.

I am able to copy a single (30GB) file (generated by mkfile in FreeBSD) to
and from the NetApp over NFSv3 at between 92-96mbit consistently, with the
FreeBSD using an NFS mount having a 100mbit link.

I am able to copy the same 30GB file from the NetApp to a Windows 2000
server using CIFS at 130-160mbit consistently. The Win2k server has a
gigabit SX card. When copying the file to the NetApp from the Win2k server,
I am seeing a maximum throughput of 69mbit, and usually it settles around
33-40mbit. I am monitoring this transfer rate using 'sh port utillization'
on the BlackDiamond. I have tested this on three different Win2k boxes, with
nearly identical results. I have also followed instructions on NetApp's
website on how to 'improve' performance through registry edits, with no
apparent result (positive or negative). I have tried three different
flowcontrol settings on the Win2k cards (send, recieve and full) - again
with no change in performance.

I'm thrilled with the NFS performance, but we are a windows shop. I need to
get performance increased on the CIFS writes to the NetApp if it's possible.

I have tried every tweak I could find, and nothing seems to change the rate
at which I can write to the NetApp via CIFS. I have included some NetApp
information:

 slot 8: Gigabit Ethernet Controller II
 e8 MAC Address: 00:03:47:25:36:6a (auto-1000sx-fd-up)
 slot 9: NVRAM
 Memory Size:        32 MB

netapp1> options cifs
cifs.audit.autosave.file.extension
cifs.audit.autosave.file.limit 0
cifs.audit.autosave.onsize.enable off
cifs.audit.autosave.onsize.threshold 500k
cifs.audit.autosave.ontime.enable off
cifs.audit.autosave.ontime.interval
cifs.audit.enable            off
cifs.audit.file_access_events.enable on
cifs.audit.logon_events.enable on
cifs.audit.logsize           524288
cifs.audit.saveas            /etc/log/adtlog.evt
cifs.bypass_traverse_checking on
cifs.comment
cifs.guest_account
cifs.home_dir
cifs.home_dir_namestyle      ntname
cifs.home_dirs_public_for_admin on
cifs.idle_timeout            1800
cifs.max_mpx                 50
cifs.netbios_aliases
cifs.netbios_over_tcp.enable on
cifs.nfs_root_ignore_acl     on
cifs.oplocks.enable          off
cifs.oplocks.opendelta       8
cifs.per_client_stats.enable off
cifs.perm_check_ro_del_ok    on
cifs.perm_check_use_gid      on
cifs.restrict_anonymous.enable off
cifs.save_case               on
cifs.scopeid
cifs.search_domains
cifs.show_snapshot           off
cifs.shutdown_msg_level      2
cifs.sidcache.enable         on
cifs.sidcache.lifetime       1440
cifs.snapshot_file_folding.enable off
cifs.symlinks.cycleguard     on
cifs.symlinks.enable         on
cifs.tcp_window_size         64240
cifs.trace_dc_connection     off
cifs.trace_login             off
cifs.wins_servers            <edited>

netapp1> options ip
ip.fastpath.enable           on
ip.ipsec.enable              off
ip.match_any_ifaddr          on
ip.path_mtu_discovery.enable on
ip.ping_throttle.alarm_interval 0
ip.ping_throttle.drop_level  10
ip.tcp.newreno.enable        on
ip.tcp.sack.enable           off

If anyone can help, I would really appreciate it. If I need to supply more
information, please just ask.

Thanks,

Tim

jeff.mery | 2 Apr 2004 18:58
Favicon

RE: AntiVirus Solutions


We are running McAfee on all of our filers (F940c + F740) and have had good experience.  We recently upgraded to version 7.1 which allows a single scanner to scan multiple filers.  Prior to this version, the restriction was as mentioned below.  ONTAP 6.4.2P6 (and others I'm sure) also allow us to designate scanners as either primary or secondary which lets us do a poor-man's load-balancing.

With the older version, we had two scanners per filer for redundancy.  Now we have all six scanners set to scan all 3 filers, so we don't alert until at least 3 scanners go off-line at the same time.  They will go off-line when the virus definitions are updated, so we just stagger their updates and never have to worry about it.

Disclaimer....I've never seen the products from other vendors; we're a McAfee shop (...the devil you know...).

Jeff Mery, MCP
National Instruments

-------------------------------------------------------------------------
"Allow me to extol the virtues of the Net Fairy, and of all the fantastic
dorks that make the nice packets go from here to there. Amen."
TB - Penny Arcade
-------------------------------------------------------------------------


"Palmer, Jason (EMEA)" <jason.palmer <at> uk.mci.com>
Sent by: owner-toasters <at> mathworks.com

04/02/2004 10:29 AM

To
"'Jack Lyons'" <jack.lyons <at> martinagency.com>, "'toasters <at> mathworks.com'" <toasters <at> mathworks.com>
cc
Subject
RE: AntiVirus Solutions





Hi Jack,

We are currently using both vendors.  In my view, a mixture of the both allows for coverge, if one of the vendors are a bit slow in reacting and releasing an update to cover a new virus type.

The latest offering from Trend allows for one scanner to scan more than one NAS Appliance, which was a restriction that was becomming a pain to live with.  I have had not seen McAfee for NetApps in action, but from reading the documentation it behaves in a similar way.

Generally we run McAfee on Local client machines and Trend on Servers, and currently we are serving a user base of 5000+ users accross EMEA and have had no problems.

Regards,

Jason
-----------------------------------
Jason Palmer <Team Leader>
Messaging & Storage Implementation
MCI [EMEA]
-----------------------------------
[e]:  jason.palmer <at> uk.mci.com
[i]:   http://www.mci.com/uk
-----------------------------------

-----Original Message-----
From: owner-toasters <at> mathworks.com
[mailto:owner-toasters <at> mathworks.com]On Behalf Of Jack Lyons
Sent: 02 April 2004 14:41
To: 'toasters <at> mathworks.com'
Subject: AntiVirus Solutions

We are looking for a virus scanning solution for our FAS960 with 350 users
accessing via CIFS.

Trend Micro is a little cheaper than McAfee but we are a McAfee shop.  But I
have also heard that Trend Micro is better for NetApp but I can't find any
specifics?

Can anyone share their experience with either product?

Thanks
Jack


This email and its contents may be confidential.  If it is and you are not
the intended recipient, please do not disclose or use the information within
this email or its attachments.  If you have received this email in error,
please delete it immediately.  Thank you.

Jack Lyons | 2 Apr 2004 19:42

RE: CIFS performance Issue

There are a lot of variables involved.

What client are you using for copying the file to and from the NetApp.  Are
you using the Win2k server you are comparing it to?

I think some of what is going is that the Win2k maybe caching the writes to
the file, but when writing to the Filer it is not caching the reads (or if
it is - it isn't doing it efficiently).

I bet if you looked at the defrag map of the Win2k box it would be
moderately fragmented.

Also, for a Gig link, a 30 MB file is not that big.  Try using a 300 MB
file.

We looked at several different solutions using different protocols and CIFS
clients.  Here is a snapshot of my results.

Single Client 
WinXP client writing 300MB file over a GigE link to a Win2k Server: 40MB/s
WinXP client reading 300MB file over a GigE link from a Win2k Server: 26MB/s
MacOSX running the Dave Client writing a 300MB file over a GigE link to a
FAS960: 22MB/s
MacOSX running the Dave Client reading a 300MB file over a GigE link from a
FAS960: 38MB/s

However with 5 clients connected to a gig switch to a single GigE connected
server
WinXP client writing 300MB file over a GigE link to a Win2k Server: 6MB/s
WinXP client reading 300MB file over a GigE link from a Win2k Server: 14MB/s
MacOSX running the Dave Client writing a 300MB file over a GigE link to a
FAS960: 18MB/s
MacOSX running the Dave Client reading a 300MB file over a GigE link from a
FAS960: 23MB/s

My analysis is the Wintel box cannot handle the load at GigE speeds.
I haven't had a chance to try using a TCP Offload Engine NIC which would
probably help.

-----Original Message-----
From: Tim Driggers [mailto:timd <at> birthdayexpress.com] 
Sent: Friday, April 02, 2004 11:59 AM
To: NetApp List (E-mail)
Subject: CIFS performance Issue

Hi All,

I have been playing with an F760 with ONTAP 6.4.1 for about thirty days. I
am having a problem understanding a CIFS transfer rate difference I am
seeing between writing to and from the NetApp.

First, a little background:

The F760 has a X1025B gigabit card (SX fiber) in it, connected to an Extreme
BlackDiamond 6808. The BlackDiamond does -not- have jumbo frames enabled at
this time. The NetApp has full flow control configured.

I am able to copy a single (30GB) file (generated by mkfile in FreeBSD) to
and from the NetApp over NFSv3 at between 92-96mbit consistently, with the
FreeBSD using an NFS mount having a 100mbit link.

I am able to copy the same 30GB file from the NetApp to a Windows 2000
server using CIFS at 130-160mbit consistently. The Win2k server has a
gigabit SX card. When copying the file to the NetApp from the Win2k server,
I am seeing a maximum throughput of 69mbit, and usually it settles around
33-40mbit. I am monitoring this transfer rate using 'sh port utillization'
on the BlackDiamond. I have tested this on three different Win2k boxes, with
nearly identical results. I have also followed instructions on NetApp's
website on how to 'improve' performance through registry edits, with no
apparent result (positive or negative). I have tried three different
flowcontrol settings on the Win2k cards (send, recieve and full) - again
with no change in performance.

I'm thrilled with the NFS performance, but we are a windows shop. I need to
get performance increased on the CIFS writes to the NetApp if it's possible.

I have tried every tweak I could find, and nothing seems to change the rate
at which I can write to the NetApp via CIFS. I have included some NetApp
information:

 slot 8: Gigabit Ethernet Controller II
 e8 MAC Address: 00:03:47:25:36:6a (auto-1000sx-fd-up)
 slot 9: NVRAM
 Memory Size:        32 MB

netapp1> options cifs
cifs.audit.autosave.file.extension
cifs.audit.autosave.file.limit 0
cifs.audit.autosave.onsize.enable off
cifs.audit.autosave.onsize.threshold 500k
cifs.audit.autosave.ontime.enable off
cifs.audit.autosave.ontime.interval
cifs.audit.enable            off
cifs.audit.file_access_events.enable on
cifs.audit.logon_events.enable on
cifs.audit.logsize           524288
cifs.audit.saveas            /etc/log/adtlog.evt
cifs.bypass_traverse_checking on
cifs.comment
cifs.guest_account
cifs.home_dir
cifs.home_dir_namestyle      ntname
cifs.home_dirs_public_for_admin on
cifs.idle_timeout            1800
cifs.max_mpx                 50
cifs.netbios_aliases
cifs.netbios_over_tcp.enable on
cifs.nfs_root_ignore_acl     on
cifs.oplocks.enable          off
cifs.oplocks.opendelta       8
cifs.per_client_stats.enable off
cifs.perm_check_ro_del_ok    on
cifs.perm_check_use_gid      on
cifs.restrict_anonymous.enable off
cifs.save_case               on
cifs.scopeid
cifs.search_domains
cifs.show_snapshot           off
cifs.shutdown_msg_level      2
cifs.sidcache.enable         on
cifs.sidcache.lifetime       1440
cifs.snapshot_file_folding.enable off
cifs.symlinks.cycleguard     on
cifs.symlinks.enable         on
cifs.tcp_window_size         64240
cifs.trace_dc_connection     off
cifs.trace_login             off
cifs.wins_servers            <edited>

netapp1> options ip
ip.fastpath.enable           on
ip.ipsec.enable              off
ip.match_any_ifaddr          on
ip.path_mtu_discovery.enable on
ip.ping_throttle.alarm_interval 0
ip.ping_throttle.drop_level  10
ip.tcp.newreno.enable        on
ip.tcp.sack.enable           off

If anyone can help, I would really appreciate it. If I need to supply more
information, please just ask.

Thanks,

Tim

This email and its contents may be confidential.  If it is and you are not
the intended recipient, please do not disclose or use the information within
this email or its attachments.  If you have received this email in error,
please delete it immediately.  Thank you.

Tim Driggers | 5 Apr 2004 02:57

RE: CIFS performance Issue

Hi Jack,

I am using the same win2k server to copy to/from the NetApp and to/from
another Win2k server. The only difference is which interface is used (the
Win2k server has 100mbit and GigE to different vlans).  I am actually
transferring a 30 gigabyte file, not 30 megabyte. Your suggestion to
defragment the Win2k box was valid, as the test server was slightly
fragmented. I did a quick analysis after the defrag and this is what I
found:

Win2k server writing 30GB file over a 100mbit link to a Win2k Server:
12.2MB/sec (link saturated)
Win2k server reading 30GB file over a 100mbit link from a Win2k Server:
12.13MB/sec (link saturated)
Win2k server writing 30GB file over a GigE link to a NetApp 760: 7MB/sec
Win2k server reading 30GB file over a GigE link from a NetApp 760: 25MB/sec

note: these are the best readings after playing with several Win2k gigE
settings  (including your suggestion of TCP offload).  I guess my question
is, should I expect better performance from the NetApp? 

-----Original Message-----
From: Jack Lyons [mailto:jack.lyons <at> martinagency.com]
Sent: Friday, April 02, 2004 9:43 AM
To: 'Tim Driggers'; 'NetApp List (E-mail)'
Subject: RE: CIFS performance Issue

There are a lot of variables involved.

What client are you using for copying the file to and from the NetApp.  Are
you using the Win2k server you are comparing it to?

I think some of what is going is that the Win2k maybe caching the writes to
the file, but when writing to the Filer it is not caching the reads (or if
it is - it isn't doing it efficiently).

I bet if you looked at the defrag map of the Win2k box it would be
moderately fragmented.

Also, for a Gig link, a 30 MB file is not that big.  Try using a 300 MB
file.

We looked at several different solutions using different protocols and CIFS
clients.  Here is a snapshot of my results.

Single Client 
WinXP client writing 300MB file over a GigE link to a Win2k Server: 40MB/s
WinXP client reading 300MB file over a GigE link from a Win2k Server: 26MB/s
MacOSX running the Dave Client writing a 300MB file over a GigE link to a
FAS960: 22MB/s
MacOSX running the Dave Client reading a 300MB file over a GigE link from a
FAS960: 38MB/s

However with 5 clients connected to a gig switch to a single GigE connected
server
WinXP client writing 300MB file over a GigE link to a Win2k Server: 6MB/s
WinXP client reading 300MB file over a GigE link from a Win2k Server: 14MB/s
MacOSX running the Dave Client writing a 300MB file over a GigE link to a
FAS960: 18MB/s
MacOSX running the Dave Client reading a 300MB file over a GigE link from a
FAS960: 23MB/s

My analysis is the Wintel box cannot handle the load at GigE speeds.
I haven't had a chance to try using a TCP Offload Engine NIC which would
probably help.

-----Original Message-----
From: Tim Driggers [mailto:timd <at> birthdayexpress.com] 
Sent: Friday, April 02, 2004 11:59 AM
To: NetApp List (E-mail)
Subject: CIFS performance Issue

Hi All,

I have been playing with an F760 with ONTAP 6.4.1 for about thirty days. I
am having a problem understanding a CIFS transfer rate difference I am
seeing between writing to and from the NetApp.

First, a little background:

The F760 has a X1025B gigabit card (SX fiber) in it, connected to an Extreme
BlackDiamond 6808. The BlackDiamond does -not- have jumbo frames enabled at
this time. The NetApp has full flow control configured.

I am able to copy a single (30GB) file (generated by mkfile in FreeBSD) to
and from the NetApp over NFSv3 at between 92-96mbit consistently, with the
FreeBSD using an NFS mount having a 100mbit link.

I am able to copy the same 30GB file from the NetApp to a Windows 2000
server using CIFS at 130-160mbit consistently. The Win2k server has a
gigabit SX card. When copying the file to the NetApp from the Win2k server,
I am seeing a maximum throughput of 69mbit, and usually it settles around
33-40mbit. I am monitoring this transfer rate using 'sh port utillization'
on the BlackDiamond. I have tested this on three different Win2k boxes, with
nearly identical results. I have also followed instructions on NetApp's
website on how to 'improve' performance through registry edits, with no
apparent result (positive or negative). I have tried three different
flowcontrol settings on the Win2k cards (send, recieve and full) - again
with no change in performance.

I'm thrilled with the NFS performance, but we are a windows shop. I need to
get performance increased on the CIFS writes to the NetApp if it's possible.

I have tried every tweak I could find, and nothing seems to change the rate
at which I can write to the NetApp via CIFS. I have included some NetApp
information:

 slot 8: Gigabit Ethernet Controller II
 e8 MAC Address: 00:03:47:25:36:6a (auto-1000sx-fd-up)
 slot 9: NVRAM
 Memory Size:        32 MB

netapp1> options cifs
cifs.audit.autosave.file.extension
cifs.audit.autosave.file.limit 0
cifs.audit.autosave.onsize.enable off
cifs.audit.autosave.onsize.threshold 500k
cifs.audit.autosave.ontime.enable off
cifs.audit.autosave.ontime.interval
cifs.audit.enable            off
cifs.audit.file_access_events.enable on
cifs.audit.logon_events.enable on
cifs.audit.logsize           524288
cifs.audit.saveas            /etc/log/adtlog.evt
cifs.bypass_traverse_checking on
cifs.comment
cifs.guest_account
cifs.home_dir
cifs.home_dir_namestyle      ntname
cifs.home_dirs_public_for_admin on
cifs.idle_timeout            1800
cifs.max_mpx                 50
cifs.netbios_aliases
cifs.netbios_over_tcp.enable on
cifs.nfs_root_ignore_acl     on
cifs.oplocks.enable          off
cifs.oplocks.opendelta       8
cifs.per_client_stats.enable off
cifs.perm_check_ro_del_ok    on
cifs.perm_check_use_gid      on
cifs.restrict_anonymous.enable off
cifs.save_case               on
cifs.scopeid
cifs.search_domains
cifs.show_snapshot           off
cifs.shutdown_msg_level      2
cifs.sidcache.enable         on
cifs.sidcache.lifetime       1440
cifs.snapshot_file_folding.enable off
cifs.symlinks.cycleguard     on
cifs.symlinks.enable         on
cifs.tcp_window_size         64240
cifs.trace_dc_connection     off
cifs.trace_login             off
cifs.wins_servers            <edited>

netapp1> options ip
ip.fastpath.enable           on
ip.ipsec.enable              off
ip.match_any_ifaddr          on
ip.path_mtu_discovery.enable on
ip.ping_throttle.alarm_interval 0
ip.ping_throttle.drop_level  10
ip.tcp.newreno.enable        on
ip.tcp.sack.enable           off

If anyone can help, I would really appreciate it. If I need to supply more
information, please just ask.

Thanks,

Tim

This email and its contents may be confidential.  If it is and you are not
the intended recipient, please do not disclose or use the information within
this email or its attachments.  If you have received this email in error,
please delete it immediately.  Thank you.

Scholz Wolfgang | 5 Apr 2004 11:11

AW: AntiVirus Solutions

hi everybody,

we are using trendmicro to scan our filer for about 8 months now without
major issues. the only very annoying thing is that the error message box
presented to the client in case of an infection is not customizable. the
error message that comes from the trendmicro scanner is really unusable
(it´s the complete path to the file which can be very very long) .

regards

wolfgang

> -----Ursprüngliche Nachricht-----
> Von: Jack Lyons [mailto:jack.lyons <at> martinagency.com] 
> Gesendet: Freitag, 2. April 2004 15:41
> An: 'toasters <at> mathworks.com'
> Betreff: AntiVirus Solutions
> 
> 
> We are looking for a virus scanning solution for our FAS960 
> with 350 users accessing via CIFS.
> 
> Trend Micro is a little cheaper than McAfee but we are a 
> McAfee shop.  But I have also heard that Trend Micro is 
> better for NetApp but I can't find any specifics?
> 
> Can anyone share their experience with either product?
> 
> Thanks
> Jack
> 
> 
> 
> This email and its contents may be confidential.  If it is 
> and you are not the intended recipient, please do not 
> disclose or use the information within this email or its 
> attachments.  If you have received this email in error, 
> please delete it immediately.  Thank you.
> 
> 

Stephane Bentebba | 5 Apr 2004 11:45
Picon

Re: CIFS performance Issue

the volume onto / from which you read / write is composed of at least 6 
disks, right ?

Tim Driggers wrote:

>Hi Jack,
>
>
>I am using the same win2k server to copy to/from the NetApp and to/from
>another Win2k server. The only difference is which interface is used (the
>Win2k server has 100mbit and GigE to different vlans).  I am actually
>transferring a 30 gigabyte file, not 30 megabyte. Your suggestion to
>defragment the Win2k box was valid, as the test server was slightly
>fragmented. I did a quick analysis after the defrag and this is what I
>found:
>
>Win2k server writing 30GB file over a 100mbit link to a Win2k Server:
>12.2MB/sec (link saturated)
>Win2k server reading 30GB file over a 100mbit link from a Win2k Server:
>12.13MB/sec (link saturated)
>Win2k server writing 30GB file over a GigE link to a NetApp 760: 7MB/sec
>Win2k server reading 30GB file over a GigE link from a NetApp 760: 25MB/sec
>
>note: these are the best readings after playing with several Win2k gigE
>settings  (including your suggestion of TCP offload).  I guess my question
>is, should I expect better performance from the NetApp? 
>
>-----Original Message-----
>From: Jack Lyons [mailto:jack.lyons <at> martinagency.com]
>Sent: Friday, April 02, 2004 9:43 AM
>To: 'Tim Driggers'; 'NetApp List (E-mail)'
>Subject: RE: CIFS performance Issue
>
>
>There are a lot of variables involved.
>
>What client are you using for copying the file to and from the NetApp.  Are
>you using the Win2k server you are comparing it to?
>
>I think some of what is going is that the Win2k maybe caching the writes to
>the file, but when writing to the Filer it is not caching the reads (or if
>it is - it isn't doing it efficiently).
>
>I bet if you looked at the defrag map of the Win2k box it would be
>moderately fragmented.
>
>Also, for a Gig link, a 30 MB file is not that big.  Try using a 300 MB
>file.
>
>We looked at several different solutions using different protocols and CIFS
>clients.  Here is a snapshot of my results.
>
>Single Client 
>WinXP client writing 300MB file over a GigE link to a Win2k Server: 40MB/s
>WinXP client reading 300MB file over a GigE link from a Win2k Server: 26MB/s
>MacOSX running the Dave Client writing a 300MB file over a GigE link to a
>FAS960: 22MB/s
>MacOSX running the Dave Client reading a 300MB file over a GigE link from a
>FAS960: 38MB/s
>
>However with 5 clients connected to a gig switch to a single GigE connected
>server
>WinXP client writing 300MB file over a GigE link to a Win2k Server: 6MB/s
>WinXP client reading 300MB file over a GigE link from a Win2k Server: 14MB/s
>MacOSX running the Dave Client writing a 300MB file over a GigE link to a
>FAS960: 18MB/s
>MacOSX running the Dave Client reading a 300MB file over a GigE link from a
>FAS960: 23MB/s
>
>My analysis is the Wintel box cannot handle the load at GigE speeds.
>I haven't had a chance to try using a TCP Offload Engine NIC which would
>probably help.
>
>
>
>
>-----Original Message-----
>From: Tim Driggers [mailto:timd <at> birthdayexpress.com] 
>Sent: Friday, April 02, 2004 11:59 AM
>To: NetApp List (E-mail)
>Subject: CIFS performance Issue
>
>Hi All,
>
>I have been playing with an F760 with ONTAP 6.4.1 for about thirty days. I
>am having a problem understanding a CIFS transfer rate difference I am
>seeing between writing to and from the NetApp.
>
>First, a little background:
>
>The F760 has a X1025B gigabit card (SX fiber) in it, connected to an Extreme
>BlackDiamond 6808. The BlackDiamond does -not- have jumbo frames enabled at
>this time. The NetApp has full flow control configured.
>
>I am able to copy a single (30GB) file (generated by mkfile in FreeBSD) to
>and from the NetApp over NFSv3 at between 92-96mbit consistently, with the
>FreeBSD using an NFS mount having a 100mbit link.
>
>I am able to copy the same 30GB file from the NetApp to a Windows 2000
>server using CIFS at 130-160mbit consistently. The Win2k server has a
>gigabit SX card. When copying the file to the NetApp from the Win2k server,
>I am seeing a maximum throughput of 69mbit, and usually it settles around
>33-40mbit. I am monitoring this transfer rate using 'sh port utillization'
>on the BlackDiamond. I have tested this on three different Win2k boxes, with
>nearly identical results. I have also followed instructions on NetApp's
>website on how to 'improve' performance through registry edits, with no
>apparent result (positive or negative). I have tried three different
>flowcontrol settings on the Win2k cards (send, recieve and full) - again
>with no change in performance.
>
>I'm thrilled with the NFS performance, but we are a windows shop. I need to
>get performance increased on the CIFS writes to the NetApp if it's possible.
>
>I have tried every tweak I could find, and nothing seems to change the rate
>at which I can write to the NetApp via CIFS. I have included some NetApp
>information:
>
>
> slot 8: Gigabit Ethernet Controller II
> e8 MAC Address: 00:03:47:25:36:6a (auto-1000sx-fd-up)
> slot 9: NVRAM
> Memory Size:        32 MB
>
>netapp1> options cifs
>cifs.audit.autosave.file.extension
>cifs.audit.autosave.file.limit 0
>cifs.audit.autosave.onsize.enable off
>cifs.audit.autosave.onsize.threshold 500k
>cifs.audit.autosave.ontime.enable off
>cifs.audit.autosave.ontime.interval
>cifs.audit.enable            off
>cifs.audit.file_access_events.enable on
>cifs.audit.logon_events.enable on
>cifs.audit.logsize           524288
>cifs.audit.saveas            /etc/log/adtlog.evt
>cifs.bypass_traverse_checking on
>cifs.comment
>cifs.guest_account
>cifs.home_dir
>cifs.home_dir_namestyle      ntname
>cifs.home_dirs_public_for_admin on
>cifs.idle_timeout            1800
>cifs.max_mpx                 50
>cifs.netbios_aliases
>cifs.netbios_over_tcp.enable on
>cifs.nfs_root_ignore_acl     on
>cifs.oplocks.enable          off
>cifs.oplocks.opendelta       8
>cifs.per_client_stats.enable off
>cifs.perm_check_ro_del_ok    on
>cifs.perm_check_use_gid      on
>cifs.restrict_anonymous.enable off
>cifs.save_case               on
>cifs.scopeid
>cifs.search_domains
>cifs.show_snapshot           off
>cifs.shutdown_msg_level      2
>cifs.sidcache.enable         on
>cifs.sidcache.lifetime       1440
>cifs.snapshot_file_folding.enable off
>cifs.symlinks.cycleguard     on
>cifs.symlinks.enable         on
>cifs.tcp_window_size         64240
>cifs.trace_dc_connection     off
>cifs.trace_login             off
>cifs.wins_servers            <edited>
>
>netapp1> options ip
>ip.fastpath.enable           on
>ip.ipsec.enable              off
>ip.match_any_ifaddr          on
>ip.path_mtu_discovery.enable on
>ip.ping_throttle.alarm_interval 0
>ip.ping_throttle.drop_level  10
>ip.tcp.newreno.enable        on
>ip.tcp.sack.enable           off
>
>
>If anyone can help, I would really appreciate it. If I need to supply more
>information, please just ask.
>
>
>Thanks,
>
>
>Tim
>
>
>This email and its contents may be confidential.  If it is and you are not
>the intended recipient, please do not disclose or use the information within
>this email or its attachments.  If you have received this email in error,
>please delete it immediately.  Thank you.
>
>
>  
>

Jack Lyons | 5 Apr 2004 15:16

RE: CIFS performance Issue

Not sure what version of Data OnTap you are running but have you tried
running netdiag to show any lower layer errors.  Also, try running 
sysstat -s 1 to show "real-time" performance stats.  We evaluated a FAS880
initially and I think the CIFS protocol is more CPU intensive than NFS and
when the CPU >99% we started dropping a lot of packets and saw crappy
numbers.

-----Original Message-----
From: Tim Driggers [mailto:timd <at> birthdayexpress.com] 
Sent: Sunday, April 04, 2004 8:58 PM
To: 'Jack Lyons'; Tim Driggers; 'NetApp List (E-mail)'
Subject: RE: CIFS performance Issue

Hi Jack,

I am using the same win2k server to copy to/from the NetApp and to/from
another Win2k server. The only difference is which interface is used (the
Win2k server has 100mbit and GigE to different vlans).  I am actually
transferring a 30 gigabyte file, not 30 megabyte. Your suggestion to
defragment the Win2k box was valid, as the test server was slightly
fragmented. I did a quick analysis after the defrag and this is what I
found:

Win2k server writing 30GB file over a 100mbit link to a Win2k Server:
12.2MB/sec (link saturated)
Win2k server reading 30GB file over a 100mbit link from a Win2k Server:
12.13MB/sec (link saturated)
Win2k server writing 30GB file over a GigE link to a NetApp 760: 7MB/sec
Win2k server reading 30GB file over a GigE link from a NetApp 760: 25MB/sec

note: these are the best readings after playing with several Win2k gigE
settings  (including your suggestion of TCP offload).  I guess my question
is, should I expect better performance from the NetApp? 

-----Original Message-----
From: Jack Lyons [mailto:jack.lyons <at> martinagency.com]
Sent: Friday, April 02, 2004 9:43 AM
To: 'Tim Driggers'; 'NetApp List (E-mail)'
Subject: RE: CIFS performance Issue

There are a lot of variables involved.

What client are you using for copying the file to and from the NetApp.  Are
you using the Win2k server you are comparing it to?

I think some of what is going is that the Win2k maybe caching the writes to
the file, but when writing to the Filer it is not caching the reads (or if
it is - it isn't doing it efficiently).

I bet if you looked at the defrag map of the Win2k box it would be
moderately fragmented.

Also, for a Gig link, a 30 MB file is not that big.  Try using a 300 MB
file.

We looked at several different solutions using different protocols and CIFS
clients.  Here is a snapshot of my results.

Single Client 
WinXP client writing 300MB file over a GigE link to a Win2k Server: 40MB/s
WinXP client reading 300MB file over a GigE link from a Win2k Server: 26MB/s
MacOSX running the Dave Client writing a 300MB file over a GigE link to a
FAS960: 22MB/s
MacOSX running the Dave Client reading a 300MB file over a GigE link from a
FAS960: 38MB/s

However with 5 clients connected to a gig switch to a single GigE connected
server
WinXP client writing 300MB file over a GigE link to a Win2k Server: 6MB/s
WinXP client reading 300MB file over a GigE link from a Win2k Server: 14MB/s
MacOSX running the Dave Client writing a 300MB file over a GigE link to a
FAS960: 18MB/s
MacOSX running the Dave Client reading a 300MB file over a GigE link from a
FAS960: 23MB/s

My analysis is the Wintel box cannot handle the load at GigE speeds.
I haven't had a chance to try using a TCP Offload Engine NIC which would
probably help.

-----Original Message-----
From: Tim Driggers [mailto:timd <at> birthdayexpress.com] 
Sent: Friday, April 02, 2004 11:59 AM
To: NetApp List (E-mail)
Subject: CIFS performance Issue

Hi All,

I have been playing with an F760 with ONTAP 6.4.1 for about thirty days. I
am having a problem understanding a CIFS transfer rate difference I am
seeing between writing to and from the NetApp.

First, a little background:

The F760 has a X1025B gigabit card (SX fiber) in it, connected to an Extreme
BlackDiamond 6808. The BlackDiamond does -not- have jumbo frames enabled at
this time. The NetApp has full flow control configured.

I am able to copy a single (30GB) file (generated by mkfile in FreeBSD) to
and from the NetApp over NFSv3 at between 92-96mbit consistently, with the
FreeBSD using an NFS mount having a 100mbit link.

I am able to copy the same 30GB file from the NetApp to a Windows 2000
server using CIFS at 130-160mbit consistently. The Win2k server has a
gigabit SX card. When copying the file to the NetApp from the Win2k server,
I am seeing a maximum throughput of 69mbit, and usually it settles around
33-40mbit. I am monitoring this transfer rate using 'sh port utillization'
on the BlackDiamond. I have tested this on three different Win2k boxes, with
nearly identical results. I have also followed instructions on NetApp's
website on how to 'improve' performance through registry edits, with no
apparent result (positive or negative). I have tried three different
flowcontrol settings on the Win2k cards (send, recieve and full) - again
with no change in performance.

I'm thrilled with the NFS performance, but we are a windows shop. I need to
get performance increased on the CIFS writes to the NetApp if it's possible.

I have tried every tweak I could find, and nothing seems to change the rate
at which I can write to the NetApp via CIFS. I have included some NetApp
information:

 slot 8: Gigabit Ethernet Controller II
 e8 MAC Address: 00:03:47:25:36:6a (auto-1000sx-fd-up)
 slot 9: NVRAM
 Memory Size:        32 MB

netapp1> options cifs
cifs.audit.autosave.file.extension
cifs.audit.autosave.file.limit 0
cifs.audit.autosave.onsize.enable off
cifs.audit.autosave.onsize.threshold 500k
cifs.audit.autosave.ontime.enable off
cifs.audit.autosave.ontime.interval
cifs.audit.enable            off
cifs.audit.file_access_events.enable on
cifs.audit.logon_events.enable on
cifs.audit.logsize           524288
cifs.audit.saveas            /etc/log/adtlog.evt
cifs.bypass_traverse_checking on
cifs.comment
cifs.guest_account
cifs.home_dir
cifs.home_dir_namestyle      ntname
cifs.home_dirs_public_for_admin on
cifs.idle_timeout            1800
cifs.max_mpx                 50
cifs.netbios_aliases
cifs.netbios_over_tcp.enable on
cifs.nfs_root_ignore_acl     on
cifs.oplocks.enable          off
cifs.oplocks.opendelta       8
cifs.per_client_stats.enable off
cifs.perm_check_ro_del_ok    on
cifs.perm_check_use_gid      on
cifs.restrict_anonymous.enable off
cifs.save_case               on
cifs.scopeid
cifs.search_domains
cifs.show_snapshot           off
cifs.shutdown_msg_level      2
cifs.sidcache.enable         on
cifs.sidcache.lifetime       1440
cifs.snapshot_file_folding.enable off
cifs.symlinks.cycleguard     on
cifs.symlinks.enable         on
cifs.tcp_window_size         64240
cifs.trace_dc_connection     off
cifs.trace_login             off
cifs.wins_servers            <edited>

netapp1> options ip
ip.fastpath.enable           on
ip.ipsec.enable              off
ip.match_any_ifaddr          on
ip.path_mtu_discovery.enable on
ip.ping_throttle.alarm_interval 0
ip.ping_throttle.drop_level  10
ip.tcp.newreno.enable        on
ip.tcp.sack.enable           off

If anyone can help, I would really appreciate it. If I need to supply more
information, please just ask.

Thanks,

Tim

This email and its contents may be confidential.  If it is and you are not
the intended recipient, please do not disclose or use the information within
this email or its attachments.  If you have received this email in error,
please delete it immediately.  Thank you.

This email and its contents may be confidential.  If it is and you are not
the intended recipient, please do not disclose or use the information within
this email or its attachments.  If you have received this email in error,
please delete it immediately.  Thank you.


Gmane