rkkang has quit [Remote host closed the connection]
yann-kaelig has joined #linux-sunxi
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
kimberlykang has joined #linux-sunxi
yann-kaelig has quit [Quit: Leaving]
NiteHawk has quit [Ping timeout: 245 seconds]
NiteHawk has joined #linux-sunxi
NiteHawk has quit [Changing host]
NiteHawk has joined #linux-sunxi
NiteHawk has quit [Read error: Connection reset by peer]
NiteHawk has joined #linux-sunxi
NiteHawk has quit [Changing host]
NiteHawk has joined #linux-sunxi
pcduino has quit [Ping timeout: 245 seconds]
Uninstall_ has quit [Ping timeout: 245 seconds]
MXfive has quit [Quit: Sleep Quit.]
Uninstall has joined #linux-sunxi
pcduino has joined #linux-sunxi
Da_Coynul has joined #linux-sunxi
Colani1210 has joined #linux-sunxi
Da_Coynul has quit [Client Quit]
Colani1200 has quit [Ping timeout: 245 seconds]
BurtyB has joined #linux-sunxi
apritzel has quit [Ping timeout: 250 seconds]
ninolein has quit [Ping timeout: 245 seconds]
ninolein has joined #linux-sunxi
robogoat_ is now known as robogoar
robogoar is now known as robogoat
MXfive has joined #linux-sunxi
MXfive has quit [Client Quit]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
tjstyle has joined #linux-sunxi
terra854 has joined #linux-sunxi
<tjstyle>
Hi, anyone know what is processor model name for sun8iw10?
paulk-collins has quit [Quit: Leaving]
orly_owl has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
nixdork has quit [Ping timeout: 258 seconds]
fvogt_vps has quit [Remote host closed the connection]
nixdork has joined #linux-sunxi
arossdotme has joined #linux-sunxi
arossdotme-planb has quit [Ping timeout: 256 seconds]
tjstyle has quit [Remote host closed the connection]
pg12 has quit [Ping timeout: 256 seconds]
pg12 has joined #linux-sunxi
repka has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
Putti has quit [Ping timeout: 256 seconds]
gianMOD has joined #linux-sunxi
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
petr has quit [Ping timeout: 265 seconds]
petr has joined #linux-sunxi
jernej has joined #linux-sunxi
gianMOD has joined #linux-sunxi
MXfive has joined #linux-sunxi
IgorPec has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
JohnDoe_71Rus has joined #linux-sunxi
lkcl has quit [Ping timeout: 250 seconds]
IgorPec has quit [Ping timeout: 260 seconds]
leviathanch has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
jernej has quit [Ping timeout: 244 seconds]
cnxsoft has joined #linux-sunxi
f0xx has joined #linux-sunxi
MXfive has quit [Quit: Sleep Quit.]
f0xx has quit [Quit: terminated!]
f0xx has joined #linux-sunxi
menomc has joined #linux-sunxi
fest_ has joined #linux-sunxi
Jacmet_ has joined #linux-sunxi
leio_ has joined #linux-sunxi
mnemoc has quit [Ping timeout: 265 seconds]
fest has quit [Ping timeout: 265 seconds]
[7] has quit [Ping timeout: 265 seconds]
repka has quit [Ping timeout: 265 seconds]
Jacmet has quit [Ping timeout: 265 seconds]
leio has quit [Ping timeout: 265 seconds]
alexxy has quit [Ping timeout: 265 seconds]
fest_ is now known as fest
alexxy has joined #linux-sunxi
repka has joined #linux-sunxi
TheSeven has joined #linux-sunxi
montjoie has quit [Quit: leaving]
leio_ is now known as leio
Vogtinat_ has joined #linux-sunxi
Vogtinat_ is now known as fvogt_vps
massi has joined #linux-sunxi
naobsd has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
Gerwin_J has joined #linux-sunxi
Leepty has joined #linux-sunxi
bugzc has quit [Ping timeout: 256 seconds]
matthias_bgg has joined #linux-sunxi
Worf has joined #linux-sunxi
Worf has quit [Remote host closed the connection]
Worf has joined #linux-sunxi
Worf_ has joined #linux-sunxi
Worf has quit [Ping timeout: 256 seconds]
fl_0 has quit [Ping timeout: 245 seconds]
fl_0 has joined #linux-sunxi
dh1tw has joined #linux-sunxi
leviathanch_ has joined #linux-sunxi
leviathanch has quit [Ping timeout: 256 seconds]
<oliv3r>
ssvb: well on my first sample, lima-tester run all night. going to add more samples during the curse of the day, i want to have 6 running for the next week.
dh1tw has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<oliv3r>
ssvb: i cna check on a few if the background turns pink/we get corruption on the cube, but i probably only have ssh access to the most of them. Is there a way to get the crash/fail status from the output?
<KotCzarny>
you should check for red background on all
<oliv3r>
ssvb: as for the cross-compiler; i'm cross-compiling kernels and u-boot without problem otherwise (using sunxi-bsp still :p)
<KotCzarny>
hmm
<KotCzarny>
ssvb, regarding above, how about dumping screen contents into png file every 1-10s?
<KotCzarny>
and maybe serving it over http?
<oliv3r>
not a horrible idea; i think we can cat /dev/fb0 normally
<KotCzarny>
(using kernel http server, so no need to add any additional software)
<oliv3r>
or busybox http server :p
<KotCzarny>
you are using png/jpeg lib anyway for testing so its there too
JohnDoe71rus has joined #linux-sunxi
JohnDoe_71Rus has quit [Read error: Connection reset by peer]
leviathanch_ has quit [Remote host closed the connection]
speakman_ is now known as spekaman
Da_Coynul has joined #linux-sunxi
<ssvb>
oliv3r: it may be more efficient to do a few quick runs increasing the DRAM clock speed in 24MHz steps until it starts failing pretty soon (less than 1 minute) and then step down from that point
<KotCzarny>
ssvb, i think he just wants to check 480
<KotCzarny>
and not the max
<ssvb>
KotCzarny: well, finding the max speed is much more useful than that
<tkaiser>
KotCzarny: Maybe oliv3r finds out that heatsinks on DRAM matter, so by exceeding 480 MHz also this finding will be faster
<ssvb>
because with the max speed we can pick some safety margin and be done with that
<ssvb>
while just running a single long test at 480MHz, we can't be sure if it can really fail after running for 1 night, running for 3 days, running for a week, etc.
<KotCzarny>
it would be useful to have automated image for that
<KotCzarny>
but that would require working watchdog too
<ssvb>
we have all of this
<KotCzarny>
and saving results in files according to sid/mac/someother id
<ssvb>
people simply don't care about reliability, unless the device is misbehaving in a really obvious way
<KotCzarny>
they are not to tier performants, so people dont expect them to be power horses
<KotCzarny>
that's why even lower speeds work for many
<ssvb>
these lower speeds are ass-pulled as well, they may or may not work reliable
<KotCzarny>
statistically speaking even optimized settings can fail in different environments (radon tends to affect computers stability greatly in mountain areas)
<ssvb>
for example, with a hynix ddr3 equipped pcduino2 board, we need to reduce the DRAM clock speed to 360MHz, because 384MHz is not low enough
<ssvb>
if you pick 384MHz as a "reasonably safe" choice, then some boards still will fail
<KotCzarny>
but per particular board model you can expect the same sane value
<KotCzarny>
as long people will provide test results
<tkaiser>
KotCzarny: When DRAM chips and resistors change then 'sane values' from the past are unreliable now
<KotCzarny>
then make a new test batch and see if it needs to be lowered
<ssvb>
who is going to do this test? in the ideal case, that would be the board manufacturer, but they usually don't care
<KotCzarny>
if you provide fully automated test suite, it might be a tool to coerce some of them to test it
<ssvb>
in fact they tend to overclock boards out of the box, because they can have nicer mhz numbers in their advertisements
<KotCzarny>
thats true unfortunatelly
JohnDoe71rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
<ssvb>
I offered to provide a fully automated test suite, but nobody was interested
<KotCzarny>
honesty isnt rewarding the bussinesses
JohnDoe_71Rus has joined #linux-sunxi
<KotCzarny>
but at least oranges with h3 arent advertised as 1.5ghz anymore ;)
<ssvb>
again, end users don't mind the risk of having occasional bitflip problems
<ssvb>
these devices are mostly toys for hobbyists
<tkaiser>
But I see a problem with 'defaults' that are set too high (u-boot) since defaults aren't questioned. We (Armbian) for example decided to use 408 MHz for NanoPi NEO or Air (and also just 912 MHz cpufreq instead of 1200) -- not a single complaint about that. So I really don't understand why we're using 480 MHz for A10/A20 boards and 672 MHz for H3
<tkaiser>
The last 'we' as in 'linux-sunxi community' or u-boot folks
<oliv3r>
ssvb: but i'm running at 480Mhz, what would be the value in increasing the clock further
<tkaiser>
oliv3r: 24 MHz steps
<KotCzarny>
oliv3r: seeing the margin
<oliv3r>
ssvb: i want to prove that 480Mhz is unstable, but so far, it seems perfectly fine :)
<ssvb>
oliv3r: 480 + 24 = 504
<oliv3r>
ok fair nuff
<KotCzarny>
if your board wou.ld fail in 504, then you will know that 480 is risky
<oliv3r>
increase freq. see what the maximum is
<oliv3r>
now your giving me tons of work :p
<ssvb>
and if 504 fails, then it's probably unreasonable to use 480 in production (you really want to have some safety margin)
<tkaiser>
oliv3r: Nope, that's fast. Just test from top to bottom. As soon as it fails use 24 Mhz lower value and start longer tests
<oliv3r>
well i wanna test it on many many boards
<KotCzarny>
see how many of them fail with 504 and 528 withing first 15 minutes
<KotCzarny>
that could give your some statistics
<tkaiser>
Nope, start from top to bottom, no need to waste 15 minutes each!
<tkaiser>
oliv3r: Do you use the u-boot .debs provided weeks ago?
<oliv3r>
tkaiser: i do
<ssvb>
btw, the a20 soc is used undervolted by the mainline kernel
<oliv3r>
ssvb: really
<ssvb>
it's also a risk factor if you really care about the reliability
<tkaiser>
oliv3r: What was the highest clockspeed available?
JohnDoe_71Rus has quit [Ping timeout: 250 seconds]
<ssvb>
vendors want to label A20 boards as having "1GHz processor"
<ssvb>
while Allwinner only clocks them up to 912MHz
<ssvb>
unless you want to increase the voltage beyond 1.4V
JohnDoe_71Rus has joined #linux-sunxi
<oliv3r>
ssvb: hmm, we are using the performance governer now, because I think we had some stability issue with the ondemand one
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<oliv3r>
ssvb: but why is the mainline kernel undervolting it?
<tkaiser>
oliv3r: For the same reason u-boot is overclocking DRAM? ;) No one cares?
<oliv3r>
O.o
<oliv3r>
that's silly
<ssvb>
oliv3r: the mainline kernel is now using the dvfs operating points invented by mripard via the "let's keep high CPU clocks speed, but reduce the core voltage to a 'safe' 1.4V level specified by the a20 datasheet" method :)
<oliv3r>
that's insane
<oliv3r>
unless it was validated that its' stable that way
<oliv3r>
but to be fair, how do we know what the correct values are
<oliv3r>
allwinner isn't really reliable in that regard either
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
<ssvb>
there is the 960MHz operating point, which is "approximately" 1GHz (so one can keep claiming ~1GHz clock speed), while the voltage is set to 1.4V
<KotCzarny>
then all that remains is creating statistics big enough to be safe
<oliv3r>
so 1.45V we kinda know is to high, right?
<KotCzarny>
100 devices? 1000?
<oliv3r>
but do we have evidence that 960@1.40 is unstable though
<ssvb>
with newer SoCs, Allwinner specifies two voltages: recommended maximum and absolute maximum (1.4V and 1.5V for H3)
<ssvb>
so it's like 1.4V is "good", 1.5V is "bad" and the real voltage limit is somewhere in between
<oliv3r>
but that's H3, does this also mean A20?
<KotCzarny>
good, bad, devices will be obsolete long before they burn out
<oliv3r>
or do we just 'assume'
<oliv3r>
nobody cares about burning out
<ssvb>
in the A20 datasheet, both recommended and absolute maximum voltages are specified as 1.4V
<oliv3r>
it's about stability
<KotCzarny>
stability for how long?
<oliv3r>
that's the question
<oliv3r>
is it acceptable that it runs for a day at full cpu load? a week? a month?
<oliv3r>
though after a few hours usually means a few weeks as well; generally speaking as you reach your temperature equilibrium
<KotCzarny>
for you its about as long it doesnt cost user money
<ssvb>
when you are undervolting the CPU, the processor starts misbehaving
<oliv3r>
ssvb: btw d96b7161916 introduced the 960@1.4v
<oliv3r>
for me, it's about the stability of our platform, our users expect our product to be stable and reliable for weeks
<oliv3r>
so if we have undervolted parts in there
<KotCzarny>
do you use all cpu power?
<KotCzarny>
if not just downclock
<oliv3r>
yes i do
<oliv3r>
but that's a stupid solution
<oliv3r>
the platform should be rock solid with the defaults
<oliv3r>
if users want more performance, then they should overclock
<KotCzarny>
yup
<oliv3r>
underclock/undervolt should be applied to save power (e.g. run slower, but still stable/safe)
<KotCzarny>
OC is fine as long user knows he is doing it
<oliv3r>
exactly
<oliv3r>
and thus, if 960@1.40v is not stable (undervolting the core) then it should not be the default.
<tkaiser>
oliv3r: Think about increased voltages for lower dvfs operating points and your observations regarding ondemand vs. performance ;)
<oliv3r>
e.g. drop the maximum operation point
<KotCzarny>
also, electronics is not entirely 0/1
<KotCzarny>
badly designed board is more prone to interferences == lower margins
<oliv3r>
tkaiser: what do you mean?
<oliv3r>
what worries me about hte bananapi patch is, that they raised all the voltages, which is strange
<oliv3r>
execpt the maximum voltage
<tkaiser>
oliv3r: If you experience instabilities with ondemand but not with performance then not the highest operating point is undervolted but the lowest or those in between
<oliv3r>
so with this, it seems that the ondemand governor may show the instability due to the lower voltages as you get lots of switching
<oliv3r>
tkaiser: exactly
<oliv3r>
as i just said :)
<tkaiser>
oliv3r: Banana Pi people also raised voltages for the higher operating point in fex files, but that got lost whith mainline kernel
<ssvb>
wens: isn't it more reasonable to use the dvfs operating points from the Allwinner's A20 SDK rather than taking everything that was ever mentioned in the FEX files?
<oliv3r>
a) we don't want to operate above 1.4v as that's the 'recommended/maximum'. anything above that is 'up to the user'
<oliv3r>
b) we probably are running with voltages that are to low for the other ranges, as can be seen by the bananapi
<tkaiser>
oliv3r: Their limit is 912 MHz at 1425 mV ;)
<oliv3r>
tkaiser: i'm a little nervous about the overvolting though :p
<KotCzarny>
you can run even 300mhz at 1.4V
<oliv3r>
yeah that's not an issue
<tkaiser>
oliv3r: Then you go with 864 MHz at 1.4V ;)
<KotCzarny>
it doesnt change anything other than power drain
<oliv3r>
you lower the voltage to save power
<oliv3r>
but pumping too much power into your chip can cause issues, one is temperature related, which is measureable
<ssvb>
tkaiser: some boards are more sensitive to low voltage, probably because of the voltage drop between the PMIC and the SoC
<oliv3r>
but you can still get a missbehaving chip, even though the temps are fine
<ssvb>
tkaiser: banana pi is apparently one of them
<oliv3r>
that is however as I said, badly designed board. so your PMIC output is not what reaches the SoC
<tkaiser>
ssvb: Sure, just wanted to point out that there were different settings that only somewhat found their way into mainline
gianMOD has joined #linux-sunxi
<oliv3r>
and thus the patch should read as such 'increase voltages as the board is badly designed and drops too much voltage'
<NiteHawk>
it's also very depedent on the actual hardware. i'm happily running my bpi-m1 with 1008mhz@1.4v (with a tweaked .dts), but i accept that's a "personal" choice and might not work for others
<NiteHawk>
..dependent
<oliv3r>
NiteHawk: the point is however, you want the mainline values to be absolutly rock solid
<KotCzarny>
nitehawk, do you abuse it or only for occasional turbo peaks?
<oliv3r>
the example of the pananapi maybe dropping too much voltage is a good argument to override it in the bananapi dts
<oliv3r>
but i saw similar things on the lime2; ondemand caused crashes; performance seems fine
<oliv3r>
assuming the crashes we see now are ram related
<NiteHawk>
KotCzarny: normally i'm using "ondemand" governor, so that would be "peak usage". i initally did some tests with "performance" setting though
<tkaiser>
ssvb: BTW: All the H3 boards without SY8106A support suffer from the same problem: Variation in DC-IN voltage cause variations in VDD_CPUX, I realized that when feeding 4.7V and 5.2V on NanoPi NEO or Orange Pi Lite
<ssvb>
tkaiser: well, my opinion is that the board manufacturer has the final say about what operating points should be used with their hardware
<KotCzarny>
do they care?
<KotCzarny>
;)
<ssvb>
sometimes they do
<KotCzarny>
who? where?
<ssvb>
oliv3r: anyway, to be on a safe side, just try to get rid of the 960MHz operating point because it overclocks the CPU compared to the reference DVFS table from Allwinner
spekaman is now known as speakman
<tkaiser>
oliv3r: ssvb: 'work around' mode: Install cpufrequtils and set max cpufreq to 912 MHz
<tkaiser>
But this won't affect 'holes' in dvfs table, to be sure one has to test through all of the dvfs operating points.
<oliv3r>
ssvb: i agree
<oliv3r>
the testing effort is what's so gruesome here, as you potentially need to test a few dozen of boards to (in)validate things
<tkaiser>
oliv3r: In case you use now a recent Armbian image you could give 'sudo armbianmonitor -p' a try. This install cpuminer in benchmark mode.
<tkaiser>
Then you can run minerd --benchmark and walk through the available cpufreq steps and check for instabilities. This way you might identify undervolte dvfs operating points.
<oliv3r>
tkaiser: i use 5.20-legacy; but this will work on a few boards; it doesn't help with a small sample size however
<oliv3r>
i'll first find my bootloader collection and try that as well
<oliv3r>
just to see what my margin is
<tkaiser>
But a special Linpack version would be better. We tested with this version back in March through dvfs settings for Pine64 and it was pretty nice to get invalidated linpack results before the board crashed
<ssvb>
yes, Linpack sees to be the most sensitive to CPU undervolting
<ssvb>
then we need results from multiple boards to indentify the worst sample, and then we also need some safety margin
<ssvb>
but until this is done, using the Allwinner's DVFS table is a safer choice, especially considering that it is more conservative than the DVFS table from the mainline kernel
IgorPec has quit [Ping timeout: 252 seconds]
<oliv3r>
ssvb: i agree, safe first; if proven we can increase the speed safely by comparing loads of boards, then increase it by all means
<wens>
ssvb: i assumed the fex file table is used by the vendor kernel
<oliv3r>
i'm about to send a mail to the sunxi mailing list, we can discuss it generally further there
<oliv3r>
ssvb: one more thing about the dram freq. why can we not just lower the freq. and assume all is stable? If 480 is 'almost stable for all' I would say 456 or 432 should be rock solid. Why can we not say 384 must thus be absolutly safe?
<oliv3r>
nice, lima-memtester caused a full lockup on my 'potentially unstable board'
<oliv3r>
:)
<oliv3r>
excellent
<KotCzarny>
having fun yet?
<oliv3r>
:)
<oliv3r>
well i can reproduce my stability issue
<oliv3r>
so thats great
tjstyle has joined #linux-sunxi
tjstyle has quit [Remote host closed the connection]
* jonkerj_
was thinking of automated testing of operating points on his H3 'test cluster'
<jonkerj_>
three boards, of which 1 controls the DCIN of the other two through USB relay and a PSU
jonkerj_ is now known as jonkerj
<KotCzarny>
jonkerj: as long as the watchdog does its work it would be enough to just script the test properly
<jonkerj>
the third one could act as a supervisor, serving u-boot a 'script' containing a set of fdt commands to alter the operating points
<jonkerj>
and be a watchdog as well through the usb relay
<KotCzarny>
and the image can self modify/store results
<jonkerj>
and collect results through http
<jonkerj>
or something like that
<KotCzarny>
all boards have hw watchdog, right?
solarnetone has joined #linux-sunxi
<jonkerj>
but it would be much more useful if we could do this with 1 board and a watchdog, so the technique could be deployed on other boards besides my test setup
<KotCzarny>
s/boards/socs/
<jonkerj>
I haven't tested it yet, but there seems to be a DT entry and driver on at least H3
<KotCzarny>
well, test results can also be uploaded when done
<jonkerj>
I think using a small bit of u-boot/fw_setenv magic you could do this
<jonkerj>
but it is much easier to do with a supervisor board :-)
<ssvb>
oliv3r: regarding "why can we not just lower the freq. and assume all is stable", that's exactly what everyone is doing now
<ssvb>
oliv3r: I guess, board manufacturers just set some higher DRAM clock speed, then see that the board is still bootable, then reduce it a bit and consider their job done
zumbi_ is now known as zumbi
<ssvb>
oliv3r: and maybe run some arbitrary light workload of their choice as a "stress test" to convince themselves that everything is alright :)
<ssvb>
oliv3r: based on my experience, lima-memtester is able to detect memory reliability problems at roughly ~48 MHz lower than any other workload, but your mileage may vary
<KotCzarny>
ssvb, would running cpuburn-a7 push the soc harder in regard of error detection?
<ssvb>
KotCzarny: it's a different test, cpuburn-a7 may help with detecting insufficient CPU core voltage problems, but has little influence on DRAM reliability
<KotCzarny>
(ie. in parallel with limamemtester, so voltage could fluctuate more)
<ssvb>
and I explained there why I don't like combining unrelated tests
<KotCzarny>
uhum
<KotCzarny>
SelfTestingAllwinnerToolsSuite
<KotCzarny>
maybe i'll get my ass around such thing
Putti has quit [Ping timeout: 265 seconds]
Putti has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
MXfive has joined #linux-sunxi
afaerber has quit [Quit: Ex-Chat]
MXfive has quit [Ping timeout: 260 seconds]
Axl_ has joined #linux-sunxi
IgorPec has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
MXfive has joined #linux-sunxi
gianMOD has joined #linux-sunxi
afaerber has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
Jacmet_ is now known as Jacmet
<oliv3r>
ssvb: i'm going for the 'why won't 384 be stable if we now know 480 is almost stable
<oliv3r>
ssvb: i fully agree with your rationale, it should be properly tested
<oliv3r>
hmm i may have prematurly just hit sent
<oliv3r>
oh well lets see what happens :)
<ssvb>
oliv3r: you could use roughly the same reasoning for the CPU clock speed: why won't 816MHz be stable if 1008MHz is almost stable?
afaerber has quit [Ping timeout: 245 seconds]
Putti has quit [Ping timeout: 252 seconds]
afaerber has joined #linux-sunxi
<ssvb>
except that if you arbitrarily suggest reducing the CPU clock speed to 816MHz, many people will complain because they understand that the performance will be worse
<KotCzarny>
yes, board will idle a bit slower often
yann has quit [Ping timeout: 244 seconds]
<ssvb>
the most important workload where the DRAM performance is the bottleneck is graphics, but people tend to attribute sluggish graphics to "bad drivers" rather than botched DRAM configuration.
gianMOD has quit [Remote host closed the connection]
<KotCzarny>
with somplefb its the real thing, is it?
<KotCzarny>
*simplefb
<ssvb>
nope, the CPU is more than fast enough for simple 2D operations and is just waiting for the data transfers from/to memory most of the time
<ssvb>
by simple 2D operations I mean handling of rectangular windows, antialiased text and basic translucency effects
<KotCzarny>
30fps fullhd video?
gianMOD has joined #linux-sunxi
<ssvb>
NEON YUV->RGB conversion is memory bandwidth limited
<oliv3r>
ssvb: also that is true; and also tha treasoning is wrong :p
<ssvb>
NEON bilinear scaling can't fully saturate memory bandwidth though, that's where the GPU is starting to become more efficient for this task
<oliv3r>
well i sent a post to the ML
<oliv3r>
so lets see where this goes
<oliv3r>
meanwhile i found one board that reliably fails around loop 2/3
<oliv3r>
so gonna setup more boards to get it them to fail also :)
<ssvb>
YUV->RGB conversion + bilinear scaling is indeed a bit too heavy for a single CPU core
<oliv3r>
and then do statistical data collection
Axl_ has quit [Remote host closed the connection]
yann has joined #linux-sunxi
Axl_ has joined #linux-sunxi
<wens>
heatsinks might also influence stability?
<NiteHawk>
cooling in general. even the airflow available depending on case might matter
<KotCzarny>
is it noticeable for ram?
<wens>
KotCzarny: if you put heatsinks on them, maybe?
<MoeIcenowy>
we shouldn't rely on heatsinks for such low-performance SBCs
<wens>
for our frequencies i dont think so though, they are only warm, not hot
<KotCzarny>
ie. did anyone checked if ram chips/ambient temperature affected limamemtester results?
<MoeIcenowy>
so I think the value should be checked without heatsink
<wens>
MoeIcenowy: all my boards have heatsinks, first thing i do when i get a new one :p
MXfive has quit [Quit: Sleep Quit.]
yann-kaelig has joined #linux-sunxi
<oliv3r>
tkaizer where are you!
<MoeIcenowy>
oh except one situation: all the boards are shipped with heatsinks
<oliv3r>
well i have one of those olimex display metal boxes, so heatflow is horrible and its nice boxed up :) ideal for my tests. also the lcd generates a nice heat
<oliv3r>
KotCzarny: i did lima-memtster + cpuburn once, and managed to crash/overheat many boards 2 years ago
<wens>
MoeIcenowy: the A80 ones were, so was the A83T test board allwinner sent out to the community
<oliv3r>
they would reach 110C and go boom
<MoeIcenowy>
wens: yes octa cores makes so much heat