Back
[01:22:25] <ries> hey guys, I am looking in axis and I see for example a like like : positions = s.position
[01:22:36] <ries> my question is, what is s and where does it get initialised?
[01:25:33] <ries> think I found it s= emc.stat()
[05:46:20] <CIA-2> EMC: 03cmorley 07master * rafaf4c21f876 10/src/hal/components/mux16.comp: remove DOS endings from mux16
[07:35:24] <ries_> ries_ is now known as ries
[09:36:54] <micges_work> alex_joni: around?
[10:03:40] <alex_joni> micges_work: sorry, not really available today :/
[10:03:51] <micges_work> ok no problem
[10:42:30] <CIA-2> EMC: 03micges 07master * r155a863d5b94 10/src/emc/usr_intf/halui.cc: Send MV FO and SO override nml messages only if hal pins was changed
[10:44:11] <JT-Dev> micges_work: thanks
[10:46:30] <micges_work> sure
[10:49:47] <micges_work> we're still supporting % as file ending?
[11:55:34] <jepler> micges_work: no plans to remove that functionality. is it causing a new problem?
[12:07:13] <micges_work> yes
[12:07:45] <micges_work> on master load file with % at begin and end and try touch off
[12:08:14] <micges_work> touch off window will show 'can't open file'
[12:08:28] <micges_work> on 2.4.0 also
[12:12:39] <cliffb> What do you guys think?
http://www.powerautomation.net/mainpage/CNC-Automation/drag-drop.html
[13:27:45] <alex_joni> cliffb: cool, but source is missing..
[14:51:58] <SWPadnos> hmmm. If I run a program that does some motion and then changes a parameter value, and I pause or abort it during motion (and before the variable changing line has been "executed"), what will the variable value be?
[14:52:05] <SWPadnos> I wonder if that made sense
[14:52:58] <cradek> if the interpreter had read ahead to that point, it will be the new value
[14:53:08] <SWPadnos> I wonder if that's a bug
[14:53:49] <cradek> I don't know, but I suspect that way lies madness
[14:54:03] <SWPadnos> it may be maddening, but I still wonder if it's a bug :)
[14:54:44] <SWPadnos> it gets back to checkpointing or saving interpreter state when there are changes
[14:55:07] <cradek> you can ask the same question about g10, g92, g20/g21, g90/g91, maybe more I haven't thought of - and the answer is the same: if it got that far, the code was executed
[14:55:22] <SWPadnos> yeah, I guess so
[14:55:30] <SWPadnos> and I wonder if those are bugs too
[14:55:35] <cradek> (that's what I meant by madness)
[14:56:06] <SWPadnos> the main reason I wonder is because there's an obvious indicator of where in the program the machine is (motion and the hilighted G-code line)
[14:56:21] <cradek> oh I certainly understand why you ask :-)
[14:56:30] <SWPadnos> but there's a non-obvious, implementation-specific place where the interpreter is
[14:56:32] <SWPadnos> yeah
[14:57:02] <cradek> a gui could show that too, but it would just be baffling
[14:57:26] <SWPadnos> yes
[14:57:54] <SWPadnos> I guess the implementation of EMC{2} just has this dichotomy, which is why I think it could be considered a bug
[14:58:31] <SWPadnos> if you pause or stop somewhere, you could rightfully expect that the program will be the same when you re-start, regardless of which interpreter/language features you use
[14:58:54] <SWPadnos> but it won't be if you've used variables, G92 ...
[14:58:58] <cradek> we should make a list of all our fundamental/architectural problems, and see if there is a coherent new design that solves them all. if so, maybe we should work on that.
[14:59:11] <SWPadnos> yes, that would be excellent
[14:59:29] <cradek> and meanwhile, try to keep from crying
[14:59:44] <SWPadnos> well, we do that in the privacy of our homes (or offices) :)
[15:00:12] <cradek> any disconnection/queueing causes architectural headaches
[15:00:27] <SWPadnos> that's true
[15:00:30] <cradek> but we seemingly can't just interpret in lock step
[15:01:05] <SWPadnos> but it's also possible to plop interpreter state into a queue as well (most of it is in a C++ object, which can be dumped into a container class)
[15:01:17] <cradek> or I dunno. maybe we could interpret in realtime. the thing we'd queue from userland would be gcode. you could throw it out willy-nilly and ask userland to start feeding you from somewhere else whenever you want.
[15:01:23] <SWPadnos> and then the problem is popping both states at the right time
[15:01:46] <SWPadnos> that is probably possible with modern-ish CPU speeds
[15:02:20] <cradek> I have no idea but it's one possible architecture to investigate
[15:02:26] <SWPadnos> or limit the queue length to something silly small, to minimize the number of checkpoints
[15:03:36] <cradek> other architectural problems: user edits the tool table while the program is running, and honor the latest diameter at any new g41/g42 and honor the latest lengths at any new motion
[15:04:00] <cradek> you just can't read ahead much if you want to do anything like that
[15:05:14] <cradek> what the operator really wants is a machine that acts like NC. the gcode is linear and you when you stop your state is like it was right where you stopped. if you change anything, it happens right away.
[15:05:22] <SWPadnos> well, G41/42 become queue flushers
[15:05:35] <SWPadnos> yeah, that's a point that seems to have been lost
[15:06:07] <SWPadnos> "my turing machine could pause and resume, so why can't your multi-processing queueing architecture do the same thing?"
[15:06:48] <cradek> NC would read and interpret a move - execute the move - read and interpret the next move - execute that move
[15:07:32] <cradek> if you single blocked it, it would stop before executing. you could even edit the move and then execute it. no queues - everything is exactly what it seems
[15:07:38] <SWPadnos> I imagine there were a lot fewer variables to deal with, ie no X [COS[#37]]
[15:07:48] <SWPadnos> yep
[15:08:55] <cradek> I want to do this at workshop :-)
[15:09:08] <SWPadnos> me too :(
[15:09:20] <cradek> make up our "but damn that's hard with this architecture" list and see if it leads us anywhere
[15:09:21] <SWPadnos> I'll see if I can be there for the first couple of days
[15:10:12] <SWPadnos> are you (or anyone else you know) getting there early?
[15:10:34] <SWPadnos> I have to leave on the 23rd at the latest, dunno what time of day
[15:10:35] <cradek> I think jeff and I will be in or near cleveland by friday night
[15:10:42] <SWPadnos> oh, cool
[15:10:51] <SWPadnos> maybe a mini-meet at John's place :)
[15:11:01] <SWPadnos> (or nearby)
[15:11:03] <cradek> that would be cool
[15:11:26] <SWPadnos> that's actually most of my interest in going - the workshop itself isn't a big draw for me this year
[15:11:39] <cradek> I think we might in in Lima OH on friday, but definitely in Cleveland OH weekend and monday
[15:12:13] <mozmck_work> Machine here at work seems to boot fine with grub-legacy...
[15:12:17] <cradek> it'd be fun to go back to stuart's later in the year, but I think jeff is out of vacation for a while
[15:12:24] <cradek> mozmck_work: yay!
[15:13:00] <cradek> mozmck_work: does that mean you are maybe close to rolling a test cd?
[15:13:02] <mozmck_work> :) I should be getting a 6-core computer tonight (pieces and parts I'll put together).
[15:13:11] <cradek> woohoo
[15:13:16] <mozmck_work> Yes, I plan on doing that as soon as possible now.
[15:13:20] <cradek> neato
[15:13:22] <SWPadnos> d00d! :)
[15:14:06] <cradek> mozmck_work: sorry 9 other people didn't pipe up to help you buy the machine
[15:14:19] <mozmck_work> Fry's has a combo deal with a biostar mobo based on 890FX chipset and a 1055t (2.8 gz) 6-core chip for $250. Better price than even a quad core and board!
[15:14:50] <mozmck_work> oh, no problem. any help I get is appreciated, and none at all is fine!
[15:15:41] <cradek> wow
[15:16:21] <mozmck_work> I'm hoping to test latency results with various kernel settings to see what gives the best results.
[15:18:16] <mozmck_work> One thought I've had is to hopefully keep the kernel updated for 10.04 as they release new kernels - and the livecd as well. That way maybe we can avoid the problem some had with 8.04 where the livecd wouldn't boot on some machines because it was older. They could install a newer version of 8.04 and then EMC2 but couldn't install from the livecd.
[15:18:22] <SWPadnos> huh. the 890FX is a great chipset. is that special still going on?
[15:18:29] <SWPadnos> (and do you have to go in person to get it?)
[15:18:37] <mozmck_work> 'till 5-20 I believe!
[15:18:50] <mozmck_work> I think so.
[15:18:52] <SWPadnos> huh. have to check that online
[15:18:54] <SWPadnos> bummer
[15:19:09] <SWPadnos> maybe I should visit my sister in Galveston (with a stop along the way) ?)
[15:19:11] <SWPadnos> :)
[15:19:55] <mozmck_work> :) They have 3 stores in the Dallas area. It's a limit of 1 per household :(
[15:20:08] <SWPadnos> I'd be buying for 3 households ;)
[15:20:45] <mozmck_work> http://www.frys.com/product/6257640?site=sr:SEARCH:MAIN_RSLT_PG
[15:22:58] <mozmck_work> no USB3 on that board but that doesn't bother me. especially for that price.
[15:23:19] <SWPadnos> oh hmm. that could be a deal breaker for me
[15:23:40] <SWPadnos> it has firewire and SATA3, which is nice
[15:24:57] <mozmck_work> yeah. I figure I can use and addon card for USB3 if I ever need it.
[15:25:47] <SWPadnos> that's true
[15:26:36] <Al_Smt> I was wondering if I was going to try adding a single block pin to halui what would be the best way of doing so ,could I just set the step bit?
[15:31:07] <cradek> the pin is already there: halui.program.pause
[15:31:11] <Al_Smt> I would like it finish the line a wait and go into step mode being able to use a single run button then when single block is off go back to run
[15:32:00] <cradek> that's not a thing you can do in halui, because that's not how it works underneath
[15:33:54] <Al_Smt> why can't I just get to step with out pausing
[15:34:34] <cradek> just because that's not the current behavior
[15:35:10] <cradek> it's not a ui issue, it's a matter of how pause works
[15:35:28] <cradek> you'd have to make a new kind of pause that waits until the move is over
[15:36:01] <Al_Smt> what about M01
[15:36:26] <cradek> what do you mean?
[15:37:00] <Al_Smt> could u set the flag for m1
[15:38:07] <SWPadnos> M1 is optional stop, and there is already a HAL pin for that (in the motion controller)
[15:38:20] <SWPadnos> IIRC
[15:38:36] <Al_Smt> but it has to be called from the program
[15:38:38] <cradek> you can turn on optional stop with halui.program.optional-stop.on
[15:38:54] <cradek> yes if you turn it on, your next M1 will stop
[15:38:55] <SWPadnos> oh hmm. IDRC
[15:39:02] <SWPadnos> (I don't remember correctly) :)
[15:39:56] <Al_Smt> you would need a m1 on every line to be able stop anywhere
[15:40:36] <SWPadnos> Doesn't AXIS automagically send a pause / step or something, if step is hit while the program is running?
[15:40:38] <cradek> yes, and you wouldn't get any blending if you did that
[15:41:48] <Al_Smt> it does go to step but not that line maybe 3 line ?
[15:46:22] <Al_Smt> you mentioned a new pause that could work how could I make it finish the line first?
[15:47:13] <Al_Smt> point me in the right direction could ya
[15:48:30] <cradek> you would have to add handling for that kind of pause in the motion controller, then add the ability to ask for it through the layers of nml, then fix the user interfaces to do it (including coming up with a sane way to explain/represent the two different kinds of pauses to the user in the UIs)
[15:52:03] <Al_Smt> thanks
[16:07:06] <CIA-2> EMC: 03jthornton 07v2.4_branch * r67a462bd47da 10/docs/src/config/ini_config.lyx: expand a bit on machine units
[17:09:10] <mozmck> SWPadnos: is there much advantage that you know of the 890FX over the 890GX?
[17:11:52] <SWPadnos> I don't know of any major differences, other than the integrated graphics
[17:12:29] <SWPadnos> there are probably fewer PCIe lanes on the GX
[17:14:54] <alex_joni> mozmck: following rtai mailing list?
[17:18:48] <mozmck> SWPadnos: thanks. I don't know what the PCIe lanes would gain me.
[17:18:54] <alex_joni> mozmck:
http://linux3.dti.supsi.ch/~bucher/kernel/config-2.6.32.11-ipipe
[17:19:04] <mozmck> alex_joni: I have been, yes.
[17:19:06] <SWPadnos> not much, unless you want to use several fast video cards at the same time
[17:19:18] <alex_joni> that guy also reports using grub1
[17:20:10] <mozmck> hadn't looked this morning yet though. Thanks!
[17:21:31] <mozmck> aha, the low-latency option is one that I have been selecting, although I have tried without it once as well.
[17:21:42] <alex_joni> hope you don't mind my message
[17:22:09] <mozmck> That is something that was supposed to work now with rtai but maybe it's still buggy.
[17:22:33] <SWPadnos> is "low-latency" the one that makes the CPU busy-wait for a bit to get the exact programmed interval?
[17:23:09] <mozmck> CONFIG_PREEMPT, no, it's a preemptible kernel.
[17:23:22] <mozmck> alex_joni: of course not!
[17:24:11] <mozmck> SWPadnos: at least I don't think it does that :) I may be showing more ignorance (I have too much to be able to hide it well...)
[17:24:29] <SWPadnos> there is an option for that, but I don't know what it's called
[17:24:53] <SWPadnos> I don't think we've ever used it, but on modern (fast) CPUs, especially with SMP, it may be a good thing to try (eventually)
[17:25:39] <mozmck> CONFIG_PREEMPT_NONE, CONFIG_PREEMPT_VOLUNTARY, CONFIG_PREEMPT
[17:25:49] <mozmck> those are the options.
[17:25:58] <SWPadnos> it's not a preempt-related option :)
[17:26:31] <SWPadnos> and for that one, you want CONFIG_PREEMPT, I'm pretty sure
[17:26:35] <mozmck> The description for CONFIG_PREEMPT is (Low-Latency Desktop.)
[17:26:48] <SWPadnos> yeah, that's different
[17:26:56] <SWPadnos> I'm talking about an RTAI option
[17:27:03] <SWPadnos> not a normal kernel option
[17:27:30] <mozmck> That's what I've been using, as there were indications that it could give been latency, but it sounds' like it may be causing boot problems.
[17:27:48] <mozmck> Ah, I see. I don't know about that option.
[17:28:03] <SWPadnos> yeah - don't listen to me, I'm not actually helping with the boot problem :)
[17:28:35] <mozmck> :)
[18:03:22] <jepler> hi andypugh
[18:16:42] <jepler> on a different subject, what can we do to make it easier for users to load rtai_smi? The wiki recommends editing rtapi.conf:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?FixingSMIIssues
[18:17:09] <jepler> rtai_smi doesn't depend on anything else; it seems like a modprobe in /etc/rc.local would be just as good
[18:17:31] <alex_joni> it's still better to load it only when you need emc2
[18:17:39] <alex_joni> thermal issues and whatnot
[18:17:48] <alex_joni> but I guess that's up to who uses it
[18:17:53] <jepler> If you think your computer will melt with smi loaded, you'd better *never* load it.
[18:18:39] <alex_joni> that's also true
[18:19:09] <alex_joni> not sure how up-to-date rtai_smi is
[18:19:14] <jepler> me either
[18:19:16] <alex_joni> with newer chipsets
[18:19:30] <mozmck_work> Maybe there could be a script someone can run to enable/disable the rtai_smi module, that would just change rtai.conf?
[18:19:30] <aystarik> works for me on G31
[18:19:44] <alex_joni> I saw some messages from mantegazza telling users to just edit the module add their chipse and recompile
[18:19:54] <alex_joni> mozmck: sudo setsmi :D
[18:20:32] <mozmck_work> alex_joni: except that doesn't work with the way our rtai packages install rtai.
[18:20:44] <mozmck_work> setsmi is not in the path.
[18:21:33] <jepler> which is the "right" way for new systems, rtai_smi or setsmi?
[18:21:59] <jepler> (I'm not familiar with either and have never used a system that required it)
[18:22:37] <mozmck_work> I think setsmi just does an insmod, and the module is then loaded even if no other rtai stuff is loaded.
[18:22:57] <mozmck_work> (I just did it the other day but I may be forgetting something)
[18:23:23] <jepler> yes, it looks that way
[18:23:40] <andypugh> I need smi, and have had bother making sure it is installed in the past. With an install and a RIP and a git pull and a dev... I ended up putting a line in the rtapi.conf scripts so that they would tell me which one they were so I knew I was editing the right one.
[18:24:31] <andypugh> And any time you make-clean the rapi.conf gets created fresh and new. Granted most folk don't do that very often.
[18:25:32] <jepler> you want to be our guinea pig? put /usr/realtime-2.6.24-16-rtai/bin/setsmi (assuming you're using our realtime packages on hardy) in /etc/rc.local on a line of its own and try without unmodified rtapi.conf
[18:26:38] <andypugh> OK, I can do that pretty much immediately, I only came in for the micrometer.
[18:27:14] <jepler> don't let me interrupt any real work
[18:28:15] <andypugh> Real work involves driving cars. Machining is recreation. I have heard that some wierdos have them the wrong way round.
[18:29:54] <micges> jepler: did you have any chance to look at % bug?
[18:30:21] <cradek> micges: we already fixed that at least once
[18:30:31] <cradek> (I didn't try it again...)
[18:30:47] <jepler> which % bug?
[18:31:08] <cradek> 07:07 < micges_wo> on master load file with % at begin and end and try touch off
[18:31:17] <micges> yes
[18:31:51] <micges> I know that long time ago some % endings bug was fixed, this is new
[18:33:08] <jepler> is it in 2.4?
[18:33:47] <micges> yes
[18:34:50] <micges> yesterday user on #emc found it
[18:34:50] <cradek> was it possibly bfb333f1 aka
http://sourceforge.net/tracker/?func=detail&aid=1734309&group_id=6744&atid=106744
[18:35:30] <cradek> nope it was 319bc0f02a9
[18:42:20] <andypugh_garage> No luck on the setsmi but I don't have an "installed" version now I loo
[18:43:15] <andypugh_garage> andypugh@CNC:~$ /usr/realtime/bin/setsmi
[18:43:15] <andypugh_garage> /usr/realtime/bin/setsmi: 6: rtai-config: not found
[18:43:15] <andypugh_garage> cannot find rtai-config (hint: make sure it's in the path; usual location: $PREFIX/bin)
[18:43:34] <andypugh_garage> So inconclusive
[18:43:46] <jepler> ah, I see now what mozmck_work meant about not working the way our rtai package installs
[18:43:55] <jepler> * jepler grumbles
[18:43:57] <jepler> I hate software
[18:43:58] <jepler> thanks
[18:44:03] <alex_joni> heh
[18:44:54] <andypugh_garage> Well, this is a custom patched kernel. by a noob. I would be astonised if it was typical.
[18:45:44] <jepler> no, I bet it's the same general failure as you'd see on the hardy setup
[18:47:18] <cradek> sadly, that reproduces here
[18:47:44] <jepler> http://emergent.unpy.net/files/sandbox/0001-fix-touch-off-when-loaded-program-uses.patch
[18:48:11] <jepler> it's nice to detect the "missing % at end" problem, but I am happy to skip over that code instead of erroring
[18:48:35] <mozmck_work> yes, I had to add /usr/realtime-xx.xx.xx/bin to my path to get setsmi to work.
[18:50:42] <mozmck_work> I would think a simple script called 'enable-smi' or something that just edited rtapi.conf would be easy enough (for someone who knows/remembers all sed/regex etc)
[18:51:16] <jepler> except for the way that each update of emc will want to reinstall the shipped version
[18:51:36] <jepler> that file was not designed to be edited; if we want something configurable after installation, then we need to redesign it
[18:51:46] <mozmck_work> hmmm.
[18:52:22] <andypugh_garage> Was that messed-up touch-off with a % in the file issue reproducible?
[18:52:38] <cradek> um, read up six lines or so
[18:52:45] <alex_joni> mozmck_work: about 3-4 more messages that grub 0.97 works and newer grub's don't
[18:54:08] <andypugh_garage> That was what reminded me. But the problem was when there _was_ a % at the beginning?
[18:55:38] <jepler> andypugh_garage: I tested on a file that had % ; G0 ... ; G1 ...; % (4 lines)
[18:56:39] <mozmck_work> alex_joni: that's good to know. I'm going to try recompiling without CONFIG_PREEMPT and see how that does with grub2
[18:56:40] <micges> jepler: your patch fixes % bug
[18:56:54] <jepler> micges: thanks for testing it
[18:57:00] <jepler> now let's play "try to imagine what else it breaks" :-/
[18:57:19] <micges> I'm working on it
[18:57:45] <mozmck_work> If it's not great (doesn't boot reliably on various systems) I'll probably just try to use grub 0.97 on the livecd.
[18:58:10] <mozmck_work> That was one kernel setting I wanted to play with and see how it affected latencies anyhow.
[18:58:30] <jepler> I wonder what the real explanation of this boot problem is; I doubt it's as simple as being a grub2 bug
[19:00:04] <mozmck_work> I doubt so as well since the ubuntu kernel boots fine with it.
[19:02:46] <micges> jepler: lets hope that removed check was redundant
[19:03:09] <SWPadnos> it wasn't removed, it was moved into the conditional just above
[19:03:16] <mozmck_work> I need to dig into grub2 a little more and see exactly what it is doing on startup. I still have a feeling it's related to kms.
[19:03:24] <jepler> it was changed from "error when this happens" to "just skip searching for the terminating % when this happens"
[19:03:52] <micges> messy code
[19:04:04] <SWPadnos> s/messy/normal/ :)
[19:04:46] <jepler> here's someone without rtai (probably) who says grub2 gives him a blank screen:
http://www.pubbs.net/201001/archlinux/1610-arch-general-video-resolution-grub2-and-kernel-2632.html
[19:05:17] <SWPadnos> I got a blank screen with grub2, when I upgraded a 9.10 install to 10.04 beta
[19:05:26] <SWPadnos> the same machine worked great with a fresh install
[19:05:52] <SWPadnos> (I don't remember if the update process actually replaces grub, there was some discussion of that on the Ubuntu site)
[19:06:49] <mozmck_work> Grub2 has had some blank screen booting problems. I looked at some of the bug reports for it.
[19:07:12] <mozmck_work> I had some problems with 9.10 using grub2 even with stock ubuntu kernels.
[19:07:12] <jepler> mozmck_work: are you using vanilla kernel + rtai patches, or ubuntu kernel + rtai patches?
[19:07:28] <mozmck_work> ubuntu kernel + rtai patches.
[19:07:31] <jepler> (if you say ubuntu+rtai, don't worry, I won't tell the rtai guy:)
[19:08:12] <mozmck_work> In 9.10 I did both, because I was having the same booting problems (and other people trying my kernel were as well).
[19:08:27] <jepler> 9.10 is also grub2?
[19:08:34] <mozmck_work> vanilla kernel didn't help any, and others on the rtai list are using vanilla with the same problems.
[19:08:42] <mozmck_work> I think so...
[19:09:00] <jepler> oh, yeah, I know it is.
[19:09:01] <mozmck_work> wait, I know so.
[19:09:28] <mozmck_work> yeah, I was looking for my menu.lst and trying to figure out what was going on!
[19:12:09] <mozmck_work> interesting, the link you sent is mentioning the video resolution. This would seem to lend support to my feeling that kms or maybe the framebuffer is related to the problem.
[19:12:41] <SWPadnos> plymouth?
[19:12:53] <SWPadnos> the flashy splashy boot thingy
[19:13:21] <mozmck_work> heh, I thought of that, but if you try to uninstall it on 10.04 it uninstalls nearly everything.
[19:13:30] <mozmck_work> mountall depends on it.
[19:13:33] <SWPadnos> yeah, the OS depends on it apparently
[19:13:58] <SWPadnos> you could try starting with the server version of Ubuntu, then add X and stuff
[19:14:50] <mozmck_work> downgrading grub sounds easier :)
[19:15:13] <SWPadnos> sure could be :)
[19:17:03] <mozmck_work> I wish shuttleworth had applied his "less is more" to stuff like plymouth instead of the actual user interface!
[19:18:01] <mozmck_work> pretty soon we'll be down to a black screen with a button in the middle that says "Do it" and the computer will try and figure out what you want...
[19:18:40] <mozmck_work> not that I don't like a simple intuitive interface...
[19:20:17] <SWPadnos> you can get that already, with a mac!
[19:21:48] <cradek> mac & cheese
[19:21:55] <mozmck_work> blech, I like linux
[19:22:19] <SWPadnos> damn "The Onion" video doesn't seem to be working
[19:22:36] <SWPadnos> their "macbook wheel" thing would be so apropos right now :)
[19:22:59] <SWPadnos> ah, this seems to work:
http://www.youtube.com/watch?v=9BnLbv6QYcA
[19:29:06] <mozmck_work> heh, no sound here, but that looks funny.
[19:31:01] <SWPadnos> it sure is :)
[19:31:18] <SWPadnos> "basically if it's shiny and has the Apple logo on it, I'll buy it"
[19:33:39] <cradek> I love the sentence predictions
[19:33:54] <SWPadnos> yeah
[19:33:59] <SWPadnos> lots of stuff about aardvarks
[19:34:02] <SWPadnos> very common
[19:34:23] <cradek> well he typed "the a" before giving up
[19:34:35] <SWPadnos> yep
[19:35:05] <SWPadnos> and the "list of all files on your hard drive" - also alphabetical (but without full paths) - was a nice touch
[19:36:00] <SWPadnos> if you decide to keep wasting^Wspending time there, look for their "money hole" one
[19:39:21] <andypugh> If it's shiny and has an Apple logo on it then I _will_ buy it.
[19:44:01] <mozmck_work> SWPadnos: I placed an order on that combo from Frys, but I noticed they have a combo with an MSI with 890GX chipset and USB3 for $25 less.
[19:44:35] <mozmck_work> Do you think the MSI would be a better motherboard than the Biostar with the 890FX chipset?
[19:50:33] <SWPadnos> I don't know. I have had bad luck with MSI and good luck with Biostar in the past, but it was long enough ago that I don't know the relative quality levels now
[19:51:12] <SWPadnos> the GX has integrated graphics (most likely with "sideport" memory, so it shouldn't affect latency), the FX will be more performance optimized, by at most a couple of percent
[19:52:06] <SWPadnos> it would be interesting to see how the integrated graphics affect latency, so in that respect the GX is better for research purposes
[19:52:11] <SWPadnos> clear as mud? :)
[19:52:13] <mozmck_work> Ok, thanks. I'll probably stick with the Biostar. I have an Nvidia card I can put in.
[19:52:13] <SWPadnos> gotta run. bbl
[19:52:27] <mozmck_work> No, Just makes my decision harder :)
[21:19:27] <jepler> snippet from a flamewar on the use of rdtsc in application code:
http://pastebin.com/UYTXDHiS
[21:19:45] <jepler> so maybe "unexpected realtime delay" due to smi will go away -- because the smi mode fudges the tsc to hide it. yay?
[21:20:29] <jepler> http://mid.gmane.org/alpine.LFD.2.00.1005152323070.3199@localhost.localdomain
[21:22:28] <SWPadnos> huh
[21:35:58] <SWPadnos> we only need to read the TSC in the kernel, so some of that post isn't relevant to us
[21:36:15] <jepler> yes, most of it's not
[21:36:42] <jepler> but smi fiddling tsc is particularly troubling, as we rely on tsc for detecting some realtime problems
[21:37:03] <jepler> we now rely to a greater extent on rtai to report them; no idea what rt_task_wait_period is doing behind the scenes to detect missed periods, though.