01-24-2018, 10:07 AM
(This post was last modified: 01-24-2018, 10:08 AM by ayufan.)
matteobp: this is very strange, on USB3.0, on 4.4, on OMV, with FDE, over GbE I get around 80MB/s.
ayufan, what type of USB3 setup do you have? HDD/SSD , WD/Seagate?
Any tests / logs that can be pulled?
Would be great if we could collate some more information, maybe throw into a WIKI, so that users can see what hardware works best with rock64 and your images. Having been lived with slow HDD performance on my BananaPi Ultra 2 for a year, i've got my rock64 arriving today and want to get the correct components to get performance like you have.
Thanks.
(01-24-2018, 10:07 AM)ayufan Wrote: matteobp: this is very strange, on USB3.0, on 4.4, on OMV, with FDE, over GbE I get around 80MB/s.
I have never seen this speed, not even in reading!
In the weekend I'll try the latest stretch 0.6.15 - 175 with default kernel 4.4.103.
I'll check the network performance using netperf with both windows and linux machine, and the USB3.0 local performance with iozone (but if I'm not mistaken it is over 100MB/s).
I can also make a test with Helios LAN test.
Do you need some particular log or output?
Thanks.
01-25-2018, 05:26 AM
(This post was last modified: 01-25-2018, 05:26 AM by Luke.)
Using build 0.5.15 Jessie (old image, but I see no reason to update) - kernel 4.4, running OMV 3, I am getting consistent ~75-90MB/s on a 2TB Barracuda 2.5in HDD.
No winderz allowed on the premises here, I use ssh -Y rock64@rock64 to do everything but software installs. Somebody has decided being able to run synaptic over an ssh connection is a security risk. So anything involved in installing software has to be done from its own keyboard, whereas I've 5 more wheezy installs where it Just Works from a comfortable chair anyplace on my local network.
When I had 5.15.130 on it, and the 1T usb3 drive, I could build a new kernel in about an hour, but u-boot or whatever is used as a booter, fails in that there do not seem to be, anyplace on the net, any instructions on how to do a "make install" and I have asked how to install a new kernel here on this forum at least twice and have been ignored both times.
This thing has all the features to make it a pi killer, but its not going to happen when everything about it is a big secret. pi's have a local keyboard/mouse event throwaway problem, and I'd replace the pi I am using in a heartbeat, if I could find out how to install an rtai kernel, and build the pi's spi driver on it that is now part of linuxcnc. But that user space code expects an entirely different set of gpio headers, so rewriting that code will be a much bigger project than building a kernel.
Cheers, gene83
Winderz ? Whiners ? You are free to whine as much as you wish - doubt it will help.
Quote:Somebody has decided being able to run synaptic over an ssh connection is a security risk. So anything involved in installing software has to be done from its own keyboard.
Are you talking about OMV? what do you mean by 'install things using synaptic over ssh'? You can enable ssh in OMV by: SSH -> Permit root login -> enable. The instructions are also up on the ayufan's git where you download the image from (see credentials).
Quote:there do not seem to be, anyplace on the net, any instructions on how to do a "make install" and I have asked how to install a new kernel here on this forum at least twice and have been ignored both times.
Here is all you need to know. Have you even read this thread ?
Quote:This thing has all the features to make it a pi killer, but its not going to happen when everything about it is a big secret.
We are truly secretive indeed, especially if you read the IRC log you surely won't find out about all the upcoming devices, features, and where development is at ...
Quote:space code expects an entirely different set of gpio headers
You already got a response to this query.
Thank you, I have not seen this thread before. It looks like the answers I need. As for the irc log, I left it running for a couple days, and at that time 2-3 weeks back, and 2 days did not fill one screen full. That was at the link floating back and forth in your reply above. Wrong link?
As for the response, what I got, wasn't what I wanted unless it can run the spi at 40-50 megabaud. Some notes I found seemed to indicate a speed in the 10 megabaud range was normal.. As stated in a prior msg, the pi is writing at 42 megabaud, and reading the responses at 25 megabaud right now, absolutely error free. The rock64 s/b able to do that at 50 megabaud, both ways.
But w/o the realtime kernel, linuxcnc will not start at all, so the first step is getting a realtime kernel built and installed as the default boot. So now I spend some time perusing that zip file of build scripts, to see if I can master that. For that, I'll take the default spi, maybe even leaving it out and try to port the userspace pi code since they would no doubt clash.
Thanks again Luke, the potential for progress has been improved. Now we see what my ancient wet ram can do with it.
Cheers gene83
Just got my rock64 2GB ram ver 2 board. Downloaded Xenial Minimal arm64 install and used latest Etcher to image a Samsung 32SD card. Is version 0.6.15 .. So far so good. Have upgrade and updated it. Noticed it download a new linux firmware during the upgrade. Haven't set it up download latest releases (0.6.16) which shows USB 3 set to HS under uboot (linux newbie so not sure if I am using uboot).
Noticed that the status lights are constantly on (pink and white). Guessing this might need fixing as I assume one is CPU activity.
Will update as I progress with my setup over the coming days.
(01-25-2018, 05:26 AM)Luke Wrote: Using build 0.5.15 Jessie (old image, but I see no reason to update) - kernel 4.4, running OMV 3, I am getting consistent ~75-90MB/s on a 2TB Barracuda 2.5in HDD.
Hi.
Just to be sure, you have rock64 with Jessie 0.5.15, (with some optimization?), and are you able to copy from/to with another PC/machine with a transfer speed (both read/write) of ~75-90MB/s?
Can I ask you the O.S. of the other PC/machine? Which is the size of the file used for test?
In my case, with stretch 0.5.15 the transfer speed was always less than 25MB/s.
Can the difference be related with debian distribution (jessie/stretch)?
I have a rock64 with 1GB, and the tests I do are with files greater that 1.5GB. My O.S. on the other PC is Windows7.
Thanks
01-26-2018, 06:04 AM
(This post was last modified: 01-26-2018, 06:08 AM by Luke.)
(01-26-2018, 05:28 AM)matteobp Wrote: (01-25-2018, 05:26 AM)Luke Wrote: Using build 0.5.15 Jessie (old image, but I see no reason to update) - kernel 4.4, running OMV 3, I am getting consistent ~75-90MB/s on a 2TB Barracuda 2.5in HDD.
Hi.
Just to be sure, you have rock64 with Jessie 0.5.15, (with some optimization?), and are you able to copy from/to with another PC/machine with a transfer speed (both read/write) of ~75-90MB/s?
Can I ask you the O.S. of the other PC/machine? Which is the size of the file used for test?
In my case, with stretch 0.5.15 the transfer speed was always less than 25MB/s.
Can the difference be related with debian distribution (jessie/stretch)?
I have a rock64 with 1GB, and the tests I do are with files greater that 1.5GB. My O.S. on the other PC is Windows7.
Thanks
Hey. Yes, I get ~90MB/s down and ~75MB/s up - see attachments below (transferring a 15GB OS image from and to the PC to illustrate). I use it daily and the speeds hold up quite well when transferring multiple files and even when family members steam media, etc., of the server.
Down
Up
I use the 0.5.15 OMV image built on Jessie on a 4GB Rock64.
One of the stationary computers is running Mint 18.3 and the other Ubuntu Mate 16.04. The pictures above are from the Mint box. The OMV SMB share is mounted permanently on both computers in fstab.
I tried the speeds in Win10 and they were on par with what I see in Linux.
Are you sure your ethernet cables and switch are not the culprit? If you have like a cat 5 cable (10/100) connected to your Rock64 or switch then I'd expect to see similar speeds to those you report. Same goes if you don't have a GbE switch.
edit: you asked about optimisations server side:
Code: min receivefile size = 16384
write cache size = 524288
getwd cache = yes
socket options = TCP_NODELAY SO_RCVBUF=65536 SO_SNDBUF=65536
max xmit = 65535
|