You can do what you usually do (censoring) but it gets press coverage this time

Why so upset? I think most Pi users interested in monitoring CPU frequency (including you) know to use vcgencmd. It appears the kernel reports the desired frequency based on load, but the actual frequency based on heat and power management may be less.
For posts like this you will get banned on most forums. Critical comments are one thing, bad behavior is something else.tkaiser wrote: ↑Sun Mar 18, 2018 1:14 am... So as expected the 1.2GHz DVFS OPP with RPi 3 B+ shows a lower voltage compared to the RPi 3 and it's still the same shit show with faked cpufreq values reported by the kernel on RPi. If you don't query ThreadX running on the main CPU (VC4) you have no idea what's happening.
Anyway, it's useless to discuss anything here. This forum and the whole RPi micro reality suffers from censorship. I expect my posting getting deleted by one of those retarded RPi censors soon.
Unfortunately this is not the case. Users expect
Code: Select all
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
What on earth is your problem? You turn up, start slagging the Pi off, start having a go at other forum users, use bad language, have had multiple reports made against your posts (many of them not particularly charitable, but they keep it to private reports)tkaiser wrote: ↑Sun Mar 18, 2018 1:14 amThank you. So as expected the 1.2GHz DVFS OPP with RPi 3 B+ shows a lower voltage compared to the RPi 3 and it's still the same show with faked cpufreq values reported by the kernel on RPi. If you don't query ThreadX running on the main CPU (VC4) you have no idea what's happening.jahboater wrote: ↑Sat Mar 17, 2018 7:56 pmWow - the full GCC build on the Pi3+ took 4.6 hours! down from 5.3 hours for the Pi3.
I ran your stat program at the same time as cpuburn53 :-Code: Select all
Time Temp CPU fake/real Health state Vcore ... 19:46:27: 70.4'C 1400/1200 MHz 0000000000000000000 1.2438V
Anyway, it's useless to discuss anything here. This forum and the whole RPi micro reality suffers from censorship. I expect my posting getting deleted by one of those retarded RPi censors soon.
Ok, then consider this being a bug report then. Linux standard to report the current CPU clockspeed is
Code: Select all
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
Hi there! I'm the guy wot did the benchmarks, and I completely agree that it's important to compare like-for-like - which is why I carried out the full testing across all Pi models on the same day using the same software revision on the same operating system release (in fact, on the same micro-SD card - literally taking it out of one Pi and putting it into the next in line.) Comparing my results to results obtained using different versions of different software running on a different operating system release is ill-advised - even where the software has the same name.ejolson wrote: ↑Fri Mar 16, 2018 4:17 amThat's an interesting comparison of Pi computers, especially the heat dissipation analysis. The Linpack Mflop numbers are surprisingly low. A Pi 3B when configured correctly gets more than 6000 double-precision Mflops when running at 1200MHz, but the graph shows about 200 Mflops, which is a factor of 30 times too slow. When running benchmarks, it is important to compare new with previously established results.
First: the gigabit Ethernet result is wholly accurate; it is bottlenecked by sharing a single USB 2.0 lane to the SoC. Try it yourself!tkaiser wrote: ↑Fri Mar 16, 2018 8:39 amSame with Gigabit Ethernet numbers but my favourite is the Wi-Fi 'Benchmark'. Neither bandwidth nor latency are benchmarked but 'signal quality' (and labeling channels as cells, claiming RPi 3 wouldn't be able to use channels 9 to 13 and that 3 B+ being able to use those would be related to 5GHz is plain weird).
Funny 'benchmarking gone wrong' example![]()
tkaiser wrote: ↑Sun Mar 18, 2018 1:14 amThank you. So as expected the 1.2GHz DVFS OPP with RPi 3 B+ shows a lower voltage compared to the RPi 3 and it's still the same shit show with faked cpufreq values reported by the kernel on RPi. If you don't query ThreadX running on the main CPU (VC4) you have no idea what's happening.jahboater wrote: ↑Sat Mar 17, 2018 7:56 pmWow - the full GCC build on the Pi3+ took 4.6 hours! down from 5.3 hours for the Pi3.
I ran your stat program at the same time as cpuburn53 :-Code: Select all
Time Temp CPU fake/real Health state Vcore ... 19:46:27: 70.4'C 1400/1200 MHz 0000000000000000000 1.2438V
Anyway, it's useless to discuss anything here. This forum and the whole RPi micro reality suffers from censorship. I expect my posting getting deleted by one of those retarded RPi censors soon.
Can't help but chuckle at that.This forum and the whole RPi micro reality suffers from censorship. I expect my posting getting deleted by one of those retarded RPi censors soon.
I tend to get rid of party people like that....ooooh, what a coincidence. I am awaiting an influx of complaints about how nasty we all are, how we are limiting freedom of speech (there isn't any one here by the way), how they are so upset I kept deleting their posts referencing (with pictures) Orange Pi's, how they should be allowed to point out how crap the new Pi is on the Pi forums (Duh, er, no). I've already had one cockwomble on the blog stating I need psychiatric help, so I'm pretty much prepared.Heater wrote: ↑Mon Mar 19, 2018 3:16 pmtkaiser,Can't help but chuckle at that.This forum and the whole RPi micro reality suffers from censorship. I expect my posting getting deleted by one of those retarded RPi censors soon.
It's like someone getting invited to a party, they are not even expected to bring a bottle, everyone is having a great time. Then someone starts complaining that the food is terrible, the wine is cheap, slagging of the host and all the other party goers.
Then they wonder why they get bounced out of the party...all the while complaining how badly wronged they are...
Agreed. Since about 1993 the Linpack benchmark has referred, not to running a particular code, but to solving a particular problem (systems of linear equations) using a particular mathematical algorithm (Gaussian or LU factorisation with partial pivoting). The rules are that the problem size should be large enough that it doesn't fit entirely in the cache of a single processor and that you can't use an algorithm which has different asymptotic time complexity, like Strassen's method, to solve the problem. The fact that Linpack refers to solving a particular problem rather than running a particular code has allowed Linpack to be a useful measure of computing performance for 25 years.Gareth Halfacree wrote: ↑Mon Mar 19, 2018 1:43 pmComparing my results to results obtained using different versions of different software running on a different operating system release is ill-advised - even where the software has the same name.
I can certainly understand your perspective, but again: the benchmark set is designed purely as a comparative of the performance of each Raspberry Pi model against each other Raspberry Pi model, and is presented as such; as all models are running the exact same benchmark, that comparison remains both intact and useful (and historically comparable against the benchmarks I published at the launch of other Pi models, handily demonstrating improvements made through OS and firmware optimisations, which would not be the case if I now switched to a different Linpack implementation which gives an order-of-magnitude different result.)ejolson wrote: ↑Mon Mar 19, 2018 5:44 pmRoy Longbottom's Linpack code is historically interesting and running it on modern hardware a fascinating act of retro computing. However, publishing the speed of that code as Linpack benchmark results out of context is confusing and makes the Pi hardware look 30 times slower than it really is.
That is an interesting expectation, but not what I'd expect. The only way to know for sure is to actually do the work to find out. Except for the 3B+ I can fill in most of that comparison. I'll do so in a few days. Maybe someone else will have results for the 3B+ by then.Gareth Halfacree wrote: ↑Mon Mar 19, 2018 5:55 pmHere's the thing: if I removed the X-axis labelling from the graph, so it was just bare bars with no numbers at all, the comparison would still be valid - and the graph would look identical, I would expect, to a Linpack implementation which runs 30 times faster on the same hardware.
Interesting - what would make you not expect that, if the benchmark you're using is a stable 30-times-faster than Roy's implementation?
You are right, there are also some who don't know. In this case, they were paying attention and figured it out.
Also don't forget that "exercise is good for you laziness is not"Heater wrote: ↑Mon Mar 19, 2018 10:42 pmAll I remember is that I'm supposed to remember I'm a womble:
https://www.youtube.com/watch?v=VIxkqoNi8I4
.The 3B+ SoC simply runs hotter - it's a higher clock speed, the board has the faster and hotter ethernet chip on it, and the wifi chip can also get hot...