Back
[01:30:04] <NTU> has anyone here tried btrfs w/ RTAI or preempt-rt and see if latency is better? once ipipe hits 3.16 im going to give it a shot
[01:30:30] <NTU> 3.16 is supposedly _the_ kernel to use for btrfs
[01:32:13] <NTU> i notice major performance increases using tune2fs -o journal_data_writeback, rootflags=data=writeback on kernel command line, then noatime,data=writeback in fstab but nothing latency-related
[01:33:12] <NTU> EFI is basically the same way, it boots up a lot faster but disabling legacy oproms and CSM doesn't do much in terms of latency
[07:53:32] <skunkworks> I still have issues with the motherboard in the k&t. Dad has about 4 of them but the latency with the new debian image is >100k. (tried multible video cards) these are ASUS M2N68-AM PLUS motherboards. Anything I should try?
[07:55:04] <skunkworks> I did try these things..
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?The_Isolcpus_Boot_Parameter_And_GRUB2
[07:56:46] <skunkworks> with 10.04 and a good video card - latency stays under 15k
[08:05:41] <jepler> skunkworks: flog 10.04 along for another few years?
[08:06:35] <skunkworks> sure.. it is working fine. (just anoying that I cannot get them to work well)
[08:06:50] <jepler> tried master branch and preempt-rt?
[08:06:59] <skunkworks> that was my next test
[08:07:15] <skunkworks> but no - I have not tried that yet
[08:08:21] <skunkworks> I should disable audio for grins..
[08:08:48] <skunkworks> I know I have had issues with that and xenomai
[08:28:25] <NTU> skunkworks: you're using 10.04? i could try making debs for you.
[08:28:56] <NTU> is seb_kuzminsky's rtai package building instructions up anywhere?
[08:30:05] <NTU> one thing i noticed is that latency got a whole lot better on one of my boards by simply changing CPU frequency from auto to fixed speed
[08:30:10] <jepler> NTU: I believe it builds as a debian package
[08:30:14] <jepler> apt-get source, debuild, etc
[08:30:37] <NTU> turning off cpu scaling / powernow / power savings in bios isnt the only magic
[08:32:05] <NTU> by cpu frequency i mean the overclock settings. you dont need to OC it but you could try changing the setting to the factory speed
[08:32:31] <NTU> jepler: that makes it easy then!
[08:37:33] <NTU> server 10.04.04, desktop 10.04 or desktop 10.04.1?
[08:40:12] <NTU> ( releases.ubuntu.com )
[08:41:28] <NTU> actually all the 10.04 releases are for "servers"
[08:44:06] <NTU> ah i found it!
[09:00:13] <NTU> heh 10.04 doesnt work for me, it keeps logging me out when i click on "install 10.04"
[09:00:36] <NTU> or anything on the desktop really.. :/
[10:54:08] <skunkworks> https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/145882
[11:28:32] <NTU> skunkworks_: are you using a 64-bit system w/ 10.04?
[11:28:44] <skunkworks_> NTU, no.
[11:29:20] <skunkworks_> ntu - the issue is debian/rtai has bad latency vs the 10.04/rtai
[11:29:37] <NTU> smp?
[11:30:19] <skunkworks_> whatever is on the live cd.. I don't know off the top of my head
[11:30:22] <NTU> multi core?
[11:30:36] <skunkworks_> the board has a 2 core
[11:30:39] <skunkworks_> amd
[11:30:45] <NTU> have you tried isolcpus at all?
[11:30:48] <skunkworks_> yes
[11:31:36] <NTU> i assume that didnt help, have you tried idle=poll ?
[11:32:08] <NTU> how bad latency are we talking?
[11:32:08] <skunkworks_> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?The_Isolcpus_Boot_Parameter_And_GRUB2#Latency_Testing
[11:32:35] <skunkworks_> >100us
[11:32:54] <skunkworks_> and rund <15us with the 10.04/rtai
[11:32:57] <skunkworks_> runs
[11:33:06] <NTU> yeah that page was based off an rtai checkout before i fixed RTAI's HAL
[11:34:21] <NTU> i really wonder how the new rtai tree would work on your system
[11:35:28] <skunkworks_> I am game.. I don't have access to it at the moment. probably wed/thur
[11:35:39] <NTU> we've been using 4-core AMD CPUs with the latest hardware on 64-bit and it works great, no extra kernel params
[11:36:10] <NTU> havent tested the new RTAI code on 32-bit yet
[11:37:09] <NTU> are you getting any APIC superious interrupts in dmesg?
[11:37:51] <NTU> cant spell spurious :/
[11:38:51] <NTU> is your AMD CPU a fusion APU?
[11:39:50] <NTU> "tried multiple video cards" missed that..
[11:41:42] <NTU> if you want to try the new code its github.com/ntulinux/rtai you'll need to use a recent checkout of linuxcnc master as well
[11:42:34] <NTU> fmax, fmin, proc, and some other fixes required are all in master
[13:16:35] <jepler> NTU: it's possible that you're seeing undefined variable warnings due to a different version of make.
[13:16:50] <NTU> it wont build for me..
[13:17:07] <jepler> at ref dcacd13 building for uspace, I do not get any undefined variable warnings
[13:17:26] <NTU> im building for RTAI and also i eventually get caught in a make loop
[13:17:45] <zq> hm
[13:17:55] <jepler> oh do they exclusively occur while building kernel modules?
[13:18:05] <NTU> one moment.
[13:18:15] <jepler> http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/214/steps/compile/logs/warnings%20%28288836%29
[13:18:36] <jepler> apparently the wheezy-rtai build gets nearly 290,000 warnings; I assume most of them are the undefined variable warnings
[13:18:52] <NTU> oh its not a loop, its 290,000
[13:18:56] <NTU> i see
[13:19:02] <NTU> it just takes awhile
[13:19:04] <jepler> well that's news to me
[13:19:12] <jepler> but I only routinely build uspace
[13:19:50] <jepler> effing kbuild
[13:20:32] <NTU> yeah hardware drivers
[13:20:42] <jepler> uspace builds hardware drivers just fine
[13:20:44] <NTU> scripts/Makefile.build line 208
[13:20:47] <NTU> *308
[13:21:28] <NTU> never have i ever saw this many :)
[13:22:12] <NTU> dpaste.com/1CW90GX
[13:25:16] <jepler> does this change shut kbuild up?
[13:25:16] <jepler> modules:
[13:25:16] <jepler> + MAKEFLAGS="$(filter-out --warn-undefined-variables,$(MAKEFLAGS))" \
[13:25:19] <jepler> $(PYTHON) modsilent.py $(MAKE) KBUILD_EXTRA_SYMBOLS=$(moduledir)/Module.
[13:25:22] <jepler> note trailing \
[13:25:42] <jepler> no probably it doesn't
[13:26:47] <jepler> maybe with this too
[13:26:47] <jepler> +ifeq ($(KERNELRELEASE),)
[13:26:47] <jepler> MAKEFLAGS += --warn-undefined-variables
[13:26:47] <jepler> +endif
[13:30:06] <NTU> nope..
[13:30:10] <zq> if i want to configure an axis to 1 pulse per unit, would it be OUTPUT_SCALE = SCALE = 1.0?
[13:31:32] <NTU> undefined variable KERNELRELEASE
[13:31:35] <NTU> xD
[13:31:55] <jepler> naturally
[13:32:35] <jepler> too bad --warn-undefined-variables is a valuable tool for finding errors in mostly-correct Makefiles
[13:33:38] <jepler> must have to be ifeq ($(origin KERNELRELEASE), undefined)
[13:34:29] <NTU> kbuild is quiet without origin KERNELRELEASE but initial make is still noisey
[13:41:43] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 6b4b13f 06linuxcnc 10src/Makefile build: sssshhhh kbuild * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6b4b13f
[13:54:46] <NTU> heh nice commit message :)
[13:58:04] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master ac8d297 06linuxcnc 10scripts/platform-is-supported platform-is-supported: armhf is reported as arm * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ac8d297
[14:12:12] <zq> how does stepgen's position scaling work? there's a comment in stepgen.c that says it's steps per unit, but only half the actual pulses are outputted
[14:12:47] <zq> as though pos-scale is steps per 2 units
[14:18:43] <jepler> zq: if you don't believe what the docs say, did you test it and see what it does?
[14:18:53] <jepler> halcmd: setp stepgen.0.enable true
[14:18:53] <jepler> halcmd: setp stepgen.0.position-scale 1
[14:18:53] <jepler> halcmd: setp stepgen.0.position-cmd 1
[14:19:08] <jepler> ... after a moment,
[14:19:10] <jepler> 12 s32 OUT 1 stepgen.0.counts
[14:19:16] <jepler> [not all lines in halcmd shown]
[14:20:31] <jepler> (interesting to me is that position-fb doesn't get particularly close to 1 .. it stops short by around 1e-4)
[14:39:42] <zq> jepler: i just said i did
[14:40:05] <zq> i have a stepper that's knwon to be 200 steps per rev
[14:40:31] <zq> setp stepgen.0.position-scale 1; setp stepgen.0.position-cmd 200 /* half a turn */
[14:40:48] <zq> setp stepgen.0.position-scale 2; setp stepgen.0.position-cmd 200 /* full turn */
[14:41:40] <zq> now i'm noticing mention about doublefreq and doublestep in the git log for stepgen
[14:45:48] <jepler> when I have stepgen position-scale 1 and command a move from 0 to 10, I count ten pulses.
http://emergent.unpythonic.net/files/sandbox/ten-pulses.png
[14:49:39] <PCW> you probably have a 1/2 stepping driver (full stepping is rare)
[14:49:47] <zq> wait no what i do?
[14:50:27] <zq> wait
[14:50:40] <PCW> full stepping is entirely too boingy
[16:17:36] <jepler> I guess soembody reads the commit list.
[16:19:43] <seb_kuzminsky> and i guess someone pays attention to the arm buildslave?
[16:27:56] <jepler> not particularly close attention
[16:28:20] <jepler> I was only looking because of the third-of-a-million warnings that I caused the rtai realtime build to spew
[16:28:26] <jepler> and that only after ntu told me it was bonkers
[16:55:44] <Tom_itx> unrelated to linuxcnc but i figured you guys would know and i think i do... writing avr asm code someone wants to use a c library is that even possible? seems it would be hard at best
[17:05:34] <jepler> you have to write the asm code to the "C" calling convention, and you need e.g., the stack register to be set compatibly with C code.
https://gcc.gnu.org/wiki/avr-gcc#Calling_Convention seems to have some salient details
[17:06:24] <jepler> and also pay attention to the call-used registers in a section above
[17:06:39] <Tom_itx> yes
[17:06:46] <Tom_itx> i was looking at a similar doc
[17:07:04] <jepler> and you probably have to link the program-as-a-whole with the C compiler so you have the C runtime
[17:07:07] <Tom_itx> i know it _can_ be done but is it worth it :D
[17:07:38] <Tom_itx> if you don't know the lib, you'd have to push all the regs
[17:10:26] <jepler> I didn't realize the question was whether it was worth it :-P
[17:10:36] <Tom_itx> haha
[19:41:47] <CaptHindsight> https://www.sparkfun.com/products/13024 I wonder if its GPIO can toggle fast enough to drive steppers.
[20:20:45] <zq> PCW: so yeah, it was half-stepping
[20:20:55] <zq> PCW: thanks for the tip
[20:22:29] <PCW> full stepping is very rarely used (and typically rings like a bell every step)
