Search the Community
Showing results for 'pinebook' in topics.
-
I added a simple benchmarking script to the StabilityTester repo: https://github.com/ThomasKaiser/StabilityTester/commit/c6c72812d1e5d1458f9257f0398534e253fa3373 If you clone the repo it's just switching into the directory and doing a 'sudo ./benchmark-pinebook.sh' (don't forget to let a 'sudo watch -n2 pine64_health.sh' run in another shell in parallel to get an idea what's going on). My results (Pinebook allowed to clock up to 1.2 GHz since proven reliable and increased thermal trip points so let throttling start later): w/o throttling throttled openssl speed rsa2048 -multi 4: 9170 7313 (80%) minerd --benchmark: 3.59 khash/s 2.84 khash/s (79%) xhpl64: 2.86 GFLOPS 2.30 GFLOPS (80%) 7z b: 2680 -- (lightweight) Interestingly the first three benchmarks are all affected by throttling in a similar way (20% performance drop) with Pinebook lying flat on a table and an idle SoC temp of ~40°C. For anyone trying this out: You won't get my scores above since your Pinebook is only allowed to run at 1152 MHz max and throttling settings today are not optimized too (if you want to be able to run your Pinebook at 1.2 GHz please read above how to contribute, test and submit your results). In case you want to explore how badly battery charging affects benchmark scores please keep in mind that you would have to adjust the following line since SoC idle temperature will be around/above 50°C in this situation anyway: COOLDOWNTEMP=50 This benchmark script should execute on any other 64-bit ARM platform and comparing results can be quite interesting (since some of those benchmarks benefit greatly from higher memory throughput for example)
-
Today @longsleepadopted community's work from last year on improved throttling and so called dvfs settings: https://github.com/longsleep/build-pine64-image/commit/227b8b7641390b6d3181166b53514a39e0c12820 In other words: Now (or with ayufan's Android and Linux builds starting from tomorrow or the day after) benchmarking Pinebook gets interesting since settings prior to this fix were broken Allwinner defaults resulting in low performance. In other words: forget about any benchmark results you've seen so far, they were all made with wrong settings. It should also be noted that while Pinebook is charging top performance is negatively affected since the PMIC gets quite hot while charging the battery and dissipates that heat over to the SoC which will in turn throttle earlier under full load --> benchmarking Pinebook is recommended while running on battery! On a related note: If community helps (we need results from at least 20 different Pinebook) there's a chance to enable 1200 MHz instead of 1152 MHz as maximum cpufreq on Pinebook: https://github.com/ThomasKaiser/StabilityTester All you need is a Pinebook, ayufan's 0.4.4 Xenial or above, some room in your fridge (since otherwise the test is useless since 'Throttling happened, results invalid'), 30 minutes of patience to let the Pinebook cool down and then: sudo apt install git git clone https://github.com/ThomasKaiser/StabilityTester cd StabilityTester sudo ./check-pinebook-cpufreq.sh Pinebook will reboot after approx 30 seconds, then login again, simply execute 'check-pinebook-cpufreq.sh' as root again and submit results (full output as can be seen on Github). To revert changes after testing it's as simple as sudo mv /boot/pine64/sun50i-a64-pine64-pinebook.dtb.bak /boot/pine64/sun50i-a64-pine64-pinebook.dtb && sudo reboot
-
Good to know (for whatever reasons I did not even try suspend/resume now). BTW: In this release /usr/local/sbin/install_rpi_monitor.sh is included with a more recent RPi-Monitor template that displays/records battery parameters. I'm especially interested in results from 11" users whether battery capacity calculation gets better over time (also a lot of other parameters are exposed, see commit from 3 days ago), One issue I ran into is that rpimonitor for whatever reason quits one hour after booting: root@pinebook:~# uptime 07:31:31 up 17:07, 2 users, load average: 0.16, 0.11, 0.13 root@pinebook:~# systemctl status rpimonitor ● rpimonitor.service - LSB: RPi-Monitor daemon Loaded: loaded (/etc/init.d/rpimonitor; bad; vendor preset: enabled) Active: active (exited) since Fri 2017-05-05 15:08:14 UTC; 16h ago Anyone has a clue what the culprit might be? Besides that: Yes, IMO both keyboard and touchpad are rather annoying on the 14" (no 11" around so this does only apply to the large variant)
-
I've installed Ayufan build xenial-mate-pinebook-bspkernel-0.4.2-47.img.xz and it effectively seems to be fixed. I've closed/flipped the screen and left it in suspend mode, and I opened back 4 hours later, battery was still around same 94% level seen previously. EDIT : about 8 hours later, my pinebook is around 81% charged/unplugged, it was probably around 92% when I resumed halt an hour ago. BTW, one thing I start hating : the trackpad is too much sensitive : I try to avoid touching it, and I'm still using external mouse, because I hate those pads anyway, but even not using this pad, while typing on keyboard, if my fingers are too near of the pad, it product a mouse-click event and I'm doing bad typos ...
-
Prime scores identical with Pinebook (tested again, this time two times to ensure the benchmark runs all the time with A64 just clocked with 1104 since slight throttling occured). So there's something wrong with cpufreq (H5 should be allowed to clock up to 1.34GHz). Anyway just to keep this in mind for those working on OPi PC2 or Prime right now: 7z/tinymembench numbers of Pinebook as reference (running at just 1.1GHz and using 2 GB LPDDR3) here: https://pastebin.com/rvrhevXr
-
Thank you! So in 'active benchmarking' mode we discovered that there's something horribly wrong with our RK3288 images currently! Numbers are way too low (XU4 scores with 4966 vs. 2725 -- first number running on the big cluster, latter on the little, so MiQi must get close to or exceed 5000). Fortunately you submitted whole output so most probably there's something wrong with both cpufreq settings and DRAM bandwidth. Even a boring Pinebook scores higher:
-
Just to asking people to give their own feedback here about suspend/resume of the Pinebook. Today I've experienced a total battery drain-out in 12 hours after a manual explicit suspend or a screen flip-close (what I'm not sure which I've done). In the past days, I did it often, but most of the time, either I've re-plugged charger for the night, or only suspended it for couple of hours. It would be interesting to know for all of you how long a real suspend can last without charging.
-
My charger is unfortunately limited to 5W discharge, but since this is pretty close to the PineBook consumption it should be okay. It's certainly good enough to accurately determine the battery capacity. I'm just waiting for my PineBook to ship. When it arrives I will do a few cycles on the battery to test the capacity outside the PineBook. Edit: I have a coupon valid until 4 May 2017 (tomorrow) to order a 14" PineBook, if you want to skip the queue. The order is estimated to ship at the end of May. If anyone is interested, PM me your email address and I will send you the code to order. You'll have to use my email address, but I'm happy to forward any emails from Pine to you.
-
Some Pinebook news: In the meantime a lot of issues have been resolved by community and fortunately ayufan added also Linux as target to his fully automated builds. Here you get latest releases: https://github.com/ayufan-pine64/linux-build/releases For anyone wanting to explore the bleeding edge (that means i3) be prepared that the Desktop uses a Debian wallpaper but since auyfan's builds are based on @longsleep's it's an Ubuntu Xenial and default login/pwd are ubuntu:ubuntu. First steps with i3: https://i3wm.org/docs/userguide.html The Network Manager GUI is not installed (fortunately since it would add half of the GNOME desktop stuff) therefore connecting to Wi-Fi is just the usual 'sudo nmtui' in a terminal and a second later you're in (in this build there is both wlan0 and wlan1 enabled -- choose either one for your client connection and keep in mind that you can use the other Wi-Fi interface later for an AP that works in parallel to client mode) Now exploring i3 booting ayufan's image from SD card the Pinebook starts to make some sense... eMMC is accessible in this release and a simple pine64_install_to_emmc.sh script is contained so you can even transfer the image to eMMC if you want (just like with Armbian's nand-sata-install) which asks you to choose a fresh OS image from a list which will then be downloaded and overwrites the eMMC's contents. But it's not necessary to run from eMMC so in case you own an SD card with high random IO performance exploring new OS images the next few weeks booted from SD card seems to be the best way.
-
And another update. Did another charge/discharge cycle and now it seems something went wrong: All graphs being at zero from 20:20 - 22:10 was due to RPi-Monitor being stopped then. But what troubles me is that the '2 percent battery capacity' event didn't fire. The Pinebook should've issue a 'shutdown -h now' at 3:45 but instead continued to run and drain the battery until input voltage might be that low that AXP803 cut power?
-
Another minor update on Pinebook battery (for those having trouble to understand what's written: this is still NOTHING related to battery life estimates since the OS image I'm running is not in good shape and an ugly monitoring hack is running in the background) This is another full charge/discharge cycle. I allowed charging with up to 15W which is somewhat problematic since further activity will add consumption (eg. running the stupid sysbench pseudo benchmark) and then the power budget easily exceeds the PSU's capabilities (5V/3A). So as @Xaliusalready suggested decreasing this value by a few W might be a good idea. With these settings PMIC temperature again maxed out at 81°C while charging (and SoC temperature is affected since connected to same metal plate). When running on battery with disabled camera stuff and only Wi-Fi connected the average battery drain was ~2.8W and reported capacity rather precise. The OS is configured to do a 'shutdown -h now' when battery capacity reaches 2% and this worked flawlessly since my SSH/Wi-Fi session did not time out but was correctly terminated -- see below. As can be seen also below there's constant background activity that might be responsible for a few 100 mW more being wasted than necessary and after following some discussions over at http://irc.pine64.uk I came to the conclusion to let the dust settle first and put the Pinebook in the drawer for at least two weeks. In the meantime ayufan let an automated Linux build that works a lot better than official Pinebook Ubuntu image, @longsleep started to work on Pinebook and so everything is simply too much WiP at the moment.
-
I honestly expected better power efficiency out of this (my before mentioned asus typically draws around 1-2W less while being much more powerful) but i guess this is the cost of bottom barrel components (namely soc). Any news on when pine has intention of selling these things to the public (and not just built-to-order) ? edit: just for fun i measured some values on my x205ta (11", baytrail cpu, same battery as pinebook): -no wifi, idle screen off -- 0.7W -display on, idle, wifi off -- 2.0-2.2W -browsing armbian, wifi on -- 3.3-4.5W Budget SoCs have still a long way to go as far as power is concerned; but then again we're talking about a soc that costs at least 5x more in bulk than a64
-
Since my battery starts to learn (remaining battery capacity display gets better and better) I pushed a preliminary DT for Pinebook containing some tweaks compared to the ones that ship with 'official' Ubuntu images: https://github.com/armbian/u-boot-pine64-armbian/commit/c751ad4f6a3867da84a1c57b82b6484f24295470 The .dts can and should be used with official Pinebook OS images (especially on 11" Pinebooks) to get some feedback whether calibration works or not (needs few charge/discharge cycles). How to use: cd /tmp wget https://raw.githubusercontent.com/armbian/u-boot-pine64-armbian/c751ad4f6a3867da84a1c57b82b6484f24295470/blobs/pinebook64.dts sudo apt install device-tree-compiler # not needed on Armbian sudo cp -p /boot/pine64/sun50i-a64-pine64-pinebook.dtb /boot/pine64/sun50i-a64-pine64-pinebook.dtb.bak sudo dtc -I dts -O dtb -o /boot/pine64/sun50i-a64-pine64-pinebook.dtb pinebook64.dts sudo reboot Benefits: charge led working faster charging more precise capacity display battery in self-learning mode Doing this stuff without setting up monitoring first is somewhat useless of course
-
And another update. Now while discharging we get the total amount of power needed (by multiplying voltage_now with current_now but also from AXP803 debug output --> power_sply). I added this to the monitoring and end up with the following numbers (no peripherals, only Wi-Fi active): Moving mouse around with default brightness: ~4.6W Leaving Pinebook alone waiting for backlight dimming: ~3.5W Waiting another few minutes until display is blanked: ~3W Now running 'stress -c' in a SSH shell: ~6.5W (the 6.2W below happened with slight throttling) So we're talking about slightly more than 3W while doing nothing with blanked display. Let's compare with Pine64/Pine64+ where we have an idle consumption of 1.5W/1.8W (the Gigabit Ethernet PHY is responsible for ~350mW alone). On Pinebook we've no Ethernet PHY but the RTL8723CS Wi-Fi/BT combination, an internal USB hub and two devices currently active: trackpad and camera. Unloading/backlisting the camera and video drivers helps a little wrt consumption but it's more or less negligible. In other words: suspend/resume has to be working on this laptop
-
Another battery update. After doing some DT adjustments I let the Pinebook fully charge. In the meantime I also added monitoring of the PMIC temperature. AXP803 gets quite hot and since it 'shares' heat dissipation with A64 (both use thermal pads connected to the same metal plate) this also affects reported SoC temperature (when AXP803°C internal thermal sensor reports +75°C then A64 temperature increases by more than 10°C). Charging led went off and now it looks like this: Unfortunately PMIC temperature currently isn't available via sysfs so it needs an ugly hack (a script running in the background, parsing AXP803 register debug output and writing it to /tmp/pmictemp where it's being picked up by RPi-Monitor). I hope this will be fixed soon upstream in BSP kernel sources.
-
Small update regarding battery on Pinebook: http://irc.pine64.uk --> Select date '27-04-2017' --> skip everything before (search for) '21:15:47' Edit: this is the 2nd discharge cycle with Pinebook mostly being idle with inactive display. Battery wasn't charged completely before so this is NOT an estimate of battery life but I just want to get a clue whether the charging circuitry starts to learn on its own or not: And this is how to look at AXP/registers (learned that yesterday night from @Xalius ): I tried to adjust DT once again to match Xalius' recommendations (especially set 10000mAh): http://sprunge.us/FORP And in the meantime I added also battery current to my monitoring so here is most recent RPi-Monitor template: http://sprunge.us/TEVO
-
Can any test actual battery capacity with discharging manually (like with imax b6). I'd really like to know if the batttery is really 10Ah or just 5Ah pretending to be 10Ah. Also, what about power consumption when i use ? Also, this seems to be more of a developer toy than anything else. If you want a usable, tiny, power efficient/longlasting runtime and cheap, something like an asus x205h will provide a much better value. While i was waiting for pinebook to come out (to satisfy my tiny laptop itch) i grabbed one of those x205s for 75$ used and it works great (none of the crappy arm support; it just works like x86 should). But enough the offtopic, just a general suggestion.
-
And guess what: this battery has to be charged. I made a small tweak overtaking Kamil's latest Pinebook DT entries for the battery and now charging happens at 15W compared to below 7W before. The Pinebook started charging with a near empty battery 9 hours before so with Micro USB and a shitty USB cable between Book and PSU a full charge cycle might exceed 24 hours easily. And those 15W are pretty much the maximum Pine Inc's 5V/3A brick can provide For the battery changes (faster charging and charging led on) see here I made a minor tweak to get slight 'overclocking' (won't share how of course) And then I disabled Ubuntu's strange ondemand service by 'sudo systemctl mask ondemand' (which can cause some troubles depending on kernel config) and installed/configured cpufrequtils instead (using interactive cpufreq governor)
-
And BTW: Pinebook has also eMMC so you might want to have a look into ayufan's PR from yesterday here: https://github.com/longsleep/build-pine64-image/commits/master Also interesting: https://github.com/longsleep/u-boot-pine64/commit/314bb8a9e7d37a37cc225b039601c7c62e409103
-
Well, I compared the drawing on the Chinese wiki page a few days ago with my M3 and I fear a heatsink (thermal pad) that doesn't cover A64 in a centered way can't be that efficient (same for AXP803). But you might be right and that might also be the reason why the I2S header isn't populated. Using an external antenna then might also require removing the heatsink. Hmm... Since we're talking about A64 already. Pinebook should be ready in January (to be sold after Chinese New Year later) and Pine folks develop a clusterboard suitable to host 8 SoPine (one master node with eMMC, all SoPine equipped with 128Mb bootable SPI NOR flash and a 10 port Gbit Ethernet switch IC onboard. Prototype will be ready next year, then we start to disclose more information.
