Jump to content

rhard

Members
  • Posts

    17
  • Joined

  • Last visited

Posts posted by rhard

  1. On 4/19/2022 at 5:23 PM, ljm42 said:

    For anyone following this thread, be sure to check out the first post for a sneak peek into 6.10.0-rc5, coming Soon(TM)!  

     

    Starting with this release you will be able to assign specific Docker containers to a VPN tunnel connected to a commercial provider! The rest of your server will use the normal Internet connection while your selected containers use WireGuard. There is even a kill switch, so if the WireGuard tunnel goes down, the containers will not be able to access the Internet.

    Can it be used with VM's?

  2. Yes, I'm also very unhappy. Last month I started to search for home server solution. Mainly as a backup for photo/video archive, plus some docker and couple VM's. First I wanted to buy QNAP, but changed to fan-less design and better hardware. So I started to search all possible software solutions. UNRAID still remains my favorite. I tried OMV and Proxmox.  OpenNAS don't want because of OpenBSD.

    But SMB performance is bad. I expected to run some projects over 10GbE from NVME. But was very disappointed waiting 20+ hours for my 450GB Apple Photos library transferring to UNRAID.
    Now I want to try custom linux build. I don't need any kind of parity or RAID. Will just rsync the data from one 10TB drive to another. Probably, I will try LVM cache with NVME to the main HDD, because UNRAID cache is also not what I expected.

     

    But I like UNRAID UI and Docker/VM management. Theoretically, I can live with performance issues, but generally speaking, I would like to have more support from the devs. At least some acknowledge.

     

     

  3. Another thing to test. Try to set Case-sensitive names: Yes on a share. I did yesterday and now my share is only 20-30% slower then unassigned device (beside it is NVME vs old SATA SSD in the USB port).

     

    Also, if you have Samsung NVME, in some of the threads here, people found it is not good with BTRFS. So I formatted it to XFS. 

  4. Enable share is easy. It is a temporary solution for me now. One problem you cannot use standard share UI and create different share folders with different parameters and only share the disk as a whole. 

    image.thumb.png.b71f09fa5242bcc143d46778dd8ca4b6.png

    There are different threads on the forum addressing strange problems with SMB/SHFS. Here are some of them: 

     

     

     

    In the last topic at the end I did some tests comparing User Share vs Disk Share. Will do now the tests with unassigned device as well.

  5. I have a problem with small files too. According to my investigations, this is unRAID SHFS problem and not SMB. You can try to create a share on an unassigned SSD drive and compare it to the normal share (even with cache only). In my case, it is much faster. It would be very interesting to hear about your experience. I like unRAID as a media server, but it is almost unusable as network storage for small file projects.

  6. 39 minutes ago, rl2664 said:

    Don´t work for me. CPU freq stays at boost freq 3.8 Ghz. Only pstat driver disable helps.

    Did you also trigger "Performance" -> "Power Save" in Tips and Tweaks? Anyway, I just continue to measure performance and looks like SMB works better with ACPI driver. I will stay with disabled pstates as well. At least until kernel 5.

    Currently, slow SMB write speeds and CPU power issues only major problems stopping me from switching to unRAID.

  7. I have the same problem. Found that intel_pstate driver is very sensible. If you run popular watch command it simply shows wrong results:
     

    watch "grep 'cpu MHz' /proc/cpuinfo"
    cpu MHz         : 4742.255
    cpu MHz         : 4480.885
    cpu MHz         : 4451.161
    cpu MHz         : 4420.211
    cpu MHz         : 4473.812
    cpu MHz         : 4423.951
    cpu MHz         : 4432.021
    cpu MHz         : 4477.743
    cpu MHz         : 4558.370
    cpu MHz         : 4413.524
    cpu MHz         : 4425.724
    cpu MHz         : 4484.005
    cpu MHz         : 4425.530
    cpu MHz         : 4403.425
    cpu MHz         : 4437.033
    cpu MHz         : 4382.428

    But if you decrease the update interval the results are much better: 

    watch -n 0.3 "grep 'cpu MHz' /proc/cpuinfo"
    
    cpu MHz         : 1686.816
    cpu MHz         : 1713.529
    cpu MHz         : 992.136
    cpu MHz         : 971.635
    cpu MHz         : 1724.956
    cpu MHz         : 4800.423
    cpu MHz         : 3784.639
    cpu MHz         : 4902.354
    cpu MHz         : 967.030
    cpu MHz         : 1059.654
    cpu MHz         : 1674.691
    cpu MHz         : 1738.267
    cpu MHz         : 2040.228
    cpu MHz         : 1502.640
    cpu MHz         : 889.176
    cpu MHz         : 838.754

    I guess, watch command immediately wakes up the CPU showing high frequency.

×
×
  • Create New...