apritzel has quit [Read error: Connection reset by peer]
<KotCzarny>
184pcs left
<KotCzarny>
they are going fast
<KotCzarny>
120pcs since the link was posted
<KotCzarny>
176
<KotCzarny>
155
<KotCzarny>
fake or not, guy will have 300x4 usd for few weeks, he he
<vpeter>
Yes. And he will send few pieces so there is a proof that this is serious business.
<KotCzarny>
as i said, gamble
<KotCzarny>
121
<vpeter>
Last time I got nanopi neo for nice price.
<KotCzarny>
how nice was nice?
<KotCzarny>
72
<vpeter>
Wait, it was orange - similar promo on cnx site.
<KotCzarny>
how to 'sell' 300 boards in 60 minutes: make a nice price and use people to spread the news
<KotCzarny>
the opipc for 8.67usd?
<KotCzarny>
got 1 from gb
<KotCzarny>
:)
<vpeter>
this one yes
<KotCzarny>
but people with big orders were cancelled/refunded
<KotCzarny>
cheap marketing for the site, because often people return for more promos/items
<KotCzarny>
45
<KotCzarny>
12
<KotCzarny>
i wonder when the sale started
apritzel has joined #linux-sunxi
<KotCzarny>
promo over
IgorPec has quit [Ping timeout: 248 seconds]
<vpeter>
Congrats to all winners! :D
<jelle>
lol
<KotCzarny>
;)
<KotCzarny>
..and let the shipping be in your favor!
<KotCzarny>
now i need to find some cheap source for 4mm barrel connectors ;)
premoboss has quit [Ping timeout: 240 seconds]
<jelle>
haha KotCzarny find one for me too :)
<KotCzarny>
how many did you gambled?
<jelle>
KotCzarny: none, but hackerspace friends bought a lot :p
<KotCzarny>
suckers :P
<jelle>
KotCzarny: but I have a lot of orangepi's already so barel connectors are always useful :)
<avph>
cant you power it through 5V pin?
apritzel has quit [Read error: Connection reset by peer]
Mr__Anderson has quit [Quit: Leaving.]
Mr__Anderson has joined #linux-sunxi
apritzel has joined #linux-sunxi
nix_ has quit [Quit: Ex-Chat]
<willmore>
avph, you mean the GPIO header?
<willmore>
That's how I powered my Opi1 boards until I got the right barrel connectors.
<avph>
yes. not sure if that works for sunxi
<avph>
Opi1 is sunxi I guess...
<KotCzarny>
its more about power routing on the boards than socs themselves
<avph>
yes that makes sense
<KotCzarny>
i think there were few that someone reported as prone to damage when powered via gpio
<avph>
I dont want to nitpick but is 5V pin a gpio?
<KotCzarny>
thought shortcut gpio == gpio header
<avph>
ok
<willmore>
Yeah, do beware that powering a board over GPIO may bypass protection circuitry on the board, so you need to make sure you're taking that into account.
<willmore>
For example on the Rpi boards (B+, 2, 3) powering via GPIO bypasses reverse voltage and overcurrent protections.
<tkaiser>
montjoie: Get back to you in half an hour (lunch first).
<montjoie>
ok thanks
MiLeon has joined #linux-sunxi
Putti has quit [Ping timeout: 265 seconds]
<willmore>
tkaiser, Yep, that's what we were discussing.
<tkaiser>
willmore: Yeah, but on RPi it makes a difference, on Orange Pi not.
<tkaiser>
montjoie: Tested 5 minutes in the direction that was not affected first: 877 Mbits/sec
<tkaiser>
montjoie: Now testing the other direction. Let's wait... :)
Axl__ has joined #linux-sunxi
<willmore>
tkaiser, do all the H3 boards provide current protection on the GPIO, then?
<plaes>
probably no
<KotCzarny>
it all matters if dcin is wired directly to gpio headers or not
<willmore>
Because my point was that using GPIO on these boards (and the Pi boards specifically) bypasses any protections they have. If the H3 boards don't have any of that, then there's nothing to bypass.
<willmore>
KotCzarny, yep.
<willmore>
KotCzarny, that's a great way to turn a PCB trace into a fuse. :(
<KotCzarny>
my bet is that if powering via gpio header works, then i guess its not routed via any regulator
<tkaiser>
willmore: I am electronics noobie but understood ssvb in that way: directly wired DC-IN to GPIO pins 2/4/6
<willmore>
+5V on most of these boards is just a pasthrough with *maybe* some protection.
<willmore>
tkaiser, understood.
<KotCzarny>
simple test with ohmometer?
<willmore>
KotCzarny, that won't test for protection.
<willmore>
And I'm pretty sure that powering via GPIO works. As tkaiser said, it does for the H3 boards.
<KotCzarny>
but could show if there is something in the path
<willmore>
My only caution was that you bypass the input overcurrent and reverse voltage protections that *might* be on the intended input.
<KotCzarny>
another bet: only Axx boards have something wired differently because they have to allow battery powering too
<willmore>
It'll work, but it's living dangerously. :)
<plaes>
willmore: I also used GPIO header for OPi PC
<tkaiser>
montjoie: Still no panic, but performance degraded and a lot of retries.
<willmore>
KotCzarny, could be. Depends if they're in battery mode or not maybe?
<willmore>
plaes, isn't that H3 based?
<plaes>
it is
<willmore>
Then that falls under tkaiser's "all H3 boards" rule. :)
<KotCzarny>
willmore, its more about designs, A line is for tablets, so DEV board should account for that
<montjoie>
tkaiser: strange that that small modification cause perf downgrade
<willmore>
KotCzarny, good point.
<KotCzarny>
emphasis on SHOULD
smookie has quit [Ping timeout: 276 seconds]
<tkaiser>
montjoie: Will post a paste soon, let's wait a few minutes more
<KotCzarny>
i wonder if anyone bought allwinner boards for android dev work
<tkaiser>
KotCzarny: Of course, Pine64 for example
<tkaiser>
montjoie: In the upper half, OPi Plus is sending and gets pretty stable 875 Mbits/sec, in the lower half we had 940 Mbits/sec plus kernel panic after a couple of seconds before
<tkaiser>
before == without your patch
<montjoie>
so the patch made loosing 70Mo/s:(
premoboss has joined #linux-sunxi
<tkaiser>
montjoie: But it's faster if the reboots caused by panic are also taken into account! ;)
<tkaiser>
And no, it's not 70Mbits/sec, that's different directions.
Net147 has quit [Quit: Quit]
<tkaiser>
940 Mbits/sec with panic vs. 849 Mbits/sec without but lots of retries
<montjoie>
the line touched bythe patch si for BQL, and according to my readings, BQL drop perf for gaining latency
<montjoie>
but just moving it a few lines before cause that drop, it is strange
<montjoie>
anyway thanks tkaiser for founding this problem
Net147 has joined #linux-sunxi
<KotCzarny>
'finding'
<montjoie>
perhaps tuning BQL could get back some perfs
<montjoie>
sorry for my english, need a spell checker in irssi
<jmcneill>
ah damn I was hoping you found another magic bit :)
<montjoie>
sun8i-emac have already ETOOMANYMAGICBIT
MiLeon has quit [Remote host closed the connection]
<jmcneill>
yeah
<jmcneill>
i haven't tested my freebsd driver lately
<tkaiser>
montjoie: Anyway: I get pretty stable 880 MBits/sec when sending from H3 to client with iperf3 -- in this mode iperf3 is the bottleneck and maxes out 1 CPU core (single-threaded stuff)
<jmcneill>
or at least the testing that i have done was with a bunch of debug options enabled
<jmcneill>
so not sure how it fares on h3
<jmcneill>
tkaiser: try the -Z flag?
Putti has joined #linux-sunxi
MiLeon has joined #linux-sunxi
<tkaiser>
jmcneill: Yeah, then it improves by 30 Mbits/sec. I would assume by choosing sane network settings and a reasonable window size the 940 Mbits/sec are possible
<jmcneill>
-Z just tells iperf3 to use a more efficient method of sending data
<jmcneill>
sendfile vs write or whatever
IgorPec has joined #linux-sunxi
afaerber has quit [Remote host closed the connection]
afaerber has joined #linux-sunxi
<tkaiser>
jmcneill: Sure, but iperf3/iperf are CPU bound anyway, I get already headache when thinking about that stubborn old man in Pine64 forum that doesn't want to understand that, telling everyone Pine64 is not able to exceed 120 Mbits/sec
<KotCzarny>
pine64 conspiracy
<tkaiser>
pine64 micro community creating weird micro reality
<KotCzarny>
what do they say about real world tests?
<tkaiser>
KotCzarny: That specific person is still moderator. Currently he says nothing after deleting/censoring many of my posts and banning me. Too funny.
Putti has quit [Ping timeout: 264 seconds]
<tkaiser>
Now provided some numbers by another guy and me showing ~80 MB/s and now it got calm there
<KotCzarny>
well, pine64 wiki page could use some update on gbit issue then
<jelly>
tkaiser: maybe they mean 120MB/s :-)
<tkaiser>
jelly: Nope, the same person always claimed Fast Ethernet would be ok since 'as fast as GbE'. Please don't remind me, that's just too weird there.
paulk-collins has joined #linux-sunxi
lemonzest has quit [Quit: Leaving]
IgorPec has quit [Ping timeout: 265 seconds]
premoboss has quit [Ping timeout: 240 seconds]
<jmcneill>
tkaiser: sendfile instead of write helps with "iperf3 is CPU bound"
<jmcneill>
at least, it's supposed to
<tkaiser>
jmcneill: Well, 30 Mbits/sec ;)
<jmcneill>
every little bit helps
<KotCzarny>
free mbits!
<tkaiser>
jmcneill: I prefer understanding over numbers ;) Especially when dealing with users that should diagnose network trouble
<jmcneill>
You are saving CPU cycles by not having to call the write syscall repeatedly.
<tkaiser>
In Pine64 land OS images are used with wrong cpufreq governor where network testing happens at the lowest cpufreq: 480 MHz. And therefore results look totally random. By simply switching from ondemand to performance 'the network' gets faster ;)
<tkaiser>
But that seems to decrease outbound iperf3 numbers: http://pastebin.com/Wt3L4U8f (strange, a magic increase after 41 seconds)
Mr__Anderson has quit [Remote host closed the connection]
<tkaiser>
Ok, no magic involved. When iperf3 task runs on the same core that processes Ethernet IRQs then it's below 700 Mbits/sec if not we're exceeding 900 Mbits/sec. That did the trick since Armbian sends eth0 IRQs to cpu3: taskset -c 0 iperf3 -c 192.168.83.115 -t 120 -Z
<KotCzarny>
tkaiser, i remember when you were saying that irqbalancing wasnt that importantes
<tkaiser>
KotCzarny: It doesn't work on ARM without fixes. And no one uses the fixes and irqbalanced has a memory leak on ARM. So you win nothing and loose memory.
<montjoie>
tkaiser: do you have tried the inkernel PKTGEN ?
<tkaiser>
montjoie: How?
<KotCzarny>
there is a kernel option for that
<montjoie>
I will read the doc, perhaps it could be usefull
<tkaiser>
Useful for what? Tuning benchmarks?
<KotCzarny>
using kernel for pktgen == less cpu usage
<tkaiser>
Not interested. Will now continue with Netatalk, testing FS, network and everything else ;)
<KotCzarny>
tkaiser, perormance can vary across the kernels/software
<KotCzarny>
*performance
<tkaiser>
GbE is limited to 940 Mbits/sec anyway. Let's look now at more interesting numbers than moronic iperf stuff :)
lamer14742959183 has joined #linux-sunxi
lamer14742959183 has quit [Client Quit]
tkaiser has quit [Ping timeout: 244 seconds]
smookie has joined #linux-sunxi
MiLeon has quit [Quit: Leaving]
tkaiser has joined #linux-sunxi
IgorPec has joined #linux-sunxi
<tkaiser>
Using netatalk and LanTest I get close to 55MB/s writing to OPi Plus 2E and exceed 78MB/s. That's fine. The 55MB/s are due to afpd (something comparable to smbd) acts single-threaded and maxes out 1 CPU core. So everything fine.
Nacho___ has joined #linux-sunxi
<tkaiser>
(78MB/s reading from OPi Plus 2E)
<wens>
tkaiser: no idea about emmc performance
<wens>
i assume they're using the allwinner stock kernel, which might need some tweaking at the fex/dt level
<tkaiser>
wens: Ah, ok. I thought you were the one asking/poking Tsvetan back then regarding voltage switching?
<tkaiser>
wens: Ah, now understood
MXfive has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
andor2007 has quit [Quit: bye]
andor2007 has joined #linux-sunxi
<wens>
tkaiser: we need hardware that is capable of voltage switching, before we can try to support it
<tkaiser>
wens: But Olimex' A64 is supposed to support that (dynamically?) or not?
arete74__ has joined #linux-sunxi
arete74_ has quit [Read error: Connection reset by peer]
MXfive has quit [Read error: Connection reset by peer]
<wens>
tkaiser: iirc they have a gpio switched regulator there, so it can be dynamically toggled
<wens>
they just have to work out how to get the vendor kernel to use it
<wens>
and that is assuming the emmc chip they used actually supports HS200, which makes a difference
Putti has joined #linux-sunxi
<wens>
lower speeds are the same, regardless of signaling voltage
<wens>
what i really want to see is support for signaling voltage switching for SD
<wens>
which would allow us to support UHS-1 speeds
<tkaiser>
wens: (mostly) understand, thanks. Then I'm already curious. But IIRC the eMMC used by Olimex supports industrial temperature range and is both expensive and slow anyway ;)
<jmcneill>
wens: do you know of any sunxi boards that actually have that wired up?
<apritzel>
it seems like the somewhat affordable eMMC chips are limited by the flash speed anyway, so maximum interface speed is somewhat moot
<jmcneill>
dunno if you have ever tried an odroidc1 but the emmc is amazingly fast on it
<jmcneill>
(compared to SD cards that is)
<apritzel>
for instance the BPi-M64 has a 8GB Samsung eMMC, which reads at max 100 MB/s and writes at 6MB/s
<apritzel>
so running it at 300MB/s interface speed does not make a real difference
<apritzel>
jmcneill: "amazingly fast" as in: it feels really fast?
<tkaiser>
apritzel: You should try out ODROID-C2 with their larger eMMC modules
MXfive has joined #linux-sunxi
<jmcneill>
apritzel: it feels a lot faster than sd on the same device
<apritzel>
tkaiser: I know the larger ones are better, but also much more expensive
<jmcneill>
apritzel: when i added UHS-I and HS200 support to NetBSD's mmc stack the odroidc1 was one of the boards I was working on at the time
<jmcneill>
HS SD -> UHS-I SD didn't feel like as big of a leap as MMCHS -> MMCHS200
<jmcneill>
on that device at least.. the jetson tk1 emmc was still slow
apritzel has quit [Read error: Connection reset by peer]
<wens>
jmcneill: none, which is why I asked Olimex to do it
<jmcneill>
that would be great :)
<jmcneill>
i have been wanting that for years
<wens>
they only did eMMC though
<jmcneill>
ah boo
<wens>
I assume SD might not be doable because the pins on the SoC side don't have an isolated VDDIO
<wens>
apritzel: 100 MB/s is 52 MHz @ 8 bits, which is MMC-HS
<wens>
HS200 IIRC is 100 MHz @ 8 bits, so double the theoretical speed
apritzel has joined #linux-sunxi
MXfive has quit [Read error: Connection reset by peer]
<apritzel>
I guess most _soldered_ eMMCs on those cheap boards are simply not fast enough (because not big enough) to make those fast interface speeds shine
<jmcneill>
these ones aren't soldered
<apritzel>
I was wondering why not more vendors use that Odroid socket, to offer cheap boards that people can equip with eMMC if they like
<apritzel>
jmcneill: I know, but those are the only one, aren't they?
<jmcneill>
i don't know of other vendors that use them
<apritzel>
also some competition should bring those Odroid eMMC module prices down ;-)
<jmcneill>
other odroids use the same socket i think (my xu4 certainly looks compatible)
<jmcneill>
i don't think i have any hs400 cards
<apritzel>
jmcneill: it seems like they are, at least backwards compatible
<jmcneill>
(i should really port those changes to freebsd..)
<wens>
jmcneill: which changes? :)
<wens>
sunxi mainline doesn't support HS200 either
<wens>
afaik a separate register has to be configured
MXfive has joined #linux-sunxi
<wens>
without hardware to try out, I couldn't do anything about it
lamer14742994746 has joined #linux-sunxi
lamer14742994746 has quit [Client Quit]
<wens>
bedtime...
<jmcneill>
wens: the changes I did to netbsd's sdmmc stack to enable uhs/hs200, i need to port them to freebsd
tkaiser has quit [Ping timeout: 248 seconds]
tkaiser has joined #linux-sunxi
<wens>
oh
<tkaiser>
montjoie: Tried it with 'Enterprise network' settings (1MB instead of 128K blocksize) and your driver again. Testing with LanTest against Netatalk: 59MB/s write to OPi Plus, 82MB/s read. Writes are still bottlenecked by single-threaded afpd process. Interpretation of results: http://www.helios.de/web/EN/support/TI/157.html
MXfive has quit [Read error: Connection reset by peer]
<montjoie>
and i need to find a 900mo/s capable network adapter
MXfive has quit [Read error: Connection reset by peer]
tkaiser has joined #linux-sunxi
arete74_ has joined #linux-sunxi
arete74__ has quit [Read error: Connection reset by peer]
<tkaiser>
montjoie: Do you have a Pine64+ lying around?
MXfive has joined #linux-sunxi
<tkaiser>
montjoie: And BTW: the numbers I got are excellent. Will test later with a GbE devices in parallel, then it get's interesting since single-threaded limitations do not apply any more then.
netlynx has quit [Quit: Ex-Chat]
<montjoie>
tkaiser: pine64 classic
MXfive has quit [Read error: Connection reset by peer]
MXfive has joined #linux-sunxi
premoboss has joined #linux-sunxi
<tkaiser>
montjoie: :( With a Pine64+ it would work with approriate settings
MXfive has quit [Read error: Connection reset by peer]
MXfive has joined #linux-sunxi
MXfive has quit [Client Quit]
<tkaiser>
montjoie: IMO it would make a lot of sense if you possess at least one Pine64+. Care to share your address details with TL Lim? I would then ask him to send out 2 Pine64+ (to increase chances you get one that is not affected by the 'GbE issue').
avph has quit [Ping timeout: 248 seconds]
cosm has quit [Remote host closed the connection]
<KotCzarny>
tkaiser, its better to send him one tested to be problematic
<montjoie>
tkaiser: thanks but I just checked, and i got the one with GbE so a pine64+
<tkaiser>
Sure, TL Lim sent out 3 more to me yesterday. I just thought why loosing more time and since montjoie's driver is used for A64 anyway?
<montjoie>
I believed that + is for one with 2G RAM
avph has joined #linux-sunxi
<tkaiser>
montjoie: That's great but maybe you're affected by the GbE issue. Green or red led?
<willmore>
wens, jmcneill, apritzel. The ODROID emmc modules are all intercompatable except for the 128GB (black) card that only works on the c2 (maybe C1). It has some incompatability with the Samsung based boards--which is ironic as it's a samsung chip.
Putti has quit [Ping timeout: 248 seconds]
cosm has joined #linux-sunxi
<tkaiser>
montjoie: if you want to get the Pine64+ up and running in shortest time to test against I strongly recommend using longsleep's Xenial image as a start (BSP kernel but who cares -- at least you need just 2 tweaks to ensure to get 940 Mbits/sec in any case).
MXfive has quit [Read error: Connection reset by peer]
BenG83 has joined #linux-sunxi
<jemk>
tkaiser: can you dump the dram registers both with boot0 and spl? boot0 with "md 0x01c62000 0x800", spl with something like this http://sprunge.us/JcHH if it doesn't get to u-boot
<tkaiser>
jemk: Do you ask me to ask the affected user or to test with my X2 (that runs with 672 MHz without problems)?
<tkaiser>
jemk: I also edited the post a minute ago and asked regarding PSU/undervoltage.
<jemk>
tkaiser: ah, sorry, the affected user of course
<jemk>
only read over it quickly
MXfive has joined #linux-sunxi
<tkaiser>
jemk: Just to understand it: I would need to build an own Armbian image with the u-boot applied from your link above?
<jemk>
having a reference from a working one wouldn't be wrong neither
<tkaiser>
s/u-boot/u-boot patch/
<jemk>
yes, if it doesn't get into u-boot that would be the only way to dump the regs i think
<tkaiser>
jemk: My X2 seems to have the same type of DRAM chips (Beelink seems to exchange them from time to time)
<jemk>
but only the spl would be enough, no need for a whole image
<tkaiser>
jemk: sure, telling the average user to do something with 'onyl the spl' is way more time consuming than to bake an Ambian image ;)