Does anyone have any experience with SMB signing??
We recently applied a DEBUG version of DoT 6.5.3 to our F760 in order to take advantage of SMB signing - a feature that won't be available until a later release of DoT 7.x - which won't be available for the F760's.
With the SMB signing turned on we are seeing a much higher load on the filer's CPUs. NetApp analyzed some Performance Data and say that the SMB signing module is adding a 30% load to our FILER CPUs.
What would you think? Is SMB signing that CPU intensive or would you think it could be sloppy code?? The performance hit is soo drastic I really have a hard time believing it is anything but bad coding (or maybe a little of both).
NetApp Support's solution was to turn off SMB signing. Of course they were not thinking at all when they said that - because why would anyone apply a DEBUG release of an OS whose only function was to add SMB signing if they did not need SMB signing????
Fortunately we have a new filer waiting for a data migration ... but I have serious concerns as to what this is going to do to my new filer. What does a 30% CPU load increase translate to on a FAS960?? ... 10% ... 15%?? How soon before I have to buy another FILER??
I don't want to drop this ... but NetApp doesn't want to pursue any resolution other than new hardware.
Anyway ... does anyone have any comments / suggestions??
- Scott W.
On Wed, Mar 30, 2005 at 05:19:50PM -0500, Waters, G Scott RDECOM(THE LOG.SEC TEAM) wrote:
Does anyone have any experience with SMB signing??
We recently applied a DEBUG version of DoT 6.5.3 to our F760 in order to take advantage of SMB signing - a feature that won't be available until a later release of DoT 7.x - which won't be available for the F760's.
With the SMB signing turned on we are seeing a much higher load on the filer's CPUs. NetApp analyzed some Performance Data and say that the SMB signing module is adding a 30% load to our FILER CPUs.
What would you think?
<snip>
SMB signing also has a large impact on windows servers, I have heard at least one story from the trenches about clients enabling smb signing with windows patches and the poor bewildered windows server operator wondering why his servers are suddenly so overloaded. So, I would imagine adding encryption would have a significant overhead. You might feel lucky that you know the cause and how to prevent it. I would say it all depends on what the other 70% of your cpu is doing. Also, assuming traffic does not increase alot with a faster filer, the percentage would most likely decrease.
Instead of balking about it in entirety, I would inquire about the applicability of using a hardware crypto card in the netapp to offload this extra load. I'm not an expert on these cards, but if they would provide a benefit, then netapp would just have to code for that too and sell an appropriate card.
SMB signing also has a large impact on windows servers, I have heard at least one story from the trenches about clients enabling smb signing with windows patches and the poor bewildered windows server operator wondering why his servers are suddenly so overloaded. So, I would imagine adding encryption would have a significant overhead. You might feel lucky that you know the cause and how to prevent it. I would say it all depends on what the other 70% of your cpu is doing. Also, assuming traffic does not increase alot with a faster filer, the percentage would most likely decrease.
To be clear, SMB signing is exactly what it says -- a signature, not encryption.
The SMB MAC is essentially an MD5 of { key | SMB packet }. If you think something is odd with NetApp's implementation and you have access to similar hardware it wouldn't be difficult to construct a test case.
-- Luke
--
SMB signing also has a large impact on windows servers, I have heard at least one story from the trenches about clients enabling smb signing with windows patches and the poor bewildered windows server operator wondering why his servers are suddenly so overloaded. So, I would imagine adding encryption would have a significant overhead. You might feel lucky that you know the cause and how to prevent it. I would say it all depends on what the other 70% of your cpu is doing. Also, assuming traffic does not increase alot with a faster filer, the percentage would most likely decrease.
To be clear, SMB signing is exactly what it says -- a signature, not encryption.
The SMB MAC is essentially an MD5 of { key | SMB packet }. If you think something is odd with NetApp's implementation and you have access to similar hardware it wouldn't be difficult to construct a test case.
MD5 is CPU intensive, which is no surprise if you look at the code for it. On my desktop Linux box (Intel P4 1.60GHz) I ran this test of MD5:
time dd if=/dev/zero bs=10240 count=51200 | openssl md5 -hex
51200+0 records in 51200+0 records out d8b61b2c0025919d5321461045c8226f 5.56s real 4.78s user 0.75s system
Then I simply counted the bytes with wc:
time dd if=/dev/zero bs=10240 count=51200 | wc -c
51200+0 records in 51200+0 records out 524288000 0.81s real 0.10s user 0.69s system
So it took about 50 times as much CPU to compute the MD5 checksum as it did to simply count the bytes.
SMB signing could use even more CPU than this test because a MD5 checksum is computed for each SMB packet. In my test only one checksum is computed for one very large input rather than many checksums for many small inputs.
Steve Losen scl@virginia.edu phone: 434-924-0640
University of Virginia ITC Unix Support
-
Adam McDougall -
Luke Howard -
Steve Losen -
Waters, G Scott RDECOM(THE LOG.SEC TEAM)