Back
[02:28:27] <jepler> stupid regression tests
[02:28:42] <jepler> they successfully detected that stepgen has been changed in an inconsequential way :-P
[02:28:53] <jepler> ... when I eventually got around to running them again
[02:29:14] <jmkasunich> heh
[02:29:39] <jmkasunich> if I was ambitious, I'd automate the regression tests on the farm
[02:30:36] <jmkasunich> gad zoiks this is slow
[02:30:42] <jepler> what is?
[02:30:46] <jmkasunich> compiling
[02:30:53] <jmkasunich> while three vm's are doing the same thing
[02:31:00] <jepler> yeah ouch
[02:31:03] <cradek> that's where nice should help you
[02:31:06] <jepler> it is such a pain the way it re-links all the modules every time
[02:31:10] <cradek> unless you're thrashing...
[02:31:41] <jepler> I verified that the new stepgen output with step_type=2 (stepgen.1) still has the same number of transitions during the test, so I bet it's OK
[02:31:52] <cradek> what changed in stepgen?
[02:32:01] <jepler> I thought the initial condition was changed
[02:32:02] <jepler> is that not true?
[02:32:09] <cradek> I don't think anyone actually did that
[02:32:12] <jepler> oh!
[02:32:20] <jepler> I won't just check this in, then
[02:32:42] <jepler> you're right
[02:33:10] <jmkasunich> http://pastebin.ca/271191
[02:33:13] <jmkasunich> ;-(
[02:33:34] <cradek> not swapping - must be fine
[02:34:09] <jmkasunich> still slow as molasses
[02:35:45] <jepler> oh -- I still had a modified version of it in my local tree
[02:35:46] <jepler> (stepgen)
[02:36:01] <cradek> ah, good
[02:36:26] <jepler> Runtest: 1 tests run, 1 successful, 0 failed + 0 expected
[02:36:31] <jmkasunich> limit3 works now
[02:36:40] <cradek> jmkasunich: thank you
[02:36:40] <jmkasunich> gotta merge cradek's changes, then check it in
[02:36:45] <cradek> jmkasunich: don't forget to fix both trees
[02:38:26] <jmkasunich> thanks for the reminder
[02:38:58] <jepler> jmkasunich: with your change, does the limit3.1 test pass?
[02:39:18] <jepler> jmkasunich: (run ../../scripts/runtests in that directory to see)
[02:39:46] <jmkasunich> in which dir? src/hal/components?
[02:39:55] <jepler> in tests/limit3.1
[02:40:52] <jmkasunich> fialed
[02:40:54] <jmkasunich> failed
[02:40:57] <jepler> darn
[02:41:13] <jepler> is it wildly different, or just a little different?
[02:41:16] <jmkasunich> ls
[02:41:56] <jmkasunich> getting all zeros on the output
[02:42:12] <jepler> I'm not setting all the limits -- maybe it'll be fixed once you've merged cradek's changes
[02:42:22] <jmkasunich> thats probably it
[02:42:37] <jmkasunich> they're merged, rebuilding now
[02:48:37] <jmkasunich> I have the VMs configured with 128M of memory each - so why is each VM process using 200+ megs of ram?
[02:50:12] <jepler> probably there's other storage for each VM -- simulated video RAM is one thing that comes to mind
[02:50:33] <cradek> 128 is ram for the VM - you still have to run the emulator itself
[02:50:44] <jmkasunich> yeah, yeah
[02:50:47] <jmkasunich> it sucks
[02:51:06] <cradek> I'm surprised it causes you any trouble since they're at nice 5
[02:51:25] <jmkasunich> they're still sucking up ram that would otherwise be used for my make
[02:51:55] <cradek> right, and you have little cache between runs
[02:52:58] <jepler> I gave 224 megs to this client and the VIRT of the vmware-vmx is 334208
[02:53:12] <jmkasunich> the cpu percentage is mostly system stuff
[02:53:17] <jmkasunich> probably disk access
[02:54:24] <jmkasunich> seems like theres about 100M of overhead for each VM
[02:55:53] <jepler> you should just send all those VMs to me
[02:56:01] <jepler> my machine downstairs has 2 gigs ram
[02:56:03] <jepler> it spends a lot of time idle
[02:56:12] <jmkasunich> I'd be happy to
[02:57:02] <cradek> jepler: did you hear/see I made a vm of the cvs server?
[02:57:11] <jepler> cradek: no, I didn't/hadn't.
[02:57:20] <cradek> jepler: I figured that would be the easiest for disaster recovery
[02:57:28] <jepler> that's pretty cool actually
[02:58:06] <jepler> jmkasunich: if they bog down your machine too much it's certainly something I'm willing to look into
[02:58:09] <SWPLinux> excellent news about the CVS VM
[02:58:14] <cradek> I thought it was important that anyone could 'restore' it without using my tapes
[02:58:24] <cradek> oh didn't I tell anyone? :-)
[02:58:29] <SWPLinux> I think not ;)
[02:58:33] <jmkasunich> you told me
[02:58:38] <cradek> ah
[02:58:38] <SWPLinux> I thought not
[02:58:44] <cradek> I did it that night we were talking about it
[02:58:50] <SWPLinux> cool
[02:59:09] <SWPLinux> how can the data be backed up by mere mortals? (ie, people like me or whomever)
[02:59:38] <cradek> dinero:var.cvs.backup
[02:59:45] <cradek> (updated nightly)
[02:59:49] <SWPLinux> ah -ok
[03:00:36] <cradek> so if I'm hit by a bus, get the VM and install it, then sync the latest var.cvs.backup onto it
[03:00:44] <cradek> couldn't be easier
[03:00:56] <jepler> cradek: what did you do about the root password on the VM?
[03:00:58] <jmkasunich> what does "wa" mean in top? "96.3% wa"
[03:01:09] <jmkasunich> waiting?
[03:01:16] <jepler> I think it is time waiting
[03:01:17] <jepler> (e.g., for disk I/O)
[03:01:20] <cradek> jepler: if someone can't figure that out, he shouldn't be running an important server
[03:02:02] <jmkasunich> jepler: test passes now
[03:02:25] <jepler> cradek: ok then
[03:02:35] <cradek> jepler: don't you think?
[03:02:47] <jmkasunich> boot to single user mode?
[03:02:50] <cradek> jepler: I thought about that but any competent unixer should be able to set it on the VM
[03:02:52] <jepler> cradek: unless the boot menu spells it out I'd have to *gasp* search the intarweb
[03:03:00] <cradek> * cradek shrugs
[03:03:21] <SWPLinux> ah - in the emcboard home dir
[03:03:31] <cradek> yes
[03:04:16] <cradek> 58291856 -9223372036600549212 312518452 101% /home/.jared
[03:04:19] <jepler> cradek: it helps to know that the first step is supposed to be "now break in to the machine"
[03:04:26] <jepler> those are some interesting numbers
[03:04:26] <cradek> that doesn't seem quite right...
[03:04:38] <SWPLinux> heh
[03:05:23] <jepler> jmkasunich: it is comforting that the 'blocks' limit3 and the 'comp' limit3 now give identical output
[03:05:29] <cradek> jepler: other suggestions welcome...?
[03:05:38] <jmkasunich> jepler: at least for one test condition
[03:05:46] <jepler> jmkasunich: well yes
[03:06:24] <jepler> cradek: no, it's fine. anyway, we don't have a viable public transporation system in lincoln, so you're basically safe from the buses
[03:06:50] <cradek> a SUV?
[03:06:52] <jmkasunich> we're not worried about buses, cause you'll still be there (and so will the server)
[03:06:57] <jmkasunich> we're worried about comets
[03:07:06] <jepler> yeah those SUVs, the ones that swerve into things
[03:07:15] <cradek> veer off the road
[03:07:35] <jepler> oh yes, veer off the road, swerving into an unemployed mother of 3
[03:08:02] <cradek> swerving into AND driven by
[03:08:13] <jepler> twin unemployed mothers of 3 (6 total)?
[03:08:39] <cradek> whee, my sim spindle seems right now
[03:09:53] <cradek> I sure caused a flurry of activity with the 3 lines of hal I accomplished writing tonight
[03:10:06] <jmkasunich> sure did
[03:10:24] <jmkasunich> my PC is gonna expend several trillion cycles thanks to you
[03:10:28] <cradek> haha
[03:10:37] <cradek> wonder if any of the other "simple" comps are wrong
[03:10:44] <jepler> oh probably
[03:10:52] <jepler> we'll never know until somebody writes tests .. or at least tests them informally
[03:10:55] <cradek> I doubt anyone has gone through/tested them all
[03:11:11] <jmkasunich> top on the VMs says they spend most of their time waiting, probably for disk
[03:11:29] <jmkasunich> thats explains the huge percentage of time the host spends on "sys" stuff
[03:14:01] <jepler> eek
[03:14:15] <jmkasunich> ?
[03:14:42] <jepler> I'm doing another limit3 test
[03:14:46] <jepler> blocks and comp differ wildly
[03:14:53] <jmkasunich> crap
[03:14:54] <jepler> -- comp ends up at somewhere crazy, in fact
[03:15:02] <cradek> arg
[03:15:39] <jepler> http://pastebin.ca/271244
[03:15:50] <jmkasunich> I hear nothink!
[03:15:58] <jepler> blocks ends up at 160 just as it reaches sample 800
[03:16:04] <jepler> comp ends up at -274.248993
[03:16:15] <jmkasunich> hmm
[03:16:25] <jepler> in fact it spends its whole time going negative
[03:16:34] <jepler> let me make sure I have done my 'cvs up' and rebuild correctly
[03:16:34] <jmkasunich> serious bustage
[03:23:30] <jepler> data.old_out = lout;
[03:23:32] <jepler> out = lout;
[03:23:48] <jmkasunich> yeah
[03:24:03] <SWPadnos> what's 1out?
[03:24:18] <SWPadnos> or is that like "you lazy lout"?
[03:24:23] <jepler> "local out"
[03:24:30] <SWPadnos> ah :)
[03:24:30] <jepler> i.e., the copy of out in a local variable
[03:25:19] <jepler> that's not the only problem, or I didn't fix it right
[03:25:22] <jepler> but it looks funny to me
[03:26:44] <SWPLinux> it looks like it makes old_out redundant, sonce out is assigned at the end of the function
[03:26:57] <jmkasunich> old-out is the value that is being stored for the next run
[03:27:08] <jepler> data.old_out = out;
[03:27:09] <jmkasunich> lout is an automatic variable, and won't survive the run
[03:27:10] <jepler> I tried changing it to this
[03:27:29] <jmkasunich> changing it _back_ to that?
[03:27:36] <jmkasunich> (thats what I just fixed)
[03:27:40] <jepler> oh
[03:27:53] <jepler> clearly I don't understand this code
[03:28:02] <cradek> it was working right, but too slow, when I used it earlier today
[03:28:19] <jmkasunich> cradek: you had 1e20 for maxaccel
[03:28:27] <jepler> this test is with small maxaccel
[03:28:30] <jmkasunich> jepler used a smaller maxaccel and then it broke (right jeff?)
[03:28:30] <cradek> ohhh
[03:28:46] <cradek> but maxaccel worked too... I had that first
[03:29:32] <SWPLinux> you aren't adding or subtracting anything from tmp if it's within the limits of delta
[03:30:21] <jepler> tmp? are you looking at the blocks.c or limit3.comp? or something else?
[03:30:32] <SWPLinux> sorry - limit2.comp
[03:30:33] <jmkasunich> the version in blocks.c works, so the problem is something that changed when it was ported to .comp
[03:33:29] <SWPLinux> ah - the second call to clamp should be operating on the difference between in and out, not the old value +- maxdelta (I think)
[03:34:14] <SWPLinux> then the output is old_out + clamp (in-out, -maxdelta, +maxdelta) (plus some extra effort to deal with signs)
[03:34:39] <jmkasunich> you looking at limit2 or limit3?
[03:34:44] <jepler> he's looking at limit2
[03:34:45] <SWPLinux> limit2.comp
[03:34:48] <jepler> i'm talking about limit3
[03:34:51] <SWPLinux> ok
[03:35:22] <jmkasunich> limit2 is correct anyway
[03:36:24] <jmkasunich> the first call to clamp limits the range of the input, and stores that in tmp
[03:37:17] <jmkasunich> the second call says "go there now, unless 'there' is outside the range that you can reach in one period from where you are now"
[03:37:39] <SWPLinux> the second call says "don't change tmp unless it's outside that range"
[03:37:53] <SWPLinux> not "go directly there unless it's outside that range"
[03:38:04] <jmkasunich> ?
[03:38:31] <jmkasunich> no
[03:38:51] <SWPLinux> if in is between (old_out-maxdelta) and (old_out+maxdelta), then tmp will be unchanged after the call to clamp
[03:38:59] <jmkasunich> clamp says "return the first arg, as long as it is between the other two. if its outside, return the appropriate limit"
[03:39:08] <jmkasunich> exactly
[03:39:16] <jmkasunich> before the call, tmp is where you want to go
[03:39:25] <SWPLinux> ah - good point ;)
[03:39:42] <jmkasunich> if its between the old+delta and old-delta, then you can go there in (less than) one period, so do it
[03:40:03] <SWPLinux> I get it now - was trying to figure out where out got changed, but it's in that gets limited (duh)
[03:40:42] <SWPLinux> well - at least sometimes being brain-dead helps others to see what's happening
[03:40:51] <SWPLinux> not that this is one of those times
[03:40:59] <cradek> haha
[03:42:16] <jepler> night guys
[03:42:20] <jepler> I'm sure you'll figure it out without me
[03:42:24] <cradek> bye
[03:42:28] <SWPLinux> see you
[03:42:29] <jmkasunich> goodnight
[03:42:31] <cradek> how do you run the test?
[03:42:35] <SWPLinux> I'm sure it would be faster without me
[03:48:54] <SWPLinux> I'd like an editor to be able to easily diff two functions, either in the same file or in two loaded files
[03:55:43] <cradek> SWPLinux: I think you could do that with xemacs if you use narrowing
[03:56:09] <SWPLinux> hmmm - I'll just save small files and use xxdiff or kdiff ;)
[03:59:17] <SWPLinux> how is local data initialized with comp?
[03:59:43] <SWPLinux> (specifically, data in the limit3.comp file)
[04:00:16] <jmkasunich> you mean old _in, old_out, and old_v?
[04:00:22] <SWPLinux> yes
[04:00:29] <jmkasunich> darned good question
[04:00:44] <jmkasunich> got a hunch the answer is "it isn't"
[04:01:12] <SWPLinux> hmmm
[04:01:13] <jmkasunich> I think comp has hooks that let you run a function during init/export time
[04:02:55] <cradek> I bet it's EXTRA_SETUP()
[04:15:14] <SWPLinux> I can confirm that there's no initialization by default
[13:15:34] <jepler> option extra_setup; ... ;; EXTRA_SETUP() { ... }
[13:46:24] <jepler> the memory for 'data' is guaranteed to be all-zero-bytes, it's memset.
[13:46:31] <jepler> if you need other default values, then EXTRA_SETUP is the way to go
[13:46:51] <jepler> but the bug was another xxx vs lxxx
[17:45:41] <jepler> SWPadnos: jmkasunich: so were you guys serious about a "group buy" of the 5i20 card? If so, we only need to convince skunkworks and one other person to get one.
[17:46:06] <SWPadnos> I'm serious about it, and I think jmk was
[17:46:43] <cradek> what's the group price? I might do that.
[17:46:52] <SWPadnos> $159 each, I think
[17:47:28] <jepler> yeah it's $159 qty 5-24
[17:49:52] <SWPadnos> I already have one actually, but I wouldn't mind getting another to see what heppens with more than 1 in a PC (also for other projects)
[17:50:11] <jepler> did you ever use the one you had with emc2?
[17:51:23] <SWPadnos> I've done some testing, but I never went beyond hooking the scope up to a couple of pins
[17:52:02] <jepler> that's about what I'll do
[17:52:33] <SWPadnos> I had the idea of doing some custom FPGA stuff, but never spent te time to get my design package to generate code for it
[17:52:46] <SWPadnos> there's also the problem of getting file data into a kernel module
[17:52:58] <SWPadnos> do you program the pluto with the HAL driver?
[17:53:28] <jepler> yes, I convert the firmware into a char[] (it's about 20kB) and link that into the .ko
[17:53:37] <SWPadnos> ah - ok. not dynamic
[17:54:04] <SWPadnos> there should be some way of using the kernel firmware API to load configs
[17:54:29] <jepler> probably not for RIP - -I think hotplug assumes the firmwares are somewhere in /usr
[17:55:03] <SWPadnos> I'm not sure it's a hotplug-only thing - the Adaptec SCSI drivers also load sequencer code
[17:55:15] <SWPadnos> but they may compile it in
[17:57:38] <jepler> or "hotplug" may not be limited to devices that are actually hotplugged
[17:58:03] <jepler> for instance I think "hotplug" loads the firmware for my laptop's minipci wireless
[17:58:29] <SWPadnos> yep - I'm looking at "request_firmware", which is the kernel call to ask userspace for a firmware blob
[17:58:46] <SWPadnos> though it may have been superceded - I haven't gotten that far yet
[18:10:31] <SWPadnos> any idea why we can't use kernel file access like they do here:
http://sosdg.org/~coywolf/lxr/source/sound/sound_firmware.c#L9
[19:21:16] <jepler> maybe we could
[19:21:20] <jepler> I'm no kernel expert
[19:26:08] <SWPadnos> that could be useful for loading tool tables, screw comp, etc. as well
[19:26:53] <jepler> one concern is portability over different kernel version
[19:26:54] <jepler> s
[19:27:19] <jepler> for emc2.2 maybe we don't care
[19:27:25] <jepler> just require kernel 2.6 for drivers that need it
[19:27:29] <SWPadnos> all of the functions (filp_open, vfs_read) are likely to be in any kernel after 2.0 or so
[19:28:13] <SWPadnos> the kernel is what actually does file reading for userspace, so it has to have some way of getting information off the disk ...
[19:28:52] <SWPadnos> (I know you know that - I'm only pointing out that it has to be possible for kernel code to read files)
[19:31:57] <jepler> limit3.comp still isn't fixed
[19:32:05] <jepler> in fact, it's overshooting its maximum (by a small amount)
[19:32:42] <jepler> it goes to 160.000015 when the maximum is supposed to be 160.000000
[19:33:10] <SWPadnos> IIRC, the output limit is clamped first, then the delta and delta-delta are added in - is there a second clamp at the end?
[19:34:02] <SWPadnos> nevermind - I'm still in "clamp output" rather than "clamp input" mode
[19:34:24] <jepler> my incomplete analysis suggests that as it nears the end of the s-curve, it discovers it doesn't have quite enough acceleration to get the velocity back down to 0
[19:34:44] <jepler> so it obeys acceleration limits, but as a consequence it overshoots a small amount
[19:34:54] <SWPadnos> and there's no I to bring it back
[19:35:22] <jepler> actually it does settle at 160
[19:35:27] <jepler> but not before going past just a bit
[19:35:29] <SWPadnos> does it always overshoot by the same amount (proportional to max_a and max_v, I suspect)
[19:35:31] <SWPadnos> oh - ok
[19:36:02] <jepler> it's a very small amount -- the low 3 significant bits of the output
[19:36:23] <SWPadnos> you're probably right about the accel limit - it's probably granularity due to time quantization
[19:37:05] <SWPadnos> the decel is applied in the period after it becomes necessary, rather than at the beginning of the period in which it should start
[19:37:15] <SWPadnos> (I think)
[19:37:28] <jepler> but blocks limit3 doesn't behave in quite the same way -- it didn't overshoot
[19:37:34] <jepler> it's still different :(
[19:37:39] <SWPadnos> hmmm - odd
[19:37:44] <jepler> if it wasn't a new behavior I wouldn't worry about it quite so much
[19:38:11] <SWPadnos> are you comparing the output of comp to the blocks implementation?
[19:38:19] <SWPadnos> (when looking for differences)
[19:39:08] <jepler> when the first limit3 (but without accel limit set) problem showed up, I generated expected output with blocks and tested that limit3 gave the same result. after the first fix, the test passed
[19:39:21] <jepler> so, I think the answer to your question is "yes"
[19:39:35] <SWPadnos> actually, I was talking about the source code ;)
[19:39:48] <SWPadnos> objects/hal/components/limit3.c (or wherever)
[19:39:49] <jepler> you said something about output
[19:40:11] <SWPadnos> the output of comp, not the output of the .comp limit3 component
[19:40:20] <jepler> oh
[19:40:30] <jepler> no, I'm looking at the .comp source
[19:40:53] <jepler> after the ";;" it's just C with predefined macros, so I wouldn't learn much more by looking at the generated code
[19:41:23] <SWPadnos> ok. that's not true for me - I learned a lot by looking at the code, because I didn't write comp ;)
[19:42:02] <jepler> I hope it didn't turn your stomach too much
[19:42:34] <SWPadnos> no, it was fine
[19:43:07] <SWPadnos> I did wish for an editor feature to compare two functions (but not the possible emacs solution cradek pointed out)
[19:43:37] <jepler> I missed that (I'm not an emacs person though)
[19:45:07] <SWPadnos> me either, that's why I don't like his suggestion
[19:51:00] <jepler> I haven't spotted a difference in logic yet, so I'm tempted to attribute the difference to the compiler giving a slightly different sequence of operations since different stuff is in locals vs in structures
[19:51:58] <jepler> I hope that's not too much of a cop-out
[19:53:18] <SWPadnos> isn't the same data in locals vs. "persistent" data, but just using diferent variable names?
[19:57:48] <jepler> that's why it seems like a cop-out
[19:59:22] <SWPadnos> oh - in that case, yes - it does seem like too much of a cop-out
[20:01:19] <SWPadnos> not that it has to be fixed immediately, but it shouldn't be considered "solved" since there's an unknown difference
[20:04:04] <jepler> I'll probably ignore it unless I hear there's a way to get outrageously bad output from limit3
[20:04:37] <SWPadnos> that makes sense - the error seems to be within a very small margin (well below any reasonable following eror, for example)
[20:05:51] <jepler> it's floating-point, it's bound to be wrong in the least significant digits anyway
[20:06:08] <SWPadnos> yep, especially when it gets quantized in some way - like time
[20:54:40] <ve7it> ve7it is now known as LawrenceG
[23:28:47] <jmkasunich> jepler: O think I found the source of the small errors:
[23:28:59] <jmkasunich> blocks.c:
[23:28:59] <jmkasunich> double old_in;/* previous input */
[23:28:59] <jmkasunich> double old_out;/* previous output */
[23:28:59] <jmkasunich> double old_v;/* previous 1st derivative */
[23:29:08] <jmkasunich> limit3.comp:
[23:29:08] <jmkasunich> float old_in;/* previous input */
[23:29:08] <jmkasunich> float old_out;/* previous output */
[23:29:08] <jmkasunich> float old_v;/* previous 1st derivative */
[23:42:53] <jepler> that sure could be it
[23:43:36] <jmkasunich> I'll let you test, since you know what the errors look like
[23:43:42] <jmkasunich> (and since I'm lazy)
[23:44:36] <jepler> yep with that change, blocks and comp match
[23:47:02] <jmkasunich> cool
[23:47:30] <jmkasunich> although the I/O from limit3 is limited to float resolution, double for internals is a good thing
[23:47:45] <jepler> yep, agreed
[23:51:22] <jepler> I (or someone) should write tests for all the .comps