| 09:25 | heap_ | hi, some simillar device to cubox but that handle better encryption? |
| 09:25 | heap_ | handles* |
| 09:30 | heap_ | mine cubox-i can do only 4mb/s via rsync... 25mb/ ftp |
| 16:33 | heap_ | any good arm device with more performance then cubox-i? |
| 16:38 | Artox | pretty sure there is one |
| 16:38 | Artox | but I dont know any |
| 16:39 | Artox | heap_: your problem seems to be that you cant use the CAAM |
| 16:39 | Artox | but other people have trouble with it too |
| 16:41 | heap_ | whats caam? |
| 16:42 | heap_ | well problem is when i use encfs or any encrypted sparse bundle write speed drastically decrease |
| 16:45 | Artox | Crypto Api Accelerator Module |
| 16:46 | heap_ | yeah |
| 16:46 | heap_ | so is there anything better? |
| 16:46 | Artox | you want to use the CAAM |
| 16:46 | heap_ | yes |
| 16:46 | Artox | for more throughput |
| 16:46 | heap_ | yse\ |
| 16:46 | Artox | but I cant tell you how as I dont know it |
| 16:47 | Artox | a faster ARM CPU will give oyu a bit better speed |
| 16:47 | Artox | obviously |
| 16:47 | Artox | but+ |
| 16:47 | Artox | ..... |
| 16:48 | jnettlet | heap_ the fastest encryption speeds are usually using neon crypto depending on the data size |
| 16:49 | jnettlet | Also make sure you are running rngd. Mixing in the hwrng to the kernels entropy pool will also help |
| 16:55 | heap_ | jnettlet: is better to use encfs or http://ecryptfs.org/downloads.html? |
| 16:55 | heap_ | what do you mean by neon crypto? |
| 16:56 | heap_ | i just see that qnaps use simillar cpus as cubox but they have so much higher performance |
| 16:59 | jnettlet | heap_ walking to the store for dinner. Will answer after chicken is cooking |
| 17:01 | heap_ | jnettlet: thank you |
| 17:01 | heap_ | Nov 12 17:00:39 universe systemd[1]: Starting Hardware RNG Entropy Gatherer Daemon... |
| 17:01 | heap_ | Nov 12 17:00:39 universe rngd[5670]: Unable to open file: /dev/tpm0 |
| 17:01 | heap_ | Nov 12 17:00:39 universe rngd[5670]: can't open any entropy source |
| 17:01 | heap_ | Nov 12 17:00:39 universe rngd[5670]: Maybe RNG device modules are not loaded |
| 17:01 | heap_ | ;-( |
| 17:10 | heap_ | http://www.hardkernel.com/main/products/prdt_info.php?g_code=G143452239825 |
| 17:10 | heap_ | is this one faster then cuboxi4? |
| 17:14 | heap_ | jnettlet: it doesnt have TPM so u cant use rngd? |
| 17:54 | jnettlet | heap_, oh this is an exynos board |
| 17:54 | jnettlet | well that chip is the one that is in my chromebook and it does have a hwrng |
| 17:54 | jnettlet | it is possible the driver isn't upstream yet. |
| 18:20 | heap_ | jnettlet: what chil? |
| 18:20 | heap_ | jnettlet: do you think that ODROID-XU4 has better performance then cubox-i4? |
| 18:23 | heap_ | jnettlet: i have cuboxi4 and i tried to install rngd on cuboxi |
| 18:35 | jnettlet | heap_, for raw processing then yes. The big cores are quad-core a15's at 2ghz |
| 18:36 | heap_ | what do u mean by raw processing? |
| 18:36 | heap_ | nas? |
| 18:36 | jnettlet | no compute power |
| 18:37 | jnettlet | operations per second |
| 18:37 | heap_ | hmhm ios? |
| 18:37 | heap_ | well i need to best performance for the NAS usecase |
| 18:37 | jnettlet | then you have USB 3.0 vs eSATA and the internal bus speeds. |
| 18:38 | jnettlet | ultimately the odroid has full gigabit ethernet vs the mx6 is limited to about 420Mbps TX and 600Mbps RX |
| 18:39 | heap_ | yeah |
| 18:39 | heap_ | so no clue if that usb3 and internal bus speed is slower or worse ... |
| 18:40 | heap_ | i dont understand how can qnap use simillar cpus as cubox and they perform so much better |
| 18:40 | heap_ | i cant get more then 5-10mb/ write on the cubox using rsync |
| 18:40 | heap_ | nfs ~25mb/s |
| 18:41 | jnettlet | what SOC does the qnap have? |
| 18:43 | heap_ | hold on |
| 18:44 | jnettlet | using the mx6 CAAM crypto engine I can push encrypted data over the network to it at about 12MB/s |
| 18:44 | jnettlet | now this is unfair to the MX6 because scp has known bandwidth limitations. I still have to test the new htscp patches |
| 18:45 | heap_ | http://www.wallpaper.com/travel/czech-republic/prague/bars/lounge-bohemia?utm_source=social&utm_medium=social&utm_campaign=Facebook |
| 18:45 | heap_ | ops |
| 18:45 | heap_ | Freescale™ ARM®v7 Cortex®-A9 dual-core 1.2GHz processor |
| 18:45 | heap_ | how u use mx6 CAAM? |
| 18:45 | jnettlet | so it is a 1.2ghz iMX6D |
| 18:46 | heap_ | jnettlet: well 12mb/s is not that much, they claim to do around 30mb/s |
| 18:46 | jnettlet | well in the new kernels it is patched to actually work and enabled, but you still need to integrate userspace |
| 18:46 | heap_ | sounds like i have no idea what to do? |
| 18:46 | jnettlet | yeah the CAAM engine tested with openssl and large data chunks does about 28-30MB/s so I will buy that. |
| 18:47 | heap_ | jnettlet: buy what and what CAAM engine? |
| 18:47 | heap_ | jnettlet: sorry im really novice in that |
| 18:48 | jnettlet | the CAAM engine is the crypto acceleration engine on the mx6 |
| 18:48 | heap_ | yes |
| 18:48 | heap_ | but how can i boost it on my cubox? |
| 18:48 | heap_ | or utilize |
| 18:48 | jnettlet | its best throughput I have seen is about 30MB/s in optimal conditions so I can see them claiming that performance |
| 18:49 | heap_ | jnettlet: who? qnap or cubox? |
| 18:49 | jnettlet | You need a newer debian jessie image from us, and then to recompile OpenSSL and GnuTLS to use cryptodev. |
| 18:49 | heap_ | jnettlet: on my cubox there is arch arm ... is that problem? |
| 18:50 | jnettlet | well I can't help you there. I know Crux is trying to get them to use my kernel to support some of this, but so far the Arch maintainers seem to prefer upstream. |
| 18:50 | jnettlet | so no help there. |
| 18:50 | heap_ | ok so what should i install then? |
| 18:51 | jnettlet | well there is no simple solution to that yet. |
| 18:52 | jnettlet | ultimately it would be our debian jessie image with an experimental repo enabled, but we haven't finished the experimental repo yet. |
| 18:52 | heap_ | ah ;/ |
| 18:52 | heap_ | is there any deadline? or plan? |
| 18:53 | jnettlet | no, because this is not requested much by customers and in general the CAAM engine support by freescale has been horrible. It isn't until recently we have gotten it stabilized. |
| 18:53 | jnettlet | I am surprised qsnap released a product based on it actually |
| 18:54 | jnettlet | of course they could be running a kernel with the NEON crypto acceleration enabled in the kernel. That tends to actually be faster than CAAM, but uses more CPU |
| 18:55 | heap_ | and i cant use neone with cuboxi? |
| 18:56 | jnettlet | sure, you just need to enable the config options in the kernel. It was introduced in 3.14 but more patches and functionality were added in later kernels. |
| 18:57 | heap_ | bit confusing... |
| 18:57 | heap_ | i thought ill be easy process |
| 18:58 | jnettlet | crypto is never an easy process |
| 19:00 | jnettlet | heap_, if you just grab out debian jessie images you will get NEON kernel acceleration enabled for crypto |
| 19:00 | jnettlet | that is probably your easiest way to test |
| 19:01 | heap_ | ah ok so arch arm is not good way to go? |
| 19:02 | jnettlet | not if you want the best support from us. Really you are better of bring this up on their forums. |
| 19:02 | heap_ | ah ok |
| 19:02 | jnettlet | they do their ow kernel versions and configs, it isn't controlled by us |
| 19:02 | heap_ | jnettlet: where is then this debian image? its supported by solidrun company? |
| 19:03 | jnettlet | https://images.solid-build.xyz/IMX6/Debian/ |
| 19:06 | heap_ | thx, is it stable? |
| 19:06 | jnettlet | sure, make sure to apt-get update and upgrade it. I think we have a couple of changes not in the latest image. |
| 19:07 | jnettle | 19:07 * jnettlet is very amused that someone using Arch linux is asking if our image is stable. |
| 19:07 | heap_ | jnettlet: i dont know which one i have to use? |
| 19:07 | heap_ | i need more stable and with the best performance :) |
| 19:08 | jnettlet | isn't that what everyone wants? |
| 19:08 | heap_ | :) |
| 19:08 | heap_ | so which way i should o |
| 19:08 | heap_ | go |
| 19:08 | heap_ | arch or debian? |
| 19:09 | heap_ | frankly i have no clue |
| 19:09 | jnettlet | well I have never heard of a commercial product launching using Arch, there is probably a reason for that |
| 19:10 | heap_ | jnettlet: okay |
| 19:10 | heap_ | ill try that debian |
| 19:10 | Defiant | jnettlet: the main dev is an arch fanboy? |
| 19:10 | jnettlet | Defiant, which main dev? |
| 19:11 | Defiant | jnettlet: you were looking for a reason the commercial product uses Arch |
| 19:12 | jnettlet | Defiant, oh maybe. I was just saying I have never seen a commercial product that uses Arch. |
| 19:12 | jnettlet | they have great documentation, but I don't think they are taken seriously |
| 19:12 | jnettlet | not for a real product. |
| 19:13 | cbxbiker61 | jnettlet, are the new kodi patches ready? |
| 19:26 | jnettlet | cbxbiker61, I have backported them, but they are not working 100% properly. You are welcome to try them, but none of them should be related to the problems you were seeing. |
| 19:30 | cbxbiker61 | jnettlet, if the patches are backwards compatible with the old api, i should probably just roll them in, and then i can bounce back and forth between api versions as i get time to test |