<oliv3r>
mripard: you where right! We are making greg fix tons of stuff ;)
<oliv3r>
hno: disp using g2d you mean? or the 'mixer processor'?
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
jinzo_ has joined #linux-sunxi
zoobab_ has joined #linux-sunxi
atiti_ has quit [Ping timeout: 240 seconds]
lkcl has quit [*.net *.split]
jinzo has quit [*.net *.split]
zoobab has quit [*.net *.split]
jinzo_ is now known as jinzo
lkcl has joined #linux-sunxi
BJfreeman has quit [Quit: had a good time]
atiti_ has joined #linux-sunxi
<ssvb>
oliv3r: disp can composite up to 4 layers together on-the-flight to get the final picture on screen
<ssvb>
oliv3r: with g2d (mixer processor) we can do various 2d graphics operations with the buffers in memory
<ssvb>
oliv3r: some of these resulting buffers in memory can be used as layers for disp
<ssvb>
Turl: ping
utente has quit [Remote host closed the connection]
Superpelican has joined #linux-sunxi
paulk-aldrin has joined #linux-sunxi
paulk-aldrin has quit [Remote host closed the connection]
tzafrir has joined #linux-sunxi
pitillo_ is now known as pitillo
pitillo has quit [Changing host]
pitillo has joined #linux-sunxi
Superpelican has quit [Ping timeout: 276 seconds]
Soru has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
Superpelican has joined #linux-sunxi
tzafrir has quit [Ping timeout: 248 seconds]
tzafrir has joined #linux-sunxi
Soru has quit [Ping timeout: 245 seconds]
<Black_Horseman>
companieros adios
Black_Horseman has quit [Remote host closed the connection]
DrOetker is now known as Dreadlish
rz2k has joined #linux-sunxi
<Turl>
ssvb: pong
<Turl>
mripard: ping
<ssvb>
Turl: about wemac, do you use your patch from before on mele a1000/a2000?
<Turl>
ssvb: the one I asked you to test?
<Turl>
ssvb: my mele is running it right now
rellla has joined #linux-sunxi
<ssvb>
Turl: yes, that one
<ssvb>
Turl: applied to which kernel?
<Turl>
ssvb: stage/sunxi-3.4 + hans' pull
OSer_ has joined #linux-sunxi
<ssvb>
Turl: did you initially develop it for some older kernel?
<Turl>
ssvb: no, we had the discussion here and on the ML, so I took the initiative and found some optimization changes, as well as adjusted the sleep routine to match the mainline driver to some extent
<Turl>
s/changes/possibilities/
<Turl>
it turned up to work a bit better for my workload I think, I didn't do any scientific measurement though
<Turl>
that + conservative let me copy out ~5MB/s via sshd while transmission is running
<atiti_>
-c arcfour
<ssvb>
Turl: was wemac very slow and only using 10mbit earlier for you (before the stage branch and this patch on top)?
<Turl>
atiti_: yeah and that :)
<Turl>
ssvb: earlier on 3.4 it'd sync up in 10Mb only yep
<Turl>
ssvb: and overall have crap performance
<ssvb>
ok, thanks, I just want to confirm that we are observing the same behavior
<Turl>
ssvb: usually fixed a bit with ethtool by forcing speed 100 duplex half autoneg off
<Turl>
it wasn't great, but it wasn't as crap either
<ssvb>
maybe I'm asking too much, but could you try to boot with nfs root?
<ssvb>
I'm getting strange results, the synthetic benchmarks and simple uploads/downloads are mostly ok, but file operations with nfs are horribly slow using the latest kernel
<ssvb>
your patch does not seem to have any significant effect on anything (not that it's bad, just seems like we need to look elsewhere)
\\Mr_C\\ has joined #linux-sunxi
<Turl>
ssvb: I don't have a serial console attached to the mele, and no nfs server
<ssvb>
Turl: ok, I see, thanks anyway
<Turl>
ssvb: it's probably a long shot but an easy one to take, can you try to boot with perf governor & max freq = that one that has the highest clocks on buses (816 was it?)
<Turl>
ssvb: I also noticed that it uses DMA on one way and cpu accesses on the other, maybe the dma path is to blame?
OSer_ has quit [Quit: Page closed]
hglm has joined #linux-sunxi
tzafrir has quit [Ping timeout: 260 seconds]
<hglm>
Correct me if I'm wrong but I had the impression from ssvb's comments that the performance problem is largely related to time-outs in the NFS driver, which makes things very slow, and which may be caused by the ethernet driver in one way or another. I am mentioning this because with NFS I have been time-outs when copying large file (on recent kernels, but also on sunxi-3.4 stable).
yuuki_ has quit [Read error: Operation timed out]
<ssvb>
hglm: are you also using wemac ethernet?
<hglm>
ssvb: Nope wlan
<ssvb>
hmm, ok
<ssvb>
do you have any usb ethernet dongle for runing tests with it?
<hglm>
I don't, but I may look at acquiring one.
<ssvb>
I just wonder if it is really the ethernet/wlan drivers related or maybe nfs is also at fault
<ssvb>
your information about wlan makes the whole picture a bit less coherent :)
<hglm>
Yeah, there's something definitely wrong with NFS.
<ssvb>
has wlan driver also been developed by allwinner (sorry, never used it before)?
<hglm>
ssvb: I've delved into the kernel details but I have the impressions that these are 100% vendor-supplied drivers like Realtek 8192CU.
<hglm>
BTW: The new Realtek WLAN drivers in the latest branches appear to be significantly faster than the old ones, it looks like.
shineworld has joined #linux-sunxi
Superpelican has quit [Read error: Operation timed out]
rz2k has quit [Read error: Connection reset by peer]
rz2k has joined #linux-sunxi
hglm has quit [Quit: leaving]
rz2k has quit [Quit: leaving]
Superpelican has joined #linux-sunxi
WarheadsSE_ is now known as WarheadsSE
hipboi has joined #linux-sunxi
Superpelican has left #linux-sunxi ["Konversation terminated!"]
shineworld has quit [Quit: Leaving]
yuuki has joined #linux-sunxi
gzamboni has quit [Remote host closed the connection]
atiti_ has quit [Ping timeout: 240 seconds]
<setkeh>
hey guys i followed http://linux-sunxi.org/Cubieboard/Programming/StatusLEDs and added thoes lines to my script.bin using fexc from sunxi-tools on archlinux arm and put the recompiled script.bin into /boot but i still have nothing in /sys/class/leds/ any ideas ??
<setkeh>
if it matters any this is on a cubieboard v1 :D
atiti_ has joined #linux-sunxi
<Turl>
setkeh: did you enable the led driver on your kernel?
<setkeh>
hmm no i dident know there was one XD
<Turl>
setkeh: make sure you have LEDS_SUNXI enabled
<setkeh>
is there a guide on the wiki for recompiling the kernel ?? (srry never done it on ARM or sunxi)
<ssvb>
Turl: I think it's time to pass the baton to you, maybe you can try to hack around this part of code to check if anything can be improved there :)
<ssvb>
I will also try to test with another switch
<Turl>
ssvb: what speeds are you getting when it works well?
<Turl>
ssvb: I'm getting ~95Mb each way on unidirectional tests
<Turl>
and ~95 + ~9 when running dual tests (-d)
dlan has quit [Ping timeout: 248 seconds]
<ssvb>
Turl: hmm, that's a good question
<ssvb>
Turl: with my submitted patch I'm only getting something like 68.6 Mbits/sec & 42.0 Mbits/sec
<Turl>
on separate or on a dual, simultaneous test?
<ssvb>
Turl: simultaneous test
<ssvb>
Turl: but with the broken mtx512's workaround it was ~90 / ~80 on simultaneous test
<Turl>
ssvb: do you want to test all the stuff I have queued?
<ssvb>
Turl: is it improving something? ;)
<Turl>
ssvb: that's what you need to find out :)
Black_Horseman has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
bsdfox_ has joined #linux-sunxi
bsdfox_ has joined #linux-sunxi
<Turl>
ssvb: I noticed iperf used weird windows and none matched
<Turl>
ssvb: forcing -w 50K on both server & client