Back
[00:00:54] <cradek> 49944 NO base-thread ( 3321, 14457 )
[00:01:11] <cradek> well maybe I'm wrong - it's almost always 3k, but I got a 14k once
[00:01:32] <jmk-kayak> try setp'ing the param back to zero after emc is running
[00:01:35] <cradek> there's a lot of junk in there - encoder stuff
[00:02:01] <jmk-kayak> the big number might be first-time-thru, either doing init stuff, or just loading up the cache
[00:02:38] <cradek> I don't see how to do that
[00:02:39] <jmk-kayak> one counterintuitive thing - as you make the base period shorter and shorter, there is less time for other stuff to displace the thread code from cache, and the worst case improves
[00:02:48] <jmk-kayak> oh, brainfart
[00:02:51] <jmk-kayak> threads you can't
[00:02:55] <jmk-kayak> functions you can
[00:02:56] <cradek> 49944 NO base-thread ( 2786, 16790 )
[00:02:57] <jmk-kayak> funct-tmax
[00:02:58] <cradek> it went up anyway
[00:03:00] <jmk-kayak> is a parameter
[00:03:09] <cradek> ah
[00:03:29] <jmk-kayak> you can also scope the function time, which can be interseting
[00:03:32] <cradek> so check my thinking here - if we get an error only during abort, it must be caused by something special that's happening at abort time
[00:03:45] <jmk-kayak> heh, back on topic
[00:03:53] <jmk-kayak> my plan was to instrument the abort code
[00:04:02] <jmk-kayak> that would avoid a printk storm, since it only runs once
[00:04:22] <cradek> well you could use isnan() and a flag to only print once
[00:05:24] <jmk-kayak> yeah
[00:05:26] <cradek> (this feels like a TP bug)
[00:05:59] <cradek> because what else is special at abort time?
[00:06:12] <jmk-kayak> hard to say
[00:06:13] <cradek> TP stops, the interpolators drain
[00:06:22] <jmk-kayak> I'm gonna but an isnan() test in check_stuff()
[00:07:19] <jmk-kayak> but what variable should I be checking....
[00:08:24] <cradek> maybe you want !isfinite()
[00:08:52] <jmk-kayak> I'm not sure how many of those are implemented in our kernel math lib
[00:08:59] <jmk-kayak> isnan is, I believe
[00:08:59] <cradek> ah
[00:09:11] <cradek> I think you could also use d==d
[00:09:57] <jmk-kayak> ?
[00:10:15] <cradek> I think for d=nan and d=inf, d==d is false
[00:10:42] <jmk-kayak> clever
[00:11:06] <cradek> if you mean that in the negative sense, I agree
[00:11:54] <jmk-kayak> chit - can't print a float in kernel space either
[00:12:04] <jmk-kayak> I guess the test is the only way to go
[00:20:12] <jmk-kayak> either the d==d test doesn't work, or it doesn't bust emcmotStatus->joint_status[0].pos_cmd
[00:20:52] <cradek> try d < 9e99 or something like that?
[00:21:01] <jmk-kayak> looks like isnan is not defined in rtapi_math
[00:22:21] <jmk-kayak> hmm, it is in rtapi/mathstubs.c
[00:23:08] <jmk-kayak> * jmk-kayak just copies the implementation into control.c
[00:23:14] <lerman> Check the optimization level of the compiler. High levels of optimization will just assume d == d and skip the test. If you can read the generated code, you will be able to tell if the test is optimized out.
[00:23:31] <jmk-kayak> I'm going to put a proper isnan in there
[00:24:55] <jmk-kayak> see line 63 of src/rtapi/mathstubs.c for the code I copied, along with an enlightning comment
[00:24:59] <jmk-kayak> it will detect infinity too
[00:25:31] <jmk-kayak> well, isnan works
[00:25:44] <jmk-kayak> now i gotta remember to deletion positions.txt before each run
[00:26:45] <cradek> ok now that I have code to catch it, I can't get the error after about 30 aborts
[00:27:16] <jmk-kayak> same here
[00:27:22] <jmk-kayak> 10 tries so far
[00:27:35] <jmk-kayak> when I had the d==d test, it happened first time
[00:27:43] <jmk-kayak> I HATE!!!!HATE!!!HATE!!!! intermittents!
[00:27:52] <cradek> guess it's fixed!
[00:28:10] <jmk-kayak> you wish
[00:28:16] <jmk-kayak> oh, now thats interesting
[00:28:35] <jmk-kayak> I hit esc, it seemed to stop normally, I started typing "you wish"
[00:28:45] <jmk-kayak> and about at "wi" it popped up the error dialog
[00:29:36] <jmk-kayak> the nan showed up in emcmotStatus->joint_status[0].pos_cmd after the call to "update status"
[00:29:59] <cradek> what's "update status"?
[00:30:11] <cradek> does it happen right when it drops back into free mode maybe?
[00:30:20] <jmk-kayak> duh, thats when joint->pos_cmd (local to motmod) is copied to emcmotStatus (shared memory)
[00:30:33] <jmk-kayak> * jmk-kayak moves the spy to joint->pos_cmd
[00:30:50] <cradek> I simply can't reproduce it anymore
[00:30:54] <cradek> wtf.
[00:31:56] <cradek> I got it every time with flowsnake before
[00:33:47] <jmk-kayak> got it first time this time
[00:33:55] <jmk-kayak> isnan after get_pos_cmds
[00:34:01] <cradek> I'm glad one of us can
[00:34:57] <cradek> it could be the interpolator then
[00:35:14] <jmk-kayak> yeah, gotta narrow it down some more
[00:35:19] <jmk-kayak> get-pos-cmds is bit
[00:35:26] <cradek> wonder which mode mot was in at the call that porks it
[00:35:40] <jmk-kayak> 400ish lines
[00:36:21] <jmk-kayak> if mode is a global I can have the spy print it
[00:36:57] <cradek> emcmotStatus->motion_state
[00:37:36] <cradek> I still haven't gotten it - trying all this time
[00:37:37] <jmk-kayak> int, right?
[00:39:01] <cradek> yes motion_state_t is an enum
[00:39:09] <jmk-kayak> 3
[00:39:35] <jmk-kayak> EMCMOT_MOTION_COORD
[00:39:40] <jmk-kayak> its not into free mode yet
[00:39:49] <cradek> nice
[00:39:56] <cradek> the focus narrows a bit more
[00:40:06] <jmk-kayak> a lot more
[00:40:11] <jmk-kayak> the coord code is only about 30 lines
[00:40:12] <cradek> how often do you get it?
[00:40:17] <jmk-kayak> of course, it calls the tp....
[00:40:22] <jmk-kayak> lately, every time
[00:40:26] <jmk-kayak> you are cursed
[00:40:39] <cradek> you can rule out the interpolators if you set TRAJ=SERVO
[00:41:20] <jmk-kayak> the interpolator function becomes a no-op?
[00:42:17] <cradek> checking
[00:43:41] <cradek> wait you said it's carte_pos_cmd?
[00:43:47] <jmk-kayak> cubicInterpolate() is returning nan
[00:44:07] <jmk-kayak> approx line 2001 of control.c
[00:44:15] <jmk-kayak> (approx because I've been hacking in the file)
[00:44:34] <cradek> 2001 is in TELEOP for me
[00:44:51] <jmk-kayak> about 10 lines before the case TELEOP
[00:45:23] <jmk-kayak> joint->pos_cmd = cubicInterpolate(stuff)
[00:45:27] <cradek> but above, carte_pos_cmd is ok?
[00:45:35] <jmk-kayak> haven't been testing that
[00:45:54] <cradek> do that one too, that's the TP output
[00:46:21] <jmk-kayak> carte_pos_cmd is a struct, not a double, right?
[00:46:24] <cradek> which gets in positions[] and joint->coarse_pos
[00:46:31] <cradek> right
[00:47:27] <cradek> you could print positions[...] instead - that's doubles
[00:47:41] <jmk-kayak> I'm gonna spy on coarse_pos_cmd first
[00:50:08] <jmk-kayak> coarse_pos is also nan
[00:50:33] <cradek> * cradek sighs
[00:51:10] <cradek> ... as the big red arrow points his way
[00:52:43] <cradek> hey... try putting a G61 in your program
[00:52:54] <jmk-kayak> what does G61 do again?
[00:53:01] <cradek> turns off blending
[00:53:06] <cradek> (wipes out a lot of code)
[00:54:14] <jmk-kayak> when you instrumented it and the prob went away, what var were you examining?
[00:54:28] <jmk-kayak> never mind
[00:54:46] <cradek> in tcRunCycle: cycle_time, discr, newvel, progress
[00:55:11] <jmk-kayak> tpGetPos is returning a EmcPos struct that contains nan
[00:55:35] <cradek> cool
[00:56:16] <cradek> ouch. when I took out my spys, I got the error on the first try
[00:56:53] <jmk-kayak> what file is runcycle and getpos in? tc.c?
[00:57:07] <jmk-kayak> tp.c I mean
[00:57:09] <cradek> tp.c
[00:57:35] <cradek> yep now I get it reliably
[00:58:15] <cradek> heisenbug
[00:59:22] <jmk-kayak> back in a couple mins, I'll help you chase it
[00:59:34] <cradek> * cradek gets a beer
[01:07:11] <jmk-kayak> back
[01:09:45] <cradek> back
[01:14:15] <jmk-kayak> GetPos doesn't do much does it?
[01:14:48] <cradek> tpGetPos, no -- tcGetPos, yes
[01:15:06] <cradek> did you happen to try g61 yet?
[01:15:10] <jmk-kayak> no
[01:15:18] <jmk-kayak> I'm chasing it from the code side
[01:15:29] <cradek> ok
[01:15:35] <jmk-kayak> somewhere there is an operation that gets normal numbers and returns nan....
[01:17:12] <cradek> I found a nan in tc->progress in tcRunCycle()
[01:18:36] <cradek> but adding more checks fixed it again
[01:18:39] <cradek> I wonder if it's a compiler bug
[01:19:03] <cradek> either that or a rogue pointer somewhere
[01:26:11] <jmk-kayak> I just had a bit of a swirl, but I think I recovered now
[01:26:16] <jmk-kayak> where are you seeing the nan?
[01:26:26] <cradek> everywhere in tcRunCycle
[01:26:48] <cradek> I'm narrowing it to the '//constrain velocity' lines
[01:27:53] <jmk-kayak> any particular variable
[01:27:54] <cradek> but when I put in more checks, it goes away
[01:28:13] <cradek> now I suspect tc->reqvel
[01:28:24] <cradek> earlier I suspected tc->cycle_time, since we divide by it
[01:29:49] <cradek> yes it's tc->reqvel
[01:31:28] <jmkasunich> I just managed to lock up kayak
[01:31:33] <cradek> ouch
[01:31:35] <jmkasunich> must have put a spy in the wrong place
[01:31:42] <cradek> oh the joy of kernel code
[01:34:12] <jmkasunich> while that reboots.....
[01:38:35] <jmk-kayak> lets see if I can do that again
[01:38:48] <cradek> nexttc->reqvel = (tc->vel_at_blend_start - primary_vel) / nexttc->feed_override;
[01:39:06] <cradek> I don't like this line - it's not always protected by if(nexttc)
[01:39:23] <cradek> seems like when aborting during a blend, nexttc may expire (decelerate to 0) before tc
[01:40:51] <cradek> nope :-)
[01:41:21] <jmk-kayak> now I'm having serious trouble keeping up
[01:41:50] <cradek> sorry, I'm jumping around because I know this code, but that doesn't mean I'm ahead
[01:42:01] <cradek> maybe you should continue the methodical search
[01:42:20] <cradek> my thinking was this:
[01:42:22] <cradek> tc->reqvel is nan
[01:42:36] <cradek> look for things that write to something->reqvel
[01:42:45] <cradek> look for ways that can be screwy
[01:42:50] <jmk-kayak> when does it go wrong"
[01:43:17] <cradek> at the beginning of tcRunCycle I see tc->reqvel = nan
[01:43:24] <jmk-kayak> at the _beginning_?
[01:43:29] <cradek> yes
[01:43:42] <cradek> so a methodical person would figure out which call to tcRunCycle has nan input
[01:43:44] <jmk-kayak> so who calls tcRunCycle? work backwards
[01:44:00] <cradek> yeah I know, lack of discipline working here
[01:44:06] <jmk-kayak> reqvel isn
[01:44:09] <jmk-kayak> dammit
[01:44:09] <cradek> whenever I touch it, the error goes away
[01:44:15] <jmk-kayak> is not a parameter to tcRunCycle
[01:44:24] <cradek> tc->reqvel
[01:44:30] <cradek> tc is the first arg
[01:44:39] <jmk-kayak> ok, so its being passed a struct with a nan in it
[01:44:43] <cradek> yes
[01:45:47] <jmk-kayak> I just put a spy right at that entry point, if that catches it I'll chase it back
[01:47:51] <cradek> nexttc->reqvel = (tc->vel_at_blend_start - primary_vel) / nexttc->feed_override;
[01:47:56] <cradek> it *IS* this line
[01:48:05] <jmk-kayak> what line number
[01:48:14] <cradek> who knows, 750 here
[01:50:07] <cradek> oh, duh
[01:50:09] <cradek> DUH
[01:51:54] <jmk-kayak> what?
[01:52:08] <cradek> to abort, FO is set to 0
[01:52:13] <cradek> guess what you can do with a 0 to get nan
[01:52:21] <jmk-kayak> divide by it
[01:52:32] <jmk-kayak> feed override goes to zero on abort?
[01:52:39] <cradek> and pause
[01:52:57] <jmk-kayak> so how come we never saw this using UP?
[01:53:05] <cradek> I sure don't know.
[01:53:35] <cradek> it's not SMP, it's rtai3.5 that made it show up
[01:53:45] <jmk-kayak> do you know for a fact that feed_override is 0 when it barfs?
[01:54:23] <cradek> I know none of those three numbers is nan, but the assignment is
[01:54:29] <cradek> so it's pretty clear
[01:56:25] <cradek> please test my fix!
[01:56:53] <jmk-kayak> be patient
[01:57:02] <cradek> :-)
[01:57:37] <cradek> I wrote that line at about 3am last fest... that's my excuse
[01:58:40] <jmk-kayak> ok, I've verified that nexttc->feed_override is indeed zero when it blows up
[01:58:50] <cradek> great
[01:58:58] <cradek> that sure propogates fast doesn't it
[01:59:15] <cradek> nan is very contagious
[02:00:10] <jmkasunich> what happens in that code as feed_override gets arbitrarily close to zero?
[02:01:15] <jmkasunich> can you explain in english what that line of code is calculating?
[02:01:42] <cradek> actually I was just wondering that myself
[02:01:57] <cradek> I wonder if I meant *
[02:02:02] <petev> I would have thought it would be multiply
[02:02:06] <petev> but what do I know
[02:02:16] <jmk-kayak> that would make more sense - you are calculating a velocity
[02:03:00] <jmk-kayak> what happens if you set feed override to 0.001 and closely observe a blend?
[02:03:10] <jmk-kayak> do you get the expected results, or do you get crazy accels?
[02:03:31] <cradek> you won't get a bad accel no matter what you do to reqvel
[02:03:51] <jmk-kayak> ok... bad test
[02:04:05] <jmk-kayak> wth is reqvel used for then?
[02:04:12] <jmk-kayak> and how can you detect if its borked?
[02:04:24] <cradek> it's the requested vel, mostly from the user
[02:04:42] <cradek> this hack is supposed to make the decel/accel of adjacent segments match
[02:05:26] <jmk-kayak> so if you set feed override to 0.001, and that should really be a multiply, what would you see? a step in accel at the blend point?
[02:06:00] <cradek> maybe poor blends when FO != 1
[02:06:22] <jmk-kayak> hence "if you set feed override to 0.001"
[02:06:25] <cradek> I think maybe it doesn't belong there at all
[02:06:36] <jmk-kayak> IOW, lets design an experiment that will tell us if that expression is correct, then run it
[02:06:48] <jmk-kayak> I'm sure a non-unity FO is part of the experiment
[02:12:10] <jmkasunich> grr... the commit has me thrashing again...
[02:15:10] <cradek> experimental evidence shows that the code is right, even though I don't remember why I wrote it that way
[02:15:37] <jmkasunich> changing it to a multiply yields observable bad results?
[02:15:51] <cradek> yes, as does removing it
[02:16:56] <jmkasunich> when the farm stops beating me up I'm gonna run UP with a test for nexttc->feed_override = zero
[02:17:22] <jmkasunich> maybe its been zero (during abort) for a while, but the two rtai's treat that differently
[02:17:50] <cradek> yes they must
[02:18:00] <cradek> we're using rtai_math
[02:19:50] <cradek> if x/0 -> 0, it would have worked fine all along
[02:21:51] <jmkasunich> yep, got one
[02:22:13] <cradek> got what?
[02:22:24] <jmkasunich> FO = 0 during abort on a UP system
[02:22:31] <jmkasunich> with the old RT kernel
[02:22:32] <cradek> but no nans?
[02:22:38] <jmkasunich> right
[02:22:45] <cradek> what's the result of the division then?
[02:23:03] <jmkasunich> I'll have to add code to check that (can't print it, but will test for zero)
[02:23:30] <cradek> you can print %d, n*100000
[02:23:50] <cradek> another interesting question is why this didn't show up in pure sim
[02:23:55] <jmkasunich> and what will that do on nan?
[02:24:10] <cradek> good question
[02:25:47] <jmkasunich> offtopic (while it builds)
[02:26:00] <jmkasunich> what video card are you running? I know its a nvidia
[02:26:18] <cradek> on the nonrealtime system?
[02:26:20] <jmkasunich> yeah
[02:26:28] <cradek> it's an nvidia model (mumblemumble)
[02:26:45] <cradek> I'm a firm believer in any old $30 nvidia card being just great
[02:26:49] <jmkasunich> thanks, that helps
[02:27:03] <cradek> they're all fine, seriously
[02:27:19] <jmkasunich> open GL support, drivers for linux, the whole nine yards>
[02:27:21] <jmkasunich> ?
[02:27:30] <cradek> it was a throwaway from work because of a bad fan - I wiretied another one onto it
[02:27:33] <cradek> yes
[02:27:43] <cradek> virtually all nvidia cards are supported by their shit driver
[02:27:49] <cradek> err, I mean proprietary
[02:27:54] <cradek> :-)
[02:28:20] <cradek> about the only GL apps I use are google earth and screensavers
[02:28:25] <cradek> and they work great
[02:30:02] <cradek> http://www.newegg.com/Product/Product.aspx?Item=N82E16814125047
[02:30:10] <cradek> $43, dual monitor support
[02:30:32] <cradek> be sure to get fanless
[02:30:50] <jmkasunich> rtapi_print ( "RV = %08x : %08x\n",
[02:30:50] <jmkasunich> (int)(((long long int)nexttc->reqvel) >> 32),
[02:30:50] <jmkasunich> (int)(((long long int)nexttc->reqvel))
[02:30:58] <jmkasunich> this ought to print a double, right?
[02:31:08] <jmkasunich> as two 32 bit hex numbers?
[02:32:03] <jmkasunich> well, with another paren and a ; on the end ;-)
[02:32:29] <cradek> don't you want & 0xffff
[02:32:36] <jmkasunich> no
[02:32:45] <jmkasunich> double is 64 bits, long long
[02:32:54] <jmkasunich> so I want to print hi 32, then lo 32
[02:33:06] <jmkasunich> the casts to int will chop the high bits
[02:33:28] <cradek> I meant ffffffff, not being sure about how that cast works
[02:33:46] <cradek> I'm obviously the wrong one to ask
[02:33:56] <jmkasunich> Apr 22 22:33:36 ke-main-1006 kernel: [3107779.424337] FO=0
[02:33:55] <jmkasunich> Apr 22 22:33:36 ke-main-1006 kernel: [3107779.424345] RV = 80000000 : 00000000
[02:34:09] <jmkasunich> so, what is 80000000000000 in IEEE fp format?
[02:34:10] <cradek> is that -0?
[02:34:19] <jmkasunich> * jmkasunich googles
[02:35:38] <jmkasunich> wikipedia: # if exponent is 0 and fraction is 0, the number is ±0 (depending on the sign bit)
[02:35:50] <cradek> so it is -0
[02:35:55] <jmkasunich> yep
[02:36:04] <cradek> ok, that's why it worked all along
[02:37:20] <jmkasunich> apparently you can't test for -0 in C though
[02:37:35] <jmkasunich> I have:
[02:37:36] <jmkasunich> if ( nexttc->reqvel == 0.0 ) {
[02:37:36] <jmkasunich> rtapi_print ( "RV=0\n" );
[02:37:36] <jmkasunich> } else if ( nexttc->reqvel == -0.0 ) {
[02:37:36] <jmkasunich> rtapi_print ( "RV=-0\n" );
[02:37:36] <jmkasunich> } else {
[02:37:38] <jmkasunich> rtapi_print ( "RV = %08x : %08x\n",
[02:37:41] <jmkasunich> (int)(((long long int)nexttc->reqvel) >> 32),
[02:37:42] <jmkasunich> (int)(((long long int)nexttc->reqvel)) );
[02:37:45] <jmkasunich> }
[02:37:52] <jmkasunich> and its still printing the binary version
[02:38:25] <cradek> I'm surprised by that
[02:38:29] <jmkasunich> me too
[02:38:44] <cradek> I thought -0.0 was a perfectly valid double
[02:38:51] <jmkasunich> I wonder if the casts aren't doing what I expect, and its not really 8000...
[02:39:21] <jmkasunich> * jmkasunich figures out another way to print a double
[02:39:37] <cradek> you could print a bit at a time in a loop and get it right for sure
[02:39:52] <jmkasunich> I'm doing a byte at a time ;-)
[02:40:22] <cradek> that's better
[02:40:28] <cradek> I didn't think about endianness in your previous way
[02:42:26] <jmkasunich> cp = (unsigned char *)(&nexttc->reqvel);
[02:42:25] <jmkasunich> for ( cn = 0 ; cn < 8 ; cn++ ) {
[02:42:25] <jmkasunich> rtapi_print ( "%02X ", *cp++ );
[02:42:25] <jmkasunich> }
[02:42:54] <jmkasunich> heh
[02:43:03] <jmkasunich> Apr 22 22:42:47 ke-main-1006 kernel: [3108329.298865] FO=0
[02:43:04] <jmkasunich> Apr 22 22:42:47 ke-main-1006 kernel: [3108329.298872] 00 00 00 00 00 00 F0 7F
[02:43:04] <jmkasunich> Apr 22 22:42:47 ke-main-1006 kernel: [3108329.298876] RV = 80000000 : 00000000
[02:43:10] <jmkasunich> the casts are definitely busted
[02:43:32] <cradek> yep
[02:44:06] <cradek> that's nan
[02:44:28] <jmkasunich> yep
[02:44:41] <cradek> err, maybe it's inf
[02:44:41] <jmkasunich> but somehow it doesn't propagate
[02:44:49] <cradek> yeah inf
[02:45:03] <cradek> I think
[02:45:26] <jmkasunich> yeah, inf
[02:45:33] <jmkasunich> http://en.wikipedia.org/wiki/IEEE_7
[02:45:47] <jmkasunich> http://en.wikipedia.org/wiki/IEEE_754
[02:45:59] <jmkasunich> nice table about half way down
[02:47:05] <jmkasunich> that card you posted - just a nice pic, or something you have firsthand experience with?
[02:47:17] <jmkasunich> pic = pick, not picture
[02:47:43] <cradek> it's just the cheapest nvidia based card on newegg
[02:47:54] <cradek> that's how I'd pick one
[02:48:10] <jmkasunich> ;-)
[02:48:17] <jmkasunich> I'm a little pickier than that
[02:48:31] <jmkasunich> for instance that one has some silly HDTV adapter
[02:48:43] <cradek> (--) PCI:*(1:0:0) nVidia Corporation NV31 [GeForce FX 5600] rev 161, Mem @ 0xe8000000/24, 0xd0000000/28
[02:48:47] <jmkasunich> and some user reviews say it runs hot
[02:48:50] <cradek> this is mine I guess
[02:49:13] <cradek> you can have hot or fan - I choose hot since the fans are crap
[02:49:59] <cradek> I've had a lot of trouble with stopped fans causing X crashes, but I've never seen that with the fanless (hot running) cards
[02:50:47] <cradek> you'll probably need PCI express won't you
[02:50:51] <jmkasunich> yes
[02:50:55] <cradek> my machines are all AGP so far
[02:51:01] <cradek> you won't find a $40 card then I bet
[02:51:04] <jmkasunich> if not, I wouldn't be buying a card at all
[02:51:17] <jmkasunich> the one you posted is pci express
[02:51:21] <cradek> oh
[02:51:28] <cradek> I'm behind the times as usual
[02:51:29] <jmkasunich> you really did just pick the first thing you saw didn't you
[02:51:45] <cradek> yeah, I searched for nvidia, and scrolled up and down and picked the lowest price
[02:51:53] <cradek> noticed it had two connectors
[02:51:56] <cradek> sold!
[02:51:58] <cradek> haha
[02:52:14] <cradek> someday I'd like one with two DVIs, but I'm too cheap to replace a working card just for that
[02:52:33] <jmkasunich> I was looking at some cards at the local store, and some listed opengl 1.5, others opengl 2.0
[02:52:46] <jmkasunich> not sure if it matters
[02:52:52] <cradek> that's probably just a difference in the supplied windows driver
[02:53:20] <cradek> for linux, the nvidia proprietary driver is very much what people write their software to.
[02:53:41] <cradek> google earth and jigglyvision are two things that pop to mind as being written to nvidia
[02:53:54] <jmkasunich> you didn't even pick the cheapest one!
[02:53:55] <jmkasunich> http://www.newegg.com/Product/Product.aspx?Item=N82E16814130067
[02:54:20] <cradek> hey I recommend that one now.
[02:54:46] <jmkasunich> "Supporting 512MB (On board 128MB)"
[02:54:58] <jmkasunich> that implies that it uses system ram (or can, if it needs to)
[02:55:16] <cradek> oh really, that must be a new PCIE thing
[02:55:21] <cradek> hope you can turn it off
[02:55:53] <cradek> * cradek <- currently looking at a very high resolution screen running on a 4MB video card
[02:56:07] <jmkasunich> how nigh?
[02:56:14] <jmkasunich> high
[02:56:19] <cradek> just 1600x1200x16bit
[02:56:33] <cradek> video ram is for gamers
[02:56:43] <jmkasunich> and it does well rendering the axis preview?
[02:57:08] <cradek> good enough (it's just software rendered)
[02:57:14] <cradek> the nvidia runs axis VERY well
[02:57:36] <jmkasunich> I thought axis used openGL
[02:57:40] <cradek> yes
[02:57:52] <jmkasunich> the whole point of openGL is to be able to use hardware accel if the card has it
[02:58:00] <jmkasunich> well, one of the points
[02:58:03] <cradek> it has some lines, and some polygons you can count on your fingers, not too tough
[02:58:16] <jmkasunich> true
[02:58:34] <jmkasunich> I certainly wouldn't mind getting a graphics card for $40
[02:58:46] <cradek> do you have hardware accelerated opengl today?
[02:59:01] <jmkasunich> but if there is significantly better out there for $50... I'd hate to buy ONLY on price
[02:59:10] <jmkasunich> no, because of RT
[02:59:33] <jmkasunich> I get one or two frames/sec for glxgears
[02:59:41] <jmkasunich> I think, its been a while
[02:59:50] <cradek> you'll get 1000 with the $40 card
[03:00:01] <cradek> maybe 2000, I dunno
[03:00:09] <jmkasunich> some silly number
[03:00:19] <jmkasunich> http://www.newegg.com/Product/Product.aspx?Item=N82E16814130069
[03:00:28] <jmkasunich> still 40 after rebate
[03:00:34] <jmkasunich> newer chipset
[03:00:37] <jmkasunich> still fanless
[03:01:01] <jmkasunich> video card, ram, and cpu are the only parts I don't have... I want to order tonight
[03:01:09] <jmkasunich> CPU I already know what I'm getting
[03:01:12] <jmkasunich> RAM I'm pretty sure
[03:01:29] <jmkasunich> gotta decide between ECC or non-ECC, any thoughts?
[03:01:47] <cradek> sorry, no thoughts
[03:04:47] <jmkasunich> its funny, the one with the 6200 chipset and the one with the 7100 seem to be on the same (or very very similar) bareboards
[03:05:03] <jmkasunich> at first I thought they reused the photos, but the power supply caps are different
[03:09:22] <jmkasunich> uh-oh, did you see the message from Ken Anton?
[03:09:30] <jmkasunich> Ubuntu 6.06 works on an old Dell that I have but not on this Core 2 Duo.
[03:09:44] <cradek> yes I saw
[03:09:44] <jmkasunich> hopefully thats a pebkac
[03:09:54] <cradek> hard to say without any real information
[03:09:56] <jmkasunich> I sure want to use 6.06 on the new box
[03:10:14] <cradek> I've installed 6.06 on all variety of modern intel machines
[03:10:34] <cradek> maybe he has a video card problem or godknowswhat
[03:46:13] <cradek> well I should be getting to bed
[03:46:21] <cradek> thanks for bug hunting with me jmk
[03:46:47] <cradek> I'm pleased about the smp success now that the abort mystery is solved
[03:47:11] <jmkasunich> yeah
[03:47:17] <jmkasunich> you're welcome
[04:15:00] <jmkasunich> darn, I should have been ordering stuff instead of debugging
[04:15:09] <cradek> yeah, that sucks
[04:15:20] <jmkasunich> actually, I should have been ordering stuff instead of farting around trying to decide what to get
[04:15:59] <jmkasunich> any other online vendors you trust?
[04:16:28] <jmkasunich> http://www.antaresdigital.com/customer/product.php?productid=17250&cat=419&page=1
[04:16:35] <jmkasunich> they have it at the good price
[04:17:31] <cradek> I don't know, I haven't bought mail order for a long time
[04:17:47] <jmkasunich> I thought you even bought shoes mail order?
[04:17:58] <jmkasunich> or do you mean computer stuff?
[04:18:12] <cradek> yeah computer stuff
[04:18:44] <cradek> I get hand-me-downs or go to the local shop and buy whatever MB/processor/ram I can get for $350
[04:19:15] <jmkasunich> the local shop hasn't dropped their price yet
[04:19:29] <jmkasunich> I'll have to keep an eye on them, they might, since Intel is lowering prices
[04:19:36] <jmkasunich> right now they want $315
[04:19:56] <jmkasunich> plus tax
[04:20:04] <cradek> you could call and ask when they'll catch up with the rest of the world, because you'd rather buy from them (be sure to add that twist)
[04:20:37] <jmkasunich> I've been there a couple times in the last week, buying other stuff, and I've said that
[04:20:59] <jmkasunich> nobody there is authorized to lower prices tho, they gotta wait until the powers that be make that decision
[04:21:04] <jmkasunich> and I can't talk to the powers
[04:21:16] <cradek> not a small enough shop... :-/
[04:21:27] <cradek> my local shop isn't either
[04:21:27] <jmkasunich> nope
[04:21:34] <jmkasunich> small enough?
[04:21:38] <cradek> right
[04:22:02] <cradek> they have 3? stores and so there's a mothership somewhere coordinating everything
[04:22:27] <jmkasunich> the only really small shops we have around here are run by russians (we have a lot of immigrants from the fall of the iron curtain), and they prefer dumb customers with lots of money, not smart ones who shop around
[04:22:43] <jmkasunich> I went in one a couple times, and got disgusted by their attitudes
[04:23:13] <jmkasunich> microcenter is where I usually go
[04:23:28] <cradek> I better get myself asleep ... goodnight
[04:23:32] <jmkasunich> goodnight
[04:23:38] <jmkasunich> I should do the same
[14:21:49] <skunkworks> cradek: the proliant server was a pentium pro. the regulator says ct: 50107oawev274 then there is 2 numbers 225431-001 and DD-1350-1 Rev: 04
[14:21:57] <skunkworks> (older than I remember it.
[14:21:59] <skunkworks> )
[14:25:23] <cradek> ah, thanks for checking!
[14:25:41] <cradek> I have one of those from a Pro too, but I haven't plugged it in because I doubt they are compatible
[14:26:00] <skunkworks> cradek: what about dual core proccessors?
[14:26:37] <cradek> that would be great for testing too, but I don't have anything like that
[14:27:03] <skunkworks> I was wondering if the kernal would see them as 2 or more proccessors - they would?
[14:27:24] <cradek> yes
[14:27:35] <skunkworks> Cool
[14:28:40] <skunkworks> I saw you find the div/0 issue - I have a duel proccessor and I think dual core that I can test on when it gets to that point.
[14:29:33] <cradek> skunkworks: you could try it anytime - I think it works fine now
[14:30:09] <skunkworks> Really - cool - so I could get the latest csv and build it?
[14:30:32] <skunkworks> cvs..
[14:30:35] <cradek> yes
[14:30:45] <cradek> kernel and rtai packages at
http://www.linuxcnc.org/experimental/
[14:31:20] <cradek> get the 1.1 versions, there are also 1.0 there
[14:33:01] <cradek> forget what I said above - I deleted the bad ones
[14:33:06] <skunkworks> cradek: thanks - nice work.
[14:33:33] <skunkworks> I have a appointment today - so I may not get to it. But hopefully this week.
[14:33:45] <cradek> ok great
[14:34:01] <cradek> testing on various single-processor machines would be helpful too
[14:34:14] <cradek> whatever you have time for would help
[14:45:48] <skunkworks> cradek: stupid question - I need to install all three of those debs?
[14:45:58] <skunkworks> * skunkworks is still not a linux person
[14:46:21] <cradek> yes, image is the kernel for booting, rtai is ... rtai, and headers are needed for compiling emc
[14:46:46] <cradek> once they are installed you will have a new option on the boot menu when you reboot
[14:47:58] <skunkworks> Thanks
[14:48:05] <cradek> sure
[18:58:33] <skunkworks> Is elsons pulse generator the only one for emc at the moment? sans the mesa that jmk is working on.
[18:59:06] <skunkworks> ment that to be in #emc
[18:59:08] <alex_joni> is the pluto servo only?
[18:59:13] <skunkworks> yes
[18:59:18] <alex_joni> I think jeff looked at putting an stepgen in there too
[18:59:33] <skunkworks> Yes - he kinda decided it wasn't worth the trouble I think :)
[18:59:41] <alex_joni> good call
[19:00:06] <skunkworks> Hi alex
[19:00:28] <alex_joni> hi sam
[19:01:56] <skunkworks> then I probably answered this correctly
http://www.cnczone.com/forums/showthread.php?p=289307#post289307
[19:05:20] <alex_joni> yup
[19:06:11] <skunkworks> cradek: do you have some pictures of your lathe? (the servo one)
[19:06:37] <skunkworks> I am compiling the stuff for the ez servo page.
[19:06:57] <skunkworks> * skunkworks hopes alex_joni is still reading ;)
[19:07:41] <alex_joni> reading what?
[19:08:47] <skunkworks> I am getting a bunch of the info togather for the servo page - but didn't get much done this weekend. (I think it will be pretty cool if I do say so my self :)
[19:09:25] <alex_joni> cool
[19:09:31] <alex_joni> thanks for doing it
[19:10:10] <skunkworks> Still busy?
[19:10:21] <alex_joni> yeah..
[19:10:29] <alex_joni> and tired :/