| mntmn | the imx8mq has CAAM (hardware crypto accelerator) so that is supposed to help with LUKS | 00:00 |
|---|---|---|
| mntmn | but afaik still slower than unencrypted. i will do a benchmark later | 00:00 |
| mntmn | (i run encrypted) | 00:00 |
| chartreuse | Oh okay, I was thinking there was no acceleration so it'd be cutting hard into the CPU usage to be doing LUKS | 00:01 |
| chartreuse | I might end up changing over to LUKS before I end up with too many files on the drive that wiping and migrating would take forever | 00:03 |
| chartreuse | If it can still manage 200MB/s or so it wouldn't be too much of a hit to use for the security gains | 00:03 |
| mntmn | ok i will check later and get back to you | 00:07 |
| chartreuse | Thanks! | 00:08 |
| mntmn | chartreuse: (write test on encrypted nvme partition) | 01:04 |
| mntmn | mntmn@reform:~$ dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc | 01:04 |
| mntmn | 1024+0 records in | 01:04 |
| mntmn | 1024+0 records out | 01:05 |
| mntmn | 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 7.13438 s, 151 MB/s | 01:05 |
| mntmn | read tests: | 01:05 |
| mntmn | Timing cached reads: 1756 MB in 2.00 seconds = 878.45 MB/sec | 01:05 |
| mntmn | Timing buffered disk reads: 692 MB in 3.01 seconds = 230.22 MB/sec | 01:05 |
| mntmn | Timing O_DIRECT cached reads: 454 MB in 2.01 seconds = 226.30 MB/sec | 01:05 |
| mntmn | Timing O_DIRECT disk reads: 726 MB in 3.00 seconds = 241.70 MB/sec | 01:05 |
| chartreuse | What too did you use for the read tests? | 01:06 |
| chartreuse | With the same dd command I'm only getting 164MB/s writes so major performance hit there | 01:07 |
| chartreuse | With bigger block sizes I can get over 220MB/s, so I'm guessing performance is doing just fine with the encryption | 01:08 |
| mntmn | for read i did hdparm -tT | 01:10 |
| mntmn | and then hdparm -tT --direct | 01:11 |
| chartreuse | I'm getting essentially the same numbers there. Probably would be a better test with something like fio that'll try different sizes rather than sequential | 01:11 |
| chartreuse | But looks like little overhead from encryption | 01:11 |
| chartreuse | Timing cached reads: 1676 MB in 2.00 seconds = 837.87 MB/sec | 01:11 |
| chartreuse | Timing buffered disk reads: 704 MB in 3.01 seconds = 234.23 MB/sec | 01:12 |
| chartreuse | Timing O_DIRECT cached reads: 448 MB in 2.01 seconds = 223.32 MB/sec | 01:12 |
| chartreuse | Timing O_DIRECT disk reads: 700 MB in 3.00 seconds = 233.10 MB/sec | 01:12 |
| chartreuse | Might be a cpu overhead doing it, but not any direct performance, so I guess I should give it a try with encrpytion | 01:13 |
| - mjw (QUIT: Quit: Leaving) (~mark@herd.wildebeest.org) | 01:13 | |
| chartreuse | \ls | 01:14 |
| chartreuse | oops XD | 01:14 |
| mntmn | chartreuse: ja surprisingly little | 01:14 |
| mntmn | afaik the bcm in raspi doesn't have hardware support even with similar cores but that makes encryption slow there | 01:15 |
| chartreuse | When I re-ran the test again I got slightly harder numbers but still right the same as what you got | 01:15 |
| mntmn | their arm cores also apparently don't have crypto extensions | 01:16 |
| chartreuse | Did also notice I get some noticable coil whine during the O_DIRECT tests mainly | 01:16 |
| mntmn | (i.e. no AES in the ARM) | 01:16 |
| chartreuse | Kinda a low buzzing sound | 01:16 |
| mntmn | yes, got that too ^^ | 01:16 |
| chartreuse | Yeah, that's what I was concerned with the A53, but if this soc has them that's nice | 01:16 |
| mntmn | almost reminiscent of a spinning disk... | 01:16 |
| mntmn | yeah imx8mq has them | 01:17 |
| chartreuse | Yeah it sounds like rapid head seeking | 01:17 |
| mntmn | it's confusing for sure that a53 is not the same as another a53 | 01:17 |
| chartreuse | Yep. Does the planned a72 or what it was board also have crypto extensions? | 01:18 |
| technomancy | the other day I learned that the switch SoC has four a53 arm cores just sitting on the die but not usable, next to the four a57 cores it actually uses. | 01:18 |
| mntmn | yes | 01:18 |
| mntmn | the chip is ls1028a | 01:18 |
| chartreuse | Kinda the annoyance with ARM even with the same familly name the chips are all different | 01:18 |
| mntmn | which is intended for networking/robotics and stuff | 01:18 |
| chartreuse | Nice. Just a shame the higher core count ones cut the gpu | 01:19 |
| chartreuse | Something like an 8 core A72 would be killer performance wise for this | 01:19 |
| mntmn | yep. might become an option if we find a good low power mobile pcie gpu | 01:19 |
| mntmn | yes i agree | 01:19 |
| mntmn | i could make a 2d fpga gpu but meh | 01:19 |
| chartreuse | Does it have more PCIe lanes on it? Or still the same 1+1 setup? | 01:20 |
| mntmn | depending on what you want to do of course | 01:20 |
| chartreuse | Having hardware video acceleration is nicer than a 2d gpu | 01:20 |
| chartreuse | For some things I'd be fine with just a serial terminal text console :) | 01:20 |
| technomancy | "serial terminal text console" you mean like a receipt printer? | 01:21 |
| mntmn | it has sata and we route that to the slot that is nvme now, and route extra pcie lane to the hdmi connector for egpu shenanigans | 01:21 |
| chartreuse | Not sure if the nvme ssd I have supports falling back to sata or not. | 01:25 |
| chartreuse | I thought the sata ones use a different keying? | 01:25 |
| mntmn | yes but it should fit anyway | 01:26 |
| chartreuse | It'd be nice to keep pcie going to the nvme slot, but if it doesn't have the ports for it I understand | 01:26 |
| mntmn | well, it's still experimental at this point | 01:27 |
| chartreuse | A SATA 3 link would probably be faster than the crippled 1x 1.0 or such link going to it now | 01:27 |
| mntmn | yeah | 01:27 |
| mntmn | as soon as the ddr4 works, i'll test which setups make the most sense | 01:28 |
| chartreuse | Just need an ARM SoC with 2x4 pcie lanes. So the NVME can run flat out | 01:28 |
| mntmn | and in the meantime solve those battery drain issues... | 01:28 |
| mntmn | i was thinking to do a motherboard with som + mxm | 01:29 |
| chartreuse | Yeah. I am also noticing not getting quite the battery life I'd expect from the batteries though I'd need to set up a better monitor on the oled to know for sure | 01:29 |
| mntmn | but need to find some discrete gpu that is not a huge waste of power | 01:29 |
| mntmn | chartreuse: you can monitor the batteries from linux too | 01:29 |
| chartreuse | Highest draw I was seeing on there was 0.34A so with 1800mAh batteries I'd expect just over 5 hours, but got closer to 3 and a bit before I had to plug in at 8% | 01:30 |
| chartreuse | But I guess the cutoff point is probably a bit below the listed capacity | 01:30 |
| chartreuse | 90% of 1800 would be 1620mAh or 4.8hr at that draw | 01:31 |
| chartreuse | I'll setup a linux script to constantly probe and log the consumption, would be interesting to know how the capacity stacks up by integrating the draw | 01:32 |
| mntmn | https://community.mnt.re/t/how-do-you-watch-your-battery-status/280/9 | 01:32 |
| mntmn | ok yeah | 01:33 |
| chartreuse | I've got the keyboard power-down part working. Right now it activates when either the power-off selection has been pressed, or the p key pressed at the menu | 01:33 |
| mntmn | oh awesome! | 01:33 |
| chartreuse | So just need a signal from the LPC that I can use to enter that state. | 01:33 |
| chartreuse | And then the LPC needs to somehow enter it's own power down state that can be woken by te serial port | 01:34 |
| chartreuse | Though what happens when the LPC hard powers off the system due to the battery being low? I presume the keyboard has no idea at the moment | 01:35 |
| chartreuse | Though I thought the backlight turned off | 01:35 |
| chartreuse | That's really the only odd state, I'm sure I could add something to linux to send a command to the keyboard during power-off to enter that state | 01:36 |
| chartreuse | But it'd be easier if the LPC knew the system shutdown | 01:36 |
| mntmn | hmm that's a good point | 01:37 |
| mntmn | yeah the keyboard is currently not informed about this, but we can stick it in the battery status flags that are polled | 01:38 |
| erlehmann | anyone here has reform with encrypted fs? | 01:38 |
| mntmn | erlehmann: yes | 01:38 |
| mntmn | erlehmann: check the log of a few minutes ago! | 01:38 |
| mntmn | we were just benchmarking that | 01:38 |
| chartreuse | Well more "benchmarking" as those don't fully reflect normal conditions | 01:39 |
| erlehmann | benchmarking? | 01:39 |
| chartreuse | Testing the performance compared with non-encrypted nvme | 01:39 |
| erlehmann | o.0 | 01:41 |
| erlehmann | why wouldn't you test LUKS against other *encrypted* devices? | 01:41 |
| erlehmann | i mean answering the question "what is faster, encrypted or unencrypted" is prob not that hard … i just don't get what is actionable from the results | 01:42 |
| erlehmann | but then again i assume there is no io overhead for encrypted devices | 01:43 |
| erlehmann | just cpu overhead | 01:43 |
| chartreuse | To see if the encryption hardware in the cpu is fast enough to deal with the data going to the drive | 01:44 |
| erlehmann | i just can't imagine any situation in which a *benkmark* would be the thing that would tell you that the encryption is too slow | 01:44 |
| erlehmann | you either notice it during normal operations or not at all | 01:44 |
| erlehmann | am i missing something? | 01:44 |
| mntmn | erlehmann: on raspberry pi the encryption is very slow | 01:45 |
| chartreuse | And in this testing, there wasn't any different in peek performance | 01:45 |
| chartreuse | So even if it is increasing CPU load, it's not bottlenecking the drive | 01:45 |
| mntmn | erlehmann: because the cores lack hardware crypto extensions | 01:45 |
| chartreuse | Really the bottle neck is the single pcie lane | 01:45 |
| erlehmann | mntmn raspi has no AES accel right | 01:45 |
| mntmn | erlehmann: so people think cortex a53 is the problem | 01:45 |
| mntmn | erlehmann: correct | 01:45 |
| mntmn | erlehmann: also imx8mq has CAAM | 01:45 |
| chartreuse | My nVME drive is capable of 2-3GB/s and gets 200-300MB/s in the reform | 01:45 |
| mntmn | naja i am afk for a while watching ds9 | 01:46 |
| chartreuse | It's worth testing to see just how much impact having encryption enable affects drive performance | 01:46 |
| chartreuse | Since the benchmarking is going through the encryption layer | 01:46 |
| chartreuse | (At least the dd one did) | 01:47 |
| erlehmann | chartreuse i'd rather write a bunch of small files though | 01:47 |
| chartreuse | That's why I recommened fio over what mntmn did, but it takes a ton of options to set up nicely | 01:47 |
| erlehmann | make a tarball of a rootfs and extract it to a folder on the encrypted device | 01:47 |
| erlehmann | the tarball does not take a ton of options though ;) | 01:47 |
| chartreuse | Because it'll do stuff like reads and writes at different sizes | 01:48 |
| erlehmann | ok raspberry pi is a joke | 01:48 |
| erlehmann | https://github.com/keks24/raspberry-pi-luks/issues/2 | 01:48 |
| erlehmann | > Without encryption: ~200MB/s write and ~250MB/s read. | 01:48 |
| erlehmann | With encryption: ~85MBs/s write and ~55MB/s read. (WRITE FASTER THAN READ) | 01:48 |
| chartreuse | Yes the CPU is the bottleneck there | 01:48 |
| erlehmann | > stick to xchacha12 or xchacha20, since these encryption methods are fast and software-based. The ARM CPU does not support hardware-accelerated AES encryption | 01:49 |
| erlehmann | hmmmmmmm | 01:49 |
| erlehmann | which algos did you test anyway | 01:49 |
| chartreuse | All we did was a quick test between mntmn's setup which is presumably just the LUKS default and my currently unencrypted | 01:50 |
| chartreuse | Nothing scientific, just giving me some idea if redoing mine as encrpyted would have a dramatic performance impact or not | 01:50 |
| chartreuse | The CPU in the reform does have crypto extensions unlike the Pi so those recommendations wouldn't be the fastest here potentially | 01:51 |
| erlehmann | chartreuse the issue contains ways to figure out the idea | 01:52 |
| erlehmann | chartreuse i have never seen a system being dog slow bc of crypto, but i guess i have never used a ranzberry pi for long | 01:52 |
| chartreuse | I'm not too too concerned about the speeds, just as long as they're decent enough | 01:52 |
| chartreuse | One of my old laptops was a low power core2duo and never had trouple with the encryption on the drive there with a sata ssd on a sata 2 port | 01:54 |
| chartreuse | But that was the slowest machine I think I bothered on. But didn't have a big impact | 01:54 |
| chartreuse | I'd imagine it'd be more on single core system like a P4 without crypto extensions. Eating a fair bit of CPU to keep up if it can | 01:54 |
| erlehmann | i am typing from a T60 | 02:00 |
| erlehmann | ; </proc/cpuinfo grep 'model name' | 02:00 |
| erlehmann | model name: Intel(R) Core(TM) Duo CPU T2400 @ 1.83GHz | 02:00 |
| erlehmann | model name: Intel(R) Core(TM) Duo CPU T2400 @ 1.83GHz | 02:00 |
| technomancy | I wonder if you could mod a reform to charge off one of the old thinkpad big barrel chargers | 02:01 |
| technomancy | I've got like twelve of those | 02:01 |
| swivel | i used to have a lot of those but they keep failing near the barrel connector, i need to source a bunch of replacement cords to repair them | 02:15 |
| technomancy | I had two of them fail, then I just started wrapping them in electrical tape and that prevented the failure | 02:17 |
| technomancy | I should do that with my reform charger too I guess | 02:17 |
| swivel | i think in my case it's due to the hot environment i've been using them in while i rebuild this desert cabin over the past few years | 02:18 |
| swivel | everything rubber and plastic gets softened and fails faster it seems | 02:18 |
| technomancy | I used the ones that failed for me in Thailand so yeah that adds up | 02:18 |
| technomancy | but they didn't fail till after I moved back to the states | 02:19 |
| swivel | hmm.. i have noticed that the flexibility of the cord is changed after going through the hot season, like it's baked out some of the oils | 02:20 |
| swivel | either way it's getting annoying, i'm all out of spares at this point and am using a repaired one, keep forgetting to order either cords or used adapters off ebay | 02:21 |
| technomancy | try electrical tape maybe | 02:22 |
| technomancy | keeps the cable right around the barrel from bending as much | 02:22 |
| ex-parrot | I’ve got a little cable sitting here which tells a USB-PD charger to start outputting 20v, I just need to solder a reform compatible plug | 02:49 |
| - chartreuse (QUIT: Ping timeout: 240 seconds) (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 03:00 | |
| + chartreuse (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 03:00 | |
| - chartreuse (QUIT: Quit: leaving) (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 03:17 | |
| + chartreuse (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 03:17 | |
| swivel | technomancy: the problem with electrical tape in 100+F temps is it'll just fall off and leave a gooey mess behind | 03:43 |
| swivel | but I have encapsulated the whole section with large-ish heatshrink tubing in the past, it works well for strain relief | 03:43 |
| chartreuse | The heat-shrink width adhesive is also extra stiff if that's what you're going for, though only shrinks 2:1 rather than 3:1 | 04:51 |
| swivel | i specifically don't want adhesive | 04:55 |
| ex-parrot | Went to dig around for solderable barrel jacks but all I have are RCAs and DINs. What is this useless apocalypse 😂 | 04:57 |
| chartreuse | Normally when I change the plug on a charger I just splice two cables together | 05:05 |
| chartreuse | Rather than getting a solderable jack | 05:05 |
| chartreuse | Just go through my box of spare AC adapters find one that fits, find one that's the right voltage and make a cable | 05:05 |
| - chartreuse (QUIT: Quit: Reconnecting) (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 05:05 | |
| + chartreuse (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 05:06 | |
| ex-parrot | I could just do that | 05:25 |
| ex-parrot | I’m sure I have some solderable jacks though annoyingly | 05:25 |
| - chartreuse (QUIT: Ping timeout: 240 seconds) (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 10:56 | |
| + chartreuse (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 10:56 | |
| + rasmus (~rasmus@c80-217-132-63.bredband.tele2.se) | 12:33 | |
| + andreas-e (~Andreas@2001:861:3108:f570:8c86:6bb4:5689:4fc2) | 14:14 | |
| - rasmus (PART: Disconnected: timeout during receiving) (~rasmus@c80-217-132-63.bredband.tele2.se) | 15:50 | |
| + rasmus (~rasmus@c80-217-132-63.bredband.tele2.se) | 15:51 | |
| + mjw (~mark@herd.wildebeest.org) | 16:26 | |
| bluerise | mntmn: I wonder if I should try LCDIF instead | 16:29 |
| bluerise | yes yes I know, DCSS is better etc etc | 16:29 |
| mntmn | bluerise: yeah try it | 16:33 |
| mntmn | should be theoretically simpler | 16:33 |
| mntmn | and it has more status regs | 16:34 |
| - mjw (QUIT: Ping timeout: 268 seconds) (~mark@herd.wildebeest.org) | 17:02 | |
| - andreas-e (QUIT: Quit: Leaving) (~Andreas@2001:861:3108:f570:8c86:6bb4:5689:4fc2) | 17:29 | |
| + mjw (~mark@herd.wildebeest.org) | 17:50 | |
| - rasmus (PART: Disconnected: timeout during receiving) (~rasmus@c80-217-132-63.bredband.tele2.se) | 17:51 | |
| + rasmus (~rasmus@c80-217-132-63.bredband.tele2.se) | 17:52 | |
| bluerise | hm | 17:54 |
| bluerise | mntmn: doesn't seem to be any better | 17:54 |
| bluerise | black, all black | 17:54 |
| mntmn | bluerise: if you use LCDIF i think you need inverted vsync/hsync polarity or something? | 17:55 |
| mntmn | also lcdif has status registers for the current scanout position if i remember... or at least fifo fill status | 17:55 |
| bluerise | the mipi dsi driver for imx8mq already does that vsync/hsync inversion | 18:03 |
| bluerise | for !dcss | 18:03 |
| bluerise | both FIFOs are empty | 18:16 |
| bluerise | maybe it's the MIPI-DSI | 18:46 |
| - erlehmann (QUIT: Ping timeout: 248 seconds) (~erle@dynamic-046-114-033-018.46.114.pool.telefonica.de) | 19:05 | |
| - TadeusTaD (QUIT: Remote host closed the connection) (tadeustad@fulu.psifactor.pl) | 19:07 | |
| + TadeusTaD (tadeustad@psifactor.pl) | 19:11 | |
| + erlehmann (~erle@dynamic-046-114-033-161.46.114.pool.telefonica.de) | 19:19 | |
| mntmn | bluerise: both fifos are empty? | 19:21 |
| mntmn | bluerise: you mean lcdif fifos? | 19:21 |
| - rasmus (PART: Disconnected: timeout during receiving) (~rasmus@c80-217-132-63.bredband.tele2.se) | 19:52 | |
| + rasmus (~rasmus@c80-217-132-63.bredband.tele2.se) | 19:53 | |
| scops | It seems that i could recover all the batteries with the nitecore sc4 :) | 20:05 |
| mntmn | scops: awesome! | 20:28 |
| - rasmus (PART: Disconnected: closed) (~rasmus@c80-217-132-63.bredband.tele2.se) | 20:39 | |
| + rasmus (~rasmus@c80-217-132-63.bredband.tele2.se) | 20:40 | |
| bluerise | mntmn: yup | 20:48 |
| - rasmus (PART: Disconnected: closed) (~rasmus@c80-217-132-63.bredband.tele2.se) | 21:10 | |
| + rasmus (~rasmus@c80-217-132-63.bredband.tele2.se) | 21:12 | |
| - rasmus (PART: Disconnected: closed) (~rasmus@c80-217-132-63.bredband.tele2.se) | 21:37 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!