Jump to content

Recommended Posts

Posted

BTW: I tested through a variety of other OS images the last weeks/months and since some of those have been recently re-released I gave it a try again today. Just as an example how important appropriate settings are if you want to squeeze out the max out of your hardware.

 

The following is 3 times exactly the same hardware (HC1 with same SSD as /dev/sda1, same SanDisk Extreme Plus with the OS on, same Gigabit network, same MacBook as client). It's even exactly same Debian version (latest Jessie) and also exactly identical Samba version. Why the performance differs that much is explained here in detail.

  • The first distro tested uses an outdated 3.10 kernel, doesn't take care about IRQ affinity or any other relevant settings (except cpufreq scaling) and also uses default (AKA bad) Samba settings.
  • The second distro is the one the first is based on. Same kernel but different cpufreq settings. Obviously also no further optimizations but here OMV has been installed with armbian-config/softy by me which explains the much better SMB write performance
  • The 3rd is latest official OMV 3 image based on Armbian and our next kernel branch so using a rather recent 4.9 LTS kernel soon to be switched to 4.14 (tweaks explained here)
 

 


Bildschirmfoto%202017-11-05%20um%2019.31

Bildschirmfoto%202017-11-05%20um%2018.43

Bildschirmfoto%202017-11-24%20um%2001.16
 

 

 

Disclaimer: The dietpi and Meveric numbers were made a few weeks ago and I couldn't believe that they were that low. But today I did a quick re-test (only one run since it takes ages due to that low performance) and so I decided to publish results. Please be aware that these Samba tests were made with a MacBook running macOS as client which does not show best possible performance (for reasons see here for example -- it needs a more recent Samba version with special settings to perform optimal with macOS clients) so most probably in real-world scenarios and with Windows as clients performance differences might not be that huge and overall SMB performance higher with the non OMV images.

 

BTW: SMB write performance with dietpi increased by 6-7 times as expected just by adding the usual 4 simple lines with some adjusted settings to smb.conf. Edit: And 'use sendfile = yes' might also make a real difference, see posts below. Won't test with dietpi again since already deleted.

Posted

Can you please test the same Armbian image with

use sendfile = yes

added to smb.conf? If I remember correctly this setting alone makes a noticeable difference on A20 (with a HDD, where samba speed looks like is bottlenecked by CPU) and I don't have a spare SSD to test how relevant is it with more powerful hardware and faster storage.

Posted
35 minutes ago, zador.blood.stained said:

use sendfile = yes

 

Good point I almost forgot about since this is set by default with OMV already (tested on day 1 when I started with OMV back in April -- OMV uses some internal preferences which then get fed into the daemon's config files automagically):

root@odroidxu4:~# testparm 2>/dev/null | grep sendfile

	use sendfile = Yes

So I tested the opposite now with Armbian/OMV by setting 'use sendfile = no' in OMV's "/config/services/smb/extraoptions", verified with testparm and as expected read performance drops a lot (directory enumeration too) while write performance slightly increases:

Bildschirmfoto%202017-11-24%20um%2008.24

So yes, 'use sendfile = yes' is important even with beefy hardware (I did a quick check also with performance governor but numbers are close to identical so it's not related with cpufreq scaling and also not a true CPU bottleneck -- watched utilization with htop, everything happens on the big cores and it looks like there's still some room... unlike with A20 where usually the smbd thread is bottlenecked by the CPU core it's running on)

 

As a comparison the 'use sendfile = yes' numbers from above again:

Bildschirmfoto%202017-11-24%20um%2001.16

Posted

Testers wanted: https://wiki.odroid.com/odroid-xu4/software/jms578_fw_update

 

The new firmware release should provide full SAT support (so we can directly talk to the disk and apply spindown settings there, also hdparm should report the drive's state correctly now). Also TRIM is now reported to work. Feedback welcome.

Posted
1 hour ago, tkaiser said:

The new firmware release should provide full SAT support (so we can directly talk to the disk and apply spindown settings there, also hdparm should report the drive's state correctly now). Also TRIM is now reported to work. Feedback welcome.

[deleted]

Posted

I was able to access oDroid Wikipage. Do I need to do anything? Like stop all processes that access the HDD? I see I have to reboot the oDroid.

Posted
57 minutes ago, tmihai20 said:

Do I need to do anything? Like stop all processes that access the HDD? I see I have to reboot the oDroid

 

The firmware upgrade will only succeed after a full power cycle of the USB-to-SATA bridge (so a simple reboot will NOT do). For ODROID-XU4 and HC1 please direct questions at https://forum.odroid.com/viewtopic.php?f=97&t=28535 (since Hardkernel provides this update).

Posted
15 hours ago, tkaiser said:

Testers wanted: https://wiki.odroid.com/odroid-xu4/software/jms578_fw_update

I'll test it soon. 

 

Do you have recommendations for an HC1 with a spinning disk which is mostly idle the during the day but used quite often in the evenings?

 

Btw. 

Cause dust is a problem in my apartment (old building etc. ), I printed a simple top for the HC1. It's not a full enclosure and I don't check the impact to temperature yet, but I think it should be ok. Had some problem with sticking tape and warping (not that unusual when printing with PETg, you should print a raft or use another thermoplast which isn't prone to warp, the top needs ~10m 1.75mm filament). :lol:HC1_top.thumb.jpeg.d46e0dce271a357ff2b083447900ee22.jpeg

 

 

 

HC1_top.stl

Posted
On 12/5/2017 at 10:18 AM, tkaiser said:

Testers wanted: https://wiki.odroid.com/odroid-xu4/software/jms578_fw_update

 

The new firmware release should provide full SAT support (so we can directly talk to the disk and apply spindown settings there, also hdparm should report the drive's state correctly now). Also TRIM is now reported to work. Feedback welcome.

 

Hello,

 

i just downloaded the pack (tool & firmware) to try on a orangepipc2 which has a attached a usb hard disk.

 

I'm a little confused right now. My usb device is (from lsusb):

 

ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. 

but if I give a look @ https://www.smartmontools.org/wiki/Supported_USB-Devices I see the following:

 

Quote

JMicron JMS567                      0x152d:0x0578                       JMicron SATA 6Gb/s bridge

 

Anyway if I run: ./JMS578FwUpdate -d /dev/sda -v

 

Quote

Bridge Firmware Version: v0.2.0.4

 

I didn't want to try the firmware upgrade because I'm not sure if this is the right model for the firmware :ph34r: Somebody can (de)confirm?

Posted

HC2_with_top_Enclosure.jpg

HC1_HC2.jpg

 

HC2 arrived. PCB almost identical but powering has changed since this variant will be powered with 12V from the barrel plug. Hardkernel sent a 12V/2A PSU which I found a bit on the low side since the Seagate Barracuda I tested with shows a pretty high peak consumption at spin up and then an idle HC2 with the disk spinning up already reads 24W measured at wall so imagine when something heavy runs on the Exynos at the same time. I would choose a 2.5A PSU just for some safety headroom.

 

Edit: Hardkernel responded that they tested their '2A rated' PSU with very high loads close to 30W over many days and also their PSU supplier said, consumption up to 2.5A wouldn't be a problem. So the PSU is sufficient even for very power hungry 3.5" disks but problems might occur if an additional host powered 2.5" disk is attached to HC2's USB2 port.

 

Dealing with 3.5" disks has the usual downside: higher consumption. Even in idle with the 12V PSU: 5.3W on average with disk sleeping (compare with HC1 values yourself on 1st page of this review).

 

Edit: tested also with a sleeping SSD and got 4.3W in idle and without just 3.9. So differences between HC1 and HC2 in idle are more or less only related to standby consumption of the disk in question and not related to the 12V PSU being less efficient than HK's 5V PSU.

 

Performance will only depend on the disk used (of course you can combine HC2 with SSDs too!) so with a somewhat decent 3.5" HDD and either mainline Armbian or Armbian based OMV you get +100 MB/s sequential performance through the network for sure as well as lousy random IO performance since all HDD simply suck here.

 

Since this is a dev sample that had been sent out prior to JMicron releasing the upgrade I had to apply latest JMS578 firmware upgrade myself and now everything simply behaves as it would be true SATA (SAT -- SCSI/ATA translation -- fully working, no spindown issues, correct drive serial numbers reported). Once HC2 will be shipped to Customers next month this won't be necessary since latest firmware upgrade already applied by Hardkernel then.

 

Final note: the plastic 'case' that can be seen above works exactly as the smaller HC1 variant and even if it's black all LEDs shine through perfectly since it's fortunately somewhat translucent.

 

100% software compatible means I was up and running in no time. Tested with XU4/HC1/HC2 OMV image: http://sprunge.us/BWMF

 

Edit: Reported SoC temperature is a few degree above HC1 level. I asked Hardkernel and they explained: 'Because of the DCDC converter circuit to make 5V from 12V input, the PCB temperature is higher around 3~4C than HC1'. Quick test with firing up short benchmarks on HC1 and HC2 seem to confirm this, the temperature rise/fall is the same just overall temperature is slightly higher. So there's nothing to worry here, it's just the PCB spreading some more heat into the SoC.

Posted

Thx for the review. Sounds good to me.

I'll connect my second 3,5" hdd which is in an usb 3.0 enclosure to the usb 2.0 port. 

Did you happen to test the transfer speed through usb 2.0 port? I guess it's 30 mb/s..or even faster? 

Basically I just need to access and play back fullhd video files from the external hdd. It's full and nothing gets stored on it. Won't be any problem, right?

Posted
45 minutes ago, trohn_javolta said:

Did you happen to test the transfer speed through usb 2.0 port? I guess it's 30 mb/s..or even faster? 

 

Same HC1 used, same SSD (EVO840), JMS578 on the board vs. JMS578 connected to USB 2.0 port (ROCK64 SATA cable), same firmware version on both JMS578 (JMS578_Hardkernel_v173.01.00.01.bin), same benchmark test: 'iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2':

JMS578 via USB 3.0                                            random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4    13592    14530    18712    18744    14664    14514
          102400      16    46857    49586    59322    59665    50182    49651
          102400     512   204547   217732   200402   205359   201479   217830
          102400    1024   233728   239458   237045   247595   241844   245813
          102400   16384   224437   276093   308294   317705   317230   274902

JMS578 via USB 2.0                                            random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     7960     7967     7995     7999     7993     7977
          102400      16    15040    15643    15984    15998    15984    15930
          102400     512    21761    21874    22360    22411    22416    21884
          102400    1024    22332    22866    22509    22585    22582    22421
          102400   16384    22476    22912    22801    22864    22765    22879

Above tests were made with performance governor... and obviously performance sucks (I've seen much better numbers already). I flashed the external JMS578 with v0.4.0.5 firmware again and tested:

JMS578 with v0.4.0.5 firmware via USB 2.0                     random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     7318     7967     7994     7999     7988     7976
          102400      16    15584    15904    15982    15998    15984    15938
          102400     512    22059    22787    22400    22442    22436    22170
          102400    1024    22508    22875    22524    22586    22583    22558
          102400   16384    22554    23002    22810    22853    22760    22956

So most probably this is a kernel issue and something slowing down USB has been commited to Hardkernel's 4.9LTS kernel in the meantime. Please direct all your questions at Hardkernel over in ODROID forum, I'm simply too tired to deal any more with this constant mess...

Posted
On 13/12/2017 at 8:01 AM, tkaiser said:

now everything simply behaves as it would be true SATA

I applied the firmware upgrade. I haven't had time to test the spin down properly, but I noticed that -C still wakes the drive up from sleep.

Posted
56 minutes ago, James Kingdon said:

I noticed that -C still wakes the drive up from sleep

 

Then most probably something went wrong. I flashed for and back differnet firmware versions maybe 30 times within the last weeks and sometimes it didn't work as expected (needs a full power cycle). So I started to immediately check again after powering on the JMS578 and this confirmed to my surprise that sometimes the update was not applied:

JMS578FwUpdate -d /dev/sda -v

 

Posted

Hello @tkaiser, after your experiences with HC1, would you still recommend it? My usecase is low-power Nextcloud "server" with 2,5" SATA drive. Currently using RPi2, but would like something with more performance and if possible with direct SATA connection including powering the drive. HC1 seemed as a perfect board, but after going through this topic I'm not sure any more. It must not be ARM-based. Thanks, Peter

Posted
1 hour ago, pse said:

HC1 seemed as a perfect board, but after going through this topic I'm not sure any mor

What are your concerns about the board?

Posted
What are your concerns about the board?

Mainly post 44#


Odoslané z môjho iPhone cez Tapatalk
Posted
33 minutes ago, pse said:

Mainly post 44#

I still do not understand your main concerns...  That write performance on USB2 sucks?

 

 

btw. as a side notice...

On 5.12.2017 at 10:18 AM, tkaiser said:

The new firmware release should provide full SAT support (so we can directly talk to the disk and apply spindown settings there, also hdparm should report the drive's state correctly now). Also TRIM is now reported to work. Feedback welcome.

FW update worked without issues, but all directory paths of the OMVs Samba users had to be recreated, cause the old ones were no longer valid.

Posted

Aren't there any issues with HDD spindown? Was this fixed with the new firmware? Does the board contain any watchdog?

Posted
2 hours ago, pse said:

Aren't there any issues with HDD spindown? Was this fixed with the new firmware?

 

Fixed with most recent firmware update. As already suggested it's the best idea to check such basic device support stuff over in Hardkernel's forum.

 

Since I found my EspressoBin again I quickly made a disk performance comparison between EspressoBin and HC2 with same disk, same 12V PSU (the one from HC2) and identical test. I created 10 partitions on an older Seagate Barracuda and ran 'iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2' on the first and last partition to measure the Zone bit recording (ZBR) influence and compared to that the USB-to-SATA overhead.

 

EspressoBin (native SATA, dual-core A53 @ 1.0GHz):

Most outer tracks                                             random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4    38374    55057    55560    56965     1069     1065
          102400      16   106295   145784   149721   146768     4417     4757
          102400     512   185709   185657   195152   208663    66077   109677
          102400    1024   185809   183024   195910   210544    94518   139335
          102400   16384   161376   190062   191007   206133   195470   173037

Most inner tracks                                             random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4    36221    52685    57760    55920     1117      876
          102400      16   102695   115695   104080   105510     4156     2258
          102400     512   114614   114578   121710   128529    51331    80396
          102400    1024   114641   114690   124344   133445    75044    95449
          102400   16384   106151   114470   127629   127190   121159   107905

 

ODROID HC2 (USB3 SATA via JMS578, octa-core with 4 x A15 cores @ 2.0GHz)::

Most outer tracks                                             random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4    13093    18465    18978    19550     1120     1041
          102400      16    60695    65743    66638    66918     4284     4759
          102400     512   181296   183683   160550   174847    59757   112229
          102400    1024   181539   183761   185347   203931    87746   130942
          102400   16384   156686   183753   190891   207956   193699   168763

Most inner tracks                                             random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4    17044    18679    18021    19589     1073      795
          102400      16    60380    66453    47286    64413     4085     2842
          102400     512   112966   112848   118677   127218    46118    80652
          102400    1024   109957    64721   118274   125493    70672    87559
          102400   16384    98049   113128   120900   130945   124400   106930

 

Especially with small block sizes sequential write and read performance suffers a lot with small block sizes due to added USB overhead while with large blocksizes the difference between native SATA and USB3 SATA is negligible (this is what the usual inappropriate pseudo benchmarks done with dd/hdparm will also show: almost no difference).

 

So it highly depends on the use case whether HC2 with its USB3 SATA implementation will perform a lot slower compared to 'true SATA' ports like on EspressoBin or almost as fast.

Posted

So sorry for the noob question, but I don't want to create topics for just one question so asking it here....What would be the best way to connect two disks (either hdd or ssd) to the HC1?  And could I use the gui in the "Armbian based OMV image" to setup both disks in either a RAID array or some rsync or some other solution for backuping data? Thanks and keep up the good work!

Posted
55 minutes ago, msev said:

What would be the best way to connect two disks (either hdd or ssd) to the HC1?

I don't know whether I understand the question since by looking at either specs or even pictures the question is already answered, isn't it? There's a SATA port behind the USB3-to-SATA bridge and there's an USB2 port.

 

56 minutes ago, msev said:

And could I use the gui in the "Armbian based OMV image" to setup both disks in either a RAID array or some rsync or some other solution for backuping data?

Sure, OMV's user interface allows you to do any stupid things you want (eg. playing RAID-1 which is just an insane waste of disks for no reason -- 'RAID is not backup' and especially mdraid's RAID-1 is crap!) but also allows to take care of data protection and backup. But that's obviously stuff for OMV documentation / forum and not for a device review thread here.

Posted

Has anyone tried to use a fan with Odroid HC-1 ? Too hot for my default load scenario (75..80 deg. cel.), even had to make an "ugly rack" (with hdd location below HC-1) to avoid hdd overheat and allow free airflow from heatsink. There are 2 "dot"-connectors marked "GND" and "12V"; looks like they are for external cooler, am i right ?

Posted
Quote

Has anyone tried to use a fan with Odroid HC-1 ?

I also thought about additional cooling ...but for me the temperature is in the range  59 C  -  69 C 

and finally I gave up and it's OK for now .

But maybe I can find a solution on the internet additional aluminum / copper radiotor or fan?  :-)

a little high this temperature ?  

regards!

Posted

It's slightly frustrating the extent to which they cut features from the XU4 when they created the HC-1 board. I would have preferred a slightly larger board which retained the hdmi/emmc/gpio and of course the fan output. If that added $10 to the price I'd be ok with that, and I doubt if it would have been any more than that.

Posted
52 minutes ago, kris777 said:

I also thought about additional cooling ...but for me the temperature is in the range  59 C  -  69 C 

 

If you look at page 1 of this thread there are thermal values from my 1st HC1. When my HC2 arrived some weeks ago I noticed a lot higher temperatures reported in the beginning. I carefully 'massaged' the PCB and this did the trick: temperatures later only a few degrees above HC1 (which is to be expected due to the additional 12V/5V DC-DC converter). So trying to get a better contact between SoC and heatsink (spreading the thermal paste) is always a good idea if the temperatures you get are a bit off.

 

https://forum.odroid.com/viewtopic.php?t=27665

Posted

thanks @tkaiser for the hint and link ... I will definitely check !

But it's finally a new odroid HC1 . Not my six-year-old laptop ... in which I exchanged thermal grease :-)

but thanks for the info ... 

 

Ps. but if the above equipment works nonstop eg Seedbox / FTP / Samba ...this temperature can be the norm  ?    How much will the SD card withstand if I use it in this way? :-)  I will have to install the system on HDD / SATA ...
if it can be done?

  ....  for now, I have changed the processor speed to max 1400 / update JMS578 firmware !

regards .... thanks a lot !

Posted

Hi, in this thread it is mentioned that the minimal idle power consumption of the HC-1 is 3.7W.

 

For the XU4 i have seen numbers  from 1.7W - 1.8W for idle power consumption: https://forum.odroid.com/viewtopic.php?f=97&t=15938

 

I don`t know if theese measurements are done with or without including the efficiency of the power supply, and which measurement device is used.

 

Has someone made measurements for the XU4 and the HC-1 with the same or comparable setup and can say if there is really such a big difference between them ?

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines