Problems with netatalk during update to 1.0

    • I´m pretty sure it is sektion.

      Have you already tried installing the backports kernel via OMV-Extras? Maybe there is a newer driver for your network card built in.
      OMV stoneburner | HP Microserver | 256GB Samsung 830 SSD for system | 4x 2TB in a RAID5
      OMV erasmus| Odroid XU4 | 5TB Data drive | 500GB Backup drive
    • Already tried the backports kernel, it´s a little bit better but 8 mb/s is still terrible.

      Yesterday i setted the p-state governor to userspace with an manual setted frequency and the speed went up to 70 - 80 MB/s which is very good.
      But i´ve to find a solution for this problem without loosing the pm features.

      Any ideas?
      OMV 4 Arrakis | Kernel 4.14 ... running on
      SelfBuilt NAS -- Asrock Q1900-ITX -- 4x 2,4 GHz in Burst Mode -- 4 GB DDR3 RAM -- RAID 5 -- 3x 3TB WD Red
    • wastez wrote:

      But i´ve to find a solution for this problem without loosing the pm features.


      Userspace does not mean you should loose power management. But u will need to configure a userspace daemon to do the job instead of the kernel. Wheezy comes with cpufreqd and cpufrequtils.

      I guess trying the kernel's ondemand governor did not do the trick for you?

      Can you tell what exact board or network adapter you are using?

      The post was edited 1 time, last by sektion31 ().

    • I´m using a Mini ITX Board with integrated CPU Asrock Q1900-itx.
      The strange thing is that sqeeze makes no problems with it.

      The Network card isn´t the problem cause iperf gave me fullspeed in both directions. (about 117mb/s)
      OMV 4 Arrakis | Kernel 4.14 ... running on
      SelfBuilt NAS -- Asrock Q1900-ITX -- 4x 2,4 GHz in Burst Mode -- 4 GB DDR3 RAM -- RAID 5 -- 3x 3TB WD Red
    • I'll look into your setup late, may be google can find something.
      Your situation seems difficult and a direction of the cause is not yet clearly visible. Sometimes a software-client like samba can trigger bugs in drivers, that are not obvious on first sight. If you had a second nic laying around it would not hurt to give it a try.
      This is also why I recommended to connect from your omv box to its own shares. Quick to do and it can give a hint in what direction to look for.

      The strange thing is that sqeeze makes no problems with it.


      Have you tried using an older kernel? snapshot.debian.org/ might be of help for that. But be careful to keep a working linux-image on your box :)
      A different idea might be to use sysresccd.org to use an different/older kernel.
      Although it is gentoo based, I had no problem booting my omv installation with it, after grub failed me on my 0.5 -> 1.0 update.
    • OK, just for information.
      Now i´m using the the backport kernel which includes the intel_pstate driver which is optimized for intel cpu´s and can handle the states much better.
      With this and the performance governor (intel_pstates just have two) the speed is incredible (read 117 mb/s, write 80 mb/s)
      The only thing is that the intel_pstate overclocks my cpu automaticly but hope this is no problem because intel_pstate normaly knows exactly what the cpu can bear.

      Thanks for your help.
      OMV 4 Arrakis | Kernel 4.14 ... running on
      SelfBuilt NAS -- Asrock Q1900-ITX -- 4x 2,4 GHz in Burst Mode -- 4 GB DDR3 RAM -- RAID 5 -- 3x 3TB WD Red
    • I installed the backports via omv-extra, so the kernel isn´t newer 3.14?
      Is this a problem?

      It clocks the cpu to 2.9 at turbo mode, so it´s a little bit over the manufacturs default value.
      OMV 4 Arrakis | Kernel 4.14 ... running on
      SelfBuilt NAS -- Asrock Q1900-ITX -- 4x 2,4 GHz in Burst Mode -- 4 GB DDR3 RAM -- RAID 5 -- 3x 3TB WD Red
    • One little other thing.

      Got on backports an error containing this error:
      firmware: failed to load rtl_nic/rtl8168g-2.fw (-2)

      I already have firmware-realtek installed but the version which is installed doesn´t contain the needed driver.
      In this package it would be implemented: packages.debian.org/jessie/firmware-realtek

      So what would the best solution to solve this problem?

      Edit:
      Already have it, seems the driver wasn´t for backports.
      intalled it with apt-get -t wheezy-backports install firmware-realtek
      OMV 4 Arrakis | Kernel 4.14 ... running on
      SelfBuilt NAS -- Asrock Q1900-ITX -- 4x 2,4 GHz in Burst Mode -- 4 GB DDR3 RAM -- RAID 5 -- 3x 3TB WD Red

      The post was edited 1 time, last by wastez ().

    • About the overclock situation: Are you sure you posted the correct model versioin of your CPU?
      Intels ARK site is usually correct and the J1900 does not have a turbo mode. However its seems to have a "burst speed". Will have to find out the difference..maybe burst affects all cores while turbo usually kicks in when only 1 or 2 cores are under load.
      In any case: The regular frequency is 2.0GHz and 2.4Ghz for burst. So 2.9 is 20% on top of that.
      Are you sure the frequency was lower under 0.5 Sardaukar? It might have to do with your UEFI settings
    • I´m sure in 0.5 it was the just 2.0 ghz for 100%....
      It uses the acpi_freq driver and this is get it directly from UEFI.

      My UEFI setting can´t edit the frequency, cause mainboard and cpu are together.

      I just can do the following:
      1.Find a solution to set a speed maximum on intel_pstate.
      2.Hope that the cpu can handle it.
      3.Go back to 0.5.

      Edit:
      Do you think it´s just an wrong displayed information?
      Cause the minimun is 1600MHz instead of 1300Mhz.

      OMV 4 Arrakis | Kernel 4.14 ... running on
      SelfBuilt NAS -- Asrock Q1900-ITX -- 4x 2,4 GHz in Burst Mode -- 4 GB DDR3 RAM -- RAID 5 -- 3x 3TB WD Red

      The post was edited 1 time, last by wastez ().

    • OK....
      Now i disabled intel_pstate via kernelflag and changed the governor to ondemand and now i´ve almost the same read/write speed but limited to 2ghz.

      What do you think generelly, is the default or the backports kernel better?
      OMV 4 Arrakis | Kernel 4.14 ... running on
      SelfBuilt NAS -- Asrock Q1900-ITX -- 4x 2,4 GHz in Burst Mode -- 4 GB DDR3 RAM -- RAID 5 -- 3x 3TB WD Red
    • Personally I would go with the default debian kernel, if everything else works fine beside the intel_pstate driver. Lower p-states (frequencies) still work without the driver on idle, right?
      The main reason for newer kernels is support for new hardware/drivers. But if these don't work I don't see much reason to use a backport provided kernel.
      I am not sure if the backport repository provides kernel updates more frequently. If so, that would be another argument in favor of the default kernel for me.
    • Ok, so now i´m writing a review cause i tested pretty much and my expierence can solve much time for other people.

      With the backport kernel i was able to reach again 117mb/s read and 60 - 90 mb/s write speed on afp.
      First i leave the automatic started driver intel_pstat with performance govenor which normaly is better, but in my case the cpu is detected wrong which mean two things:
      my system was overclocked from 2 Ghz to 2,9 GHz, but this could be managed by setting a max cpu scalling. But the other problem was that the minium frequency was also detected wrong (1600Mhz instead of 1300 Mhz)

      So i´m now using the backport kernel but with acpi_freq driver, but not with default conservative governor, ondemand did the trick for me.
      Seems like they have changed something in the newer kernel on it, so that more p-states can be used which is very important for me.

      Thanks for your help.

      Edit:
      Maybe a admin or a mod can split this theme in two. (the netatalk theme, and the performance issues theme)
      OMV 4 Arrakis | Kernel 4.14 ... running on
      SelfBuilt NAS -- Asrock Q1900-ITX -- 4x 2,4 GHz in Burst Mode -- 4 GB DDR3 RAM -- RAID 5 -- 3x 3TB WD Red