Jump to content

lionceau

Members
  • Posts

    70
  • Joined

  • Last visited

Posts posted by lionceau

  1. Ubuntu 18.04 LTS with all powertop settings on "good" idles at 16W on my Dell T20, Unraid with the exact same hardware idles at 31W for no good reason. CPUs were idle and disks were spun down in both tests.

    Even with this quite power efficient hardware and 0,28 cent per kWh that's ~37 euros per year or the price of a Tier 2 "Plus" license in two years.

    I'd rather pay Lime Technology than my power company, it would help save the environment too.

    • Upvote 2
  2. Ok, I'm at the UPS now and did some research. You're right in that unRAID doesn't control the delay. This "Turn off UPS after shutdown" functionality doesn't work with Cyberpower UPS and should be set to "NO" or you will experience behaviour such as the scheduled hard shutdowns I experienced.

     

    There's also no way to change the default 1 hour shutdown delay/schedule, not even in the Windows software or unRAID's apctest. APC units default to 90 seconds. I'm going to do some more research on this considering the poster in the freeNAS forum seems to be able to control this via USB.

     

    There's a longer thread here:

    http://lime-technology.com/forum/index.php?topic=13411.0

     

     

  3. The UPS itself doesn't have an option to change this on its LCD, but perhaps there's a way to change this with the Windows software. I've never installed that software (and didn't plan to) but will try it via a VM.

    As I mentioned the UPS is no longer attached and I'm at the office right now, so I can't debug it any further right now.

     

    based on the command list here I do suspect that it's a linux daemon passing the command for the delayed shutdown via USB , perhaps with load.off.delay :

    https://forums.freenas.org/index.php?threads/cyber-power-systems-cp850pfclcd-working.18673/

    Maybe something in the UPS firmware changed and it now expects minutes instead of seconds? Of course I could be wrong and it really is some EEPROM setting stored in the UPS, but then it'd be helpful if the "Turn off UPS after shutdown" setting came with a warning for these cases.

  4. Description: 

    UPS plugin schedules 60 minute (one hour) poweroff after graceful shutdown/halt

     

    How to reproduce: 

    execute a graceful UPS shutdown with the "Turn off UPS after shutdown" setting in unRAID enabled and the Cyberpower CP900EPFCLCD connected via USB

     

    Expected results: 

    UPS shuts down seconds after computer halts gracefully, enabling the computer to power back on automatically after mains power is restored

     

    Actual results: 

    UPS continues running and schedules a hard poweroff 60 minutes (one hour) after computer halts, even if the server is running with mounted filesystems at that point. This schedule also persists through resuming mains-power and — from what I can tell — cannot be canceled with any of the three buttons. A 59 min countdown is displayed on the UPS' LCD screen which automatically turns off after 5 seconds of inactivity. 

     

    Other information: 

     

    I have a new Cyberpower CP900EPFCLCD which is detected correctly by unRAID.

     

    There's one bug though, the "Power Off UPS" option in the unRAID UPS settings panel schedules a hard power-off n one hour (60 minutes) instead of the presumably intended 60 seconds after halting the computer. This schedule persists through mains-resume/power on and will be executed no matter what.

    You can probably guess the rest and how I found out about this bug. :(

     

    Can anybody reproduce this?

     

    One explanation would be that APC uses seconds and Cyberpower uses minutes as the default unit. I know the feature worked fine with my old APC and shut the UPS down after a minute.

  5. I had problems with something "thrashing" my disk with reads causing one disk to always stay spun up. After some troubleshooting I found that it was cache_dirs plugin.

    It seems that one of my backup folders contains a large amount of directories, apparently too many to fit into RAM, so cache_dirs read the structure from disk every 10 seconds because the cached structure got evicted in the mean time. This resulted in endless directories reads from disk to memory. Not great.

     

    Excluding that folder worked for the most part but some reads were still not cached; now I doubled my RAM, included the folder again and had zero read/write from any disk in the past few hours.

    Is there any way to figure out how much memory the cached directory structure currently uses?

  6. 18 hours ago, JohanSF said:

    Paul, thank you for clarifying once more. My strategy is to follow this thread and pull the trigger on an unRAID Ryzen server when you announce that the stability issues have been fixed and not a second before that.

     

    I am in the same position, looking to replace my quadcore Haswell which idles at only 35W, about 40% of what an overclocked Ryzen system seems to consume.

     

    Since Pauven says it's an unRAID specific problem I may just keep my unRAID Haswell system as a strict NAS and build a second Ryzen-based system with a different Linux distribution as my workstation which I'll shut down when it isn't in use.

  7. On 6/16/2017 at 3:38 PM, 1812 said:

     

    Link to thread?

     

    http://www.insanelymac.com/forum/topic/309087-insanely-fast-virtual-mac-qemu-ovmf-clover-and-native-graphics/page-25

     

    Looks like this requries QEMU 2.9.0 to work. The parameters are simple enough to add to the unraid XML, but I haven't updated to 6.4-rc yet. 

    Once 6.4 is stable and those parameters are confirmed working we should be able to use macOS on unraid with unpatched clover versions.

    • Upvote 1
  8. somebody (helgrind over at insanelymac) seems to have found a way around the clover patch, does anybody know how to convert this to unraid compatible XML?
     

    I think I've found a way to avoid the ugly Clover patch:
    -cpu Penryn,vendor=GenuineIntel,kvm=on,+invtsc,vmware-cpuid-freq=on
    vmware-cpuid-freq requires kvm to be exposed and invtsc enabled, hence the kvm=on,+invtsc
    Tested on qemu 2.9.0.

     

  9. I feel like fixing the Global C-State and NPT bugs, both issues that look like they could be software related, would go a long way towards making Ryzen attractive for Unraid. A 10-20W idle increase over my quadcore haswell Xeon would be acceptable, but an additional 40-50W of needless idle power consumption and mysteriously crippled multicore VM performance is not.

    A shame really, looks like I'll have to wait for Skylake-X/Kabylake-X and lose the ECC support or wait a year or so for the refresh of Ryzen.

     

  10. Yes, GPU PCIe bandwidth has surprisingly little effect on gaming performance in my experience.

    Many OSD programs show PCIe bus saturation and the most I see is 5-7% on loading screens where the VRAM is being filled with textures from RAM or SSD. Typical bus utilisation during gaming is around 1-2% even when with remote streaming.

    Of course this could be wildly different with other workloads running CUDA.

     

    The GPU PCIe bandwidth topic often comes up with people running external GPUs over Thunderbolt. What they don’t realise that it's the significant latency from protocol encapsulation/translation that robs performance, not the raw throughput.

     

  11. Yeah, I think you are on the right track regarding power consumption.

     

    Based on other reviews Ryzen should be fairly economic in idle, perhaps 5-10W higher than Kaby Lake. 5 Gbit/10 Gbit LAN controllers are known to be very power hungry. It'd be quite disappointing if it turns out that the BIOS only disables access but not power to the chipset.

     

    Gaming mainboards in particular don't seem to pay much attention to these details because what's another 10W here and there when you have 8 case fans and six LED strips.

    I suspect a basic B350 board without all the extra features would idle much lower but unfortunately these usually have very questionable 4+2 phase power layouts.

     

    Idle power consumption between a 1700 and 1800X should be almost identical when all cores are clocked down. TDP really only suggests  power consumption at maximum load and in the case of Ryzen that's maximum load on one core at boost.

    Actual power consumption at 100% load on all cores is usually much higher.

  12. 4 hours ago, Pauven said:

    I've found something odd related to power consumption.

     

    I'm running an 1800X on the ASRock X370 Fatal1ty Professional Gaming and a GeForce GTX 670.

     

    It is idling at 46w in Windows 10 ("Performance" power profile), but 56w in unRAID (Safe Mode).  No array drives configured or even installed.

     

    Any ideas why unRAID would be consuming 10w more, just sitting there idle?

     

     

    Perhaps it is the GPU? Unlike Windows 10, unRAID doesn't have graphics drivers with power managmentby default.

     

    My power consumption drops by ~12W when I start my Win10 VM with Nvidia WHQL drivers and my GTX1060 passed through.

     

    Thanks for the numbers by the way. Quite a bit higher than I hoped they would be. I wonder if the full featured mainboard with a 5-Gbit NIC, Soundblaster and other fancy features is party to blame. 

     

    As for EDAC I don't think Ryzen supports it. I remember reading that ECC and single error bit correction is silently functional but not validated and unsupported.

    Two-bit error correction with reporting and kernel halt is not implemented and won't work with standard desktop Ryzen.

    I guess that's where they draw the line for Naples or some other dedicated workstation SKU (Ryzen Pro?) 

  13. 1 hour ago, hblockx said:

     

    I am idling with around 70 Watts, but:

    Watercooled (pump is around 10 watts) , overclocked to 3.9, ram set to 3,5V, several harddrives, 980ti, 1050ti, 6 fans and just bronze psu (@wall)

    So i guess 60 watt is a bit too much without that all?! I would say 40W are achievable...

     

     

    Yes, thanks for the data point. I'm very curious what a "bare" system would idle at.

    10W for the pump, 7W per idle graphics card, 1W per fan would bring it down to 40W OC before any minor "tweaks" like deactivating the soundcard or any unused controllers, etc.

    That's not as bad as I thought it would be.

×
×
  • Create New...