Back
[19:40:38] <aystarik> guys, why you turn off whole ACPI?
[19:42:18] <jepler> aystarik: because we're not entirely sure which parts of ACPI hurt latency on some machines and which parts are fine on all machines.
[19:42:30] <cradek> because it's not clear exactly what needs to be turned off to make a kernel that works with acceptable realtime performance on all machines
[19:42:34] <cradek> hey, what he said
[19:43:18] <jepler> also none of us enjoys configuring and building kernels; it's a necessary hassle someone has to go through before we can use the software we really care about, emc2
[19:47:59] <micges> jepler: thanks
[20:01:52] <aystarik> well, if you don't enable ACPI you live machine in so-called legacy mode, where it provides most functions of ACPI (like thermal control) with SMI...
[20:02:35] <aystarik> And also you can't use LAPIC timer without ACPI telling you there it is.
[20:05:06] <aystarik> With enabled ACPI, LAPIC and disabled C1E, I was able to get latency down to ~2500 ns
[20:07:11] <jepler> interesting.
[20:07:45] <jepler> I'm not familiar with C1E. What is it?
[20:08:27] <jepler> ah, this was moderately enlightening:
http://lwn.net/Articles/286432/
[20:08:43] <aystarik> whis is so called enhanced idle state. Processor enters it then HALT instruction is issued.
[20:10:04] <aystarik> with C1E frequency and voltage of processor go down to lowest working value, as with cpufreq regulation. Thus waking up from it gives about 15ms of latency.
[20:12:41] <jepler> we know at least some of the systems we want to support have no LAPIC, and RTAI compiled for LAPIC doesn't work on no-LAPIC systems, so we can't change that for the time being.
[20:13:01] <jepler> (unless that's changed since rtai 3.3 days; I don't keep up on that kind of thing)
[20:13:09] <alex_joni> I don't think it has
[20:14:11] <jepler> and unless none of these changes modify kernel / rtai ABIs, we can't make them until we switch to a new distro anyway -- or at any rate, we haven't forced this kind of upgrade before now
[20:14:23] <jepler> (new distro version, that is)
[20:21:08] <aystarik> 10.04 you mean? :)
[20:21:22] <alex_joni> if that will be a LTS ;)
[20:23:37] <jepler> if a volunteer shows up an announces he wants to build kernel, rtai, and emc packages fur the lifetime of another ubuntu release, yes, we'll probably be on 8.04 until the next LTS comes out.
[20:24:41] <aystarik> and if no such person shows up, what happens?
[20:26:42] <jepler> then we ignore 8.10, 9.04, 9.10 like they don't exist
[20:27:30] <aystarik> how does it differ from "we'll probably be on 8.04 until the next LTS comes out"?
[20:31:56] <aystarik> btw, is it difficult to add support for Atheros gigabit network adapter? generic 8.04 kernel supports it, but in rtai it is left out. Configuring it in works without any problems?..
[20:33:40] <alex_joni> aystarik: do you know what module provides support for it?
[20:34:03] <aystarik> CONFIG_ATL1
[20:34:32] <alex_joni> and it's surely part ot he 8.04 generic kernel? not part of lum or lbm ?
[20:35:01] <aystarik> config.*generic has it in M.
[20:36:47] <aystarik> if I manually install only generic kernel into rtai distro, adapter is found. so it's distributed inside the generic kernel package
[20:37:03] <alex_joni> ok.. probably I forgot to include it :/
[20:37:43] <aystarik> it's new and defaults to =n. So it is easy to leave it out :)
[20:37:53] <alex_joni> ah, that might be a reason
[20:38:42] <alex_joni> did you manage to build it for 2.6.24-16-rtai ?
[20:38:49] <alex_joni> if not, I can send you the .ko probably
[20:39:55] <aystarik> no, I've settled with all custom kernel/rtai/emc, so it's not urgent or anything.
[20:40:15] <alex_joni> ah, even better ;)
[20:40:37] <alex_joni> I'll make a note to keep it in mind for when we'll build a new one :)
[20:42:10] <alex_joni> jepler: check latest message on the rtai mailing list ;)
[20:42:38] <alex_joni> guess that answers your question if the LAPIC configured but not available is still in 3.6
[20:42:57] <jepler> indeed
[20:43:22] <aystarik> what does it say? I'm not yet subscribed to rtai...
[20:44:03] <jepler> aystarik: basically what I said above: If you enable LAPIC in kernel configuration, rtai is not usable on machines without LAPIC (even though LAPIC is optional for the rest of linux)
[20:44:38] <jepler> http://mail.rtai.org/pipermail/rtai/2009-February/021063.html
[20:45:22] <jepler> unfortunately, it's much easier to make a kernel that runs on one machine than one that runs on almost all machines
[20:46:19] <aystarik> tell me :)
[20:46:21] <alex_joni> and unfortunately the one that runs on all machines (or most machines) isn't optimized for certain machines
[20:47:21] <aystarik> * aystarik is maintainer of ACPI EC/battery/AC in Linux
[20:47:28] <alex_joni> aystarik: cool
[20:47:42] <alex_joni> so you probably know a bit more about ACPI than we do ;)
[20:47:59] <cradek> yeah, maybe a bit
[20:52:22] <aystarik> yep, this is why I enabled it regardless of all warnings in wiki :)
[20:53:43] <jepler> make sure and drop in around feb/mar next year when we're trying to get emc2 working on the next lts .. we'll pick your brains
[20:54:10] <cradek> if there is a better mix we'd love to know what it is
[20:54:22] <cradek> the rtai help is not much help last I looked.
[20:55:12] <jepler> there tends to be more superstition than information
[20:55:30] <alex_joni> aystarik: if you feel the packages you built are helpfull, we can host/distribute them under linuxcnc.org/experimental/
[20:55:31] <jepler> and, yes, our wiki helps to spread it
[20:56:27] <aystarik> I've already added a note about C1E to it, this seems to be a worst offender, and it does not require kernel changes.
[20:59:47] <alex_joni> looks good
[21:00:49] <alex_joni> jepler: so .. any plans for the weekend?
[21:01:06] <alex_joni> 2.3.0~beta1 ?
[21:01:28] <jepler> alex_joni: is the tree ready? I haven't been in touch with development lately
[21:01:56] <jepler> I was saying to cradek that we need to work on instructions for users to switch among 2.2.x and 2.3beta ...
[21:02:27] <alex_joni> it's in pretty good shape I'd say
[21:03:16] <aystarik> jepler: I have a question about AXIS... Why you split arcs to segments before storing them? Is it better to split them at draw time?
[21:04:53] <jepler> aystarik: since the original AXIS did all the "drawing" of the preview plot in Python, the way to get good refresh rates was to put the whole preview plot in a single display list. this means I had to do a fixed subdivision of arcs when the list is built
[21:05:36] <jepler> aystarik: maybe today this could be revisited, because iirc the individial opengl calls done to draw the preview plot are mostly taking place in C++ (though it's traversing a Python list-of-lists or list-of-tuples to do it)
[21:05:45] <jepler> so basically: performance, simplicity, inertia
[21:07:35] <aystarik> ok. I was thinking that I may miss something :)
[21:09:57] <jepler> bbl
[21:28:18] <alex_joni> good night all
[21:44:30] <jepler> night alex_joni
[23:48:59] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py:
[23:48:59] <CIA-2> EMC: show correct cone position with backplot turned off (closes SF#2632523)
[23:48:59] <CIA-2> EMC: liveplotter is responsible for performing the translations that arise from
[23:48:59] <CIA-2> EMC: rotational axes, so the cone position has to come from the liveplotter at all
[23:48:59] <CIA-2> EMC: times. Provide a new way to do this, and then use it
[23:49:07] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/extensions/emcmodule.cc:
[23:49:07] <CIA-2> EMC: show correct cone position with backplot turned off (closes SF#2632523)
[23:49:07] <CIA-2> EMC: liveplotter is responsible for performing the translations that arise from
[23:49:08] <CIA-2> EMC: rotational axes, so the cone position has to come from the liveplotter at all
[23:49:10] <CIA-2> EMC: times. Provide a new way to do this, and then use it