Jump to content

Armbian running on Pine64 (and other A64/H5 devices)

tkaiser

By tkaiser
in Pine A64

 Share

Recommended Posts

@lex

@lex

Posted
Posted

I ran some short tests with 100M mode enabled (connected to GbE router) (GbE test was taking sooo long and i needed to know if the script was running) and see if TX/RX would change/improve on this mode.

The odd thing is that if i run the same test more than once i get different values, take an example 1/25, it is so bad in one run and the next one is almost normal, just make me wonder there is something else involved.

 

Do you get very different values on your tests?

 

I will let the GbE test running this weekend.

TX/RX	TX		RX	
delay:	Mb/s	retry	Mb/s	retry
 0/25:	70.2	1	92.3	53
 0/26:	76.1	0	92.2	49
 0/27:	75.4	0	92.2	82
 0/28:	71.4	1	94.0	73
 0/29:	69.4	2	92.2	78
 0/30:	81.7	2	92.2	115
 0/31:	70.9	1	92.2	44
 1/ 0:	75.5	0	94.1	44
 1/ 1:	69.3	1	92.2	48
 1/ 2:	70.9	1	94.1	42
 1/ 3:	73.0	1	92.2	47
 1/ 4:	71.0	12	94.1	44
 1/ 5:	69.9	1	92.2	46
 1/ 6:	73.9	132	94.1	72
 1/ 7:	88.7	247	94.1	83
 1/ 8:	92.4	352	90.4	119
 1/ 9:	75.7	742	92.2	50
 1/10:	68.5	2	94.1	45
 1/11:	69.9	1106	90.4	52
 1/12:	75.6	0	94.1	46
 1/13:	70.0	1	92.3	45
 1/14:	60.4	1223	94.1	56
 1/15:	58.7	1290	90.4	56
 1/16:	73.5	1	94.1	44
 1/17:	71.1	2	94.1	50
 1/18:	40.8	1214	92.3	53
 1/19:	31.5	1138	91.9	84
 1/20:	47.6	1278	92.3	82
 1/21:	47.0	1288	90.4	58
 1/22:	68.8	2	92.3	49
 1/23:	71.5	1	94.1	44
 1/24:	70.5	1	94.1	43
 1/25:	979	177	90.3	51
 1/26:	27.5	1028	92.3	115
 1/27:	42.0	1326	92.3	53
 1/28:	71.3	1	92.3	54
 1/29:	71.8	1	94.2	45
 1/30:	28.5	1132	88.5	55
 1/31:	70.6	1	91.2	206
 2/ 0:	29.5	1078	92.3	86
 2/ 1:	70.2	2	94.2	76
 2/ 2:	41.2	1271	88.2	55
 2/ 3:	9.85	640	90.4	51
 2/ 4:	75.5	0	94.2	47
 2/ 5:	71.4	1	90.0	87
 2/ 6:	8.84	665	84.4	129
 2/ 7:	1.10	172	90.4	102
 2/ 8:	75.8	2	94.1	53
 2/ 9:	69.5	4	94.2	43
 2/10:	71.4	4	92.3	53
 2/11:	3.92	405	90.5	51
 2/12:	73.3	1	94.1	74
 2/13:	75.7	0	91.9	72
 2/14:	8.24	571	92.3	55
 2/15:	72.6	1	94.1	78
 2/16:	71.1	1	94.1	42
 2/17:	70.4	1	92.2	100
 2/18:	16.6	883	92.3	51
 2/19:	70.0	1	92.3	49
 2/20:	69.8	1	92.3	78
 2/21:	15.4	915	92.3	58
 2/22:	22.1	1006	92.3	55
 2/23:	15.1	964	88.6	106
 2/24:	72.1	2	92.3	55
 2/25:	69.5	2	94.1	44
 2/26:	71.4	1	92.3	51
 2/27:	8.92	618	91.9	75

Next run starting from 1/24:

TX/RX	TX		RX	
delay:	Mb/s	retry	Mb/s	retry
 1/24:	70.4	2	94.2	78
 1/25:	71.0	1	92.3	51
 1/26:	70.8	1	94.1	44
0
tkaiser

tkaiser

Posted
  • Author
Posted

Do you get very different values on your tests?

 

Absolutely. Four things to mention: 

  • The board you're testing with is broken, TX/RX delay shouldn't influence Fast Ethernet (as far as I understood). Such variations in 100 Mbits/sec mode is a clear sign that there's something really wrong. I would assume you cleaned contacts already, exchanged cables and switch port?
  • This '979' value you report is most probably Kbits/sec. My script sucks a lot since it assumes iperf3 output being printed in Mbits/sec. But in such cases as yours where really something goes horribly wrong this is wrong. Anyway: based on your results you can already stop, there's nothing to improve/test
  • Xunlong's BSP kernel for OPi PC 2 seems to not make any use of tx-delay/rx-delay set in DT, maybe they currently use a crude mixture of sys_config.fex and .dts but at least my test results show identical results iterating through all 256 combinations (0-7 TX, 0-31 RX). In other words: it's currently a waste of time to try to tweak Ethernet settings for OPi PC 2 unless this is resolved
  • With my 2GB Pine64+ it looks like this: As soon as rx-delay is above 4 then no Ethernet connection is possible any more (see below). Test will last a few hours so I'll update then the results in OPi PC 2 github repo issue

TX/RX delay test results with Pine64+ so far:

 

 

 0/ 0:	876	233	941	0
 0/ 1:	900	150	941	0
 0/ 2:	388	1346	148	0
 0/ 3:	312	1701	967	0
 0/ 4:	898	108	55.9	0
 0/ 5:		
 0/ 6:		
 0/ 7:		
 0/ 8:		
 0/ 9:		
 0/10:		
 0/11:		
 0/12:		
 0/13:		
 0/14:		
 0/15:		
 0/16:		
 0/17:		
 0/18:		
 0/19:		
 0/20:		
 0/21:		
 0/22:		
 0/23:		
 0/24:		
 0/25:		
 0/26:		
 0/27:		
 0/28:		
 0/29:		
 0/30:		
 0/31:		
 1/ 0:	915	0	941	0
 1/ 1:	916	0	941	0
 1/ 2:	917	0	154	0
 1/ 3:	915	0	647	0
 1/ 4:	917	0	64.7	0
 1/ 5:		
 1/ 6:		
 1/ 7:		
 1/ 8:		
 1/ 9:		
 1/10:		
 1/11:		
 1/12:		
 1/13:		
 1/14:		
 1/15:		
 1/16:		
 1/17:		
 1/18:		
 1/19:		
 1/20:		
 1/21:		
 1/22:		
 1/23:		
 1/24:		
 1/25:		
 1/26:		
 1/27:		
 1/28:		
 1/29:		
 1/30:		
 1/31:		
 2/ 0:	914	0	941	0

 

 

 

Empty entries means: No connection between client and server possible at all. I had a laugh before since I thought it would be a great idea to test this with as many Pine64+ as possible. I then realized that Pine people sent me 7 Pine64+ samples, the first maybe still stuck in customs, the 2nd one bent to death, N° 3 at Zador's desk, N° 5 at jernej's desk, N° 4 and 6 sent out to @androsch (who helped nailing down the Pine64 GbE issue). But @androsch was so kind and sent me N°4 back so I can at least test with one other Pine64+ tomorrow.

0
androsch

androsch

Posted
Posted

Absolutely. Four things to mention:

  • The board you're testing with is broken, TX/RX delay shouldn't influence Fast Ethernet (as far as I understood). Such variations in 100 Mbits/sec mode is a clear sign that there's something really wrong. I would assume you cleaned contacts already, exchanged cables and switch port?
  • This '979' value you report is most probably Kbits/sec. My script sucks a lot since it assumes iperf3 output being printed in Mbits/sec. But in such cases as yours where really something goes horribly wrong this is wrong. Anyway: based on your results you can already stop, there's nothing to improve/test
  • Xunlong's BSP kernel for OPi PC 2 seems to not make any use of tx-delay/rx-delay set in DT, maybe they currently use a crude mixture of sys_config.fex and .dts but at least my test results show identical results iterating through all 256 combinations (0-7 TX, 0-31 RX). In other words: it's currently a waste of time to try to tweak Ethernet settings for OPi PC 2 unless this is resolved
  • With my 2GB Pine64+ it looks like this: As soon as rx-delay is above 4 then no Ethernet connection is possible any more (see below). Test will last a few hours so I'll update then the results in OPi PC 2 github repo issue
TX/RX delay test results with Pine64+ so far:

 

 0/ 0:	876	233	941	0
 0/ 1:	900	150	941	0
 0/ 2:	388	1346	148	0
 0/ 3:	312	1701	967	0
 0/ 4:	898	108	55.9	0
 0/ 5:		
 0/ 6:		
 0/ 7:		
 0/ 8:		
 0/ 9:		
 0/10:		
 0/11:		
 0/12:		
 0/13:		
 0/14:		
 0/15:		
 0/16:		
 0/17:		
 0/18:		
 0/19:		
 0/20:		
 0/21:		
 0/22:		
 0/23:		
 0/24:		
 0/25:		
 0/26:		
 0/27:		
 0/28:		
 0/29:		
 0/30:		
 0/31:		
 1/ 0:	915	0	941	0
 1/ 1:	916	0	941	0
 1/ 2:	917	0	154	0
 1/ 3:	915	0	647	0
 1/ 4:	917	0	64.7	0
 1/ 5:		
 1/ 6:		
 1/ 7:		
 1/ 8:		
 1/ 9:		
 1/10:		
 1/11:		
 1/12:		
 1/13:		
 1/14:		
 1/15:		
 1/16:		
 1/17:		
 1/18:		
 1/19:		
 1/20:		
 1/21:		
 1/22:		
 1/23:		
 1/24:		
 1/25:		
 1/26:		
 1/27:		
 1/28:		
 1/29:		
 1/30:		
 1/31:		
 2/ 0:	914	0	941	0

 

 

Empty entries means: No connection between client and server possible at all. I had a laugh before since I thought it would be a great idea to test this with as many Pine64+ as possible. I then realized that Pine people sent me 7 Pine64+ samples, the first maybe still stuck in customs, the 2nd one bent to death, N° 3 at Zador's desk, N° 5 at jernej's desk, N° 4 and 6 sent out to @androsch (who helped nailing down the Pine64 GbE issue). But @androsch was so kind and sent me N°4 back so I can at least test with one other Pine64+ tomorrow.

Where do i place this script to test my boards?

 

Gesendet von meinem XT1032 mit Tapatalk

0
androsch

androsch

Posted
Posted

Where do i place this script to test my boards?

 

Gesendet von meinem XT1032 mit Tapatalk

Sorry, did not check first, its already mentioned in the script itself....

Will do some checks tomorrow.

 

Gesendet von meinem XT1032 mit Tapatalk

0
tkaiser

tkaiser

Posted
  • Author
Posted

Sorry, did not check first, its already mentioned in the script itself....

Will do some checks tomorrow.

 

Great! Just a few notes. It can be pretty annoying when things go wrong (the script tries to test something and initiates a reboot automatically, 8*32 times in worst case scenario). So I hope you've another Linux box and an SD card reader to remove the execution of the script in /etc/rc.local if this happens.

 

Then longsleep's default settings are 3/0 (TX/RX delay). First step is therefore to create a .dts and adjust there tx-delay to be '<0x0>;' (must exactly look like the rx-delay value):

dtc -I dts -O dtb -o /boot/pine64-plus.dtb /boot/new.dts

And then those paths have to be adjusted and of course on another GbE capable host iperf3 on port 6000 has to be started. Script version suitable for Armbian on Pine64+:

 

 

#!/bin/bash
#
# script intended to test through TX/RX parameters. Should be called from
# eg. /etc/rc.local with a short delay to ensure network is already up, eg.
# sleep 5 && /usr/local/bin/test-tx-rx.sh

TestPartner=192.168.83.161			# here 3 x 'iperf3 -s' must be running
TimeToTest=20						# how long should iperf3 run each
TX_File=/var/log/tx-value			# file containing actual tx value
RX_File=/var/log/rx-value			# file containing actual rx value
LogFile=/var/log/tx-rx.log			# result log
SourceDTS=/boot/new.dts				# source, must contain rx/tx set to 0!
TargetDTB=/boot/pine64-plus.dtb 	# target .dtb

Main() {
	CheckPrerequisits
	read TX <"${TX_File}"
	read RX <"${RX_File}"
	# TestTX >/tmp/tx.txt
	# sleep $(( ${TimeToTest} + 2 ))
	# TXSum=$(awk 'BEGIN {FS = "|"} ; {sum+=$1} END {print sum}' /tmp/tx.txt)
	# TXRetr=$(awk 'BEGIN {FS = "|"} ; {sum+=$2} END {print sum}' /tmp/tx.txt)
	# TX_Result="${TXSum}\t${TXRetr}"
	TX_Result=$(taskset 8 iperf3 -c ${TestPartner} -t ${TimeToTest} -p 6000 | awk -F" " '/sender$/ {print $7"\t"$9}' | sed 's/sender/0/')
	RX_Result=$(taskset 8 iperf3 -R -c ${TestPartner} -t ${TimeToTest} -p 6000 | awk -F" " '/sender$/ {print $7"\t"$9}' | sed 's/sender/0/')
	echo -e "$(printf "%2s" ${TX})/$(printf "%2s" ${RX}):\t${TX_Result}\t${RX_Result}" >>"${LogFile}"
	cat "${LogFile}" >/dev/tty1
	IncrementAndReboot
} # Main

CheckPrerequisits() {
	export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
	echo 1-2 >/proc/irq/$(awk -F":" "/1c30000.eth/ {print \$1}" </proc/interrupts | sed 's/\ //g')/smp_affinity_list
	echo 1 > /sys/class/net/eth0/queues/rx-0/rps_cpus
	echo 1 > /sys/class/net/eth0/queues/tx-0/xps_cpus
	echo 32768 > /proc/sys/net/core/rps_sock_flow_entries
	which iperf3 >/dev/null 2>&1 || apt-get -f -qq -y install iperf3
	which ethtool >/dev/null 2>&1 || apt-get -f -qq -y install ethtool
	which dtc >/dev/null 2>&1 || apt-get -f -qq -y install device-tree-compiler
	[[ -f "${TX_File}" ]] || echo -n 0 >"${TX_File}"
	[[ -f "${RX_File}" ]] || echo -n 0 >"${RX_File}"
	[[ -f "${LogFile}" ]] || echo -e "TX/RX\tTX\t\tRX\t\ndelay:\tMb/s\tretry\tMb/s\tretry" >"${LogFile}"
} # CheckPrerequisits

TestTX() {
	taskset 4 iperf3 -c ${TestPartner} -t ${TimeToTest} -p 6000 | awk -F" " '/sender$/ {print $7"|"$9}' &
	sleep 0.3
	taskset 8 iperf3 -c ${TestPartner} -t ${TimeToTest} -p 6001 | awk -F" " '/sender$/ {print $7"|"$9}' &
	sleep 0.3
	taskset 1 iperf3 -c ${TestPartner} -t ${TimeToTest} -p 6002 | awk -F" " '/sender$/ {print $7"|"$9}' &
} # TestTX

IncrementAndReboot() {
	let RX++
	if [ ${RX} -eq 32 ]; then
		RX=0
		let TX++
	fi
	if [ ${TX} -lt 8 ]; then
		# write stuff to files, patch .dtb, reboot
		echo -n ${TX} >"${TX_File}"
		echo -n ${RX} >"${RX_File}"
		HexTX="$(printf '<0x%x>;' ${TX})"
		HexRX="$(printf '<0x%x>;' ${RX})"
		sed -e "s/tx-delay = <0x0>;/tx-delay = ${HexTX}/" \
			-e "s/rx-delay = <0x0>;/rx-delay = ${HexRX}/" \
			<"${SourceDTS}" | dtc -I dts -O dtb -o "${TargetDTB}"
		sync
		reboot
	fi
} # IncrementAndReboot

Main $@ 

 

 

 

(no complicated iperf3 TX measurement since obviously with OPi PC 2 I tested all the time the same settings)

0
androsch

androsch

Posted
Posted

Great! Just a few notes. It can be pretty annoying when things go wrong (the script tries to test something and initiates a reboot automatically, 8*32 times in worst case scenario). So I hope you've another Linux box and an SD card reader to remove the execution of the script in /etc/rc.local if this happens.

 

Sorry, does not make sense to check out other values, because the board only works in GbE-mode with longsleeps gmac-kernel, with normal kernel GbE is still unusable.

 

gmac-kernel with network-script.sh and performance governor including a 5V/3A PSU allows about 500mbits now, so this is fine for me.

0
tkaiser

tkaiser

Posted
  • Author
Posted

because the board only works in GbE-mode with longsleeps gmac-kernel, with normal kernel GbE is still unusable.

 

Which board are you talking about? The one i sent to you with '2' written on the Ethernet jack? This one worked for me without any problem using the unpatched kernel and exceeding 900 Mbits/sec in both directions.

0
androsch

androsch

Posted
Posted

Which board are you talking about? The one i sent to you with '2' written on the Ethernet jack? This one worked for me without any problem using the unpatched kernel and exceeding 900 Mbits/sec in both directions.

 

Of course not, this is a board you already used for testing, so it makes no sense from my point of view, i tried to test the other board i received from tllim (same revision and version like your board btw) but this does not work with any other than longsleeps gmac-kernel in GbE-mode. I even just exchanged the two boards with their PSU, SD card and cable to the switch and they show the same results.

 

I get about 500 mbits now with the 'bad' board, so for me this is fine now....

0
tkaiser

tkaiser

Posted
  • Author
Posted

I get about 500 mbits now with the 'bad' board, so for me this is fine now....

 

Ah, ok. Sorry, but I really don't care about these 'bad' boards. Pine64 users should make some noise to get their broken hardware replaced/refunded. The aforementioned test was meant to be used on working boards. I'll fine tune the script slightly (since testing RX delay values between 8 and 31 is a waste of time) and post a new version later :)

0
hojnikb

hojnikb

Posted
Posted

I don't really see 500mbit cap an issue on this board. At the end of the day, you're still limited by other IO (USB 2.0 for one) so having a full blown gigabit ethernet on a board like this is pretty pointless, unless you also have usb3 or native sata to play with.

0
androsch

androsch

Posted
Posted

I don't really see 500mbit cap an issue on this board. At the end of the day, you're still limited by other IO (USB 2.0 for one) so having a full blown gigabit ethernet on a board like this is pretty pointless, unless you also have usb3 or native sata to play with.

Yes, thats the reason why its ok for me now, 500mbits exceed the about 20mb of usb2, so this is fine, at least for me

 

Gesendet von meinem XT1032 mit Tapatalk

0
tkaiser

tkaiser

Posted
  • Author
Posted

20mb of usb2

 

Huh? This is Allwinner country, here we speak UASP ;)

 

Really: 500 Mbits/sec == defective. We can use ZFS on our boards with active lz4 compression (or btrfs/lzo with mainline kernel) and easily exceed 50MB/s with average data regarding disk IO. Also when things are set up correctly especially on the 2GB Pine64+ the write speed to the board can be as high as 80 MB/s even if there's just slow USB2.0 storage behind: Since data (up to 1.5GB in size) will get buffered in memory and flushed to disk later.

 

Next problem: With such a defective board (or inappropriate settings) you can easily end up with one CPU core 100% busy serving Ethernet IRQs. If you now happen to run your application on the same core then you are already limited to 500 Mbits/sec max on the wire but in reality overall throughput will be way below since application and IRQ handling fight for CPU ressources.

 

There's not much interesting on Pine64 or A64 in general (for my use cases). The only real plus is the ability to easily exceed 900 Mbits/sec GbE throughput in both directions.

0
androsch

androsch

Posted
Posted

Huh? This is Allwinner country, here we speak UASP ;)

 

Really: 500 Mbits/sec == defective. We can use ZFS on our boards with active lz4 compression (or btrfs/lzo with mainline kernel) and easily exceed 50MB/s with average data regarding disk IO. Also when things are set up correctly especially on the 2GB Pine64+ the write speed to the board can be as high as 80 MB/s even if there's just slow USB2.0 storage behind: Since data (up to 1.5GB in size) will get buffered in memory and flushed to disk later.

 

Next problem: With such a defective board (or inappropriate settings) you can easily end up with one CPU core 100% busy serving Ethernet IRQs. If you now happen to run your application on the same core then you are already limited to 500 Mbits/sec max on the wire but in reality overall throughput will be way below since application and IRQ handling fight for CPU ressources.

 

There's not much interesting on Pine64 or A64 in general (for my use cases). The only real plus is the ability to easily exceed 900 Mbits/sec GbE throughput in both directions.

You are surely right as far as i know your knowledge here, but i only use this certain board as minecraft server for my son and his friends (even via remote login), so the slowest part is the SD card or even my internet connection :-)

 

Gesendet von meinem XT1032 mit Tapatalk

0
tkaiser

tkaiser

Posted
  • Author
Posted

The out of control moderator just banned me.

 

Yesterday he had also a great day, banned one account, censored a whole thread away and in two other threads important information:

  • here he deleted the last post mentioning that there's now also an Armbian Desktop image available (beta)
  • And in this thread he deleted posts containing the following information:
  • Firefox works without any problems on Armbian, that's simply since we install the armhf version by default on the desktop image since the arm64 version shows problems (this 'trick' can of course also be used to cure even the most crappy OS images for Pine64: on the broken Debian images from Pine wiki it's just 'apt-get purge firefox && apt-get install firefox:armhf' and those steps in between)
  • Chromium with our Armbian desktop image is just a simple 'apt-get install chromium', there's really no need to install .deb packages from linaro or somewhere else.
  • Using Chromium with '--disable-seccomp-filter-sandbox' is a bad idea, it would be better to address the problem (kernel fix needed?)
  • If one wants to use '--disable-seccomp-filter-sandbox' though this can be added to all 'Exec' occurences in /usr/share/applications/chromium-browser.desktop

So he managed to make Pain64 land great again, instead of informing people that there is software available that doesn't suck they (Pine Inc folks and their beloved premium moderator) ensure that no one knows, that people still use outdated, smelly and broken OS images containing numerous serious flaws and that nothing will change. Users are not informed that there are working 3rd party OS images existent in the meantime and users aren't tought how to use Firefox if they want since one person is allowed what he does best all the time: censoring everything he doesn't understand.

3
pfeerick

pfeerick

Posted
Posted
  • Firefox works without any problems on Armbian, that's simply since we install the armhf version by default on the desktop image since the arm64 version shows problems (this 'trick' can of course also be used to cure even the most crappy OS images for Pine64: on the broken Debian images from Pine wiki it's just 'apt-get purge firefox && apt-get install firefox:armhf' and those steps in between)

 

It might work just fine with Armbian (I haven't tried it myself as I haven't run the desktop beta - my intended use for the pine was always headless server stuff - but I believe you anyway) - but it will NOT work with the debian images for the pine64 (without using external repos, etc) - and it has nothing to do with them being crappy either - it's the clash between Mozilla's distribution requirements and Debian policies that were fault there. Debian Jessie does not, and has never shipped with firefox in it's repo. Starting with Debian Stretch, it will be available, and in the meantime, the extended support release of firefox was backported to Debian Jessie as firefox-esr.  Now, that is an issue - as the  firefox-esr:arm64 appears to be broken for the pine64, and the firefox-esr:armhf package won't install without some serious massaging. Or being stubborn, ignoring the whole "old is good as is stable philosophy of debian" and jump onto the unstable bandwagon... ;)

 

It's because of things like this I generally say... yeah, there's a workaround/bandaid, or you can go install Armbian and not look back! ;-)

The following packages have unmet dependencies:
 firefox-esr:armhf : Depends: libatk1.0-0:armhf (>= 1.12.4) but it is not going to be installed
                     Depends: libdbus-glib-1-2:armhf (>= 0.78) but it is not going to be installed
                     Depends: libgdk-pixbuf2.0-0:armhf (>= 2.22.0) but it is not going to be installed
                     Depends: libglib2.0-0:armhf (>= 2.20.0) but it is not going to be installed
                     Depends: libgtk2.0-0:armhf (>= 2.24.0) but it is not going to be installed
                     Depends: libpango-1.0-0:armhf (>= 1.14.0) but it is not going to be installed
                     Recommends: gstreamer1.0-libav:armhf but it is not going to be installed
                     Recommends: gstreamer1.0-plugins-good:armhf but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
0
tkaiser

tkaiser

Posted
  • Author
Posted

Pinebook announced: https://www.pine64.org/?page_id=3707

 

Armbian support can be added easily since it's just different DRAM type and two different screen resolutions (hopefully we're able to distinguish between them prior to loading kernel): http://www.cnx-software.com/2016/11/24/pinebook-arm-linux-laptop-powered-by-allwinner-a64-processor-to-sell-for-89-and-up/#comment-536419

 

Edit: Both screen sizes use the same laughable 1280x720 1376x768. So in case displays are compatible a single set of settings (DRAM, LCD settings) is ok for both variants. I'm assuming that trackpad drivers are already available in BSP or will be provided soon.

1
pfeerick

pfeerick

Posted
Posted

I might look at the Olimex one instead... especially because it can run windows(kidding!!!)... or more importantly seems to have some more sensible resolutions... 1376x768 and 1920x1080. I suppose this one should be interesting... at least there won't be a GbE issue this time as they fixed it by removing the ethernet! :-P So was that the hardware problems fixed... just the minor detail of crappy software?

0
tkaiser

tkaiser

Posted
  • Author
Posted

I might look at the Olimex one instead... especially because it can run windows(kidding!!!)... or more importantly seems to have some more sensible resolutions... 1376x768 and 1920x1080.

 

What's the latter resolution? I thought they only want to go with 1366x768 (LVDS --> eDP)?

 

Anyway: Maybe you could do the micro community over there a favour and post http://web.archive.org/save/_embed/http://bundie.neterra.net:8080/a64/A64%20LCD使用说明书.pdf to the LCD subforum? So tinkerers who want to exceed the 800x480 currently know where to adjust values...

0
tkaiser

tkaiser

Posted
  • Author
Posted

I decided to test USB/UAS performance with Pine64+ now that we can use USB with mainline kernel. I chose the Xenial/vanilla Armbian image I built yesterday with A64 cores running with 864 MHz, an ASM1153 enclosure with a Samsung EVO 750 inside, btrfs without compression as test fs and let these three commands run:

iozone -e -I -a -s 100M -r 1k -r 2k -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 4K -r 1024K
iozone -O -i 0 -i 1 -i 2 -e -+n -r 4K -s 2000m

The first test line is the one known from our SD card tests, the next two (using a large 2 or 4 GB testfile size to minimize caching/buffer effects) from the USB/UAS link above. With just 100 MB test data size some numbers are obviously wrong (way too high so buffers were tested and not the device).

 

But test results are simply excellent given that we're talking about USB 2.0 here since UAS is a lot more efficient than the old USB Mass Storage mode normally used with USB 2.0 (using Allwinner SoCs here is a real advantage since they speak UAS even with USB 2.0). Sequential write/read speeds exceed 41 and 42 MB/s and random IO is also quite nice -- to be able to compare search for 'EVO 750' numbers in this thread here (and please read a bit through to get a deeper understanding how to interpret these numbers).

 

Funny is that regarding random IO A64 with UASP easily outperforms the older A20 with SATA. Banana Pro (A20/SATA) vs. Pine64+ (A64/USB2.0):

                  Random IO in IOPS           Sequential IO in MB/S
                 SATA           USB2           SATA            USB2
            4K read/write  4K read/write   1M read/write   1M read/write
  A20         2779/893       1277/619        106 / 39         34 / 35
  A64           - / -        5033/6033         - / -          42 / 41

To sum it up: A64 outperforms A20 everywhere except of sequential read speeds (A20's SATA interface is able to exceed 200 MB/s -- the 106 MB/s above are the result of Samsung's EVO 750 not being that fast here). To be fair: measuring random IO with 4K blocksize means also tampering random IO with sequential bottlenecks -- but I'm just too lazy to repeat tests with 1K. But since in real world situations it's exactly the same why bother.

 

All results:

 

 

root@pine64:/root# iozone -e -I -a -s 100M -r 1k -r 2k -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
        Iozone: Performance Test of File I/O
                Version $Revision: 3.429 $
                Compiled for 64 bit mode.
                Build: linux 

        Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                     Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                     Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                     Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                     Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                     Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                     Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
                     Vangel Bojaxhi, Ben England, Vikentsi Lapa.

        Run began: Thu Nov 24 17:43:52 2016

        Include fsync in write timing
        O_DIRECT feature enabled
        Auto Mode
        File size set to 102400 kB
        Record Size 1 kB
        Record Size 2 kB
        Record Size 4 kB
        Record Size 16 kB
        Record Size 512 kB
        Record Size 1024 kB
        Record Size 16384 kB
        Command line used: iozone -e -I -a -s 100M -r 1k -r 2k -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
        Output is in kBytes/sec
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 kBytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
          102400       1     1596      713    62022   272580   203148      927                                                          
          102400       2     2930      728    44717   425265   352913     1797                                                          
          102400       4     7830     7824     8003     8006     9041     7790                                                          
          102400      16    20113    19568    21309    21333    21322    19154                                                          
          102400     512    36226    36206    38725    38869    38203    36143                                                          
          102400    1024    36415    36515    38882    39043    38699    36348                                                          
          102400   16384    37491    37525    41261    41368    41354    37430                                                          

iozone test complete.
root@pine64:/mnt# iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 4K -r 1024K
        Iozone: Performance Test of File I/O
                Version $Revision: 3.429 $
                Compiled for 64 bit mode.
                Build: linux 

        Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                     Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                     Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                     Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                     Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                     Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                     Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
                     Vangel Bojaxhi, Ben England, Vikentsi Lapa.

        Run began: Thu Nov 24 17:55:49 2016

        Auto Mode
        Using maximum file size of 4096000 kilobytes.
        File size set to 4096000 kB
        Record Size 4 kB
        Record Size 1024 kB
        Command line used: iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 4K -r 1024K
        Output is in kBytes/sec
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 kBytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
         4096000       4    41741    41583    42025    42062                                                                          
         4096000    1024    41850    41765    42025    42350                                                                          

iozone test complete.
root@pine64:/mnt# iozone -O -i 0 -i 1 -i 2 -e -+n -r 4K -s 2000m
        Iozone: Performance Test of File I/O
                Version $Revision: 3.429 $
                Compiled for 64 bit mode.
                Build: linux 

        Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                     Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                     Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                     Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                     Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                     Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                     Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
                     Vangel Bojaxhi, Ben England, Vikentsi Lapa.

        Run began: Thu Nov 24 18:13:10 2016

        OPS Mode. Output is in operations per second.
        Include fsync in write timing
        No retest option selected
        Record Size 4 kB
        File size set to 2048000 kB
        Command line used: iozone -O -i 0 -i 1 -i 2 -e -+n -r 4K -s 2000m
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 kBytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
         2048000       4     9497        0    10491        0     5033     6033                                                          

iozone test complete. 

 

 

 
Conclusion: Time to overthink 'SATA is better' platitudes at least when we're talking about aging A10/A20 here. A64 performs pretty well here and I would assume the same will be true for H5 (there we get 4 real USB ports unlike 2 with Pine64 now -- but with A64 one of the ports can be switched between OTG and a real USB host port using an own PHY while H5's OTG port seems not to be switchable. If performance is close to H3 this isn't that much of a problem since OTG port there in host mode is just slightly slower compared to real host ports)
 
EDIT: I ran the same set of test with 3 different setups: H3 board using USB2/UAS, A20 board using USB2/UAS and same A20 board (and same SSD of course) using SATA (kernel 4.8.11 with A20, 4.9 with H3):
 
Tested were the same 3 iozone calls:
iozone -e -I -a -s 100M -r 1k -r 2k -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 && iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 4K -r 1024K && iozone -O -i 0 -i 1 -i 2 -e -+n -r 4K -s 2000m
OPi Plus 2E using USB2/UAS:

OPi Plus 2E using USB2/UAS:

        Iozone: Performance Test of File I/O
                Version $Revision: 3.429 $
                Compiled for 32 bit mode.
                Build: linux 

        Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                     Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                     Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                     Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                     Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                     Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                     Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
                     Vangel Bojaxhi, Ben England, Vikentsi Lapa.

        Run began: Sat Nov 26 15:56:02 2016

        Include fsync in write timing
        O_DIRECT feature enabled
        Auto Mode
        File size set to 102400 kB
        Record Size 1 kB
        Record Size 2 kB
        Record Size 4 kB
        Record Size 16 kB
        Record Size 512 kB
        Record Size 1024 kB
        Record Size 16384 kB
        Command line used: iozone -e -I -a -s 100M -r 1k -r 2k -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
        Output is in kBytes/sec
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 kBytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
          102400       1     1567      680    50938   168999   131923      805                                                          
          102400       2     3220      462    63130   266504   225224     1584                                                          
          102400       4     7806     7790     8001     8006     8002     7662                                                          
          102400      16    16873    17504    18379    18303    18284    16839                                                          
          102400     512    29373    29373    30751    30808    30510    29226                                                          
          102400    1024    29737    29739    30979    31033    30856    29674                                                          
          102400   16384    33055    33041    38893    39003    38976    33006                                                          

iozone test complete.
        Iozone: Performance Test of File I/O
                Version $Revision: 3.429 $
                Compiled for 32 bit mode.
                Build: linux 

        Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                     Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                     Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                     Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                     Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                     Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                     Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
                     Vangel Bojaxhi, Ben England, Vikentsi Lapa.

        Run began: Sat Nov 26 16:10:08 2016

        Auto Mode
        Using maximum file size of 4096000 kilobytes.
        File size set to 4096000 kB
        Record Size 4 kB
        Record Size 1024 kB
        Command line used: iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 4K -r 1024K
        Output is in kBytes/sec
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 kBytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
         4096000       4    39058    38517    41282    41654                                                                          
         4096000    1024    39144    38748    41228    41327                                                                          

iozone test complete.
        Iozone: Performance Test of File I/O
                Version $Revision: 3.429 $
                Compiled for 32 bit mode.
                Build: linux 

        Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                     Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                     Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                     Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                     Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                     Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                     Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
                     Vangel Bojaxhi, Ben England, Vikentsi Lapa.

        Run began: Sat Nov 26 16:24:02 2016

        OPS Mode. Output is in operations per second.
        Include fsync in write timing
        No retest option selected
        Record Size 4 kB
        File size set to 2048000 kB
        Command line used: iozone -O -i 0 -i 1 -i 2 -e -+n -r 4K -s 2000m
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 kBytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
         2048000       4     9431        0    10335        0     1972     5387                                                          

iozone test complete.

 
Banana Pi (A20) using USB2/UAS:

	Iozone: Performance Test of File I/O
	        Version $Revision: 3.429 $
		Compiled for 32 bit mode.
		Build: linux 

	Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
	             Al Slater, Scott Rhine, Mike Wisner, Ken Goss
	             Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
	             Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
	             Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
	             Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
	             Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
	             Vangel Bojaxhi, Ben England, Vikentsi Lapa.

	Run began: Sat Nov 26 19:18:15 2016

	Include fsync in write timing
	O_DIRECT feature enabled
	Auto Mode
	File size set to 102400 kB
	Record Size 1 kB
	Record Size 2 kB
	Record Size 4 kB
	Record Size 16 kB
	Record Size 512 kB
	Record Size 1024 kB
	Record Size 16384 kB
	Command line used: iozone -e -I -a -s 100M -r 1k -r 2k -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
	Output is in kBytes/sec
	Time Resolution = 0.000001 seconds.
	Processor cache size set to 1024 kBytes.
	Processor cache line size set to 32 bytes.
	File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
          102400       1      193      159    23932   162784   122658      124                                                          
          102400       2      389      286    22200   251044   207089      249                                                          
          102400       4     6074     5926     7986     7976     6380     5542                                                          
          102400      16    14721    14144    18206    18213    16340    13792                                                          
          102400     512    28276    28245    29026    29085    28848    28297                                                          
          102400    1024    28846    28920    29747    29846    29713    28892                                                          
          102400   16384    32384    32323    38236    38342    38337    32323                                                          

iozone test complete.
	Iozone: Performance Test of File I/O
	        Version $Revision: 3.429 $
		Compiled for 32 bit mode.
		Build: linux 

	Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
	             Al Slater, Scott Rhine, Mike Wisner, Ken Goss
	             Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
	             Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
	             Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
	             Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
	             Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
	             Vangel Bojaxhi, Ben England, Vikentsi Lapa.

	Run began: Sat Nov 26 18:49:32 2016

	Auto Mode
	Using maximum file size of 4096000 kilobytes.
	File size set to 4096000 kB
	Record Size 4 kB
	Record Size 1024 kB
	Command line used: iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 4K -r 1024K
	Output is in kBytes/sec
	Time Resolution = 0.000001 seconds.
	Processor cache size set to 1024 kBytes.
	Processor cache line size set to 32 bytes.
	File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
         4096000       4    38851    38627    40882    40960                                                                          
         4096000    1024    38620    38026    40738    40905                                                                          

iozone test complete.
	Iozone: Performance Test of File I/O
	        Version $Revision: 3.429 $
		Compiled for 32 bit mode.
		Build: linux 

	Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
	             Al Slater, Scott Rhine, Mike Wisner, Ken Goss
	             Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
	             Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
	             Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
	             Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
	             Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
	             Vangel Bojaxhi, Ben England, Vikentsi Lapa.

	Run began: Sat Nov 26 19:03:35 2016

	OPS Mode. Output is in operations per second.
	Include fsync in write timing
	No retest option selected
	Record Size 4 kB
	File size set to 2048000 kB
	Command line used: iozone -O -i 0 -i 1 -i 2 -e -+n -r 4K -s 2000m
	Time Resolution = 0.000001 seconds.
	Processor cache size set to 1024 kBytes.
	Processor cache line size set to 32 bytes.
	File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
         2048000       4     9353        0    10248        0     1861     3202                                                          

iozone test complete.

 
Banana Pi (A20) using SATA:

	Iozone: Performance Test of File I/O
	        Version $Revision: 3.429 $
		Compiled for 32 bit mode.
		Build: linux 

	Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
	             Al Slater, Scott Rhine, Mike Wisner, Ken Goss
	             Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
	             Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
	             Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
	             Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
	             Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
	             Vangel Bojaxhi, Ben England, Vikentsi Lapa.

	Run began: Sat Nov 26 22:02:28 2016

	Include fsync in write timing
	O_DIRECT feature enabled
	Auto Mode
	File size set to 102400 kB
	Record Size 1 kB
	Record Size 2 kB
	Record Size 4 kB
	Record Size 16 kB
	Record Size 512 kB
	Record Size 1024 kB
	Record Size 16384 kB
	Command line used: iozone -e -I -a -s 100M -r 1k -r 2k -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
	Output is in kBytes/sec
	Time Resolution = 0.000001 seconds.
	Processor cache size set to 1024 kBytes.
	Processor cache line size set to 32 bytes.
	File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
          102400       1     1555     1297    76934   178591   133928     1118                                                          
          102400       2     3248     2439    86959   275155   226845     2211                                                          
          102400       4    10728    11153    26619    26740    18436     9476                                                          
          102400      16    19512    18678    53121    51509    43061    17199                                                          
          102400     512    28718    28589    73136    73520    70356    28631                                                          
          102400    1024    29135    29124    76796    77144    75211    29178                                                          
          102400   16384    29986    30029   160906   161418   162063    29985                                                          

iozone test complete.
	Iozone: Performance Test of File I/O
	        Version $Revision: 3.429 $
		Compiled for 32 bit mode.
		Build: linux 

	Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
	             Al Slater, Scott Rhine, Mike Wisner, Ken Goss
	             Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
	             Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
	             Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
	             Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
	             Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
	             Vangel Bojaxhi, Ben England, Vikentsi Lapa.

	Run began: Sat Nov 26 22:10:28 2016

	Auto Mode
	Using maximum file size of 4096000 kilobytes.
	File size set to 4096000 kB
	Record Size 4 kB
	Record Size 1024 kB
	Command line used: iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 4K -r 1024K
	Output is in kBytes/sec
	Time Resolution = 0.000001 seconds.
	Processor cache size set to 1024 kBytes.
	Processor cache line size set to 32 bytes.
	File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
         4096000       4    38377    38195   134852   135486                                                                          
         4096000    1024    37797    37633   123923   124249                                                                          

iozone test complete.
	Iozone: Performance Test of File I/O
	        Version $Revision: 3.429 $
		Compiled for 32 bit mode.
		Build: linux 

	Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
	             Al Slater, Scott Rhine, Mike Wisner, Ken Goss
	             Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
	             Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
	             Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
	             Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
	             Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
	             Vangel Bojaxhi, Ben England, Vikentsi Lapa.

	Run began: Sat Nov 26 22:20:03 2016

	OPS Mode. Output is in operations per second.
	Include fsync in write timing
	No retest option selected
	Record Size 4 kB
	File size set to 2048000 kB
	Command line used: iozone -O -i 0 -i 1 -i 2 -e -+n -r 4K -s 2000m
	Time Resolution = 0.000001 seconds.
	Processor cache size set to 1024 kBytes.
	Processor cache line size set to 32 bytes.
	File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
         2048000       4     9277        0    35442        0     4036     2807                                                          

iozone test complete.

0
pfeerick

pfeerick

Posted
Posted

Don't know how they're doing it... I read that from their exceptionally detailed(!) product page... https://www.olimex.com/Products/DIY%20Laptop/

 

Wildo... ;)

 

re: test results... so why wouldn't it be better using a H5 be better than the pine64 since you could stack up three native USB ports instead of 2 (when the OTG port is switched)? And still do something with the 4th?  :lol:

 

 

What's the latter resolution? I thought they only want to go with 1366x768 (LVDS --> eDP)?

 

Anyway: Maybe you could do the micro community over there a favour and post http://web.archive.org/save/_embed/http://bundie.neterra.net:8080/a64/A64%20LCD使用说明书.pdf to the LCD subforum? So tinkerers who want to exceed the 800x480 currently know where to adjust values...

0
pfeerick

pfeerick

Posted
Posted

lol... oops! the pine64 forum... er... the whole shebang... is now offline... looks like the pinebook is getting a little too much interest... and TL said the IT guys were all over it! :-O

 

"It's not just you! http://forum.pine64.orglooks down from here."

 

@hojnikb... true, but if you were running it with wanting that sort of throughput... I'd be worried about the batteries being able to do much more than short-term UPS work... as they'd have to carry the load of the pine64 and the attached hard drives (unless using externally powered drives, at which point why bother having a battery on the pine64?). I was thinking more of the ability to shove ~40MB x 3 through to the GbE... yup... think we found the next bottleneck! :D

0
zador.blood.stained

zador.blood.stained

Posted
Posted

Isn't gigabit issue fixed now ?

GBit issue on what board?

Pine64? It's a hardware issue and the best way to fix this is replacing the board.

PC2? I don't remember any issues there, but as soon as we get test images we need to collect enough statistics data to adjust TX/RX delays to improve GBit performance.

 

And what about mali, don't we need blobs for that ?

We need to get DRM display driver and Mali kernel driver first (at least for using mali with X desktop).

0
tkaiser

tkaiser

Posted
  • Author
Posted

PC2? I don't remember any issues there

 

https://github.com/OrangePiLibra/OrangePi_H5SDK/issues/4#issuecomment-261462313

 

Using a patch to force 100 MBit/sec since TX/RX delay currently can't be adjusted the 'usual way' IMO isn't a solution to be honest (of course it would be one for Pine64's Android offers since Android users seem to be happy to better use stable Fast Ethernet than broken GBit Ethernet -- but TL Lim and Pine people are simply too ignorant to even think about improvements at all)

0

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept