(2015-02-24, 11:00)Vlaves Wrote: [ -> ]Thanks for your great work here. I'm using my two HP Chromeboxes together with openelec and they are working great 
Except, that I would like to lower the fanspeed a lil.
Hopw would I do that in Openelec? Can you please help me out here?
Thanks again for your support
Regards
Vlaves
I have no idea, I was making a generalization - that's a question for the OpenELEC folks. But IMO it would be a bad idea to lower the fan speeds from the firmware defaults.
Why do you think, it would be a bad idea? At the moment I'm dual booting, so it's the stock firmware (HP). I guess, I should first try your coreboot, which seems to have way lower speeds already.
Did you or anyone else try to lower clockspeeds and/or voltages?
I'm using a MeLE F10 Deluxe (Airmouse) with my ChromeBox, works perfectly fine, except for turning it on, instead I am using WOL via Yatse on Android.
Maybe that helps.
@
Vlaves
If you find anything useful about how to control the fanspeed, please let me know.
A solution on OS level would be nice...
Has anyone noticed that the USB ports are a tad flaky? It seems especially bad when doing a reboot vs. a power off/on. The devices aren't initialized and don't show up in dmesg/lsusb.
I have two Asus Chromeboxes with the 01/29 firmware and it's happened on both with different devices (Pulse Eight CEC adapter, Logitech Unifying Receiver, usb3 nic). One is OpenELEC 5.0.2, the other Arch Linux with kernel 3.18.6.
Unplugging and re-plugging gets the devices to show up.
I'm using a 1 second boot delay, hoping maybe a longer delay will let the USB bus/devices settle.
Yes I have noticed they are a little flaky, on Kodibuntu the mce receiver doesn't seem to always work.Didn't have that problem on openelec. Rebooting seems to fix it. Also, on the hp chromebox the back usb ports are recognized better for me. Like when installing openelec the keyboard needs to be plugged into the back rather than the front.
(2015-02-24, 12:09)IngoRap Wrote: [ -> ]Why do you think, it would be a bad idea? At the moment I'm dual booting, so it's the stock firmware (HP). I guess, I should first try your coreboot, which seems to have way lower speeds already.
Did you or anyone else try to lower clockspeeds and/or voltages?
I'm using a MeLE F10 Deluxe (Airmouse) with my ChromeBox, works perfectly fine, except for turning it on, instead I am using WOL via Yatse on Android.
Maybe that helps.
@Vlaves
If you find anything useful about how to control the fanspeed, please let me know.
A solution on OS level would be nice...
I think it's a bad idea to go below the values I'm using, as you'll likely not be to control the temp adequately. The CPU/GPU clockspeeds are already dynamic, and we're dealing with a ULV processor - there's no room for tweaking there.
(2015-02-24, 16:43)naloj Wrote: [ -> ]Has anyone noticed that the USB ports are a tad flaky? It seems especially bad when doing a reboot vs. a power off/on. The devices aren't initialized and don't show up in dmesg/lsusb.
I have two Asus Chromeboxes with the 01/29 firmware and it's happened on both with different devices (Pulse Eight CEC adapter, Logitech Unifying Receiver, usb3 nic). One is OpenELEC 5.0.2, the other Arch Linux with kernel 3.18.6.
Unplugging and re-plugging gets the devices to show up.
I'm using a 1 second boot delay, hoping maybe a longer delay will let the USB bus/devices settle.
no, the stock firmware is flaky - the USB ports are fine. The dev boot screen timeout won't change a thing, all the hardware init is done well before the video comes on screen.
(2015-02-24, 16:58)calev Wrote: [ -> ]Yes I have noticed they are a little flaky, on Kodibuntu the mce receiver doesn't seem to always work.Didn't have that problem on openelec. Rebooting seems to fix it. Also, on the hp chromebox the back usb ports are recognized better for me. Like when installing openelec the keyboard needs to be plugged into the back rather than the front.
can't say I've seen any difference between front and rear ports on any of the boxes I've tested. Sounds like a flaky device rather than a flaky port.
(2015-02-10, 00:29)Matt Devo Wrote: [ -> ] (2015-02-10, 00:03)BenH Wrote: [ -> ]Hi Matt, I read in this thread that you have tried to increase the memory allocated to the GPU but have not had success. Did you test with various amounts of system RAM or just on a box with 2GB RAM?
Do you know if it works like some computers (Mac Mini's I think), where more GPU RAM is automatically allocated if you increase the total RAM in the system. Others allow increasing the max GPU RAM in the bios depending on the amount of system RAM.
When I check my M004u with 2GB RAM, there is 256MB allocated to the GPU. It would be interesting to see how much is allocated if there was 4GB or 8GB RAM.
Thanks
Ben
it's fixed to 256MB regardless of system RAM. I'll test something else now to see if I can bump to 512MB. stay tuned
Matt, did you have any luck with the test? Or is that still to do?
Thanks
Ben
Aside from upgrade the kernel is there any way to improve video/graphics quality?
I am trying to use the device to steam stream, and on wired network I'm getting 30% fps loss.
(2015-02-25, 00:04)BenH Wrote: [ -> ]Matt, did you have any luck with the test? Or is that still to do?
Thanks
Ben
so I talked to the Intel linux driver devs. The amount of system memory available as GPU memory to any application is completely dynamic, up to 2GB. The 256MB is just the aperture size. Steam's VRAM detection is completely broken, so it reporting 268.12MB or whatever is bogus and has no effect on performance. I don't think upping the aperture to 512MB would make any real difference in performance.
(2015-02-25, 02:02)Reb313 Wrote: [ -> ]Aside from upgrade the kernel is there any way to improve video/graphics quality?
I am trying to use the device to steam stream, and on wired network I'm getting 30% fps loss.
I don't think you're asking the right question here - it's not an issue of video/graphics quality. It's either an issue of your network dropping packets, or the ChromeBox not being able to decode/process them quickly enough. Given that the CB can handle decoding a 60Mbps 1080p h.264 stream without breaking a sweat, I'm guessing this is either a network issue or something Steam-specific -- but definitely unrelated to my setup script or Kodi performance...
(2015-02-25, 02:14)Matt Devo Wrote: [ -> ]so I talked to the Intel linux driver devs. The amount of system memory available as GPU memory to any application is completely dynamic, up to 2GB. The 256MB is just the aperture size. Steam's VRAM detection is completely broken, so it reporting 268.12MB or whatever is bogus and has no effect on performance. I don't think upping the aperture to 512MB would make any real difference in performance.
OK, thanks for looking into it.
I had an issue with video tearing on Ubuntu with mythtv frontend and tried the TearFree option in xorg, which fixed the tearing but made the video stutter occasionally (only in myth, not in kodi). I have now removed the TearFree option and installed the compton composite manager, which so far looks like it's fixed the tearing without stuttering.
From memory, someone mentioned dual channel ram might also increase performance, so that might be another option if I find some cheap enough.
Sorry to get off topic.
Ben
(2015-02-24, 18:02)Matt Devo Wrote: [ -> ]no, the stock firmware is flaky - the USB ports are fine. The dev boot screen timeout won't change a thing, all the hardware init is done well before the video comes on screen.
Matt, does the coreboot firmware improve this?
(2015-02-25, 06:44)katsup Wrote: [ -> ] (2015-02-24, 18:02)Matt Devo Wrote: [ -> ]no, the stock firmware is flaky - the USB ports are fine. The dev boot screen timeout won't change a thing, all the hardware init is done well before the video comes on screen.
Matt, does the coreboot firmware improve this?
the only thing that the firmware should affect is device init prior to boot. Once the OS boots, it does its own (re)init. I don't have any devices which exhibit the behavior you described, so I can't really say either way though.
Im using 2 logitech unifying receivers on the front of my HP. Troublefree. Standalone option with Kodibuntu.
Only problems are when I want to boot from USB, then I need to connect my usb stick in the back, and a hardwired keyboard in the front. And I'm not sure if I need to use the lower or upper usb port in the back, or the left or the right one in the front with my hardwired keyboard. Eventually I get the combination right and it boots fine.
Oh, and if I boot Gparted Live from USB, I recall needing to reinsert the unifying receivers, but luckily not with Kodibuntu.
weird, my unifying receivers work 100%, regardless of port used. Maybe it's your devices, not the receivers. Also, why are you using more than one receiver? kinda defeats the purpose unless you're moving one device between multiple systems
(2015-02-24, 18:02)Matt Devo Wrote: [ -> ]I think it's a bad idea to go below the values I'm using, as you'll likely not be to control the temp adequately. The CPU/GPU clockspeeds are already dynamic, and we're dealing with a ULV processor - there's no room for tweaking there.
There is always room for tweaking.
Intel, just like any other manufacturer, goes the safe route and sets voltages, that are rather high to ensure that the processor is stable, without much testing - it doesn't matter, that it's a ULV processor. Even smartphone SoCs that are binned best/fastest can oftentimes handle their tasks with much lower voltages.
Despite the clockspeeds being dynamic, while video playback the CPU sits at 1,4 GHz with less than 10 % load. I feel like it would be worth trying, to either lock it at a P-State with lower frequency or maybe a less "aggressive" governor?
Your settings for fanspeed might be good, but people with enough knowledge might want to make their own experiences, with their specific setup.
(2015-02-25, 10:05)IngoRap Wrote: [ -> ]There is always room for tweaking.
Intel, just like any other manufacturer, goes the safe route and sets voltages, that are rather high to ensure that the processor is stable, without much testing - it doesn't matter, that it's a ULV processor. Even smartphone SoCs that are binned best/fastest can oftentimes handle their tasks with much lower voltages.
Despite the clockspeeds being dynamic, while video playback the CPU sits at 1,4 GHz with less than 10 % load. I feel like it would be worth trying, to either lock it at a P-State with lower frequency or maybe a less "aggressive" governor?
Your settings for fanspeed might be good, but people with enough knowledge might want to make their own experiences, with their specific setup.
of course, but none of that requires modifying the firmware, it can all be handled at the kernel/OS level