View previous topic :: View next topic |
Author |
Message |
erm67 l33t


Joined: 01 Nov 2005 Posts: 647 Location: EU
|
Posted: Mon Dec 30, 2019 12:43 pm Post subject: |
|
|
Good idea, I am also considering a rockchip.
BTW after my adventure with Allwinner H3 SoC I found out why it was overheting like that:
https://h3droid.com/blog/sunvell-r69-my-adventures-with-a-cheap-tv-box
My board is the newer revision 2.0 of the r69, rebranded, but is just the same kind; there are a lot of those 19$ shipped boxes based on the r69 on ebay. Apparently with a fan works, the reson is clear, it is identical to a orangepi development board but there is no voltage regulator on the board and it is not possible to change the cpu-frequence which is downclocked to 1.0Ghz. The gpu instead is normal, to reduce costs to the minimum they removed a lot of components from the original xunlong design, it not a scam but they are worth 19$ shipped. Basically it might work as a tv box, since the cpu will be idle and the gpu will decode the video, but 720p is all it can do smoothless, and it is unusable as home server. They probably also used second rate SoC that do not pass the tests at 1.2Ghz ....
It was a lot of fun anyway, using binwalk on the firmware in the emmc I was able to get the original dtb (almost useless with all winner), and the fex, I just feed them to https://h3droid.com/ and after a couple of days fiddling with the stupid fex everything worked.
If you need help with the rockpi ask, I might also get a rockchip board.
BTW what VPN do you use? _________________ Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
Back to top |
|
 |
crocket Guru

Joined: 29 Apr 2017 Posts: 454
|
Posted: Mon Dec 30, 2019 2:05 pm Post subject: |
|
|
I used OpenVPN for a while. But, it was awkward because it used certificates that expire. Managing expiring certificates is not a good idea.
I'm thinking about wireguard. I read that it is lighter on resource. |
|
Back to top |
|
 |
erm67 l33t


Joined: 01 Nov 2005 Posts: 647 Location: EU
|
Posted: Mon Dec 30, 2019 10:47 pm Post subject: |
|
|
install a calendar server on the rockpi _________________ Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
Back to top |
|
 |
crocket Guru

Joined: 29 Apr 2017 Posts: 454
|
Posted: Mon Dec 30, 2019 11:02 pm Post subject: |
|
|
erm67 wrote: | install a calendar server on the rockpi |
I would do that on a NAS. Anything that stores non-replaceable data should go to an ARM NAS. I would use Helios64 for that. |
|
Back to top |
|
 |
erm67 l33t


Joined: 01 Nov 2005 Posts: 647 Location: EU
|
Posted: Tue Dec 31, 2019 8:59 am Post subject: |
|
|
Wel if you run applications on it it is no longer a Network-attached storage
It is good that the helios has 2x 1gbit nic, like mine, and using a switch that supports link aggregation it will reach 2gbit speed, pushing nfs or smb at that speed to several clients will use a lot of CPU and memory. I decided that the NAS should only do the nas. _________________ Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
Back to top |
|
 |
crocket Guru

Joined: 29 Apr 2017 Posts: 454
|
Posted: Tue Dec 31, 2019 11:19 am Post subject: |
|
|
Maybe, having a dedicated ARM build machine is beneficial to you. It's not to me, yet. |
|
Back to top |
|
 |
erm67 l33t


Joined: 01 Nov 2005 Posts: 647 Location: EU
|
Posted: Tue Dec 31, 2019 11:33 am Post subject: |
|
|
I don't have a dedicated arm build machine, only a nas and a home server Building and emerging it is not a problem, the n2 is fast enough to do that autonomously overnight. I spend already enough time bumping and fixing for arm64 outdated ebuild like Plex, fixing also crosscompile wirdness would be too much really
I was just questioning your usage of the acronym NAS if you run applications on it, it is a home server, you can of course use the helios64 as a home server. _________________ Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
Back to top |
|
 |
crocket Guru

Joined: 29 Apr 2017 Posts: 454
|
Posted: Tue Dec 31, 2019 1:13 pm Post subject: |
|
|
Some things run efficiently on NAS.
- MPD(MusicPlayerDaemon) database
- ...
|
|
Back to top |
|
 |
erm67 l33t


Joined: 01 Nov 2005 Posts: 647 Location: EU
|
Posted: Tue Dec 31, 2019 8:09 pm Post subject: |
|
|
Well only if compared to running it on the 100Mbit rpi ethernet
I was also a bit scared but on my hardware and network mpd works perfectly on the home server and the music library is accessed over nfs on the NAS, and I only have flac or dsd (a lot of them). Apparently that is a problem with slow boards/networks.
That is also the reason why I never bought a board without a fast ethernet
The only problem is that inotify doesn't work over nfs, but I rescan the library when I add something, I will find a solution for that as well maybe ....
Maybe pNFS supports inotify .... _________________ Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
Back to top |
|
 |
crocket Guru

Joined: 29 Apr 2017 Posts: 454
|
Posted: Wed Jan 01, 2020 6:02 am Post subject: |
|
|
MPD database building happens efficiently on a local machine. Building an MPD database by fetching file lists over NFS is substantially slower.
I'd build MPD database on NAS and actually play the music on a remote machine.
What duties would you assign to your ARM build machine such as Odroid N2?
What duties would you assign to other ARM machines? |
|
Back to top |
|
 |
erm67 l33t


Joined: 01 Nov 2005 Posts: 647 Location: EU
|
Posted: Wed Jan 01, 2020 10:27 am Post subject: |
|
|
What do you mean in real life numbers with "Building an MPD database by fetching file lists over NFS is substantially slower."? is that a god given absolute value or do you have numbers to prove it? Even just theoretical numbers are good, it seems bullshit to me and probably is. You might have heard about the scientific method, and what you say is very unscientific.
How can you think that nfs@80megabytes/second can be slower than sdcard@30Megabytes/second (if you are lucky) or slower than usb2@40Megabytes/second (on the paper)? Trust me real gigabit is a lot faster than that, not the usb2 attached gbit on the raspi but real one. In fact root on iscsi is a great solution for small boards.
Of course the USB3/uas attached ssd on my odroid N2is faster than that, just like a PCIe-sata SSD/M.2 drive, probably NFS is on par with an eMMC 5.0 or a just bit slower than a locally attached rotational disk @100Mbytes/s. And clearly if use a raspi2 as the nas it will be a lot slower than mine.
In theory what you say doesn't make sense and real life tests prove that the number are correct, if you want to waste money just stick a 128Gb uSD in your raspi and enjoy
the nfs machine can push 200Megabytes/second, faster than most rotational disks, using a second usb3 gbit card it might even be faster
It is really a pain see a regular gbit ethernet card that transfers 1.000Mbit/second full duplex (that is 2.000 Mbit in total) connected to a usb2 bus that transfers 400Mbit/second half duplex (that is 400 Mbit/s intotal) when Xunlong did that on some orangepi boards everybody cried that is was a scam, and in fact is.
To be honest I don't use the mpd library and most of the time use cantata to stream the songs from my pc to the mpd server, actually I access the nfs share from the pc and use cantata to stream to the mpd server, you know because of the inotify problem I also use sometimes rompr as a frontend for mpd. _________________ Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
Back to top |
|
 |
crocket Guru

Joined: 29 Apr 2017 Posts: 454
|
Posted: Wed Jan 01, 2020 11:02 am Post subject: |
|
|
NFS can be fast if it transfers a lot of data at once. But, in my direct experiences, fetching file lists over NFS on gigabit ethernet was substantially slower than fetching file lists on a local disk.
I could feel the substantial lag when a file manager was fetching a file list from an NFS directory.
I guess dolphin file manager made NFS substantially slower by synchronous sequential requests of file attributes.
If dolphin requested everything at once, it would have been a lot faster.
In general, a series of synchronous sequential requests over network is very slow.
Requesting a list asynchronously over network is hundreds of times as fast.
If you combine asynchrony with parallelism, it becomes even faster. If you combine those with a batch operation, it becomes an instant task.
It's not about bandwidth. It's about latency and asynchrony and batching. Transferring a file list doesn't require a lot of bandwidth.
I haven't tested nfs storage plugin on MPD, but I suspect it is slow due to lack of batching and asynchrony. It's not scientific, but it is an educated guess from my past experiences with network programming and NFS.
Asynchronous programming is more difficult than synchronous programming.
https://www.musicpd.org/doc/html/plugins.html#proxy can accelerate MPD database building.
On my machine, mpd consumes about 13MB of resident memory and almost no CPU resource. It wouldn't be much of a burden to helios64, rock pi 4, and odroid n2 with 4GB RAM and powerful CPU cores.
But, if your music library is not big enough, it might not matter much. |
|
Back to top |
|
 |
crocket Guru

Joined: 29 Apr 2017 Posts: 454
|
|
Back to top |
|
 |
|