There are ECC SODIMMs. Kingston. 8Gb.
Sent from my iPad using Tapatalk HD
How much are they? Newegg has one(so it claims), but the picture isn't of an SODIMM.
There are ECC SODIMMs. Kingston. 8Gb.
Sent from my iPad using Tapatalk HD
Cant find the E3C224D2I anywhere in my country :-/
Well it uses almost one entire thread... (2 cores, 4 threads) so it hovers a bit under 50/200. Doesn't quite rail it, but close. Makes me glad I picked the i3 over the Pentium since it's got a higher clock rate. Multiple samba connections will use different threads right? It's just that one samba connection is single threaded?How much of one core is CIFS needing to saturate Gb? Just curious how much spare room you get. :)
Thanks for testing it!
Well it uses almost one entire thread... (2 cores, 4 threads) so it hovers a bit under 50/200. Doesn't quite rail it, but close. Makes me glad I picked the i3 over the Pentium since it's got a higher clock rate. Multiple samba connections will use different threads right? It's just that one samba connection is single threaded?
Yes, one thread per smbd process. However, samba spawns a new smbd process for every new CIFS connection. Therefore, multiple cores will not speed up single user operations, but will increase performance in a multi user scenario. For example, right now I see four smbd processes running in parallel on my FreeNAS server.Nope. One thread for the smbd service. And because of how cifs works its been said we shouldn't expect this to change anytime soon.
Yes, one thread per smbd process. However, samba spawns a new smbd process for every new CIFS connection. Therefore, multiple cores will not speed up single user operations, but will increase performance in a multi user scenario. For example, right now I see four smbd processes running in parallel on my FreeNAS server.
Multithreading and Samba
People sometimes tout threads as a uniformly good thing. They are very nice in their place but are quite inappropriate for smbd. nmbd is another matter, and multi-threading it would be very nice.
The short version is that smbd is not multithreaded, and alternative servers that take this approach under Unix (such as Syntax, at the time of writing) suffer tremendous performance penalties and are less robust. nmbd is not threaded either, but this is because it is not possible to do it while keeping code consistent and portable across 35 or more platforms. (This drawback also applies to threading smbd.)
The longer versions is that there are very good reasons for not making smbd multi-threaded. Multi-threading would actually make Samba much slower, less scalable, less portable and much less robust. The fact that we use a separate process for each connection is one of Samba's biggest advantages.
Threading smbd
A few problems that would arise from a threaded smbd are:
- It's not only to create threads instead of processes, but you must care about all variables if they have to be thread specific (currently they would be global).
- if one thread dies (eg. a seg fault) then all threads die. We can immediately throw robustness out the window.
- many of the system calls we make are blocking. Non-blocking equivalents of many calls are either not available or are awkward (and slow) to use. So while we block in one thread all clients are waiting. Imagine if one share is a slow NFS filesystem and the others are fast, we will end up slowing all clients to the speed of NFS.
- you can't run as a different uid in different threads. This means we would have to switch uid/gid on _every_ SMB packet. It would be horrendously slow.
- the per process file descriptor limit would mean that we could only support a limited number of clients.
- we couldn't use the system locking calls as the locking context of fcntl() is a process, not a thread.
The information you pasted is about multithreading, i.e. using multiple threads in single smbd process. That is still a problem. However, samba is using multiple smbd processes for a very long time already.
https://www.samba.org/samba/docs/man/manpages/smbd.8.html:
[PANEL]A session is created whenever a client requests one. Each client gets a copy of the server for each session. This copy then services all connections made by the client during that session. When all connections from its client are closed, the copy of the server for that client terminates.[/PANEL]
You can test it for yourself. When you start samba there's only one smbd process running, but as you start connecting from different clients the number of processes will grow. You can even run smbstatus -p to see which process (PID) is serving which client.
I didn't doubt that they existed... just that they're so uncommon that they are likely very highly priced.
I tested the DualCore Pentium G3220 with 3GHz and about 80mb/s SMB read transfer resulted in about ~18% CPU usage (monitored in 'top'). It's not really GbE saturated but close; I will test a quite faster SSD to saturate the NIC.Well it uses almost one entire thread... (2 cores, 4 threads) so it hovers a bit under 50/200. Doesn't quite rail it, but close. Makes me glad I picked the i3 over the Pentium since it's got a higher clock rate.
Yeah, for some reason I got slower reads than writes (and that's with lz4 compression and RAIDZ2).
I remember reading some things a while back about 4k sector/disk alignment affecting speeds but totally wasn't thinking about it during my setup. Is that still a "thing" that needs to be configured?
I'm starting to realize that... based on what I'm seeing of processor usage I probably could have just gone with the G3220. Oh well. Can't hurt to have a bit more power at my disposal. Right now I run subsonic on another computer that pulls from the FreeNAS box... if I can get subsonic or plex running, maybe I can put the i3 to better use and avoid keeping my i7 machine on.