Back
[00:14:22] <skunkworks> cradek: I have the period set to 40us. (I could raise it) but it seems to have some odd behavior. I am running the stepper_inch config and the torc.ngc. It runs zippy for the first few minutes - then the mouse start to stick as you run it across the screen. also the updates of the tool get further and further apart.
[00:23:45] <cradek> skunkworks: if you clear the backplot does it go back to normal?
[00:24:45] <skunkworks> by george - it does
[00:25:06] <cradek> unfortunately that's just the result of it saving up more lines that it has to draw
[00:25:25] <cradek> but, fortunately, that doesn't affect the pulse generation etc
[00:25:50] <skunkworks> Ok - makes sense
[00:30:35] <skunkworks> Thanks :)
[00:30:57] <cradek> sure
[01:57:28] <cradek> did anyone see stuart S is going to give his shop guys wireless gamepads to jog the machines with?
[01:58:47] <jepler> yes I think I saw that message go by
[01:59:21] <skunkworks> don't trust it? ;)
[02:00:02] <jepler> in fact, I imagined that jmkasunich had a few things to say about the idea
[02:06:12] <jmkasunich> actually I didn't say anything
[02:06:40] <jmkasunich> stuart is gonna do what stuart is gonna do
[02:06:45] <skunkworks> I would think there should be some sort of 'charge pump' comunication between the tx and rx. So if communication gets 'sketchy' it knows to estop. yes estop. expecially if there is an estop on the txmter. If i push the estop I hope it does estop.
[02:07:10] <jmkasunich> an estop on the transmitter is not an estop
[02:07:23] <jmkasunich> but he's never indicated that he wants to do that
[02:07:29] <skunkworks> right
[02:08:19] <cradek> well whatever happens, it'll be jepler's fault for writing hal_input
[02:08:54] <cradek> * cradek waits for jmk to paste his NOT MY FAULT comment from hal
[02:09:40] <jmkasunich> I don't consider keyboard jogging to be safe, so wireless jogging is just incrementally worse, not fundamentally worse
[02:10:01] <skunkworks> cradek: the dual processors ran all afternoon.
[02:10:07] <cradek> cool
[02:10:15] <jmkasunich> "safe" means I'd put my hand between the tool and a solid object and jog toward it
[02:10:18] <cradek> I'm just playing with mine again, and I like how much more responsive AXIS is while it's running
[02:10:34] <cradek> it's a very real improvement on my slow machine
[02:16:59] <cradek> jmkasunich:
[02:16:59] <cradek> 49944 NO base-thread ( 3318, 20438 )
[02:17:06] <cradek> are these nsec or clocks?
[02:17:43] <jepler> clocks, I think
[02:18:59] <cradek> hmm, that means base period takes usually 9nsec but sometimes up to 51nsec
[02:19:48] <cradek> wonder what goes so badly sometimes
[02:20:54] <jepler> lots of cache misses, I assume
[02:21:19] <jepler> there are also special, once-per-startup calculations
[02:21:45] <jmkasunich> clocks
[02:21:57] <jmkasunich> 9uS you mean
[02:22:16] <jmkasunich> look at the individual function parameters
[02:22:22] <jmkasunich> foo.time and foo.tmax
[02:22:33] <jmkasunich> for real fun, scope them
[02:22:38] <jmkasunich> (.time, not .tmax)
[02:22:49] <cradek> sure, uS :-)
[02:22:55] <jmkasunich> and gradually raise the trigger level, until you are only triggering on the longest ones
[02:23:01] <cradek> I'm taking some unneeded junk out of base-thread
[02:24:36] <skunkworks> Is there a way to see what each processor is doing - load wise
[02:24:42] <cradek> top
[02:25:00] <jepler> any of you developer types know if the nutty sim-encoder/encoder/halui joypad jogging method described on
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Using_A_Joypad_To_Move_Your_CNC_Machine is still a sensible way to do that in emc 2.1, or is there something more straightforward now?
[02:25:15] <jepler> 'top' will not show what is happening in the realtime system, though
[02:25:17] <jmkasunich> uhhhh...
[02:25:26] <jmkasunich> hmmm
[02:25:42] <jepler> it looks quite complicated, even ignoring the stuff about jog-scale and coolant
[02:25:45] <jmkasunich> I think that is still the only way to turn a velocity command (from a stick or pad) into jogging
[02:26:11] <cradek> maybe we should backport the halui analog jog input
[02:26:12] <jmkasunich> we could make a simple comp that takes a velocity and delivers a count
[02:27:01] <jmkasunich> that is probably a better approach - I haven't tried halui for anything, but for velocity (as opposed to position/wheel) jogs the lack of realtime probably won't hurt
[02:28:16] <jepler> er -- this example is not using halui
[02:28:17] <jepler> net countX encoder.0.counts => axis.0.jog-counts
[02:28:23] <jepler> sorry I misled
[02:28:54] <cradek> alex_joni says halui analog jogging works great
[02:29:02] <cradek> I haven't tried it either (but I could - I have a joystick)
[02:30:20] <jepler> Is that TRUNK only? I don't see an analog jog input in 2.1.4 but maybe I missed it.
[02:30:39] <jmkasunich> jepler: the screwy sim-enc -> enc -> motion way uses the RT path
[02:31:36] <cradek> jepler: yes, trunk
[02:31:41] <jepler> (if someone can figure out what the "missing component" for joypad jogging is, I'll write it up)
[02:31:48] <jepler> anyway, 'night
[02:32:06] <jmkasunich> I think halui is the better approach
[02:32:08] <jmkasunich> goodnight
[02:32:51] <cradek> jmkasunich: I don't think I can get to those numbers with scope
[02:33:25] <jmkasunich> not the thread ones
[02:33:30] <jmkasunich> but the function one you can
[02:33:37] <jmkasunich> the thread one is just the sum of all the functions
[02:33:49] <cradek> wow, looks like I could easily run a 5kHz servo cycle on this machine
[02:34:12] <cradek> no waiting for IO in it though I guess - bad test
[02:34:54] <cradek> what happens if my base thread sometimes takes longer than the specified base period?
[02:35:07] <jmkasunich> I think the next one starts right away
[02:35:19] <jmkasunich> either that, or it drops one
[02:35:35] <cradek> 'starts right away' would be consistent with the lockup some people report
[02:35:52] <jmkasunich> you mean when base period is too small?
[02:36:01] <cradek> yes
[02:38:02] <cradek> jmkasunich: I wish I could see average and maybe stddev of the thread times
[02:38:16] <cradek> I wonder how hard those are to calculate in a running fashion
[02:38:32] <jmkasunich> we could change them from params to pins, then use sampler to catch them and post-process
[02:38:38] <cradek> true
[02:38:45] <cradek> or just a look in scope would be good enough for me
[02:39:06] <jmkasunich> you can sort of guess the average
[02:39:21] <cradek> yeah by halcmd show a bunch of times
[02:39:34] <jmkasunich> at least most of the time I've looked at them, 99% of samples are close to the same value, and you have a few fliers
[02:39:45] <jmkasunich> usually the fliers are periodic
[02:39:59] <jmkasunich> although you also get bursts of them when you do things like move the mouse or refresh a webpage
[02:40:26] <jmkasunich> halcmd show? you're still not scoping? or you really want to see the overall total?
[02:44:53] <cradek> I think the overall total is the only useful number for deciding what periods are possible, isn't it?
[02:45:12] <cradek> btw I can confirm that the machine does lock when you set the period 'too low'
[02:45:30] <cradek> where too low = 1.5x what seems to be a typical/average period
[02:45:43] <cradek> so the long ones do cause a problem
[02:45:54] <cradek> (not sure I understand what's going on)
[02:48:10] <jmkasunich> at 1.5x, you are dedicating 2/3 of the CPU to that thread
[02:48:33] <jmkasunich> it still has to service the other RT thread, plus user space and system stuff
[02:48:36] <cradek> I guess I didn't think about the servo thread also needing to run
[02:48:42] <cradek> 2/3 of *one* cpu
[02:48:49] <jmkasunich> ;-P
[02:48:52] <cradek> (that was my intent anyway)
[02:49:09] <jmkasunich> this is base thread you are messing with?
[02:49:12] <cradek> so the fast threads interrupt the slow ones all the time right?
[02:49:13] <jmkasunich> (steppers)
[02:49:17] <jmkasunich> yes
[02:49:19] <cradek> yes steppers
[02:49:36] <jmkasunich> in HAL, priorities are set based on period
[02:49:53] <cradek> I had always run at 50usec but 15 runs (slowly), 10 hangs
[02:50:25] <jmkasunich> also, the displayed time doesn't include the RTAI overhead before the thread is invoked, nor the overhead for restoring stuff after it finishes
[02:50:58] <cradek> hmm - with lots of base threads interrupting it, maybe the servo thread could never finish in time
[02:51:21] <cradek> I didn't think of that angle
[02:53:23] <skunkworksX2> another stuid question - how do I know linux see;s the 2 processors?
[02:53:35] <jmkasunich> cat /proc/cpuinfo
[02:53:42] <jmkasunich> should list two of them
[02:54:19] <cradek> also top shows some new stuff
[02:54:24] <jmkasunich> the time displayed for the servo thread should include all the interrupts
[02:54:46] <skunkworksX2> it dies show 2 :)
[02:54:51] <skunkworksX2> does
[02:54:53] <jmkasunich> it is just rdtsc() at end - rdtsc() at start, nothing fancy
[02:55:22] <skunkworksX2> I don't really see it in top. but I may not know what I am looking at
[02:55:37] <cradek> Cpu0 : 2.9% us, 2.9% sy, 0.0% ni, 94.2% id, 0.0% wa, 0.0% hi, 0.0% si
[02:55:37] <cradek> Cpu1 : 0.0% us, 1.9% sy, 0.0% ni, 98.1% id, 0.0% wa, 0.0% hi, 0.0% si
[02:55:50] <cradek> also there's a new column "P" that shows what CPU each process is on
[02:56:05] <skunkworksX2> yah - nto seeing that
[02:56:10] <skunkworksX2> not
[02:56:38] <cradek> try hitting `1'
[02:56:47] <cradek> maybe I had to turn it on
[02:57:32] <cradek> then `f' `J' (turns on P) space `W'
[02:57:41] <skunkworksX2> 1 does show the 2nd cpu - but I don't see the extra column
[02:58:01] <cradek> wow talk about cryptic to configure...
[03:05:20] <skunkworksX2> cpu0 is around 40%us and cpu 1 is around 40% sys
[03:05:31] <skunkworksX2> when emc is running
[03:06:26] <cradek> wow, I can't believe I used to use software that did only exact stop
[03:06:38] <cradek> (I'm cutting the axis splash screen in air, in exact stop mode)
[03:06:52] <cradek> maybe back then, the top speed was so low, I didn't notice
[03:06:54] <jmkasunich> go, stop, go, stop, go, stop
[03:07:09] <cradek> yeah, it sounds pretty rough, the curves are terrible
[03:08:28] <skunkworksX2> jmkasunich: did you see the link to cnczone where a guy was comparing emc to mach?
[03:08:37] <jmkasunich> yeah
[03:09:01] <skunkworksX2> I thought it was interesting. he has used mach emc and turbocnc
[03:09:18] <skunkworksX2> what is ni?
[03:09:30] <cradek> that's what the knights say
[03:09:34] <skunkworksX2> ;)
[03:10:01] <cradek> seriously I have no idea what you're asking
[03:11:05] <skunkworksX2> it has utilization - us,sy,ni
[03:11:17] <cradek> oh, niced
[03:11:56] <skunkworksX2> h
[03:11:59] <cradek> AXIS is niced
[03:12:00] <skunkworksX2> ah
[03:12:47] <skunkworksX2> ok - time for bed :)
[03:12:52] <cradek> goodnight
[13:18:39] <cradek_> cradek_ is now known as cradek
[16:02:28] <skunkworks> cradek: are you hoping to put the new rt kernel in an upcoming release?
[16:03:18] <cradek> that is not my plan right now (in the 2.1 series), because I have no confidence it won't break some machines
[16:04:46] <skunkworks> I see.
[17:12:22] <skunkwork1> why am I getting this?
http://www.pastebin.ca/457905
[17:47:33] <alex_joni> skunkwork1: did you boot the other kernel?
[17:47:44] <skunkwork1> Yes
[17:47:55] <alex_joni> well.. then it won't work
[17:48:06] <alex_joni> you need to run the other testsuite
[17:48:17] <alex_joni> this one is compiled for the 2.6.17
[17:48:26] <skunkwork1> hmm I thought I did.
[17:48:37] <alex_joni> uname -a
[17:49:21] <skunkwork1> Linux samco-desktop 2.6.17-rtai3.5 #2 SMP Fri Apr 20 22:15:13 CDT 2007 i686 GNU/Linux
[17:49:42] <alex_joni> hmm.. then check dmesg
[17:49:51] <skunkwork1> I got emc agian and rebuilt it - doesn't work either
[17:50:06] <skunkwork1> think I may have borked somethin ;)
[17:52:41] <alex_joni> you think?
[17:53:06] <skunkwork1> http://www.pastebin.ca/458009
[17:53:33] <skunkwork1> the three debs installed correctly (as far as I know) and it seemed to boot corectly.
[17:53:59] <skunkwork1> but I cannot run the latency test and now I see emc isn't quite right
[17:54:54] <skunkwork1> http://www.pastebin.ca/458014
[17:54:59] <alex_joni> RTAI[hal]: ERROR, LOCAL APIC CONFIGURED BUT NOT AVAILABLE/ENABLED
[17:55:06] <alex_joni> that's your problem
[17:55:13] <skunkwork1> ok - something I can fix?
[17:55:23] <alex_joni> try adding -nolapic to the option in grub
[17:56:01] <skunkwork1> nolapic
[17:56:16] <alex_joni> yeah, that
[17:56:26] <skunkwork1> should I just try inserting it at boot
[17:56:34] <alex_joni> you can do that too
[17:56:48] <alex_joni> if you're confident with grubs mistique ways of editing params :D
[17:56:50] <skunkwork1> or I could edit a file... If I knew where it was
[17:56:59] <alex_joni> it's /boot/grub/menu.lst
[17:57:33] <alex_joni> although I'm not so sure it will help
[17:57:50] <alex_joni> I think cradek enabled the lapic in the kernel, but your machine doesn't have it..
[17:58:23] <skunkwork1> ah
[17:59:16] <skunkwork1> where?
http://www.pastebin.ca/458020
[17:59:35] <skunkwork1> titleUbuntu, kernel 2.6.17-rtai3.5 (recovery mode)
[17:59:35] <skunkwork1> root(hd0,0)
[17:59:35] <skunkwork1> kernel/boot/vmlinuz-2.6.17-rtai3.5 root=/dev/hda1 ro single
[17:59:35] <skunkwork1> initrd/boot/initrd.img-2.6.17-rtai3.5
[17:59:35] <skunkwork1> boot
[17:59:37] <alex_joni> kernel /boot/vmlinuz-2.6.17-rtai3.5 root=/dev/hda1 ro quiet splash
[17:59:46] <alex_joni> kernel /boot/vmlinuz-2.6.17-rtai3.5 root=/dev/hda1 ro quiet splash nolapic
[17:59:52] <skunkwork1> Thanks
[18:00:10] <alex_joni> if it doesn't work.. just boot the 2.6.15 and fix the file
[18:01:00] <skunkwork1> bbiab
[18:02:42] <skunkworks> its booting
[18:03:04] <alex_joni> I suspect you'll get the same error.. but maybe not :D
[18:05:37] <jepler> nolapic / noapic doesn't fix that error
[18:06:10] <jepler> if linux is configured with CONFIG_X86_LOCAL_APIC but it is not found at boot time, Linux still works fine
[18:06:19] <jepler> (or if it is disabled)
[18:06:33] <jepler> but rtai breaks if CONFIG_X86_LOCAL_APIC is defined but the APIC is not found or is disabled
[18:08:30] <cradek> oh good, this is the thing that was a pain last time before we got it right
[18:09:12] <alex_joni> cradek: right
[18:10:51] <cradek> let me see if I can turn it off
[18:15:06] <jepler> grumble, emc2 doesn't build on my old fedora core 64-bit machine after jmk reverted the rtapi_types.h change
[18:15:09] <jepler> /usr/include/sys/types.h:46: error: conflicting types for 'loff_t'
[18:15:10] <jepler> (also for various other types)
[18:15:13] <jepler> /usr/include/linux/types.h:25: error: previous declaration of 'loff_t' was here
[18:19:25] <alex_joni> jepler: think you can spot why it does some depending before sudo make setuid, after make ?
[18:20:10] <jepler> alex_joni: hmph, it does?
[18:20:12] <jepler> grumble
[18:20:30] <skunkworks> Same error as predicted ;)
[18:20:36] <skunkworks> * skunkworks had a meeting
[18:20:45] <jepler> I have noticed it doing "some things" twice for comp stuff and I guess that would happen on 'sudo make setuid' as well
[18:21:05] <alex_joni> yeah, it was comp related
[18:24:55] <skunkworks> so the kernel has to be rebuilt?
[18:25:15] <cradek> I think turning off LOCAL_APIC is going to break SMP detection
[18:25:32] <skunkworks> ew
[18:25:44] <alex_joni> yuck
[18:25:51] <skunkworks> this is a pentium II 450
[18:26:00] <alex_joni> that just about says SMP for everyone is a dream
[18:26:08] <cradek> yep it does
[18:26:59] <cradek> I wonder if rtai actually CAN'T work with that kernel option turned on
[18:28:13] <alex_joni> I bet it can
[18:28:19] <cradek> if (!mpc->mpc_lapic) {
[18:28:23] <cradek> printk(KERN_ERR "SMP mptable: null local APIC address!\n");
[18:28:28] <cradek> ^^ yeah it won't work
[18:28:55] <cradek> alex_joni: you think it gives an error and stops just because of some pedantry?
[18:28:59] <alex_joni> yeah, but the kernel has another way of detecting lapic
[18:29:05] <alex_joni> and keeps working
[18:29:16] <alex_joni> I see _NO_ reason rtai shouldn't do the same
[18:29:34] <alex_joni> or maybe detect what the kernel has found out
[18:29:35] <alex_joni> and use that
[18:31:25] <jepler> rtai doesn't have portability to many systems with the same kernel image and modules as a priority
[18:31:45] <cradek> I'll lie to rtai and rebuild it. maybe it will just work.
[18:31:46] <jepler> it uses a different timer strategy (8254 or APIC) depending on compile time flags, and only includes one strategy
[18:31:49] <alex_joni> yeah, I guess that's correct
[18:32:13] <alex_joni> s/correct/true/
[18:32:17] <cradek> jepler: you think lying will work?
[18:32:41] <jepler> cradek: unfortunately, I'm not sure
[18:32:45] <alex_joni> I think it can work always using 8254
[18:32:56] <alex_joni> although that might not be the best thing
[18:33:00] <cradek> wth, I'll try
[18:34:51] <alex_joni> cradek: the guy from germany I told you about (mschumacher) reports that his 4xXeon 2.4 works ok with the new kernel
[18:35:01] <cradek> nice
[18:35:10] <alex_joni> only emc crashes
[18:35:17] <alex_joni> but that's because he didn't recompile
[18:41:22] <cradek> skunkworks:
http://linuxcnc.org/experimental/rtai-modules-2.6.17-rtai3.5_1.1_i386.deb
[18:41:37] <cradek> skunkworks: please install this and retry
[18:44:51] <cradek> * cradek crosses his fingers
[18:45:50] <skunkworks> Ok :)\
[18:46:17] <cradek> I'm glad you found a machine with this issue, it's the problem I was worried about
[18:47:18] <skunkworks> http://linuxcnc.org/experimental/rtai-modules-2.6.17-rtai3.5_1.1_i386.deb
[18:48:45] <skunkworks> do I need to reboot or rebuild emc2?
[18:49:08] <cradek> umm I don't think so
[18:49:08] <jepler> a reboot is probably not necessary
[18:49:18] <cradek> I'm not so sure about rebuild
[18:49:46] <jepler> alex_joni: these TRIVIAL_BUILD changes I checked in probably don't really correct the problem (that something about comp is done twice) but they should prevent it from happening again at 'sudo make setuid'. I wasn't actually seeing that behavior today, though, and I'm not sure why
[18:51:42] <skunkwork1> this should run the latency test - correct?
[18:51:43] <skunkwork1> sudo mknod /dev/rtf3 c 150 3; cd /usr/realtime-2.6.17-rtai3.5/testsuite/kern/latency; ./run
[18:51:53] <cradek> yes
[18:52:53] <cradek> this sounds like a bad sign
[18:52:55] <skunkwork1> then I get the same error running that - should I reboot. Emc also bombs
[18:53:03] <skunkwork1> should I reboot?
[18:53:06] <cradek> you get the same LOCAL APIC error?
[18:53:36] <cradek> does `dpkg -l rtai-modules-2.6.17-rtai3.5' show version 1.1?
[18:54:07] <skunkwork1> yes
[18:54:25] <jepler> elfring actually attached a patch
[18:54:27] <skunkwork1> sorry -n yes to your previous message
[18:54:35] <jepler> --- E:/Quellen/emc2/src/hal/classicladder/socket_server.cSat Sep 30 05:58:22 2006
[18:54:37] <jepler> +++ E:/Projekte/emc/2.1.4/src/hal/classicladder/socket_server.cWed Apr 25 18:24:04 2007
[18:55:19] <cradek> skunkworks: say again please
[18:55:26] <skunkwork1> rtai-modules-2 1.1
[18:55:32] <cradek> ok
[18:55:40] <skunkwork1> same error in dmesg
[18:55:54] <skunkwork1> I will reboot
[18:56:12] <cradek> I probably screwed up, looking
[18:56:42] <cradek> CONFIG_X86_LOCAL_APIC_FALSE=''
[18:56:42] <cradek> CONFIG_X86_LOCAL_APIC_TRUE='#'
[18:56:52] <cradek> wtf is this shit
[18:56:56] <cradek> (pardon me)
[18:57:50] <jepler> ahaha this file that he's actually produced a patch for was one of the "never used" classicladder files that I finally removed on TRUNK two months ago.
[18:58:16] <cradek> oh good grief
[19:00:30] <skunkwork1> same thing as you guys probably figured
[19:00:45] <cradek> problem still there?
[19:01:09] <skunkwork1> http://www.pastebin.ca/458146
[19:01:37] <cradek> ok I must not have managed to lie convincingly enough
[19:03:02] <skunkworks> I have that problem sometimes
[19:04:05] <alex_joni> jepler: all good now
[19:18:02] <cradek> skunkworks: please get that same file and install again (I did not change the version number or filename)
[19:18:25] <skunkworks> ok :)
[19:18:54] <skunkworks> pardon my paste
http://linuxcnc.org/experimental/rtai-modules-2.6.17-rtai3.5_1.1_i386.deb
[19:24:44] <skunkwork1> different
http://www.pastebin.ca/458184
[19:24:50] <skunkwork1> going to reboot
[19:25:12] <cradek> yuck
[19:25:25] <skunkwork1> also the latency test starts but never scrolls numbers. then when you hit ctrl c - it has one row of ungodly big numbers
[19:25:33] <skunkwork1> rebooting
[19:26:15] <cradek> we're screwed
[19:26:44] <skunkworks> too much of a hasle having 2 different kernels - single and multible?
[19:27:30] <cradek> it means building different emc2 packages at the least
[19:27:43] <skunkworks> sounds like a pain ;)
[19:29:33] <cradek> apic_write_around, apic_wait_icr_idle are used if CONFIG_SMP and only exist if CONFIG_X86_LOCAL_APIC
[19:29:58] <cradek> which matches the expectations of the kernel config
[19:32:13] <cradek> so, sadly, I don't see an easy answer
[19:33:31] <skunkworks> same thing after a reboot.
[19:33:33] <cradek> I removed that bogus rtai*1.1 package
[19:33:49] <cradek> skunkworks: yeah, I see in the code that it's not going to work
[19:33:56] <skunkworks> yeck
[19:34:02] <cradek> thanks for testing
[19:34:07] <skunkworks> no problem
[19:34:37] <skunkworks> so it won't work with 'any' single processor computer?
[19:34:50] <cradek> I bet it does work with more modern ones
[19:35:37] <cradek> although the only one I've tried personally is an SMP board with only one processor in it, which may be a special case
[19:36:25] <skunkworks> darn
[19:37:07] <cradek> yeah this is very disappointing
[19:37:14] <cradek> oh well
[20:59:55] <alex_joni> cradek: on that 4-processor box
[21:00:06] <alex_joni> it crashes as soon as he starts emc
[21:00:43] <cradek> he should send me an equivalent machine so I can test
[21:01:17] <skunkworks> :)
[21:01:47] <skunkworks> alex_joni: get fresh source and stuff?
[21:02:24] <cradek> do all the rtai tests work, but not emc? he compiled it, right?
[21:02:38] <cradek> yeah what skunkworks says
[21:02:58] <cradek> in rtai, you tell it the number of processors - I wonder if it is broken if that's wrong
[21:03:04] <cradek> * cradek grumbles about rtai
[21:03:18] <skunkworks> is there another solution?
[21:03:39] <cradek> not really, I don't think
[21:05:24] <alex_joni> I asked him to test latency now
[21:05:51] <skunkworks> I mainly wanted to run the rtai test to see if it crashed with the new rtai. Because I ran it on the dual proccessor and it didn't
[21:06:09] <skunkworks> the glxgears and latency test
[21:07:35] <skunkworks> the dual proccessor even went into screen saver while everything was running and no issues
[21:14:54] <alex_joni> cradek: latency test crashes too
[21:15:53] <cradek> alex_joni: I might see if I can build rtai for 4 or 8 and it still runs on 2
[21:16:15] <alex_joni> cradek: slowly I get the feeling that this is not really usefull
[21:16:22] <cradek> right
[21:16:39] <alex_joni> rtai for SMP is far from distributable
[21:17:20] <cradek> I feel like we're lucky to have a UP rtai kernel that works widely
[21:17:35] <alex_joni> yeah, me too
[21:17:48] <cradek> like jepler says, making one build work on many machines is not at all important to rtai
[21:18:24] <alex_joni> if they keep doing source only distribs
[21:18:55] <cradek> in their place I wouldn't want to package for a bunch of distributions either
[22:59:14] <skunkworks> cradek: the kernal doesn't work on my portable either. 1.7ghz pentium
[23:00:10] <cradek> ok, it was an interesting experiment, I'll leave the files there for experts to use when they want
[23:00:19] <cradek> thanks for your help testing
[23:00:25] <skunkworks> no problem
[23:00:33] <skunkworks> thanks for all your work
[23:05:10] <skunkworksX2> jepler: tuning off the live plot really works great this computer.
[23:06:44] <skunkworks> turning
[23:12:07] <alex_joni> good night all