Is Sumerian NOT A Language Isolate?

This article presents some interesting parallels between Sumerian language and Turkish family languages. We’re often told Sumerian is a Language Isolate – that it is unrelated to any other known language. Yet these folks make a good case for it being in the Turkish group:

http://www.sumerianturks.org/sumerian_turkish.htm

LINGUISTIC PROOFS: SUMERIAN IS A TURKIC LANGUAGE (160 YEARS of RESEARCH ARTICLES AND BOOKS)

Last Update: September 9, 2018

The Sumerian language is not an isolate language. 160 years of articles and books prove this fact.

(Linguistic proofs must be considered together with Archaeological, Cultural, Mythological, Genetic and other proofs: see Sumerian origins , and also Sumerian Migrations, Sumerian Original Homeland Central Asia, Ancestral Homeland Siberia, Ugur (Hurrian), and Implications for the Indo-European Homeland for details)

Sumerian Migrations

Sumerian Migrations on Eurasian Map click on the map for the article and full size image

First of all, the origins of Sumerians were established by those who had discovered this ancient civilization lost in history for 4000 years until 1850: British scholar Edward Hincks and Henry Rawlinson classified this new language and the people as Turkic (Turanian) and their origins as Central Asia in the 1850s. So, the idea of Sumerians being Turks is not a novel fact!

Frenchman Jules Oppert who named this civilization as Sumer (could it have been Subar?) and other Oriental Studies scholars including British philologist Edwin Norris, Danish Orientalist Niels Westergaard, and Finnish scholar Wilhelm Lagus (article by Finnish linguist Tapani Harvianen) have agreed. They were referring to Turkic people as Scythian while others referred to them as Turanian. (Later, the word Turanian or Turanid was replaced by Ural Altaic in Western academic circles.)

1850s A very important 2011 article by Professor Kevin J. Cathcart explains how Sumerian cuneiform was deciphered by Edward Hincks as well as the role of Rawlinson in the discovery of Sumer.

1874 French Orientalist Francois Lenormant analyzed Turkic-Sumerian mythology by comparing Sumerian myths with Central Asian magic and cultural similarities, in addition to comparing Sumerian language with Ural-Altaic languages. He published his book La magie chez les chaldeens et les origines accadiennes concluding Sumerian to be Turanian.

1874 It was well established in European circles that Sumerians were Turanian (Turkic) for almost 20 years until Joseph Halevy declared in 1874 that there was no such language as Sumerian!

He purported in many “academic papers” that the newly discovered language was a secret Babylonian priest communication protocol and not a real language! Unfortunately this was a ridiculous assertion/lie but very tellingly, most European scholars except Francois Lenormant and Oppert played along! And the Sumerian studies were largely hindered (except the works of Hungarian scholars) until 1915!

1915 Renowned German Assyriologist Fritz Hommel showed that 200 Sumerian words were Turkic

1930s It was Ataturk who in the 1930s invited scholars from Europe and Turkey to Ankara to study the subject and then adding his own linguistic and history work of almost 5 years, showing Sumerians to be Turkic and of Central Asian origin. He also said that Anatolia (Turkey) was the land of the Turks for 7000 years. And since then many linguistic, archaeological, ethnological, genetic and geographic articles and books firmly established Sumerian as Turkic many times over!

And it goes on from there for a couple of more pages, all rich with links to supporting works.

It had always bugged me a little that Sumer seemed to spring fully formed on the scene as a complete and advanced society, then just evaporated one day. Something just wrong about it.

This thesis makes much more sense. It started in the central Asia area and followed the known paths of migration of peoples, farming, and culture, southwest. Eventually founding Sumer. Then as Empires wandered back and forth, absorbed some things from Persia and shifted into the present, but with lots of Cousin Languages around, some perhaps siblings, or maybe even derivatives. The Turks arising from the same origin area:

https://en.wikipedia.org/wiki/Turkic_migration

Turkic migration refers to the expansion of the Turkic tribes and Turkic languages into Central Asia, Eastern Europe and West Asia, mainly between the 6th and 11th centuries. The region of origin of the Turkic peoples is southern Siberia (North Asia) and the northern parts of modern-day Xinjiang, Mongolia and Kazakhstan.

Identified Turkic tribes were known by the 6th century, and by the 10th century most of Central Asia was settled by Turkic tribes. The Seljuq dynasty settled in Anatolia starting in the 11th century, ultimately resulting in permanent Turkic settlement and presence there. Meanwhile, other Turkic tribes either ultimately formed independent nations, such as Kyrgyzstan, Turkmenistan, Uzbekistan and Kazakhstan, and others now enclaves within other nations, such as Chuvashia, Bashkortostan, Tatarstan, the Crimean Tatars, the Uyghurs in China, and the Sakha Republic Siberia.

Turkic languages are agglutinative rather than inflected. There is a theory that each language type slowly mutates into the other. You can see some of that with English. We have largely abandoned inflected endings of Old English / Germanic in favor of small auxiliary words. The next step is to affix those words as endings, and then they become inflections. Wash and repeat…

It is known that when Siberia goes Way Way Cold, as it periodically does in climate cycles, a massive wave of migration heads south and west into the warmer areas. Was a very old one of those responsible for the formation of Sumer? Might there be interesting archaeological sites “up stream” in the source areas? Hmmmm….

Subscribe to feed

Advertisements

New Toys!

To some extent this is a “marker post”. I’ll be adding bits to it as I unpack and try out my New Toys.

For now it’s just saying that I’ve received them. What are they? They 3 SBCs that I ordered from Ameridroid with the Tip Jar. This makes somewhere around 7 or 8 things I’ve ordered from them. Every one is lower in price than Amazon, arrives a bit faster than the “slow shipping” choice claims, and has been “exactly right”. It probably helps that I’m in the same State as they are; but still: They do a good job of doing exactly what they say they will do without any negative surprises.

So what did I get?

Rock64 – smaller than I expected

Physically about the size of an Orange Pi One, but with a lot more computes inside. 8.5 x 5.6 cm. That’s small!

Here’s the blurb on it:

ROCK64 Single Board Computer
$29.95 USD

Great features at a great price!

ROCK64 is a single-board computer with a footprint similar to the ODROID-C2 and Raspberry Pi 3, but with some extra cool features! In addition to a Quad-Core ARM Cortex A53 64-bit processor, USB2.0 ports, 40-pin GPIO header and microSD slot similar to the C2 and RasPi3, it also shares the following features with the C2 that are not present on the RasPi3: eMMC module socket,4K/60fps video decoding, gigabit Ethernet and IR receiver. But the real kicker is that the ROCK64 trades 2 USB2.0 ports for a USB3.0 port to provide high-speed USB access to your projects!

Additional items required to operate – see “NOT INCLUDED” section below

KEY FEATURES

Powerful Linux/Android Computer
RK3328 1.5GHz 64-bit quad-core CPU, multi-core GPU
Mali-450 MP2 GPU supporting up to 4K@60fps video decoding via VP9 or 10-bit H265/H264
User may choose between 1GB/2GB/4GB LPDDR3 RAM (selectable on purchase, memory not expandable)
10/100/1000Mbps Ethernet with RJ-45 LAN jack
2x high speed USB2.0 host ports
1x super speed USB3.0 host port
40 GPIO pins (quasi-Raspberry Pi compatible) + Pi-P5+ Bus
128Mb SPI Flash on board
3.5mm A/V Jack on board
Physical power / reset / recovery buttons
IR Receiver
Linux or Android available
Size: 85 x 56 x 18 mm, Weight: 40g
Package includes main board

IMHO it very much will need a heat sink. I didn’t order one with it as I want to test it bare first. I’ve got an Amazon ‘wish list’ up with a package of a half dozen heat sinks in it for something like $8. If it doesn’t show up by Christmas I’ll just hit the button myself. In terms of build quality and ‘feel in the hand’, so far I like it the most ;-)

In theory, this ought ot be 1.25 or so faster than the R. Pi M3 (or hopefully about enough to be just enough…) Note that it has a USB 3.0 port, so can likely be even faster with the I/O factor. Finally, I was feeling morose about the sloth of my Pi M3 on Devuan 2.0 when I remembered that the Clock was set artificially low on Raspian. Surely Devuan fixed this, no? No.

https://chiefio.wordpress.com/2017/11/22/make-your-raspberry-pi-m3-run-2-x-as-fast-at-the-advertized-rate/

Well I changed the setting to “On Demand” and now the Devuan 2.0 is performing much better. Can you say 2 Times Better? At the advertised 1.2 MHz clock rate… It really REALLY is important to keep an eye on what the OS does to your clock settings and what kind of heat sink you have.

Now, take that double from getting back to full clock speed, multiply it by 15/12 (or 5/4) for the higher clock speed on this board, season with the fact that the Mali GPU is OpenGL friendly and it ought to be ready to rock with GPU based math, and this ought to do a great job of various math based jobs in a cluster. As we saw in a prior posting on benchmarks, with a v8 based operating system, the NEON calls really accelerate math!

At $30, it isn’t going to break the bank, either.

So after I fire it up and push it “to the wall” (and maybe a bit beyond), then, and only then, I’ll order a heat sink for it ;-)

Pine A64 – the Allwinner variation

A much larger SBC, a bit larger than the Raspberry Pi even. Slightly larger than a small USB disk. Here’s their blurb:

PINE A64
$22.95 USD

The PINE64 PINE A64 is an amazingly low-cost 64-bit single-board computer! It sports a quad-core ARM Cortex A53 64-bit processor, Mali 400 MP2 GPU, dual I/O expansion slots, HDMI 1.4a video port and 10/100 Ethernet port on the 512MB model, and 10/100/1000 Ethernet port on the 1GB model.

KEY FEATURES

Powerful Linux/Android Computer
Allwinner A64/R18 1.2GHz 64-bit quad-core CPU
Mali-400 MP2 GPU
User may choose between 512MB & 1GB DDR3 RAM
10/100/1000Mbps Ethernet with RJ-45 LAN jack on 1GB/2GB LTS models, and 10/100Mbps on 512MB model
2x high speed USB2.0 host ports
40 GPIO pins (quasi-Raspberry Pi compatible) + Euler Bus
1GB model has CSI camera port, DSI display port and touch control port
Linux or Android available
Package includes main board
Weight: 46 g
Dimensions: 127 x 79 x 21 mm

This is a $23 low cost board. I got the 1 GB version, the 512 MB board is $18. These are the “cheap seats” with zip. At 12 cm long, we’re talking a big board. Roughly 5 inches. (Remember the ancient 5 inch floppy disks? Yeah, that big.) But at $18 to $23 I’m not going to complain. No USB 3.0, so not for the Disk Server. Still it’s basically a Raspberry Pi M3 class machine for significantly less and with a Mali GPU and GigE networking. We’ll see if I can get the GPU to be a math engine or if software issue make it too much of a PITA.

RockPro64

The very high end 6 core machine with two very hot A72 cores. It’s roughly the same size a the A64 board, but a lot more computes.

This is basically a 1.5 GHz quad core A53 board with two A72 cores added onto it. All for $60. It’s a new design, and will likely have various teething problems. Still, I’m willing to “go there” and see how it does as a desktop machine (where single core performance does matter) with a proper build of a v8 64 bit OS (even if I have to build it myself). The hardware ought to rock, but the prior benchmark makes it look like they put a v7 32 bit Ubuntu on the board and hobbled it with the wrong software. We’ll see…

ROCKPro64
$59.99 USD

Looking for a powerhouse of an SBC, but one that is still affordable? The ROCKPro64 is the most powerful Single Board Computer released by PINE64, powered by Rockchip’s RK3399 processor. The RK3399 is a 6-core chip with two ARM Cortex-A72 CPU cores, four Cortex-A53 cores, and Mali-T860MP4 graphics. This impressive single board computer is offered in 2GB and 4GB configurations.

Moreover, the board comes packed with features, including an USB 3.0 and USB type C with DP1.2 port, a full PCIe x4 as well as eMMC module socket. You also get a 40pin header with I2C, SPI, UARTs and GPIOs.

The board is backwards compatible with many of the existing PINE64 peripherals, including the Wifi/BT module, camera module and LCD panel. All this in the exact same model “A” dimension as the original PINE A64.

KEY FEATURES

SoC – Rockchip RK3399 Hexa-Core (dual ARM Cortex A72 and quad ARM Cortex A53) 64-Bit Processor and MALI T-860MP4 Quad-Core GPU
RAM – 2GB or 4GB LPDDR4
PCIe x4 open ended slot
eMMCmodule/microSD card storage (not included)
1x USB 3.0 type C Host with DP 1.2, 1x USB 3.0 type A Host, 2x USB 2.0 Host
Gigabit Ethernet
PI-2 GPIO Bus
1x HDMI 2.0 port, MiPi DSI interface, eDP and Touch Panel interfaces, stereo MiPi CSI interface

RESOURCES

https://www.pine64.org/?page_id=61456

Please Note:
1. Pine64 is committed to supplying the ROCKPro64 board for at least 5 years until the year 2023.
2. The ROCKPro64 is still in early stage development cycle, so the current batch is only suitable for developers and early adopters.

I did buy the extra large heat sink for this puppy (something like $7?) as I’m certain it will be heat limiting.

What Now?

I’ll be downloading the Usual OS Build for each board and doing some general benchmarking between them (and compared to the XU4 and Pi M3). Then once I’ve worked out the details on the Gentoo build process, putting The Exact Same OS on each of them for further “head to head” runs.

I’ve likely got a couple of months of work ahead of me out of this, but I ought to have a decent idea of what is good and what is junk by the end of the week (just in case anyone is thinking Christmas ;-)

With that: Thank YOU! to all the folks who tossed some coin in the PayPal Tip Jar and made this possible. Hopefully the investment in the tip jar will return information you find worth it.

With that, I’ve got to get back to work making these things run ;-)

Update: First Benchmarks!

I’ve settled on 2 benchmarks to run. I’ve run them on the RockPro64, but can’t post captured images at the moment. I downloaded the basic OS (not a “desktop”) and tried to install LXDE on it. That turned into a bit of a goose chase, so I ran the benchmarks in a plain terminal session and wrote down the results. I’ve now downloaded the Ubuntu Desktop software, though inspecting the uSD card with gparted (intending to grow the ext4 file system) it’s all a “bag of bits”.. I’m hoping it does something trick on First Fire and turns into a system. Otherwise I’m back at a restart download uncompress etc. etc.

I also ran the benchmarks on the Odroid UX4Q (fanless). Those are the numbers I’m going to cut / past here. I ran sysbench with max prime at 20000 and max iterations at 100,000 (and it hit max iterations). Threads set to number of cores. 6 on the RockPro64 and 8 on the Odroid XU4. I also ran the “armbianmonitor -z” benchmark. I’m using the Armbian OS releases as that’s what is on the Odroid and it gives a same base of comparison. It also means I can worry about Gentoo another day.

With that:

Odroid XU4Q

First off, what kind of code are we executing?

root@odroidxu4:/# which sysbench
/usr/bin/sysbench
root@odroidxu4:/# file -s /usr/bin/sysbench
/usr/bin/sysbench: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=664005ab6bf45166f9882338db01b59750af0447, stripped

It is 32 Bit ARM executable, so v7 instructions. But we knew that because that’s all the XU4 has. A set of 4 simple v7 CPUs and 4 A15 that are also v7 cpus, but much faster. This means that to get the 64 bit precision, sysbench will need to do multiple 32 bit operations. From the man page on sysbench:

cpu
The cpu is one of the most simple benchmarks in SysBench. In this mode each request consists in calculation of prime numbers up to a value specified by the –cpu-max-primes option. All calculations are performed using 64-bit integers.

That’s going to put all 32 bit machines in the bind of using 32 bit ints to calculate a 64 bit int.

How well did it do?

chiefio@odroidxu4:/$ bench
sysbench --num-threads=8 --test=cpu --cpu-max-prime=20000 --max-requests=100000 run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 8

Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 20000


Test execution summary:
    total time:                          503.1545s
    total number of events:              100000
    total time taken by event execution: 4024.7536
    per-request statistics:
         min:                                 22.32ms
         avg:                                 40.25ms
         max:                                 82.01ms
         approx.  95 percentile:              49.11ms

Threads fairness:
    events (avg/stddev):           12500.0000/2254.45
    execution time (avg/stddev):   503.0942/0.02

503 seconds elapsed and 4024 CPU seconds. Or about 8.3 minutes and 67 CPU minutes. For comparison, the RockPro64 had:
33 seconds elapsed and 201 CPU seconds. Or about 1/2 minute and 3.35 CPU minutes. This with no heat sink too!

Clearly if you are doing 64 bit math you want a 64 bit hardware math processor.

So I’ll need to look over some of the climate model codes I’ve got again and see if they mostly do 32 bit or 64 bit math. IIRC, it was mostly 32 bit… but I wasn’t looking all that carefully…

Next up, the Armbianmonitor test:

root@odroidxu4:/# armbianmonitor -z
Preparing benchmark. Be patient please...

7-Zip (A) 9.20  Copyright (c) 1999-2010 Igor Pavlov  2010-11-18
p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,8 CPUs)

RAM size:    1996 MB,  # CPU hardware threads:   8
RAM usage:   1701 MB,  # Benchmark threads:      8

Dict        Compressing          |        Decompressing
      Speed Usage    R/U Rating  |    Speed Usage    R/U Rating
       KB/s     %   MIPS   MIPS  |     KB/s     %   MIPS   MIPS

22:    5764   641    875   5607  |    88379   685   1163   7970
23:    3539   481    750   3606  |    87062   679   1172   7965
24:    4305   552    838   4628  |    85001   699   1127   7884
25:    4214   572    841   4812  |    83972   721   1095   7896
----------------------------------------------------------------
Avr:          561    826   4663               696   1139   7929
Tot:          629    983   6296

Monitoring output recorded while running the benchmark:

Time       big.LITTLE   load %cpu %sys %usr %nice %io %irq   CPU  C.St.
16:18:50: 1100/ 600MHz  0.83  34%   1%  29%   0%   3%   0% 58.0°C  0/3
16:18:55:  600/ 600MHz  0.76   0%   0%   0%   0%   0%   0% 55.0°C  0/3
16:19:00: 2000/ 600MHz  0.70   1%   0%   0%   0%   0%   0% 66.0°C  1/3
16:19:07: 1600/1500MHz  1.36  89%   2%  87%   0%   0%   0% 83.0°C  3/3
16:19:13: 1600/1500MHz  2.46  72%   2%  69%   0%   0%   0% 81.0°C  3/3
16:19:18: 1100/1500MHz  2.42  58%   2%  56%   0%   0%   0% 70.0°C  2/3
16:19:24: 1600/1500MHz  2.87  84%   1%  82%   0%   0%   0% 85.0°C  3/3
16:19:29: 1600/1500MHz  2.96  57%   3%  54%   0%   0%   0% 83.0°C  3/3
16:19:35: 1500/1500MHz  3.36  88%   3%  84%   0%   0%   0% 84.0°C  3/3
16:19:40: 1600/ 600MHz  3.81  72%   2%  69%   0%   0%   0% 79.0°C  3/3
16:19:47: 1500/1500MHz  3.59  64%   1%  62%   0%   0%   0% 86.0°C  3/3
16:19:52: 2000/ 600MHz  3.94  58%   0%  58%   0%   0%   0% 83.0°C  3/3
16:19:58: 1500/1500MHz  3.71  81%   5%  75%   0%   0%   0% 83.0°C  3/3
16:20:03: 1400/1500MHz  4.29  87%   3%  83%   0%   0%   0% 84.0°C  3/3
Time       big.LITTLE   load %cpu %sys %usr %nice %io %irq   CPU  C.St.
16:20:08: 1400/1500MHz  4.50  90%   2%  87%   0%   0%   0% 84.0°C  3/3
16:20:13: 1500/1500MHz  4.78  92%   2%  90%   0%   0%   0% 85.0°C  3/3
16:20:18: 1700/ 600MHz  4.72  59%   2%  57%   0%   0%   0% 82.0°C  3/3
16:20:24: 1800/ 600MHz  4.58  23%   1%  22%   0%   0%   0% 78.0°C  3/3
16:20:30: 1400/1500MHz  4.86  98%   2%  96%   0%   0%   0% 87.0°C  3/3

Particularly interesting to me is that this one, if run as root, tells you what your core temperatures are doing. Here we can see the A15 cores sometimes hitting 2 GHz, but frequently heat limiting back down to 1400-1600 MHz. I suspect the model with the fan would do better here ;-) FWIW, it doesn’t take much air movement to help. In a different test I just fanned the thing with an Airstream Sales Brochure and dropped the temp down to 79 C. Very modest air flow.

This test does not always fully load the CPU, so some of the lower freq settings are when load is low. Clearly the 600 MHz is when near idle.(CPU shown as 0%) then it jumps up to 2 GHz at the first hit of the load, then drops back at 89% loaded. Further down it hits 83 C and starts to heat limit with freq held back to 1600 MHz (notice that the “little” cores are left fully loaded and full speed at 1500 MHz). Then the load drops off to 58% and the BIG CPUs are idled back to 1100 MHz. This benchmark does bursts of p7zip compresses and decompresses and there are times the CPU load is not filling up all the cores.

I *THINK* the R/U is rated MIPS / CPU.. but the man page is unenlightening. In any case, it gets 825 Ave Mips/u and 4663 total on compression with 1139 /u and 7929 on decompression.

The RockPor64 came in at 895 / u and 4323 total on compression with 1516 /u and 8014 total on decompression.

895/825=1.085 x the per core speed for the RockPro64 average.
4323/4663=0.927 x the total throughput,or about 93% of the XU4 fully booked – but no heat sink.

1516/1139=1.33 x the per core on decompression, a full 1/3 faster on average.
8014/7929=1.01 x the total on decompression, so roughly a wash on total throughput.

So what’s that mean to me? Looks like with fewer cores, the RockPro64 overall beats the Odroid XU4Q even without a heatsink(!) and only slightly under performs it on one compression benchmark test. Furthermore, when you just need One Fast CPU Core for some single threaded job, it will way outperform using just the A72 core. Hopefully I’ll be able to put a suitable desktop OS on it and see how FireFox does. That’s the one limiting / irritation on the R. Pi M3. Which reminds me, I ought to benchmark it next…

Overall, I’m quite pleased with the RockPro64. As soon as I’ve got some decent screen grabs of the benchmark without heat sink, then I’ll apply the one I have and re-run the tests. See if it is heat limiting or not. Watching the CPU freq display, it looked like it was holding a steady 1.8 GHz the whole test with temps ranging from 46.9 C to 79.4 C so not getting that hot. It looks like this chip does better overall heat management. Don’t know if it is just more efficient (smaller gate sizes), the metal packaging, or heat being sent out through the PC Board. Whatever it is, I’m liking it. It did get hot to the touch during testing (that 80 C point is kinda hot to touch ;-) but seems to have not slowed down.

One Caveat:

At first unboxing, I shut off the XU4 (where I’d made the OS chip for the RockPro64) and unplugged it’s power brick from the power strip. Then unplugged all the various wires from it to move things like Ethernet, KB/Mouse/USB-hub, Monitor, etc over to the RockPro64. Plugged the (relatively huge like a laptop “rat on a rope” 12 VDC power brick) in for the RockPro64, then reached over and plugged the round power connector into the board.

Nothing Happened

WT? Click power switch on board. Plug and unplug barrel connector. Look up web page for what switch is a which… Got the Voltmeter to test the power brick for V out. Read that the green LED by the power in connector out to light up when power is on. White near the reset button when the OS loads. No LEDs on. Go to unplug the power from the board to apply Voltmeter… and notice the wire is a little thin and doesn’t seem to be going to the right place… Follow it and find the 5 VDC power wall wart for the XU4 laying on the desktop. Oh Dear.

WARNING: IF you have multiple SBCs, and one of them has that size barrel connector, I’m sure it would do Very Bad Things to send 12 VDC into your Odroid XU4. Only my habit of unplugging both ends prevented a “wrong volts” event (though hopefully 5 VDC in to the RockPro64 would do no harm).

OK, nag mode off ;-) Now I’ll go see if I can get a desktop up, do a set of Pi M3 and RockPro64 with data grabs, and maybe work in the Rock64 after dinner ;-)

Raspberry Pi Model 2 – 64 Bit Devuan OS

Well, this is a bit of a surprise. The Raspberry Pi M3 running a full 64 bit Devuan 2.0 OS did a very credible job on the sysbench benchmark. It isn’t running Armbian so no Armbianmonitor results. (I’ll need to boot a different chip for that).

Only 4 cores, so run with only 4 threads, it finishes far faster than the XU4, and only takes 2 x as long as the RockPro64.

root@devuan:/SG2/ext/chiefio/bin# ./bench 4
sysbench --num-threads=4 --test=cpu --cpu-max-prime=20000 --max-requests=100000 run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 4

Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 20000


Test execution summary:
    total time:                          77.5115s
    total number of events:              100000
    total time taken by event execution: 309.9987
    per-request statistics:
         min:                                  3.05ms
         avg:                                  3.10ms
         max:                                 30.34ms
         approx.  95 percentile:               3.10ms

Threads fairness:
    events (avg/stddev):           25000.0000/110.88
    execution time (avg/stddev):   77.4997/0.00

Compare 77 seconds vs 33 seconds for the RockPro64 and 503 seconds for the XU4.

root@devuan:/SG2/ext/chiefio/bin# file -s /usr/bin/sysbench
/usr/bin/sysbench: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=60f81f8faa3466144dadca7bf3f1e368a40d3159, stripped

That full 64 Bit math sure is a winner!

The R.Pi didn’t heat up all that much either.

root@devuan:/home/chiefio# cpustate
Freq
1200000

Temp x 1000
60148

Freq
1200000

Temp x 1000
61224

These results also make sense as the 4 A53 cores in both chipsets are running almost the same clock speed while the 2 x A72 cores are about double the throughput as an A53 core. In short, the RockPro64 ought to be about double the total computes of the Pi chip.

For 32 bit problems, the XU4 and RockPro64 are about the same, but for 64 bit math, the 32 bit hardware takes it in the shorts; and even the R.Pi M3 beats it.

Rock64

First off, I’m posting this from a Chromium browser on the Rock64. The Armbian OS for it is built with an XFCE desktop and Chromium browser. Not my favorites, but certainly nice enough. The “htop” command has the very nice feature of displaying CPU frequency by CPU along with chip temperature. I hope that migrates to other systems ‘soon’.

I ran into one “almost show stopper” on the Rock64. It uses an odd size barrel connector PSU. I’d just “lept to the conclusion” that as a very small board it would use uUSB for the power. Nope. The Orange Pi One also uses a small barrel connector at 5 VDC, but it’s about 1/2 mm too big. Well, with a bit of force, not so much as to break anything but more than for “on a regular basis”, I got it to connect and power up the board. When I’m done posting this it will be powered off until I can get a proper PSU for it. (Power Supply Unit).

The O.Pi One is 4 mm OD x 1.7 mm ID.
The Rock64 is 3.5 mm OD x 1.35 mm ID.

So 1/2 millimeter squashing of the fitting on the board and then .35 mm ‘looseness’ on the inner pin. Not good, but not catastrophic for one use.

Overall, I like it. With the USB 3.0 port and Mali video, it is likely a better choice for general use (for my kinds of use) than the R. Pi M3. It is also 4 c A53 cores and at 1.3 GHz is trivially faster than the 1.2 GHz of the Pi M3 but trivially slower than the 1.4 GHz Pi M3 B+. For file server duty, with the USB 3.0, it will be better. For GPU based computing, it will be easier to “make go” as it is a more common GPU (Graphics Processor Unit).

Basically, I like this little board.

On to the statistics of the benchmark. They are remarkably similar to the R. Pi M3. The Pi M3 is 77 1/2 seconds elapsed 310 seconds total CPU time. The Rock64 is 72 seconds and 290. I doubt folks will notice the difference. What I DID notice was that it didn’t heat limit even without a heat sink. Never went above 72 C. It also runs at full 1.3 GHz “out of the box” (unlike the Pi that is set to 1/2 speed clock unless you intervene.) For most folks, those two things alone will be worth it. For the model I got, the 2 GB of main memory is also nice. Reduced need for swapping. Being $30 is nice too. (Made in China not so much…)

OK, here’s the report:

root@rock64:/SG2/ext/chiefio/bin# ./bench 4
sysbench --num-threads=4 --test=cpu --cpu-max-prime=20000 --max-requests=100000 run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 4

Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 20000


Test execution summary:
    total time:                          72.4354s
    total number of events:              100000
    total time taken by event execution: 289.6596
    per-request statistics:
         min:                                  2.80ms
         avg:                                  2.90ms
         max:                                 57.89ms
         approx.  95 percentile:               2.83ms

Threads fairness:
    events (avg/stddev):           25000.0000/220.63
    execution time (avg/stddev):   72.4149/0.01


armbianmonitor -z
Preparing benchmark. Be patient please...
Selecting previously unselected package p7zip.
(Reading database ... 67333 files and directories currently installed.)
Preparing to unpack .../p7zip_16.02+dfsg-3+deb9u1_arm64.deb ...
Unpacking p7zip (16.02+dfsg-3+deb9u1) ...
Setting up p7zip (16.02+dfsg-3+deb9u1) ...
Processing triggers for man-db (2.7.6.1-2) ...

7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,4 CPUs LE)

LE
CPU Freq:  1283  1281  1283  1271  1278  1271  1282  1286  1284

RAM size:    1991 MB,  # CPU hardware threads:   4
RAM usage:    882 MB,  # Benchmark threads:      4

                       Compressing  |                  Decompressing
Dict     Speed Usage    R/U Rating  |      Speed Usage    R/U Rating
         KiB/s     %   MIPS   MIPS  |      KiB/s     %   MIPS   MIPS

22:       1781   305    568   1733  |      53464   381   1198   4561
23:       1903   328    592   1939  |      54009   390   1197   4673
24:       1883   340    596   2025  |      51261   380   1184   4500
25:       1848   351    602   2111  |      50178   389   1149   4466
----------------------------------  | ------------------------------
Avr:             331    589   1952  |              385   1182   4550
Tot:             358    886   3251

Monitoring output recorded while running the benchmark:

Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.
05:09:21: 1296MHz  2.63  24%   2%  14%   0%   7%   0% 59.5°C  0/7
05:09:26:  600MHz  2.42   4%   1%   3%   0%   0%   0% 55.0°C  0/7
05:09:31: 1296MHz  2.30  29%   1%  27%   0%   0%   0% 60.0°C  0/7
05:09:36: 1296MHz  2.60  54%   2%  52%   0%   0%   0% 66.5°C  0/7
05:09:43: 1296MHz  2.71  93%   2%  90%   0%   0%   0% 70.8°C  0/7
05:09:48: 1296MHz  2.73  79%   2%  76%   0%   0%   0% 67.7°C  0/7
05:09:56: 1296MHz  3.00  90%   2%  88%   0%   0%   0% 72.5°C  0/7
05:10:01: 1296MHz  3.14  80%   1%  78%   0%   0%   0% 68.5°C  0/7
05:10:07: 1296MHz  3.13  85%   2%  82%   0%   0%   0% 69.6°C  0/7
05:10:12: 1296MHz  3.28  91%   2%  88%   0%   0%   0% 70.0°C  0/7
05:10:18: 1296MHz  3.18  92%   1%  90%   0%   0%   0% 72.5°C  0/7
05:10:24: 1296MHz  3.00  67%   2%  65%   0%   0%   0% 67.7°C  0/7
05:10:29: 1296MHz  3.00  83%   2%  80%   0%   0%   0% 68.5°C  0/7
05:10:34: 1296MHz  3.00  86%   2%  83%   0%   0%   0% 70.0°C  0/7
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.
05:10:39: 1296MHz  3.00  89%   2%  87%   0%   0%   0% 69.6°C  0/7
05:10:44: 1296MHz  3.00  93%   3%  89%   0%   0%   0% 69.6°C  0/7
05:10:50: 1296MHz  3.38  96%   3%  92%   0%   0%   0% 69.6°C  0/7
05:10:55: 1296MHz  3.51  98%   3%  95%   0%   0%   0% 70.0°C  0/7

The CPU is pegged more often on this armbianmonitor benchmark than were the other boards. Understandable as the speed is slower so less likely disk or other things will limit first. Note that CPU temp never goes over 72.5 C so this is one cool cookie. Frequency stays 1.3 GHz throughout. Nice.

With that, time to shut it down and order the proper power supply…

RockPro64 – Armbian Ubuntu

This is significantly faster than the terminal only version. 10 seconds vs 33. What’s different? Don’t know exactly. Different builds, different flags.

Here’s the run results:

root@rockpro64:/SG2/ext/chiefio/bin# ./bench 6
sysbench --num-threads=6 --test=cpu --cpu-max-prime=20000 --max-requests=100000 run
WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
WARNING: --num-threads is deprecated, use --threads instead
WARNING: --max-requests is deprecated, use --events instead
sysbench 1.0.11 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 6
Initializing random number generator from current time


Prime numbers limit: 20000

Initializing worker threads...

Threads started!

CPU speed:
    events per second:  2460.55

General statistics:
    total time:                          10.0037s
    total number of events:              24622

Latency (ms):
         min:                                  1.41
         avg:                                  2.44
         max:                                 28.27
         95th percentile:                      3.55
         sum:                              59969.86

Threads fairness:
    events (avg/stddev):           4103.6667/1891.79
    execution time (avg/stddev):   9.9950/0.00


armbianmonitor -z
Preparing benchmark. Be patient please...

7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,6 CPUs LE)

LE
CPU Freq:   359  1291   596  1077  1798  1797  1797  1798  1797

RAM size:    1991 MB,  # CPU hardware threads:   6
RAM usage:   1323 MB,  # Benchmark threads:      6

                       Compressing  |                  Decompressing
Dict     Speed Usage    R/U Rating  |      Speed Usage    R/U Rating
         KiB/s     %   MIPS   MIPS  |      KiB/s     %   MIPS   MIPS

22:       4400   482    888   4281  |      93959   525   1527   8013
23:       4427   510    884   4511  |      91859   523   1521   7948
24:       4077   493    890   4384  |      89059   528   1480   7817
25:       4079   529    880   4658  |      86386   545   1411   7688
----------------------------------  | ------------------------------
Avr:             504    886   4458  |              530   1485   7867
Tot:             517   1185   6163

Monitoring output recorded while running the benchmark:

Time       big.LITTLE   load %cpu %sys %usr %nice %io %irq   CPU  C.St.
06:51:55: 1800/1416MHz  3.08  17%   1%  15%   0%   0%   0% 63.8°C  0/3
06:52:00:  600/1416MHz  2.83   1%   0%   1%   0%   0%   0% 56.7°C  0/3
06:52:05:  600/ 600MHz  2.61   1%   0%   1%   0%   0%   0% 55.0°C  0/3
06:52:10: 1800/1416MHz  2.48  51%   1%  49%   0%   0%   0% 67.2°C  0/3
06:52:15: 1800/1416MHz  2.76  92%   0%  91%   0%   0%   0% 72.8°C  0/3
06:52:20: 1800/1416MHz  3.18  81%   2%  79%   0%   0%   0% 72.8°C  0/3
06:52:25: 1800/1416MHz  3.33  93%   0%  92%   0%   0%   0% 78.8°C  0/3
06:52:30: 1800/1416MHz  3.38  63%   2%  60%   0%   0%   0% 75.6°C  0/3
06:52:36: 1800/1416MHz  3.59  93%   1%  91%   0%   0%   0% 76.2°C  0/3
06:52:42: 1800/1416MHz  3.70  82%   1%  81%   0%   0%   0% 80.0°C  0/3
06:52:47: 1800/1416MHz  3.97  67%   1%  65%   0%   0%   0% 78.8°C  0/3
06:52:53: 1800/1416MHz  4.05  79%   2%  77%   0%   0%   0% 80.0°C  0/3
06:52:58: 1800/1416MHz  4.05  95%   2%  93%   0%   0%   0% 80.0°C  0/3
06:53:04: 1800/1416MHz  4.21  98%   1%  96%   0%   0%   0% 80.0°C  0/3
Time       big.LITTLE   load %cpu %sys %usr %nice %io %irq   CPU  C.St.
06:53:11: 1608/1416MHz  4.35  87%   1%  85%   0%   0%   0% 81.1°C  0/3

It only has 24,622 “events”, were the other one had 100,000; and yes, I re-ran it with the new approved –events=100000 and that made no difference. It just isn’t clear what’s different. It IS a newer sysbench. It’s also a different release of Linux, so may be missing some of the CPU slowing patches for Specter and Meltdown. Just don’t know.

Note that on the armbianmonitor -z test it holds full clock all the way to the last item when it touches 81 C and drops the BIG cores back to 1.688 GHz for a moment. This with no heat sink. Unlike the R. Pi where you MUST have a heat sink to get full speed, or the XU4 where even with a big heat sink it heat limits, this board is much more workable even without a heat sink. I’m good with that.

Overall, I’m very much impressed with the “snappy” character of this board. Even with Chromium it’s not pausing / slowing like other boards did (spell checking seems to be the issue in that it constantly scans all the text for spelling)

Frankly, I find this a quite nice “desktop experience”. I know this isn’t a Devuan and it has SystemD on it. I’ll try a Devuan “uplift” later. But for right now, I think I’m going to make this my “Daily Driver” for a while. It is interesting to watch the HTOP display that shows CPU freq for each CPU and see tht in full typing on Chromium toe two BIG cores are down at 600 MHz. Basically just the 4 x A53 cores at 1.42 GHz are “enough” for it to feel responsive.

I’ve got to think there’s some software tuning that was done that both sped up the benchmark AND makes it feel so “snappy”.

Well, this completes my benchmarks for the day. I still have a Pin64 board. It is a lower priced bigger PC Board area relative of the Rock64, using the Alwinner CPU chip. I’ll give it a go tomorrow and post results here then.

For now, I’m just kind of “really surprised” by how much different OS builds changes the performance of the hardware. Even from the same provider.

https://www.armbian.com/rockpro64/

reports this as kernel 4.4.y Bionic (the Ubuntu name) and the other system was “Stretch” – the Debian name, also on legacy kernel 4.4.y (so ought not be those Specter / Meltdown patches).

OK, I’m going to call it a night and tomorrow redo both runs on the RockPro64, just to make sure I have it right and “it isn’t about me” ;-)

Subscribe to feed