Frank Steinmetzger wrote: > Am Sun, Dec 18, 2022 at 09:12:37AM -0600 schrieb Dale: > >>> On Sat, Dec 17, 2022 at 4:42 PM Dale <rdalek1...@gmail.com >>> <mailto:rdalek1...@gmail.com>> wrote: >>> <SNIP> >>>> My reasoning is simple, I'm already familiar with LVM and how to >>> manage it. >>> <SNIP> >>> […] >>> Wipe the machine. You'll be happier. >>> >>> Best wishes, >>> Mark >> Well, I finally got it so I could do a backup. I didn't need a hammer >> but the thought crossed my mind. lol Even tho I now have a 1GB network >> card, it's still really slow. It shows up as a 1GB connection on both >> my Gentoo machine and the NAS machine. This is a example of the speeds >> I'm seeing. Just snippets. >> >> >> 277,193,507 100% 16.18MB/s 0:00:16 >> 519,216,571 100% 18.86MB/s 0:00:26 >> 738,078,565 100% 23.54MB/s 0:00:29 >> >> >> As you can see, the files sizes are large enough it should do better. > Gbit nets at around 116..117 MB/s. > >> When I use iftop, it shows it isn't doing anywhere near the speed it >> should, maybe 1/4th or so. I'd expect at least double or triple that >> speed. In all honesty, I'd think the hard drive would be the limiting >> factor. Even on my Gentoo rig I only get about 50 to 60MBs/sec for >> encrypted drives. I think the encryption slows that down. When copying >> from a plain drive to a plain drive, I get 100MBs/sec or so. >> >> I can't figure out why it is so slow tho. The NAS rig is a 4 core CPU >> and 8GBs of memory. > OK, so you already noticed that encryption slows you down. This won’t happen > with a CPU that has AES instructions (well, and if the encryption you chose > actually uses AES, and not something else like Blowfish). So I guess your > CPU is too old, given your earlier descriptions. > > When I built my NAS in November 2016, I installed a Celeron G1840 at first. > A very affordable (33 €) and frugal CPU (2 cores, 53 W, which were never > actually drawn). I knew it didn’t have AES back then (Intel removed that > limit from Celerons in architectures after Haswell), but from experiments I > knew it would achieve around 150..160 MB/s with LUKS, which was enough for > Gbit ethernet. But not for scrubs, when all HDDs were worked in parallel. So > after a year I did an upgrade after all and bought the smallest and cheapest > CPU that had AES, an i3-41xx. > >> It should have enough horsepower under the hood. >> Maybe it is something I'm not aware of. It is a older rig so maybe it >> isn't SATA's fastest version, maybe even the original or something. I > SATA 2 is 3 Gbit/s, so still not saturated by a single HDD.
This could be a SATA 1. I don't recall the speed of that. Thing is, when I go to a console and use htop, it shows the CPU is maxed out most of the time. It kinda gets busy for a good bit, idle for a short time then back to close to 100%. It has plenty of memory even tho it is caching a lot in memory. It shows less than 1GB actually used by the system itself, not including cache tho. With that info, I suspect the CPU is the bottleneck. It's the only thing that is showing heavy usage. This may have nothing to do with SATA. I suspect it is the encryption that really hits the CPU hard. Also, the CPU temp is good too. I replaced the stock cooler with a larger model. I think it is running around 100F or so. I don't think temps are a issue. > > Network transfers are single-core work. If it is really such an old machine, > I guess the CPU is the bottleneck again. Do you transfer via ssh? If so, use > something else that doesn’t encrypt the transport stream. When I am bound by > CPU in such cases (like with my ancient netbook with an Atom N450), and I > don’t want to set up a file server (that is nowhere near as flexible as ssh > anyways), I use netcat: > > On the receiving end, start a netcat listener and extract from it: > nc -l -p $Portnumber | tar xf - > The portnumber must be any number above 1024, if you’re not root. > > And on the sender, pack all your stuff into a tar (uncompressed!, since > videos aren’t compressible further and it will bog down the CPU again) and > pipe it to the receiver: > tar cf - * | nc $Destination_IP $Portnumber > > Once the client is done, press Ctrl+C on the receiver. > > Or maybe use rsync with the rsync-protocol instead of ssh. That’ll be more > flexible, because the tar-and-nc method doesn’t know about existing files on > the receiving end. (But I’ve never tested that approach.) > Since this is local, I just use rsync to do my backups. I did have to change the options a bit. It seems TrueNAS doesn't like some of the permissions or something. Anyway, I found a way that works. As I mentioned above, I think this is a CPU issue. It does show that I need to see how encryption will work with the CPU on a Raspberry Pi tho. Maybe the newer ones will have the needed support and not cause problems. While at it, the dashboard CPU info doesn't really show the CPU maxing out as well as htop does. If someone thinks their TrueNAS box is slow, may want to use htop or similar tools to check things. The memory is pretty accurate tho. Thing about htop, it shows how busy each core is and that is usually most helpful. Some processes only use one core, even tho some have left the single core CPUs behind long ago. lol This is gonna take a while. :/ Dale :-) :-)
