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