CPU

Central Processing Unit

by

ASRock DeskMini A300M with AMD Ryzen 3400G

Below are some photographs during assembly of the Asrock A300M with an AMD Ryzen 5 Pro 3400G processor.

The Asrock web-site detailing the specs of the A300M: DeskMini A300 Series.

Three noticable reviews on the A300M:

  1. Anandtech has a very readable review of the A300M: Home> Systems The ASRock DeskMini A300 Review: An Affordable DIY AMD Ryzen mini-PC
  2. A short review from Techspot: Asrock DeskMini A300 Review.
  3. A German review with many photos during assembly: ASRock DeskMini A300 mit AMD Ryzen 5 2400G im Test.

1. CPU. Three photos from the AMD 3400G CPU:

2. Power. The power supply of the A300M will provide at most 19V x 6.32A = 120W.


3. Dimensions. The case has volume of at most two liters, exemplified by the two milk cartons.


4. Mounting. CPU mounted on motherboard.

5. Temperature. I installed a Noctua NH-L9a-AM4 cooler. Running the AMD at full speed with full load shows the following temperature using command sensors:

amdgpu-pci-0300
Adapter: PCI adapter
vddgfx:           N/A
vddnb:            N/A
edge:         +85.0°C  (crit = +80.0°C, hyst =  +0.0°C)

k10temp-pci-00c3
Adapter: PCI adapter
Vcore:         1.23 V
Vsoc:          1.07 V
Tctl:         +85.2°C
Tdie:         +85.2°C
Icore:       100.00 A
Isoc:          9.00 A

nvme-pci-0100
Adapter: PCI adapter
Composite:    +57.9°C  (low  =  -0.1°C, high = +74.8°C)
                       (crit = +79.8°C)

nct6793-isa-0290
Adapter: ISA adapter
in0:                   656.00 mV (min =  +0.00 V, max =  +1.74 V)
in1:                     1.86 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in2:                     3.41 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in3:                     3.39 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in4:                   328.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in5:                   216.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in6:                   448.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in7:                     3.39 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in8:                     3.30 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in9:                     1.84 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in10:                  256.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in11:                  216.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in12:                    1.86 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in13:                    1.71 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in14:                  272.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
fan1:                     0 RPM  (min =    0 RPM)
fan2:                  2626 RPM  (min =    0 RPM)
fan3:                     0 RPM  (min =    0 RPM)
fan4:                     0 RPM  (min =    0 RPM)
fan5:                     0 RPM  (min =    0 RPM)
SYSTIN:                 +97.0°C  (high =  +0.0°C, hyst =  +0.0°C)  sensor = thermistor
CPUTIN:                 +87.5°C  (high = +80.0°C, hyst = +75.0°C)  ALARM  sensor = thermistor
AUXTIN0:                +62.0°C  (high =  +0.0°C, hyst =  +0.0°C)  ALARM  sensor = thermistor
AUXTIN1:                +94.0°C    sensor = thermistor
AUXTIN2:                +90.0°C    sensor = thermistor
AUXTIN3:                +86.0°C    sensor = thermistor
SMBUSMASTER 0:          +85.0°C
PCH_CHIP_CPU_MAX_TEMP:   +0.0°C
PCH_CHIP_TEMP:           +0.0°C
PCH_CPU_TEMP:            +0.0°C
intrusion0:            OK
intrusion1:            ALARM
beep_enable:           disabled

Fully loaded:

  1  [||||||||||||||||||||||||||||||||||||||||                            52.9%]   Tasks: 120, 405 thr; 5 running
  2  [||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||99.4%]   Load average: 7.28 6.82 6.02
  3  [||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||99.4%]   Uptime: 8 days, 07:27:51
  4  [||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||94.1%]
  5  [|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
  6  [||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||  88.2%]
  7  [|||||||||||||||||||||||||||||||||                                   44.2%]
  8  [|||||||||||||||||||||||||||||||||||||||                             50.6%]
  Mem[|||||||||||||||||||||||||||||||||||||||||||||||||||||||       28.7G/60.8G]
  Swp[                                                                    0K/0K]
by

Parallelization and CPU Cache Overflow

In the post Rewriting Perl to plain C the runtime of the serial runs were reported. As expected the C program was a lot faster than the Perl script. Now running programs in parallel showed two unexpected behaviours: (1) more parallelizations can degrade runtime, and (2) running unoptimized programs can be faster.

See also CPU Usage Time Is Dependant on Load.

In the following we use the C program siriusDynCall and the Perl script siriusDynUpro which was described in above mentioned post. The program or scripts reads roughly 3GB of data. Before starting the program or script all this data has been already read into memory by using something like wc or grep.

1. AMD Processor. Running 8 parallel instances, s=size=8, p=partition=1(1)8:

for i in 1 2 3 4 5 6 7 8; do time siriusDynCall -p$i -s8 * > ../resultCp$i & done
real 50.85s
user 50.01s
sys 0

Merging the results with the sort command takes a negligible amount of time

sort -m -t, -k3.1 resultCp* > resultCmerged

Best results are obtained when running just s=4 instances in parallel:

$ for i in 1 2 3 4 ; do /bin/time -p siriusDynCall -p$i -s4 * > ../dyn4413c1p$i & done
real 33.68
user 32.48
sys 1.18

Continue reading →

by

Running CPU/GPU Intensive Jobs on Titan Supercomputer

There is a an INCITE program (HPC Call for Proposals), where one can apply for CPU/GPU intensive jobs, the link is INCITE.

From the FAQ: The INCITE program is open to US- and non-US-based researchers and research organizations needing large allocations of computer time, supporting resources, and data storage to pursue transformational advances in science and engineering.

The machines in question: Mira and Titan.

by

Counting to Ten on Linux

Very good article on timing CPU bound application.

Random ASCII - tech blog of Bruce Dawson

I recently discovered a Linux shell script that was running slowly due to an inefficiently implemented loop. This innocent investigation ended up uncovering misleading information from time and a bad interaction between the Linux thread scheduler and its CPU power management algorithms.

View original post 1,944 more words

by

CPU Usage Time Is Dependant on Load

I wanted to write a short benchmark for my son to demonstrate that the AMD Bulldozer 8 core CPU is better than a 6 core CPU from AMD when computing with integers. So I wrote a short C program to compute a recurrence relation using integers only, see C code below. When I ran this program on one core, then two cores, then three cores, and so on, I was a little bit surprised to see that the CPU usage time grew. Indeed, it grew quite significantly: from 20 to 60% up! Once all cores of the CPU are used then the CPU usage does no longer increase. In this case it does seem to have reached its equilibrium.

The AMD CPU is a FX 8120, 3.1GHz. For comparison I used an Intel i7-2640, 2.8GHz, 4 core CPU.

Continue reading →