[00:04:03] <jepler> http://article.gmane.org/gmane.linux.kernel/927886
hmmm. I wonder how much longer this SVN checkout of gphoto2 will take on the airport wi-fi connection
I wonder if that's not the best time to check out software
why wouldn't it be?
it finished though, so I guess it's not all bad
see you later
have a good flight
SWPadnos: those cases you have - will they take a full sized pci card?
* full hight
jepler: can you take a look at this patch: http://www.pastebin.ca/1716497
it speed up loading program with many dwells
from 30 sec down to about 3 sec
(to be specific glcanon.draw_dwells run time drop from 30 sec down to about 3 sec)
in general I think that kind of change is OK particularly if the payoff is big. Just curious, by comparison how much does this trim the load time: http://emergent.unpy.net/files/sandbox/glcanon.patch
also, roughly how many dwells in the file that takes 30 seconds to load on unmodified emc?
this is test file but normally we have many dwells too (laser cutter)
huh. a file with 100000 G1 moves and 100000 G4P1 dwells loads in about 7 seconds for me with the glcanon.patch I just proposed, or 8 seconds without
jepler: here I have 10% speed up
this is my test file: http://filebin.ca/vxnovd/1.ngc
it's slow to download, so I stopped it. my test program is very simple. http://pastebin.ca/1716519
in fact you could probably change it to an O-word loop and get about the same test
what kind of system are you running on? this timing is on 9.10, sim, core 2 duo, forced to 800MHz
intel accelerated opengl, but since you've started by establishing that 90% of the time is taken interpreting Python that shouldn't be relevant.
9.04 sim, celeron 2.8Ghz
I'm just trying to aviod bottlenecks on loading gcode
next is in gcode.parse()
jepler: I'll test glcanon patch deeply at work tommorow, if all tests will be correct and speed up will be visible I'll commit it
the proposed change looks OK. It's just odd that your machine is so much slower than mine -- you say 30 seconds for one phase of the load for a file 1.5x as big as mine, I say 8 seconds for the whole load...
now, our test programs aren't the same, so that could be the reason. but it should boil down to the number of dwells being drawn..
probably something is messed up here, python programs are REALLY slow
error: patch failed: lib/python/rs274/glcanon.py:66
error: lib/python/rs274/glcanon.py: patch does not apply
error: patch failed: src/emc/usr_intf/axis/extensions/emcmodule.cc:1680
error: src/emc/usr_intf/axis/extensions/emcmodule.cc: patch does not apply
patch doesn't apply here anyway
oh, it's pastebin fucking up whitespace
with your patch loading my file still takes around 7 to 8 seconds
jepler: ok I'll give it test on real rt machine tommorow
what's pystone performance on your system?
$ python -mtest.pystone
Pystone(1.1) time for 50000 passes = 0.68
This machine benchmarks at 73529.4 pystones/second
Pystone(1.1) time for 50000 passes = 1.75
that's not at all fast.
eh 3am, good night all
Does the "IBM Real-Time "SMI Free" mode drive" linked by Jepler have any relevance to trying to run RTAI on IBM Thinkpad laptops?
See - http://article.gmane.org/gmane.linux.kernel/927886
seems like it might be relevant, but I sure don't know for sure
well, thanks, guess I will keep it in the back of my mind since it will not really matter to me until after Ubuntu 10.4 LTS gets EMC
I am really looking forward to 10.4 because it'll be spring then
never did get the 8.04 EMC release to co-operate with the built-in Ethernet on my T400
have not heard anything lately about CNC Workshop and the prospects of having EMC fest there, anything up?
I think some of us are planning to go
I don't know if we'll do anything particularly special - for instance I don't think there will be any interesting machines to work on
does it look like we will have the time frame and facility access that we are accustomed to having?
sorry what do you mean?
ability to wander in and out at all hours and stay all week
oh I see - I would think so
so... what would be an interesting project machine? lathe:done, rotary axis:done, rigid tap:done, ah.... "spice rack" style tool changer?
not long ago I'd have said a random toolchanger - but that's done
... or maybe the upgrades to kinematics that are in process
dunno about spice rack. I think it's trivially easy to hack in, but would only work for spice rack
we probably want something more general - but what?
well, I was thinking of a more generalized solution to motion from "macros" to do the spice rack, not a pure hack
that is only bacause you have done such a good job on all the "small" projects
rfl/task redesign is another huge one that we could argue about for a while and then put off for another year
yeah the low-hanging fruit and also most a bit further up are all picked
run from line (i.e. redesign all the modal stuff about program starting/stopping)
skunworks, yes, they fit a 5i22-sized card just fine, but there can be some interference between the cables and the hard disk
the (laptop-sized) hard disk(s) mount under the top of the case, and there isn't a lot of room there
Dave911_ is now known as Dave911
steve_stallings is now known as steves_logging
I have a work machine (ubuntu 6.06) with simulator. I tried loading the same file with moves and dwells as I did last night. total load time was higher, about 24 seconds. pystone 30120.5/second (50000 passes = 1.66)
micges patch reduced it to 20
this machine is a Pentium 4 2.40GHz (family 15 model 2 stepping 7)
[Global Notice] Hi all, Sorry for the delay in updating you -- wanted to get confirmation from sponsors about the actual issue, we are indeed still experiencing heavy DDoS and our upstream providers are working to curb it at the borders were possible. Further info will be via wallops. Thank you.
[Server Notice] Hi all, the server you are connected to (orwell) will be going down shortly, you may wish to connect to a different server by connecting to chat.freenode.net