<tkaiser>
Has anyone already tried out Uenal's SATA write performance patch?
<KotCzarny>
i just found out few hours ago thanks to cnx entry
<KotCzarny>
might as well recompile kernel to test in the evening
<tkaiser>
I'm currently testung on an A10 board since all A20 devices are productive installations.
<tkaiser>
It would be great to forward Allwinner's Wink's mail address to Uenal. He's still searching for documentation...
wwilly has quit [Ping timeout: 258 seconds]
<montjoie>
will try on R40 soon
<KotCzarny>
tkaiser: already trashed your bpi-r1?
<tkaiser>
KotCzarny: 'all A20 devices are productive installations'
victhor has joined #linux-sunxi
foxx_ has joined #linux-sunxi
s_frit has quit [Remote host closed the connection]
s_frit has joined #linux-sunxi
Mangy_Dog has quit [Ping timeout: 252 seconds]
Mangy_Dog has joined #linux-sunxi
Andy-D has quit [Ping timeout: 268 seconds]
Andy-D has joined #linux-sunxi
ganbold has joined #linux-sunxi
mpmc has joined #linux-sunxi
lurchi_ is now known as lurchi__
jstefanop has joined #linux-sunxi
MoeIcenowy has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
MoeIcenowy has joined #linux-sunxi
<willmore>
oliv3r[m], you got some A20's? ;)
jstefano_ has joined #linux-sunxi
jstefanop has quit [Ping timeout: 268 seconds]
jstefanop has joined #linux-sunxi
jstefano_ has quit [Ping timeout: 252 seconds]
JohnDoe_71Rus has joined #linux-sunxi
jstefanop has quit [Remote host closed the connection]
jstefanop has joined #linux-sunxi
jstefanop has quit [Read error: Connection reset by peer]
jstefanop has joined #linux-sunxi
Andy-D has quit [Ping timeout: 258 seconds]
jstefanop has quit [Remote host closed the connection]
Andy-D has joined #linux-sunxi
jstefanop has joined #linux-sunxi
* plaes
has some :P
jstefanop has quit [Ping timeout: 244 seconds]
return0e has quit [Ping timeout: 246 seconds]
return0e has joined #linux-sunxi
<tkaiser>
It would be great if some more A20/A10 users could start with reliability testing. Putting a btrfs on a SATA disk and then doing some torture testing (running IO benchmarks for example)
<tkaiser>
If this performance improvement is accompanied by sporadic data corruption we won not that much ;)
<aalm>
got some A{1,2}0s, most w/o sata in use i think
dddddd has joined #linux-sunxi
<MoeIcenowy>
this patch is too magic to believe
<KotCzarny>
not that much, cache/queues help a lot
<dddddd>
hi
<MoeIcenowy>
wink doesn't reply me on SATA doc
<KotCzarny>
try running uboot without block cache option and see what speeds it would achieve from sdcards ;)
<tkaiser>
MoeIcenowy: Thanks for asking :)
<tkaiser>
aalm: In case you test please ensure to use btrfs (or even ZFS). With ext4 or other 'non-checksumming' fs occuring data corruption can be missed.
Andy-D has quit [Ping timeout: 246 seconds]
<jo0nas>
tkaiser: do you have some more info (I bet you already wrote about it somewhere - thanks for your excellent reflections in general!) about ext4 being unsuitable for detecting data corruption? Seems to me that with metadata_csum,64bit and journal_checksum should get decent coverage as per https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums
<tkaiser>
jo0nas: My understanding is that ext4 just like Apple's APFS is only protecting filesystem metadata which is great. But if we're searching for reliability corner cases we want not only metadata but the data itself to be protected by checksums
<tkaiser>
Writing a 100MB file for example as a test case will touch just a few metadata bits (inode and directory updates) while the purpose of the test is to get any data corruption
<jo0nas>
thanks for elaborating
\\Mr_C\\ has quit [Quit: (Read error: Connection reset by beer)]
cnxsoft has quit [Quit: cnxsoft]
<smaeul>
the checksumming doesn't have to be provided by the filesystem -- you could write a 100MB file of random data to a tmpfs, take its sha256sum, copy it to disk, and compare the sha256sum of the file on disk
<KotCzarny>
it would take a bit more scripting to write stability test out of it though
Andy-D has joined #linux-sunxi
<tkaiser>
smaeul: Sure but then you need to ensure that you empty caches in between (can be missed by inexperienced people) and you're only testing a specific access pattern. That's why I prefer the iozone call using a bunch of different access patterns.
<tkaiser>
Also btrfs reports data corruption with the first block it occurs
AneoX_ has joined #linux-sunxi
<jo0nas>
for testing stability of kernel driver specifically I agree that running a specially configured system makes sense
<KotCzarny>
megi: it's direct gpio without any ir circuit on the way?
<megi>
direct
<KotCzarny>
so, ir can be added on any gpio pin?
<megi>
probably not
<KotCzarny>
(i have opi1 which is missing ir)
<megi>
multiplexed
<megi>
S_CIR_RX function
<megi>
on PL11 pin
<KotCzarny>
ahm.
afaerber has quit [Quit: Leaving]
<megi>
So you can hook there some 1-wire sensor like those DHT22 temprature/humidity sensors
<megi>
personally I use blue-pill for sensors and plug it into USB (blue-pill has USB-UART integrated and has FW that handles the weird protocols and timings and offers a simple serial interface to read-out the measured/converted values at any time)
<megi>
that way it doesn't depend on GPIO and can be developed on the regular workstation
random_yanek has quit [Ping timeout: 248 seconds]
Andy-D has quit [Ping timeout: 258 seconds]
random_yanek has joined #linux-sunxi
selfbg has quit [Remote host closed the connection]
<aalm>
megi++
<aalm>
good enough for usb2uart*3 too
AneoX has joined #linux-sunxi
AneoX_ has quit [Ping timeout: 268 seconds]
* willmore
agrees with megi, too.
afaerber has joined #linux-sunxi
<tuxillo>
megi: thanks
<tuxillo>
yes, the dht22 has vcc, gnd and dat only
<megi>
maybe it's 5V though?
<tuxillo>
the ping in the opi?
<tuxillo>
the sensor is am2302
<megi>
no DHT
<megi>
pin is 3.3V
<megi>
PL11
<megi>
most probably
<tuxillo>
let's find out
<megi>
it may be less, depending on PL port supply, but i doubt it
indy has quit [Ping timeout: 248 seconds]
<tuxillo>
the port supply is the 5v pin 1 of the opi
<megi>
no way
<KotCzarny>
:>
<KotCzarny>
yeah, it's meant to power usb
<tuxillo>
it's 5v according to my multimeter
<KotCzarny>
it's even in the pinout table
<KotCzarny>
but i think he wondered what vcc your sensor requires
<tuxillo>
ranged, from 3.3 to 5.5 according to the internet about that chip
<megi>
VCC-IO says 3.3V
<tuxillo>
where
<megi>
ip zero schematic
<megi>
pi
<tuxillo>
the sensor DAT pin is 3v
<megi>
ok
<tuxillo>
megi: multimeter says 5v in the 1x13 pin 1 of the opi zero
<megi>
PL11 is pin 13
<tuxillo>
in the expansion port spec is also specified 5V
<tuxillo>
so if dat in the sensor provides 3v should it work then with opi zero pin 13?
<megi>
I thought you were saying PL11 is 5V
<megi>
yes
<tuxillo>
no no sorry for the confusion
<tuxillo>
i measured it but it's meaningless I guess :) (21mV)
<megi>
sure, it's probably disabled ;)
<tuxillo>
hehe
<tuxillo>
what do you guys use to access gpio? C? python?
foxx_ has quit [Ping timeout: 258 seconds]
<mru>
wires, mostly :)
<tuxillo>
heh
foxx_ has joined #linux-sunxi
PaddyF has quit [Remote host closed the connection]
nuuuciano has joined #linux-sunxi
<aalm>
lol
<aalm>
tuxillo, os?
<tuxillo>
linux, armbian
<aalm>
oic., idk. then :]
<tuxillo>
heh
JohnDoe_71Rus has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
altious has joined #linux-sunxi
msimpson has quit [Read error: Connection reset by peer]
<tuxillo>
megi: in any case if you have any instructions or pointers how I can access to PL11 as a normal gpio pin, it would be great