we're getting pizza ;-)
new emc2, emc2-dev, axis (1.2a2) packages in the breezy repository
ok - back
well, on my laptop with BDI 4.2x (kernel 2.6.9-adeos), I can run BDI at 24 uS PERIOD, and there's no slowdown in the GUI.
Running EMC2 with stepgen at BASE_PERIOD=50 uS, the machine is basically unusable, though it doesn't quite crash
I can see individual lines of text in konsole being drawn in parts, desktop icon lables are drawn as the shadow first then the text, etc.
the CPU is a PIII 1 GHz, 512M RAM
video is a Rage mobility. I'm not sure if it's shared memory or not
looking at the tmax times (which are reported on this BDI, luckily):
parport.0.read.tmax = 16762
parport.0.write.tmax = 19276
stepgen.make-pulses.tmax = 15086
and that's over 50 uS total, so there's at least one problem
those parport numbers look exceedingly high to me
I'll be around if you have any questions. doing misc chores though, so I may not respond immediately
ok, now this is just wacky. after a while running (but not actually executing any programs or anything), parport.0.write.tmax is now 7028277 (!)
either this kernel isn't providing correct times, something is really screwed up on this computer (possible, it's a laptop), or there are gremlins in the parport code
running stepper-inch here tends to bog things down a bit too
I changed hal_parport.c so that parport.write is a null function (only sets port=arg, does no outb), and tmax is still 14248
this time, the nasty function is motion-command-handler.tmax, at 6996430
that implies that something is interrupting the RT code that takes about 7mS
again, this is a laptop, so some weird things may be going on, but the BDI kernel doesn't have apm / acpi support, AFAIK
yes it does
I'm getting 17uS for parport read, 20 for write
13uS for makepulses
that's what I get, for the most part
a couple microseconds more, maybe
but that's a long time for two outb instructions
scoping the .timee params to see typicals
between 7.5 and 8uS most of the time
ok - there's definitely something wrong with the laptop. now several of the tmax params are 7-ish ms
something in the background
yeah, but what can be "background" ro RT tasks?
one that adeos/rtai isn't catching somehow
or shared video, on that machine (possibly)
not for 7ms
my best estimate of "typical" base thread execution is 40uS when the scope is sampleing in that thread
my laptop would crap out (missed realtime deadlines) whenever the processor fan turned on or off
no bios settings or kernel settings would fix it
I still say laptops are useless for emc, even though some people seem to be able to use them
some laptops are useless
with no reliable way of knowing which ones
it's an interesting data point though, that the BDI emc works perfectly at 24 uS, and emc2 doesn't work at 50 uS
on the same machine, same kernel, same boot
well, hal does add some overhead
we've long known that emc2 can't run as tight as emc1
yes, but I hope it isn't that much
I didn't know it was a factor of 2 though
it seems worse lately
I think it is worse lately, I just can't pinpoint when it started
it's not an ADEOS / kernel version thing, because I'm seeing this on an older BDI (middle of last year)
if we weren't in kernel space, we could profile
I wonder if we could come up with something that would give a similar kind of information
and if the profiling code didn't add time
tmax and time
you can measure how much time it adds
jeez, 51uS for ddt !?!
hmmm - on my "normal" emc machine, I'm now getting an error that librs274.so cannot be opened (with axis, after full make, and axis install)
rip or install?
methinks something in RTAI / RTAPI has changed, and task switching is slightly fubar'ed
I'm gonna take a look at just running stepgen alone
parport alone, etc
I'm recompiling, just to be sure that I did all the right stuff (--enable-run-in-place ... )
SWPadnos: in your axis directory, sudo rm -r build, then env EMCROOT=.... python setup.py build, look for this line:
g++ -pthread -shared build/temp.linux-i686-2.4/extensions/gcodemodule.o -L/usr/src/emc2/lib -lrs274 -lnml -lm -lstdc++ -o build/lib.linux-i686-2.4/gcode.so -Wl,-rpath,/usr/src/emc2/lib
the -rpath should be your emc2's lib directory
ok - in a couple of minutes, once the emc2 build finishes
5uS typical for sum2
all it does is add a couple floats
I have a hunch
in my config I have 9 ddt
3 for each axis
but they're in the 1mS thread, so not so noticable
or is it 2?
yes, the rpath looks correct
wherever it is
where do the kernel headers live?
ok, the configure option is "--enable-run-in-place", right?
the final messages from configure will reflect that if it was recognized
jmkasunich: are you asking me?
asking anyone who knows
well, now I get an error with the emc script: /usr/local/share/emc/tcl/bin/pickconfig.tcl: No such file or directory
SWPadnos: look in Makefile.inc and check RUN_IN_PLACE
I bet you didn't get it set
whoever put two keys next to each other should be shot
ok, now I'm back to this error:
/Project/emc2/bin/milltask: error while loading shared libraries: librs274.so: cannot open sharedobject file: No such file or directory
are you sure your cvs is updated?
a devel checkout, not anon?
I'm sure I fixed this
this was running before, I'm not sure why I recompiled
in Makefile.inc what is LIB_DIR?
well, it's not up to dat, Entries shows 1.52, and the last commit brought it to 1.55
maybe I should try better to remember which machine I actually did the cvs up on ;)
as jmk says, EBKAC
heh - I see a Problem with that :)
or, no problem, I guess
cradek, do you know what made your kernel provide timing information to RTAI?
the older BDI does, I think BDI 4.30 doesn't
SWPadnos: no, but any interested party could surely wade through the kernel configs
surely they could
fscking RTAI crap shit trash
looks like jmk found the problem
the calls to rtapi_get_time (which translate into calls to RTAI) are taking far longer than the actual code
and the recent change is because until cradek started asking about overrun detection, I knew they didn't work well anyway, so I had them commented out
oh so it's my fault
rdtsc is a serializing instruction, I think
that may be part of the problem
its not rdtsc at all
its what rtai does before/after that
I replaced the calls to rtai with calls to the rdtsc macro itself
multiply / divide (several times)?
(so the results are in clocks, not ns)
numbers less than 1000 for sum2
then I kept the rdtsc for the calulations, but uncommented the calls to RTAI, and the numbers became 9000+
so we're taking a 5-7uS hit at everh HAL function
in cycles, or ns?
9000 is cycles
well - I guess we now know. good job
yeah nice find
rtapi_get_time calls rt_get_cpu_time_ns()
which apparently is a horrible pig
so timing is going away again
as I recall, all that did was call the kernel get_time_ns, which was rdtsc + scaling
it didn't look that bad
that blows my mind - why would the authors of a REALTIME OS make the function you call to measure time so fscking slow
well, somewhere in there is something ugly
I'm sorely tempted to change rtapi_get_time to return time in clocks, use rdtsc, and say fsck it
yep - just do that.
I'm afraid of portability issues tho
we can find a way around my dual-core issue when the time comes
apparently, it's there on all Pentium chips, and possibly the 486 as well
on that issue: I seem to recall designing RTAPI so that on a SMP box it runs all RT tasks on the same CPU
dunno how that works on dual core
I think dual core == SMP
it may work, in which case the RT tasks would always read the same TSC
its not on 486 I don't think, but I'm not worried about those, they're old even by my standards
what about AMD, etc>?
(although it seems to work fine here)
amd has it
the problem is that the TSCs on dual-cores aren't synced on the Athlon X2 or the Opteron
I think instead of changing rtapi_get_time, I'll add rtapi_get_clocks to the API
I wouldn't bother with that. The whole reason for get_clocks would be to get the time
just to make it clear to the caller that he isn't getting ns
I think I was the main opponent to using rdtsc, but I think the potential problems (in a couple of years) aren't anywhere near as important as the performance gain today
make it ns though (not sure exactly how to do that)
can't do that
even a divide is faster than rt_get_...
at least not for version 2.0
the problem is getting the cal factor
can't do what?
right -cat /proc/cpuinfo | grep MHz
what is the system clock? it ain't easy tpo find out in a portable way
'cat /proc/cpuinfo | grep MHz' should be pretty portable across all Linux systems
how do you get it from /proc into the rtapi kernel module
(especially if its a deb, you can't compile it in)
yeah I had that idea for about 5 seconds
does it need to be compiled in?
you can dereference something pretty quickly
it needs to be available to the internals of rtapi.ko
hmm, I guess you could pass it as an insmod parameter
one more thing for the realtime script to do ;-)
it's probably somewhere in the kernel already - else they wouldn't be able to do get_cpu_time_ns
you don't want to go there
I was reading, and my head almost exploded
I bet you can get it from sysctl(2)
CPUs that slow the clock during the idle task, CPUs that stop the clock during the idle task
kernel code that resyncs the TSC every time the idle task exits
yes - those are a problem
truly sick shit for someone used to embedded
well - the kernel has do_gettimeofday
returns a timeval
look at rtai_rtapi.c line 529
I used do_gettimeofday, it caused problems on some systems, alex commented it out
[03:08:08] <SWPadnos> http://lxr.linux.no/ident?i=do_gettimeofday
it's in this file (for 1.6.11) http://lxr.linux.no/source/kernel/time.c
alex didn't say what kind of problems
maybe it's not suitable to call from a RT task
could be, or it's just not there sometimes
yeah that's a lousy comment
looking at time.c, it seems that the function isn't defined if CONFIG_TIME_INTERPOLATION isn't true
when speaking of RTAI, what is "immediate mode"?
see you guys later (like Thursday)
[03:13:36] <SWPadnos> http://lxr.linux.no/source/arch/i386/kernel/time.c#L95
SWPadnos: see you
SWPadnos is now known as SWP_Away
ahhhhhhh, thats better
running stepper-inch, the system is FAR more responsive now
parport read is about 2500 clocks, write is about 5200, stepgen-makepulses is about 400
I think over 80% of the time in the RT threads was being spend in that damned time measuring function
I'm glad you found it
emc2 was starting to get a bad reputation
now... do I announce to folks that HEAD has a fairly important fix in it, or do we need to do some further checking of the build system before we cause a stampede to CVS?
wait a bit, jepler's looking for a problem that's maybe in pickconfig
I'm gonna commit my changes, the commit message won't cause a rush
but answering the folks who say "why do I need to set BASE_PERIOD to 200uS", that will cause a rush
hmm - I actually thought about the bug you just fixed, but it was in the middle of something else and I forgot about it
now I just have to hope that rdtsc is implemented on all the compile farm slots
what bug I just fixed?
oh, it was jepler
duplicate dirs in configs-path
I think rdtsc exists on true pentiums, and anything newer from intel. It at least exists on K6es and newer from AMD. Not sure about oddballs.
wonder if I should make new packages now
I'd let the compile farm run thru its paces first
* jmkasunich goes to start it
sed: -e expression #1, char 0: no previous regular expression
Machine configuration directory is ''
Machine configuration file is ''
did you hit cancel or OK?
neither, this is before that
I see the problem
jepler's change has an unintended consequence when emc is run with no args
you want me to fix it
I'm already typing commit
interesting time behavior here... parport write is very consistent at about 5200 clocks, but a couple times a second it jumps to 12000 clocks or more
jmkasunich: does it sometimes do more than one outb?
it always does the same number
which is 2
one to the data port, one to the control port
HAL provides all the outputs, even if they aren't in use
emc1 would skip the outbs if those outputs had not changed
I can get flurries of the long ones when I move the mouse
one reason for things to get long during other activity is cache
if the only thing running is RT code, it remains in cache from one thread execution to the next
jepler: can you make doubleclick work while you're in there?
if lots of user space stuff is going on, cache gets overrwitten
that probably accounts for the small scale jitter
there is a hard floor at about 5100 clocks
then a distribution of runs that vary from 5100 to about 5300 (most under 5125)
then nothing between 5400 and 12000
12000 to 15000 happen maybe 1% of the time
when very active
jepler used [ file normalize ]
that isn't available on older tcl (pre 8.4)
dunno if thats a factor or not for emc
do you have any idea what tcl versions are on what bdis?
obviously it's ok for ubuntu
I'm trying to figure out what I have here
tclsh --version and similar doesn't work
% info tclversion
I'll check the farm
BDI-2.x has 8.0, BDI-TNG has 8.3, BDI-Live has 8.4
so it's fine right now?
-2.x and -TNG are on the chopping block IMHO
and it's looking worse and worse for them as work continues
quite a weekend
45 commits "yesterday" (CIA is on UTC I think)
122 so far this month
[04:23:03] <jmkasunich> http://cia.navi.cx/stats/project/emc
we've averaged a commit every 7.5 hours for almost a year and a half
new emc2, emc2-dev, emc2-axis packages in the breezy repository (again)
hope I got everything in there
compile farm is happy (two slots anyway), so my rtapi change didn't bust anything
its a shame we can't actually test on the far
I can't see any way to automate it tho
you could insert and remove a module, but that's a lousy test.
the only real test would be to start emc and run 3dchips or something
probably can't do that automated.
and even that only tests a fraction of the system - only one gui, only one config
as far as you can tell, the current HEAD will compile and run both in place and installed?
we need to make a tarball while it is pseudo-stable, before the next wild session like these last few days
and we need to communicate some changes, like --enable-run-in-place
maybe it's better to make tags
the timing bug is significant enough that I want to announce the fix
there's nowhere to put a tarball where people will look for it.
alex was/is hosting daily tarballs
but you're right, gotta point people to them
yeah, but I don't think anyone is using them unless cvs breaks
tags can be moved, right?
so we could have a tag TESTING, that always points to the latest reasonable stable thing
yes I think we could
and a wiki page that tells testers both how to get it and compile it, and what to expect
IMO that's what my debs are for
"foo is known not to work, but bar and baz should, if they don't please report it"
I make a new one when I think something important has changed, and everything's in a sane state
cradek: just fyi, make tgz is not working at the moment, we might want to add that back
HiAlex... latest debs are not working either
LawrenceG: yes they are, since last night
logo var is missing from pickconfig.tcl
and my config dirs are empty
/etc/emc2/sample-configs/stepper has NO files
if fixed logo var by adding >>set logo ""<< at line 36 of pickconfig.tcl
I seem to be missing emc2-wizard.gif as well which shoed up the logo error
Those files must not be in the debs.... I removed and installed emc2 several times even a fresh deb download
I was hoping to test the timing fixes on this old 200mhz unit
I can see the files in the deb, the config dirs get created, but the ini files are not being placed into the directories
To test, uninstall emc2 and rm -rf /etc/emc2, then reinstall deb
where did you get the debs from?
cradek: In case you didnt catch above.... latest emc2 debs contain but do not install any sample configs... /etc/emc2 has sample dirs, but no contents... a du /etc/emc2 shows only 52 blocks
from the .ro repository
dunno, not sure, probably not fully done yet
* alex_joni has a plane to catch in an hour
np.... I need to get to bed... 1am here
I had a version from a couple of days ago working
lots of changes this weekend... good show
* alex_joni goes away for a while
alex_joni is now known as alex_joni_away
LawrenceG: if you dpkg --purge emc2 and then apt-get install emc2, do you get config files?
ok I think I reproduced the problem, not sure if I understand it fully
if you apt-get remove emc2, it preserves the configuration files in /etc
if you remove them with rm, it also preserves that (?)
so ... don't do that
dpkg --purge emc2 and then reinstall should fix your problem
cradek: Thanks... that has restored the sample ini's. When running stepper-inch, /usr/bin/milltask errors out when trying to load librs274.so.. a search of my hd does not find this file anywhere
LawrenceG: I fixed that - updated packages available
cradek: Thanks... downloading now
LawrenceG: should be smooth from here on - alpha19 was the first package I made with the new build system.
cradek: np... hope I havent been a pest... the deb idea is fantastic....
not at all, I really appreciate your testing and good bug reports
you are helping make this smooth for when we make the big release
yea... the more people that can try out the new stuff, the faster its gets stable
running cds now in sepper_in YEA!!
it runs quite well on a P200.....
great, jmk made an important fix yesterday that should have made it run much faster (reduced BASE_PERIOD possible)
axis-sim seems to be another story... I get a blank axis window and 100% cpu usage forever...maybe some update is being scheduled faster than it can run... no errors on cmd line
can you run other opengl programs like glxgears?
buy faster computer
that could be the problem..... glxgears comes up, runs a few revs and stalls out... hmm this is an old matrox card
I'm surprised, but Mesa, the software GL renderer, might have trouble on such a slow machine
I get an update about every 20 seconds... xorg is the cpu hog
hmm, doesn't seem like it should be that slow.
its so slow I can see it rendering each face of each tooth!
let me check my xorg config and see what is turned on
you could try turning off DRI
hmmm I notice in the Module sectopn, that I am loading GLcore... that may be the matrox accellerator
as I understand it, that may be bad with RT?
no, that's fine I think
but try commenting out Load "dri"
if you have it
also if your screen depth is 24 or 32, change it to 16
ok its there... should I comment out the dri mode 0666 as well?
I don't think it matters
default depth is 16
strange.... tried a few more setting combinations... no real change... glxgears runs about 3 revs and thenslows to a crawl. The good news is that its not an EMC2 problem. Cheers... gotta run... doing tax stuff today... would rather be making chips :}
ok good luck with taxes
I may try another video card later
cradek: I've got both installed and rip versions of testing here. I like what I see of it. I've got a couple of questions about halconfig in relation to the "new world order."
rayh: did you make install, or use the deb?
I don't have ubuntu yet. This is 4.30 bdi
from a couple hours ago.
My vision for halconfig was that it would be able to start, without HAL or EMC running.
btw I am working on making the update friendlier - I hope to get it to show the changelog for the new version of the packages before you decide to update (like the system packages do)
does that still require a running hal and halcmd?
aside On the make install. Should there be a make uninstall?
I'm still fuzzy about how halconfig works
the problem with make uninstall is that it can't determine whether you have modified files (like configs). Typically packages do not have a make uninstall.
Details are not critical right now.
ok I'll let you ask the questions and I'll try to answer them
It's been a long time since I ran an MS system but there was a package remover.
make install is from a time before package management - if you use the deb packages, you can certainly remove them cleanly
If halconfig found am rt system it would offer to start an empty HAL
I see people using make install only on systems that don't have package management, or are so out of date there aren't packages
I guess I was thinking I'd like to remove the installed version.
you'll have to do that by hand then - /usr/local/etc/emc2, /usr/local/share/doc/emc2? a few files in /usr/local/bin, a few files in /usr/local/lib
we could write a make uninstall if we decide it's necessary
What halconfig did was start realtime or the most basic demo script.
ok so you want it to be able to do a realtime start
does it have to do anything else?
Once realtime is going, it drops into ordinary halconfig mode with tree and all.
so it needs to know two things: where is realtime, where is halcmd
But what I seem to be missing on the installed version is a way to get halconfig to start.
Isn't halconfig on $PATH when running installed?
The installed version is fairly easy to find these.
currently it knows neither of those things: the halcmd location comes from the environment
What isn't easy is to find and start halconfig.
jepler: only when a child of the emc script
jepler: oh I reread, you're right
I see two immediate choices.
rayh: if you want the user to invoke halconfig directly, it should go in the bin dir
rayh: currently it's off in some script directory
rip out the environmental testing and always start it from tkemc, mini, axis. etc.
That choice is easy.
we might rename it to emc-halconfig and put it in bin, for instance
we intend to have emc-configuration or something like that to run setupconfig
now, you do not need root privs to start realtime, so that is not a problem
I don't see any big stumbling blocks, just some playing with the installation is necessary
But if it's installed, I don't need the startup testing for things like MS and rtxx
I don't follow - what are MS/rtxx
Those are tests at the start of halconfig.
let me pull it up
I guess the real question I have is how does halconfig fit in with other scripts like setupconfig.
BTW I really like the new look of the chooser.
sounds like setupconfig and halconfig are very similar - we want the user to be able to run them without emc running
the tree widget is great.
so they will be in the path (and there will be menu entries on the system Apps menu to start them)
great, I like it too, very much
it's an elegant solution to multiple config directories
Okay. That works.
rayh: already with installed, if you copy a config into your home directory ~/emc2/configs/configname, it will show up on the chooser
rayh: setupconfig will do just that (and there is also a system-wide config directory)
your personal configs show up on top, then the systemwide configs, then the samples on the bottom
jmk was talking about user configurable things. will display color and font be a part of this like they are with other linux apps?
The color and font selections for Tk applications are customizable through the X resource database
but Tk is not "themeable" in the modern sense
Ah we we have never been very successful at keeping that location for TkEmc alive.
It does require work on the "option" database for each display.
tk is sometimes finicky when you markedly change font sizes for instance
but things like colors are easy to change
Yep. Font is better in 8.5 but ...
What I'm thinking of is a .myconfig file in the users home directory.
there is a standard X way of doing that involving a file in the home directory called .Xresources
it would then be handled without any special code in tkemc
have you had a lot of requests for this kind of customization?
Some. More like help it looks bad.
chew chew chew
maybe we need to work on the defaults a bit then
but "help it looks bad" doesn't help us much, does it
These come from several sources. One is KDE's config all apps alike.
yeah, but we won't have that kind of themability without a total rewrite of the guis.
to me, that doesn't seem like an important goal right now.
we would have to ditch tcl/tk and start over.
KDE does it now to tkemc. Mini is already close to their default colors and fonts.
KDE themes show up in tkemc?? There must be something at work I don't know about.
cradek: KDE writes some X resources
I know nothing about how it works but it does change bg, fg and some fonts.
ok, that much is easy
getting 3D buttons etc. is impossible
maybe getting rid of the blue, in favor of a more standard gray look, would help
I guess I was thinking less about hard coded stuff than an approach to user configuration.
TK has color choosers and font choosers and such.
like jepler said, that's already possible with X resources but it's hardly friendly.
you could definitely make a preferences screen and write the results to a file in the user's home directory to be read when tkemc starts
Okay. I'll salt that away for a later release.
but .. but .. the X resources database already exists!
the answer to "our GUIs look terrible" should not involve "let's write another GUI application to solve that problem"
I'm pretty sure I would duck out of any gui-improvement part of the project; I put that energy into AXIS. That's not to say I think it shouldn't/couldn't be done.
we should strategically add a few configuration options (like using a non-bold font by default, and some white backgrounds), after which Tk looks a lot more modern .. at least like a win95-era program.
yes, that might help a surprising amount.
All of that can be done in TkEmc.
I think sometimes "sensible defaults" are better than all the configurability in the world.
Then we would just need to replace snapshots of the old with the new.
In several hundred places.
including the splash screen
no problem. alex said the splash screen was a quick hack (but I think it's really good)
Would TkEmc be editable by a user in the installed emc2?
using sudo, it sure is
if a user customizes it and then installs a new deb, the deb install will give an option of keeping the customizations or using the new distributed file
alex_joni_away is now known as alex_joni
I thought you were away
* alex_joni couldn't stay away
I'm in the hotel right now, it's good that wireless works
the new config selector looks and works great
btw, you've got mail
it already did last night
cradek: got my email?
ok, eager to know what you think
I like 06
like.. like? or really like?
it looks nice
I like the globe thing
how about the logo?
it's cute but I think the pengiun should have a tool of some kind
or just safety glasses?
btw, I like 06 better too
rayh: care to look at a picture?
Sure send it on.
or send a link
link is better I think, let me put it someplace
[21:38:06] <cradek> http://timeguy.com/cradek-files/emc/linuxCNC_06.jpg
unfortnately it's huge because someone made a jpg when it should have been png
don't want to abuse the wireless here
cradek: you can convert :D
it's too late, it'll look terrible
I assume this is not the final content... the part about viruses is silly
that's taken from the current site
uh I assume this is not the final content... the part about viruses is silly
I just pointed him some URL to take sample data from
cradek: it will be a CMS, so you can fix what you don't like :P
I think putting safety goggles on the logo would be just enough of a twist to make it cute/funny
how about we collect some ideas, and I'll get back to the designer
and we'll see
but I don't care for it much
I particularly dislike the out-of-focus macintosh keyboard
I don't really like it either
I mean it's ok, but barely
I prefer 06 too
greetings from germany
nice so far, but it's dark ;)
Yes, at this time of night it probably is
you should come to the US .. it isn't dark yet, except in metaphor
Where are you in Germany, alex_joni
lol, I'm not scared of metaphor-typed dark
rayh: near freiburg (near switzerland and france)