In conclusion, how does Samba/Linux compare with MS Windows file and print? About the same as the comparison between...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
"chalk and cheese!" Now, do not get me started on that one!
FOR MORE INFORMATION:
- FEEDBACK: Do the Samba numbers speak for themselves?
Send your thoughts to Site Editor Jan Stafford
With MS Windows file and print serving the costs of ownership include:
- The cost of the OS itself
- The cost OS Client Access Licenses (CALs)
- Larger and more costly hardware
- Maintenance of the above
- Staffing (Generally, staff has to be on-site to reboot systems.)
- Higher user support demand due to more issues with reliability
- The O/S is free or much lower cost
- There are NO CALs
- Hardware performs better and lasts longer (lower cost)
- Maintenance is minimal and updates are less demanding
- Staffing can readily be outsourced (lower manpower costs)
- Users are generally happier (have fewer problems)
Every system has inherent design limitations that become its bottleneck. Generally speaking, the slowest component that is involved in the services being evaluated will be the primary limiting factor in the benchmarks obtained. Workloads that are used to measure scalability should be reflective of the type of work that the file server will be expected to handle.
So, this results in clear limitations when comparing benchmark figures and goes a long way toward explaining some of the wide gaps that have been reported in published Samba versus Windows file serving performance reports.
On a system that has a file I/O capacity of 450MBytes/sec, 1 gigabit ethernet, and 1 Gigabyte of RAM:
- MS Windows 2000 Advanced Server:
FAT32 file system: Peak I/O 37.6 MB/s at 20 clients
NTFS file system: Peak I/O 27 MB/s at 10 clients
- Samba 2.2.5 on Linux 2.4.18:
Ext2 file system: Peak I/O 36 MB/s at 5 clients
But these figures do not tell the complete story. With Windows 2000 Advanced Server, the FAT32 system failed at 32 clients, the NTFS file system I/O dropped to 12 MB/s at 60 concurrent clients. By comparison, the Samba on Linux system still delivered I/O at 29 MB/s with 60 concurrent clients. Each client was running a simulated Ziff-Davis NetBench test. What conclusions can IT shops draw from comparison tests?
There is anecdotal information that a Samba server can outperform MS Windows 2000 Server and deliver more than five times the aggregate I/O, but would the test conditions parallel your environment? If not, then what do the results mean?
Here are some rough guidelines for system configuration design: MS Windows 2000 requires approximately 330KB memory per concurrent client. Samba 2.2.5 on Linux requires approximately 460KB memory per concurrent client.
Given that sufficient memory has been provided, that there are no other factors that will limit throughput, and given identical hardware, Samba will support up to 10 times the number of concurrent users from the same machine as MS Windows 2000 Advanced Server and still deliver a higher aggregate I/O volume. In the real world this may not be realized.
In conclusion, Samba scales very well. We know of large sites that support up to 3,000 users off one machine. We know that Samba runs on any Unix platform no matter what CPU architecture. MS Windows 2000 runs only on Intel CPUs today -- and that restricts it to smaller systems than Samba can run on. How does the Linux/Samba team compare to Windows 2000 in reliability?
Based on rough metrics from past Samba mailing-list postings, it would seem that about 30% of the Samba installed base runs a near current release. About 30% run a version of samba that is up to 1 generation out of date (ie: current version is 2.2.7a, 2.0.x is the immediately prior generation) and about 40% of the installed base is more than 1 generation behind. Many sites do not update until there is a compelling reason to do so. The most common reason for updating is the addition of new or updated MS Windows machines to the network that bring about a breakage because of incompatibilities in the later generation MS Windows products or service packs.
Samba sites that want new features may upgrade to a more recent version. Recent new feature additions have attracted great interest. The addition of the Configuration Wizard has helped some sites to provide a more functional MS Windows networking environment. Many sites are now adopting LDAP for user management and as a migration path from MS Windows NT4.
Samba can be shut down and restarted without having to reboot the host server. This means that the cycle time is very short (unlike having to reboot a whole server - something unavoidable in MS Windows).
I know of sites that have had the Samba server constantly on-line for over 400 days. We may talk all we like about 99.999% uptime availability, but Samba regularly delivers that on Unix/Linux.
It is fair to say that Samba updates and fixes can be much less intrusive and disruptive than MS Windows updates tend to be.