Quick Pinebook Preview / Review

[tkaiser]

Yesterday my 14" Pinebook arrived so I thought I'll collect some already available information. A lot of work still has to be done to get a decent laptop experience with this hardware so this is neither a review nor a stupid Un-Review but just a preview instead.

 

To get the idea about dimensions I added a 13" and a 15" laptop to the picture. Pinebook is wedge-shaped and thickness matches both the 2011 15" MacBook Pro and the 13" from 2015:

 

 

Display size closely matches the 13" MacBook Pro (but of course pixel density / resolution don't match as well as quality: TN vs. IPS and coating -- it should be obvious if you've the 'you get what you pay for' principle in mind but I'm sure we'll see reviews somewhere else where people are comparing Pinebook with Chrome/MacBooks and think they would get the same display quality for a fraction of costs)

 

Last hardware detail: heat dissipation. I've been curious how well the Pinebook's thermal design is and it looks pretty good. This is the moronic sysbench pseudo benchmark calculating prime numbers endlessly and the Pinebook sitting on a pillow to prevent airflow below the case bottom. Throttling settings are rather conservative with 65°C defined as first trip point and only after a couple of minutes the internal A64 SoC temperature reached this value and slight throttling occured (1.15 GHz down to 1.1 GHz, that's a 'difference' you won't be able to notice). So it seems the combination of a thermal pad with a large metal plate inside the case is rather sufficient:

 

 

What you see here is a graph drawn by RPi-Monitor, one of my favourite tools to get a clue what's going on with ARM devices (since it's not a heavy monitoring tool that changes the way the OS behaves but it's pretty lightweight sp you can run it in the background and let it monitor/record stuff like cpufreq scaling, consumption and so on).

 

Pinebook currently ships with a rather clean Ubuntu Xenial on the eMMC with Mate desktop environment based on latest BSP u-boot and kernel. To get RPi-Monitor installed on this Ubuntu @pfeerickprovides a script (please follow progress over there). When I played around with Wi-Fi I noticed that Wi-Fi powermanagement seems to be enabled (makes working via SSH close to impossible) and that MAC address changes on every reboot. To disable Wi-Fi powermanagement I simply used the Armbian way:

root@pinebook:~# cat /etc/NetworkManager/dispatcher.d/99disable-power-management
#!/bin/sh
case "$2" in
up) /sbin/iwconfig $1 power off || true ;;
down) /sbin/iwconfig $1 power on || true ;;
esac

Unless Wi-Fi driver gets a fix to use a MAC address based on the SoC's individual so called SID one way to assign a fixed MAC address for the Wi-Fi is to add a wifi.cloned-mac-address property to all NetworkManager profiles after establishing a Wi-Fi connection first:

nmcli con show | grep wlan | while read ; do set ${REPLY}; nmcli con modify "$1" wifi.cloned-mac-address $(cat /sys/class/net/$4/address); done

(I'm pretty sure some masochistic people prefer fiddling around in /etc/network/interfaces instead so if you're not using your laptop as a laptop being carried around and seeing a lot of Wi-Fis you can also use the usual tweaks for the interfaces file. Please also note that using a random MAC address can be considered a privacy feature on laptops since it makes tracking of you in public environments harder).

 

While watching the Pinebook's charging/discharging behaviour I noticed that consumption drawn from wall while charging oscillates between 9W and 15W while being used and display active so it's really great that Pine Inc fixed Pine64's design flaw N° 1: Pinebook is NOT equipped with shitty Micro USB for DC-IN leading to all sorts of trouble but just like SoPine baseboard now uses a 3.5mm/1.35mm barrel jack combined with a 5V/3A PSU (for other hardware details please refer to linux-sunxi wiki page).

 

Battery status (health, capacity, voltage and so on) is already available through sysfs but some values are wrong or need calibration. This needs to be fixed with further upgrades. Also interesting: charging seems to be under control of the ARISC core inside A64 SoC and works together with Pinebook's AXP803 PMIC (powermanagement IC) even when there's no OS running. This will be somewhat challenging to implement later with mainline I would believe...

 

I'll stop here for now since Pinebook is still stuff for developers and not end users. Just some resources for interested parties:

• https://github.com/ayufan-pine64/boot-tools (Kamil implemented an u-boot based approach to flash directly to eMMC and there you find the necessary BLOBs to convert other BSP based Pine64 images for Pinebook since different DRAM and other settings require different SPL+u-boot)
• https://github.com/ayufan-pine64/linux-pine64 (based on longsleep's BSP kernel but with more fixes currently for Pinebook)
• $mainline resources (I lost track where to find most recent stuff but will add this later)

 

Wrt Armbian running on Pinebook we could now simply exchange u-boot+SPL+DT of our Xenial Desktop image... but I hope we won't do that but wait until dust has settled while helping with development efforts in the meantime. In other words: no Armbian on Pinebook (right) now  

[Tido]

LOL, that you would spend money for this is really a surprise to me.

 

1 hour ago, tkaiser said:

Pinebook is NOT equipped with shitty Micro USB for DC-IN leading to all sorts of trouble

Well, this is especially in this case not so relevant. This device comes with an accu in opposite to all the SBCs.

[tkaiser]

3 hours ago, Tido said:

Well, this is especially in this case not so relevant. This device comes with an accu in opposite to all the SBCs.

 

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)

 

[Tido]

I know where you come from, but nonetheless on SBC the problem with Micro USB is the fact that there is no accu like in a mobile phone that can cover power peaks.

 

Your charging issue is something else, beside the small PSU is better for the accu   slow charging is better.

How many mAh does the accu have, so I can compare to a Tablet?

[hmartin]

44 minutes ago, Tido said:

How many mAh does the accu have, so I can compare to a Tablet?

 

10,000mAh. They have the full specifications published on the website...

 

6 hours ago, tkaiser said:

While watching the Pinebook's charging/discharging behaviour I noticed that consumption drawn from wall while charging oscillates between 9W and 15W

 

Can it still operate from AC power if you unplug the battery? Or is this a single power supply device like most cellphones?

 

Edit: according to the schematics, you should be able to disconnect the battery and still have it powered, unless I'm misunderstanding the function of the AXP803?

 

The only reason I ask is because it's probably easier to unplug the battery and observe the power consumption from the wall than trying to measure between the battery and the main PCB.

 

Or maybe there is a sysfs entry for the current out of the battery?

[tkaiser]

6 minutes ago, hmartin said:

Can it still operate from AC power if you unplug the battery?

 

This is something I won't do (now) since I'm pretty good in destroying hardware. But just like any other X-Powers PMIC the AXP803 can be fed from 3 sources: DC-IN, USB OTG and battery though I would assume OTG won't work here (since exposed as type A receptacle) and I would think it's also as usual that AXP803 will compensate from voltage/current drops on DC-IN by using the battery and also works fine without a battery at all (same with Pine64). Link to schematic: http://linux-sunxi.org/Pine_Pinebook#See_also

 

What I'm currently doing is just adding the available data sources to RPi-Monitor templates to get an idea what's going on and playing with appropriate device tree settings for the battery (we were there already with A20/AX209: see the 2 links to forum threads. And what I'm also doing is shutting Linux down and watching the Powermeter (since the battery stuff lives inside the OpenRISC core and continues to charge. Since I've to leave now I disconnected the PB from mains since last reported /sys/class/power_supply/battery/voltage_now was already exceeding 4.26V)

[hojnikb]

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.

[tkaiser]

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  ):

 

root@pinebook:~# echo 1 >/sys/class/axppower/axpdebug ; echo 1 >/sys/class/axppower/regdebug
root@pinebook:~# dmesg | tail -n42
[ 3245.541858] charger->ic_temp = 79
[ 3245.541878] charger->bat_temp = 30
[ 3245.541887] charger->vbat = 4010
[ 3245.541896] charger->ibat = 1848
[ 3245.541904] charger->ocv = 3774
[ 3245.541913] charger->disvbat = 4010
[ 3245.541922] charger->disibat = 0
[ 3245.541930] power_sply = 0 mW
[ 3245.542006] Axp Rdc = 127
[ 3245.542083] Axp batt_max_cap = 4798
[ 3245.542159] Axp coulumb_counter = 1709
[ 3245.542219] Axp REG_B8 = f0
[ 3245.542227] charger->is_on = 1
[ 3245.542236] charger->bat_current_direction = 1
[ 3245.542244] charger->charge_on = 1
[ 3245.542252] charger->ext_valid = 1
[ 3245.542381] AXP rest_vol = 36
[ 3245.542390] Axp OCV_percentage = 33
[ 3245.542398] Axp Coulumb_percentage = 36
[ 3245.542407] charger->rest_vol = 36
[ 3245.542552] battery vol change: 35->36 
[ 3245.542565] for test 4010 3774 1848 33 36 1709
[ 3255.420970] charger->ic_temp = 79
[ 3255.420991] charger->bat_temp = 30
[ 3255.421001] charger->vbat = 4010
[ 3255.421009] charger->ibat = 1852
[ 3255.421018] charger->ocv = 3774
[ 3255.421026] charger->disvbat = 4010
[ 3255.421035] charger->disibat = 0
[ 3255.421043] power_sply = 0 mW
[ 3255.421119] Axp Rdc = 127
[ 3255.421196] Axp batt_max_cap = 4798
[ 3255.421273] Axp coulumb_counter = 1715
[ 3255.421333] Axp REG_B8 = f0
[ 3255.421341] charger->is_on = 1
[ 3255.421350] charger->bat_current_direction = 1
[ 3255.421358] charger->charge_on = 1
[ 3255.421366] charger->ext_valid = 1
[ 3255.421496] AXP rest_vol = 36
[ 3255.421504] Axp OCV_percentage = 33
[ 3255.421513] Axp Coulumb_percentage = 36
[ 3255.421521] charger->rest_vol = 36

 

 

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

 

[tkaiser]

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.

[tkaiser]

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

 

[tkaiser]

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

[hojnikb]

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

 

[tkaiser]

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.

 

 

System load:   0.12 0.16 0.15      Up time:       15:08 hours        Local users:   2                
Memory usage:  15 % of 1989MB     IP:            192.168.83.186
CPU temp:      35°C               
Usage of /:    31% of 15G        Battery:       13% discharging    


1 package can be updated.
0 updates are security updates.
 
Last login: Sat Apr 29 12:09:46 2017 from 192.168.83.91
pine64@pinebook:~$ sudo -s
[sudo] password for pine64: 
root@pinebook:~# lsmod
Module                  Size  Used by
zram                   18970  4
ss                     41661  0
8723cs               1231438  0
cfg80211              430891  1 8723cs
hdmi                   55158  0
disp                 1148789  3 hdmi
root@pinebook:~# Connection to 192.168.83.186 closed by remote host.
Connection to 192.168.83.186 closed.

[tkaiser]

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?

[tkaiser]

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.

[hmartin]

On 4/27/2017 at 7:57 PM, hojnikb said:

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 ?

 

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.

[hojnikb]

6 hours ago, hmartin said:

 

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.

Yeah, 5W should be fine. Definitely better than to trust software capacity report

[tkaiser]

Now the first time something related to battery life. I measured the difference between two possible Wi-Fi powermanagement settings for RealTek's RTL8723 chip few hours ago: rtw_power_mgnt=2 compared to rtw_power_mgnt=0 made a whopping 250 mW difference in idle: https://github.com/ayufan-pine64/linux-build/commit/68c633221b2d35ed42845174c23c84f19e1a69de

 

I guess we'll be able to identify other areas with some room for improvements in the next weeks and then some estimates regarding battery life are possible. Pine folks also said the battery used in 11" PB has a slightly higher capacity than the one in 14" PB.

 

Battery specs (to be mirrored by everyone interested in):

• 11": https://app.box.com/s/zrrzzjnf37z846pj91bsvf8w8st67z54
• 14": https://app.box.com/s/9dw8m6267mymjgwfcrpcoeumkvmbeqiy 

 

[martinayotte]

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.

 

 

[tkaiser]

9 hours ago, martinayotte said:

Today I've experienced a total battery drain-out in 12 hours after a manual explicit suspend or a screen flip-close

 

This is obviously no suspend since my 14" runs 12 hours in idle on battery (with an average consumption slightly below 3W). At the moment it's too early to do any such measurements since folks over at http://irc.pine64.uk still fight with resume and other settings (eg. an unnecessary amount of regulators remains on in suspend since otherwise most things don't work after resume)

 

Edit: It's the best idea to check for new 'legacy' OS images over here: https://jenkins.ayufan.eu/job/linux-build-pine-a64/ (and there the changelog, suspend has been fixed just yesterday)

[martinayotte]

Yes, I was using Ayufan build, but from 2 days ago.

So, I will maybe try it again in the following days...

 

[martinayotte]

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 ...

[tkaiser]

13 hours ago, martinayotte said:

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.

 

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)

[hojnikb]

It's a cheap device; bad touchpad and keyboard is almost a given. Might be useful to disable touchpad alltogether when mouse is plugged in.

[tkaiser]

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

[hojnikb]

Please, dont put electronics in the fridge.Condensation will kill it !

 

might be a better idea to remove the bottom cover and blow a fan to the soc area. For short terms, filling a plastic bag with water will also do the trick (until water heats up anyway).

[tkaiser]

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)

[Igor]

I finally received 11" version. Stock Ubuntu gives me bad first impression, while last community build operates much much better!

 

This Notebook can be comparable to low end notebooks, which all usually share build and material quality issues. I can compare this notebook to Acer Aspire E11, which I owned few years ago. It was powered by bay trail Celeron which has more power, solid hw support out of the box, has good power efficiency, but it was ugly, trackpad was utter shit, broken by design, keyboard worse than here, screen much worse and usable only from direct angle. It was around 250 EUR and you could upgrade 2Gb memory to 8Gb and replace HDD with SSD ... for extra 100-150 EUR.

 

Pine's keyboard and trackpad is better than that and probably similar better than low cost Acer(s) today, even it's also so so - time will tell. This Pine 11" costs roughly 110 EUR EU shipped and taxed and I am looking forward to put Armbian on it as soon as possible 

It's pointless to compare this to mid or high end notebooks in any category except overall dimensions. Here is one visual comparison with Dell XPS 13" from late 2014.

[valant]

I don't have it, but It's very interesting. Yet is interesting to hear about support of "suspension" on it.

where it's implemented? don't you know? is this ACPI compliant thing?

does it support hibernation too (S4)? just curious, since that's definitely going to kill the on-board eMMC if it does.

for the same reason - is paging (swapping) turned on in the OS distribution?

[martinayotte]

What is the relation between hibernation and eMMC ?

Any Linux distro can support swap file or partition ...