Back
[01:30:16] <jmkasunich> hi guys
[01:30:26] <jmkasunich> cradek: thanks for fixing my bug
[01:30:36] <jmkasunich> I'll forgive you the inline declaration, this time
[01:40:49] <cradek> hi jmk
[01:41:21] <cradek> hmm, you read back, so we shouldn't talk about you when you're away
[01:44:27] <jmkasunich> lol
[01:44:42] <jmkasunich> you can talk about me when my IRC client is disconnected
[01:44:47] <jmkasunich> every 8 hours
[01:44:49] <cradek> it's impossible to tell when that is
[01:45:35] <jmkasunich> then I guess you have to whisper
[01:47:33] <jmkasunich> did you ever get your vise?
[01:47:39] <cradek> yes
[01:47:52] <jmkasunich> decent quality?
[01:47:57] <cradek> it's adequate but not great
[01:48:13] <cradek> it looks very nice, but when indicating the back I notice it's not quite flat
[01:48:29] <jmkasunich> what part isn't flat?
[01:48:35] <jmkasunich> the bed? the jaws?
[01:48:39] <cradek> the non-moving jaw
[01:49:00] <cradek> I didn't indicate anything else
[01:49:15] <jmkasunich> top of the jaw?
[01:49:36] <cradek> no, the jaw part of the jaw
[01:49:46] <cradek> the clamping part that you align to the machine
[01:50:11] <jmkasunich> * jmkasunich is having a visualization failure
[01:50:30] <jmkasunich> flat != parallel to base ?
[01:50:51] <cradek> no
[01:50:53] <cradek> flat = planar
[01:50:57] <jmkasunich> ah
[01:51:06] <cradek> the non-moving jaw is not planar
[01:51:19] <jmkasunich> bowed toward or away from the moving one?
[01:51:29] <cradek> toward
[01:51:47] <jmkasunich> bummer, if I had to have one or the other I'd rather have it the other way
[01:51:51] <jmkasunich> how much?
[01:52:25] <cradek> about .0015
[01:52:53] <cradek> it's mostly flat near the center, but near the ends it curves away
[01:52:57] <jmkasunich> its hardened I assume
[01:53:12] <cradek> yeah I'm sure it is.
[01:53:19] <cradek> when clamped tight, it might be fine
[01:53:25] <cradek> who knows, maybe it's on purpose
[01:53:36] <jmkasunich> doubt it
[01:53:43] <cradek> I've never seen a vise do that though, I've indicated them a lot of times
[01:54:04] <jmkasunich> its mostly flat, and curves on the ends, NOT a uniform curve?
[01:54:11] <cradek> right
[01:54:20] <jmkasunich> strange
[01:54:36] <jmkasunich> I stand corrected - in that case I'd rather have it curved the other way
[01:54:44] <jmkasunich> high edges you could lap down
[01:54:51] <cradek> it'll be just fine for me, it's about what I paid for I guess
[01:55:41] <jmkasunich> as long as you are aware of it you can deal with it
[01:55:45] <cradek> right
[01:55:54] <jmkasunich> still annoying tho
[01:56:01] <cradek> yeah I was surprised.
[01:56:09] <cradek> but ... $79?
[01:56:19] <cradek> not much money.
[01:56:25] <jmkasunich> + $80 shipping
[01:56:37] <cradek> yeah that's the problem. shipping for a better one would have been no more.
[01:56:45] <cradek> * cradek shrugs
[01:56:49] <jmkasunich> and shipping it back would be dumb
[01:56:53] <cradek> yep
[01:56:58] <jmkasunich> they probably count on that
[01:57:03] <cradek> no doubt
[01:57:21] <jmkasunich> you: this vise sucks, gimme my money back
[01:57:25] <jmkasunich> them: OK, just send it back
[01:57:42] <jmkasunich> you: hmm, $160 and no vise, or $159 and a bent vise
[01:58:00] <jmkasunich> you: never mind
[01:58:08] <cradek> yeah, tough call there.
[01:58:33] <cradek> it'll be fine really.
[22:40:12] <jepler> I am *amazed* how regular a waveform I get with a userspace python program:
[22:40:13] <jepler> while 1:
[22:40:13] <jepler> h.out = x
[22:40:13] <jepler> x = not x
[22:40:13] <jepler> time.sleep(.001)
[22:40:33] <jepler> hooked to the parport which is being written from a 50uS thread
[22:41:10] <jepler> of course the high/low times are more like 5ms than the requested 1ms but what's 4ms between friends?
[22:41:34] <jepler> on the other hand, with my scope triggering I can easily find that there are times it stays in one state longer
[22:42:40] <jepler> (being able to trigger on "signal present more than 10ms" is a novelty to me but I'm sure it's not to most of you)
[22:57:26] <SWPadnos> the 50 uS thread is what's giving you the apparent accuracy - it quantizes the timeing of the userspace writes to the signal
[22:57:35] <SWPadnos> timing
[22:58:29] <SWPadnos> the extra long pulses can be explained by clock skew as well - they may not be due to any major scheduling error
[23:03:08] <jepler> when it's long it's much more than 50uS too long
[23:03:15] <SWPadnos> ah, ok
[23:03:36] <jepler> e.g., 20ms
[23:03:57] <SWPadnos> oh - way longer than a HZ interval too
[23:04:09] <SWPadnos> jiffie - that's the name
[23:08:00] <SWPadnos> hmmm. what is HZ on that machine? I think the sleep() resolution is 1 jiffie
[23:11:52] <jepler> not sure how to find out
[23:12:02] <SWPadnos> damned good question
[23:12:09] <SWPadnos> I think it's in dmesg
[23:12:21] <SWPadnos> or it was when you booted ;)
[23:12:30] <jepler> don't see anything useful in /var/log/dmesg
[23:13:33] <jepler> /proc/sys/dev/rtc/max-user-freq is 1024
[23:15:56] <SWPadnos> that's the real-time clock interrupt, which I'm not sure is Hz
[23:16:04] <jepler> $ python -c 'import os; print os.sysconf("SC_CLK_TCK")'
[23:16:04] <jepler> 100
[23:16:10] <SWPadnos> heh
[23:16:39] <SWPadnos> I guess the python sleep doesn't use the OS sleep call, or I'm wrong about the resolution
[23:18:07] <jepler> select(0, NULL, NULL, NULL, {0, 1000}) = 0 (Timeout)
[23:18:11] <jepler> looks like it uses select
[23:18:39] <SWPadnos> interesting
[23:19:07] <SWPadnos> I thought the timeval had nanoeconds, not microseconds
[23:19:14] <SWPadnos> nanoseconds
[23:19:34] <jepler> select was designed back when the idea of a 1GHz CPU was crazy talk
[23:19:53] <jepler> microsecond was all the resolution you could ever hope for
[23:19:59] <SWPadnos> ah well. I'm up to my ears in Hz and settling times - can't keep it all in there at the same time :)
[23:20:03] <SWPadnos> heh
[23:20:20] <SWPadnos> it's pretty amazing what was done with very slow processors back in the day
[23:20:20] <jepler> well microsecond is still better than you can hope for from something running unix :-P
[23:20:26] <SWPadnos> :)
[23:20:57] <SWPadnos> a Core 2 duo T5600 gets pretty close to being able to get to the microsecond
[23:21:27] <SWPadnos> max latency for most samples was in the 200 ns range (with the other core loaded)
[23:21:27] <jepler> with interrupts
[23:21:34] <jepler> ?
[23:21:54] <jepler> I mean, based on a timer interrupt?
[23:22:09] <jepler> tempting to take the entire core and just busy wait for the next interval
[23:22:13] <SWPadnos> I did latency testing with a dual-core processor, and got latencies down in the sub-microsecond range, but only when there was a high CPU load on the otehr core :)
[23:22:19] <SWPadnos> yeah - I considered that
[23:22:31] <SWPadnos> use the TSC for extremely high precision
[23:22:31] <jepler> while(gettsc() < nexttime) {}
[23:22:40] <jepler> dinner time here .. or rather, time to make dinner
[23:22:41] <jepler> bbl
[23:23:11] <SWPadnos> see you
[23:32:43] <skunkworks> mmmmm pizza
[23:55:43] <jepler> ooh pizza would have been good
[23:55:47] <jepler> in fact I just had leftovers
[23:56:23] <jepler> slightly odd dish -- red beans with cornbread dumplings