olympia

Members
  • Posts

    458
  • Joined

  • Last visited

Everything posted by olympia

  1. No, it is not. It is some German crap... I wrote Kill-A-Watt, because that how most people know this measurement units. Sorry for the confusion. edit: I don't even think they actually have a 220v model for Europe, do they?
  2. Unfortunately the one I have doesn't have that feature (to measure watts).
  3. Last night I tried what you suggested and the idle power draw dropped from 60VA to 41-45VA overnight without a load, so it certainly seems like an issue with the batteries. However, I wonder where would it end up with new batteries. I feel 40VA is still a lot. Dilemma is now whether if to buy new batteries and live with whatever I end up or try to look up some good deal for another, greener UPS, e.g. the CyberPower mentioned here.
  4. Thank you for all feedback so far! You were right, it is actually 60VA, my meter is not featured with wattage measurement and since I am not deeply in electricity, I always considered "VA" as "watt". My UPS is the older model (SUA1500I), so it is probably not equipped with latest green technologies, still I find 60W(VA) is indeed FAR too much. ...but I don't think it actually do charge the batteries. If I am not mistaken in charging mode the UPS activates the fan and get a lot more noisy. What actually it does if it really charges. When this happens, then it draws 110-130VA. ...or is it possible that there is a low charging mode, when the unit actually doesn't turn on the fan, but still charging?
  5. I am using an APC Smart-UPS 1500. I was curious about the power consumption of the unit itself, so I measured today with a kill-a-watt and I was actually shocked to see it is sucking 60W in idle with nothing connected. It was also fully charged at the time of measuring. I am wondering if this normal... I thought it should be max. 15-20w. ...or is this something with my unit? Another, maybe silly question: is the UPS using more power as the batteries are wearing out? I.e. could the issue be due to weak batteries (I can imagine maybe they need continous charging or something)?
  6. It still doesn't move folders with foldername begins with a dot (".example") though. Maybe reduce your annoyance
  7. Why, there is a direct link from the download page... How could this be more slick?
  8. The same place as for all releases: http://dnld.lime-technology.com/beta/unRAIDServer-6.0-beta14b-x86_64.txt
  9. My network was going continously up and down with the above message in the log. Sometimes there was 10 minutes between two lockups, sometimes hours. There was no lockups at all if the server was in idle. I recompiled unRAID with disabled r8169 kernel driver and compiled r8168-8.039.00 from realtek instead of this. Problem went away. For two days, the link is rock solid as before. I suspect more people will have this problem when v6 becomes final.
  10. I am getting the following message in the system log, while my network gets locked up for about 5-7 seconds: Tower kernel: r8169 0000:04:00.0 eth0: link up I have Realtek RTL8111B LAN Controller on my MB. I remember this being an issue in v5 beta cycle where if I remember correctly the solotion was to move to disable the r8169 kernel driver and use r8168 driver from the vendor. I understood that recently we moved back to r8169. Is there anyone else experiencing this?
  11. I am almost sure percentage wise much more users want DVB support than e.g. having the possibility for Xen virtualization. I don't understand your standpoint saying "this wont happen in any reaosnable timeframe though". As other pointed out by others, the community is only asking to enable drivers via the .config / menuconfig option. No development needed at all from LT side. I see where you are coming from in your other post referencing OpenELEC. However, I really do think that most users would just be fine with and accomodate the "unsupported" approach. Moreover, Tom is some earlier discussions was positive about this - I think he just hasn't had the chance to look at this. Users would only be fine with it if it works. If it doesn't work and we include the driver, the inevitable will happen where users will ask for updates and further patches. This is why I like host device pass through with a virtual machine. Drivers for unsupported devices like these can be supplied via a guest VM which is updated and maintained on a regular basis. Furthermore, any complications from those drivers are isolated from impacting the host thanks to isolation. For USB devices, this doesn't even require IOMMU (Intel VT-d). I tend to lean more towards NAS on this, but it really isn't my call, but Tom M's as it involves the driver stack. I will ask him to weigh in with his opinion. First of all, thank you Jon for picking this up! I couldn't agree more that host device pass through with a VM is best solution. However, I think you appreciate that it is hard to justify the cost of VT-x capable HW being couple of hundreds, if the current setup can perfectly handle the use case. I think you misunderstood something. This is working and you don't need to include anything else, just the drivers. Plenty of people are using it either by recompiling each and every release themselves (like myself) or using a community build shared accross here in the forum. I think what NAS was saying above is that _some_ drivers might not work and need patching. Heck, that's were I think you can say if it doesn't work upstream, then you can't do anything about it. That's where I said people will be fine and accomodate. They will buy what is proven to work. As for Tom's latest known opinion, you can read about here: http://lime-technology.com/forum/index.php?topic=19819.msg176976#msg176976
  12. I am almost sure percentage wise much more users want DVB support than e.g. having the possibility for Xen virtualization. I don't understand your standpoint saying "this wont happen in any reaosnable timeframe though". As other pointed out by others, the community is only asking to enable drivers via the .config / menuconfig option. No development needed at all from LT side. I see where you are coming from in your other post referencing OpenELEC. However, I really do think that most users would just be fine with and accomodate the "unsupported" approach. Moreover, Tom is some earlier discussions was positive about this - I think he just hasn't had the chance to look at this.
  13. I agree - but that is not a new feature! Since it only seems to affect a proportion of users if fixing it proves a bit intractable then I can see this being something that could still be outstanding as a "Known Issue" even when v6 goes final. After all it is not something that can lead to data loss or something like that. The downside is the cost of the power (and possibly extra noise/heat) due to disks not spinning down. Some have worried about disk lifetime due to this issue but much of the evidence seems to point to it increasing disk lifetime as spinning disks up/down is harder on them than continually spinning.. This would be a very weird approach at the very least. Spinning down drives is one of the core and greatest feature of unRAID. Releasing v6 with a known issue like that would be just like I said - VERY strange. Just because you are not affected or just don't care about this, you shouldn't think this is OK. ...and there were smaller than this bugs holding up a release in the past.
  14. I am sorry if this has been asked before, but I haven't seen it. Does a dockerized application have direct access to HW resources? I am wondering about this to see if it was possible to dockerize TVHeadend. As most of us know, the unRAID kernel doesn't include those modules and drivers what are required to run TVHeadend so unRAID can actually be used as a TV server. Currently the only way to get around this is to recompile the kernel with the necessary modules included. So is Docker making this easier or it doesn't have access to the HW?
  15. It provides a good overview on the overal health of your system while in idle. ...and see no point in your objection either. Anyway, it's up to bonienl to decide and whether if the reasoning behind is valid or not, I am thankful him to his work.
  16. There is a danger that disks spin up when being queried for a temperature read, this also affects the 'load' speed of the GUI, i.e it becomes sluggish. Two reasons why is it not implemented. Unmenu had never ever spin up my disks and I haven't read any such issue reported during the years unmenu has this feature, but fair enough... Point taken...
  17. Great work! Thank you! Would it also be possible to adopt unmenu's way of hdd temp checking so that temps (WD drives) will be displayed even when the disks are spun down?
  18. Ok, thanks, I will figure the HW support. I was just wondering that until it's very obvious that some core2 CPU support vt-d, say the e8400, it is not so certain if there is ANY LGA 775 motherboard with IOMMU support to house them. Anyway, as said I will sort this out. Back to the ups question: I think it is just the first step the ups talks to Linux, but I suppose there are additional configuration required for KVM to shut down the VMs as well, before shutting down the host, no? ...and a bonus question. Say I have a tv tuner card to pass through. Does this card itself need to support pass through as we'll, or once pass through works on the hypervisor level, will this surely work? Edit: what CPU are you using with your asrock extreme and/ or what would be the minimum you would recommend? Thanks again!
  19. Hi Grumpy, First of all, thank you very much for your hard work on this! It looks pretty exciting! Secondly, please let me ask a couple of questions: 1. I am a bit confused about the required HW. It's clear that vt-d is needed for pass through, but reading the topic I read out that IOMMU is a must have as well? If this is the case, I believe this close out all core2 CPUs what are otherwise vt-d capable. At least the link you shared tells that only ivy sandy and Nehalem CPUs support IOMMU. Is this understanding correct? 2. Did you experiment with UPS integration into this solution? If yes, do you have solution for the UPS shutting gracefully down everything if required? 3. Do you have some rough number for performance comparison with bare metal? Thank you very much for your feedback in advance. Edit: khm, reading a bit more seems like vt-d=IOMMU? Phew...
  20. This one is also packed together with fuse. I don't want any package to overwrite default fuse. That would be dangerous. No, it's sshfs only. It's just called "sshfs-fuse". It installs a single binary: /usr/bin/sshfs Thank you! Based on some the quick and rough first tests it looks like working quite well!
  21. This one is also packed together with fuse. I don't want any package to overwrite default fuse. That would be dangerous.
  22. I would like to do the opposite. I want the unRAID server to be the sftp client and mount a remote share on a remote server.
  23. I am trying to figure out if it is possible to permanetly mount a remote folder using sftp, but no luck since it seems sshfs would be needed. There are slack packages for sshfs, but it seems to be together with fuse and I am a bit afraid installing it would interfere with the default fuse comes with unraid. Does someone know how this would be possible? Thank you in advance!
  24. Hi, I think it was not mentioned before: In case the 'Confirm reboot & powerdown commands:' is set to 'No', then you can't reboot and powerdown because those buttons are greyed out.