#emc-devel | Logs for 2007-04-15

[01:01:36] <jmkasunich> SWPadnos doesn't know if he's coming or going...
[01:01:46] <SWPadnos> I do, but the computer doesn't
[01:01:49] <jmkasunich> heh
[01:02:04] <jmkasunich> well, I'm now committed to building a new computer
[01:02:10] <jmkasunich> (bought the first part)
[01:02:15] <SWPadnos> heh - you said it on IRC, so you have to do it now ;)
[01:02:28] <jmkasunich> I spent money, so I have to do it now
[01:02:31] <jmkasunich> IRC means nothing!
[01:02:35] <SWPadnos> you can do a pretty significant upgrade to the farm machine by replacing the CPU
[01:02:44] <SWPadnos> the X2 chips are dirt cheap now
[01:03:03] <jmkasunich> that won
[01:03:05] <jmkasunich> oops
[01:03:15] <jmkasunich> that won't speed up the disk, or give it more ram or....
[01:03:29] <jmkasunich> I just got a 150G Raptor disk (10KRPM)
[01:03:32] <SWPadnos> you can do a RAM upgrade at the same time, that's pretty cheap too ;)
[01:03:35] <SWPadnos> cool
[01:03:50] <jmkasunich> next decision is single or dual socket mobo
[01:03:58] <jmkasunich> I'm gonna either go 12xx or 22xx
[01:04:08] <SWPadnos> you know my advice ;)
[01:04:32] <jmkasunich> yeah, I was actually hoping to pick your brain on that topic
[01:04:42] <SWPadnos> even if you get only one CPU now, you have a lot more headroom with the dual
[01:05:16] <SWPadnos> farm upgrade: http://www.newegg.com/Product/Product.aspx?Item=N82E16819103052
[01:05:45] <jmkasunich> that will drop into a socket that had a sempron?
[01:05:56] <SWPadnos> is it socket 754 or 939?
[01:06:06] <SWPadnos> the mb
[01:06:08] <jmkasunich> not sure, lemme try to figure it out
[01:06:15] <SWPadnos> heh
[01:06:32] <SWPadnos> actually, if you run RT on that box, there's no point in getting an X2
[01:06:37] <jmkasunich> I do
[01:06:39] <SWPadnos> unless you want to work on SMP RTAI
[01:06:49] <jmkasunich> I don't
[01:06:53] <SWPadnos> (which would be nice, considering the direction of the CPU market)
[01:07:52] <jmkasunich> socket 462?
[01:07:59] <jmkasunich> or is this the manual from an even older mobo...
[01:08:06] <SWPadnos> 462 is a pentium of some sort
[01:08:13] <cradek> can I use that to replace my 'model name: AMD Sempron(tm) Processor 3300+' and get smp?
[01:08:17] <SWPadnos> pentium something of some sort ,,,
[01:08:42] <jmkasunich> model name : AMD Athlon(tm) XP 2000+ is what I have now
[01:08:44] <SWPadnos> I'm not sure if the sempron 3300 was available in 754 or if they're all 939s
[01:08:58] <SWPadnos> if you have a socket 939 MB, then yes, you should get a very nice boost with that CPU
[01:09:15] <jmkasunich> socket 462
[01:09:21] <SWPadnos> hmmm. I thought you had a 64-bit chip in the farm machine
[01:09:27] <jmkasunich> nope
[01:09:40] <jmkasunich> http://www.soyousa.com/products/proddesc.php?id=304 <-- the mobo
[01:09:43] <SWPadnos> ok, then you're close to the top end of that motherboard, and it isn't worth it to upgrade
[01:09:55] <SWPadnos> oh, 462 - socket A
[01:10:07] <SWPadnos> I should have known, that's what I'm typing on ;)
[01:10:09] <jmkasunich> I had already reached that conclusion, hence the desire to build a new system
[01:10:16] <jmkasunich> ;-)
[01:10:41] <SWPadnos> well, if the new system is intended to run RT, then you have a dilemma regarding CPU type and quantity
[01:11:16] <SWPadnos> since SMP doesn't seem to be a priority
[01:11:27] <SWPadnos> RT SMP (plus A64, what the heck ;) )
[01:11:53] <jmkasunich> well, I'll probably be keeping this system as my RT/hardware playing box
[01:12:32] <jmkasunich> the new one will be: farm server, web server, FPGA place/route machine, network backup machine, etc, etc
[01:12:34] <SWPadnos> ok. the farm is already VMs, so the host doesn't really matter there
[01:13:11] <SWPadnos> I haven't toyed much with processor affinity in VMWare (having multiple VMs use separate cores)
[01:13:52] <SWPadnos> what happened to the sempron/A64 purchase you were making last fall? did that end up being this Athlon?
[01:14:02] <jmkasunich> I never bought anything
[01:14:07] <SWPadnos> oh, that explains it ;)
[01:14:29] <jmkasunich> this computer is two years old this month
[01:14:46] <cradek> hm, I think mine's 754
[01:15:01] <jmkasunich> http://www.newegg.com/Product/Product.aspx?Item=N82E16813151046
[01:15:15] <SWPadnos> heh. I'm still using a 6 year old PC for most work, and my laptop is the same age
[01:15:20] <jmkasunich> am I being blind? it says "special combo deal", but doesn't say what its combo'ed with
[01:15:37] <SWPadnos> Kingston 1GB 240-pin DDR2 SDRAM
[01:15:40] <jmkasunich> I thought you used that fancy new dual-head machine?
[01:15:58] <jmkasunich> oh, dus
[01:16:01] <jmkasunich> duh
[01:16:06] <SWPadnos> it's not my day-to-day machine, due to me waffling on product licenses and such
[01:16:17] <jmkasunich> and only $20 off, nothing to get terribly excited about
[01:16:19] <cradek> what are product licenses?
[01:16:30] <jmkasunich> some strangness
[01:16:39] <cradek> (sorry)
[01:16:42] <SWPadnos> they're things that people sometimes have to put up with and pay large amounts of money for, in the non-Linux world ;)
[01:17:24] <jmkasunich> dual socket mobos aren't cheap - nothing under $250
[01:17:42] <cradek> http://www.newegg.com/Product/Product.asp?Item=N82E16813135170
[01:17:50] <cradek> my board ($42)
[01:18:08] <jmkasunich> thats about what I paid for mine when I got it
[01:18:18] <jmkasunich> I think it was a combo deal, mobo and CPU for about $100
[01:19:15] <jmkasunich> this time around I want to get something that isn't already a couple years behind the leading edge, maybe I'll stay happy with it longer
[01:20:07] <jmkasunich> I don't want to be as leading edge as SWP tho ;-)
[01:20:14] <SWPadnos> heh
[01:20:23] <SWPadnos> at least you use the things you buy ...
[01:20:32] <SWPadnos> no, you can't have it ;)
[01:21:53] <jmkasunich> well, there are 9 dual socket mobos in the 200-300 price range...
[01:22:50] <jmkasunich> 2 ASUS, 2 Gigabyte, and 5 Tyan
[01:23:09] <SWPadnos> under "server motherboards"?
[01:23:15] <jmkasunich> yeah
[01:23:27] <jmkasunich> no dual socket opteron boards under regular
[01:23:34] <SWPadnos> only one, and ASUS
[01:23:37] <SWPadnos> an
[01:23:45] <SWPadnos> http://www.newegg.com/Product/Product.aspx?Item=N82E16813131146
[01:23:49] <SWPadnos> $347 though
[01:24:02] <jmkasunich> I think thats socket 1207FX, not 1207
[01:24:16] <jmkasunich> made for some fancy gamer targeted Athlon FX thing
[01:24:17] <SWPadnos> yes. sadly, I don't know enough about the new sockets to know the difference
[01:24:20] <SWPadnos> ah
[01:24:36] <jmkasunich> not sure opterons would work in there, and too much $ anyway
[01:25:55] <jmkasunich> only 2 chipsets...
[01:26:05] <SWPadnos> NForce 590 or 680, it seems
[01:26:17] <jmkasunich> NVIDIA nForce Pro 3600, and Serverworks HT1000
[01:26:36] <SWPadnos> hmmm. back to the classroom for me ;)
[01:26:51] <jmkasunich> http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&N=2010200302+4018+1071323148&Subcategory=302&description=&Ntk=&srchInDesc=
[01:27:08] <jmkasunich> clicking on the boxes in the left sidebar tells a lot
[01:28:40] <SWPadnos> given those manufacturers, I'd choose Tyan, then Asus a far second, and Gigabyte a distant third
[01:28:48] <jmkasunich> Hmm, CEB form factor - thats a new one for me
[01:29:43] <jmkasunich> and then there were 5 ;-)
[01:31:06] <jmkasunich> actually, then there were 3
[01:31:19] <jmkasunich> two are open box units that duplicate the others
[01:31:19] <SWPadnos> heh. no room for expansion slots on those. the CPU sockets (and 8x240 pin DIMMS) are huge
[01:31:42] <SWPadnos> right. I usually do power search and check OEM and Retail
[01:31:45] <jmkasunich> they have either 3 or 4 PCI
[01:31:49] <cradek> jmkasunich: I left in and out pins in X mode so you could drive that line low from 'inside' or 'outside'
[01:32:20] <jmkasunich> that seems confusing to me (and to anybody who doesn't really know about open collector)
[01:32:30] <cradek> yes
[01:32:31] <jmkasunich> I suppose we could have "OC" mode....
[01:32:38] <jmkasunich> for those in the know
[01:32:51] <cradek> but if they don't understand it's OC, they won't get it to work anyway
[01:33:09] <jmkasunich> cause they won't add pullups?
[01:33:11] <cradek> well depending what they drive it with I guess.
[01:33:51] <cradek> I think one way it might be useful would be for an estop loopback that uses only one pin
[01:34:10] <cradek> haven't thought that through very well though
[01:35:56] <jmkasunich> feel free to change it if you want - maddash was rather confused by the whole thing (mostly because X mode is completey undocumented), thats why I made the change
[01:37:47] <cradek> well it's otherworldly, you made it less so I guess
[01:38:01] <cradek> I wasn't using the OC that way anyway
[03:38:42] <cradek> wow I sure killed your conversation...
[03:39:28] <SWPadnos> heh - this is the EMC development channel, don'tcha know
[03:39:35] <cradek> yeah
[03:40:27] <cradek> well I decided I don't need a faster computer.
[03:40:53] <SWPadnos> there's not much you can do with a socket 754 - none of the available upgrades are worth it
[03:40:57] <SWPadnos> except possibly for more RAM
[03:41:10] <cradek> I'd like a fast smp machine to try rtai again, but it's easy not to want to do that
[03:41:18] <SWPadnos> heh
[03:41:40] <SWPadnos> I didn't see any dual-core 754 chips anyway, so you're into motherboard and memory-land anyway
[03:41:44] <SWPadnos> in addition to CPU(s)
[03:41:47] <cradek> yep
[03:42:07] <cradek> still < $500 for a nice upgrade I suppose
[03:42:30] <SWPadnos> depends on the amount of memory and CPU speed ...
[03:43:14] <cradek> I'm not sure how emc will work out as processors become more varied
[03:43:31] <cradek> we may be on the tail end of providing one kernel that runs nicely on most things
[03:43:50] <SWPadnos> I've been thinking about that. I think SMP will be necessary/desirable in the next major release
[03:44:17] <SWPadnos> not because we need it, but just so people can use all of the CPU they get with relatively modern machines
[03:44:22] <cradek> yeah.
[03:44:52] <cradek> the rtai setup I was trying to get to work tied realtime tasks to one processor - if we do that, they won't see much benefit except when running emc
[03:45:13] <cradek> well, unless they have more than 2 I guess
[03:45:20] <SWPadnos> user apps still get spread across both (all) cores though
[03:45:28] <cradek> oh is that right?
[03:45:32] <SWPadnos> it's just that the RTAI apps should be on one only
[03:45:38] <SWPadnos> I think so, but I'm not poisitive
[03:45:54] <SWPadnos> I don't think RTAI prevents other tasks from using a CPU, but you can bind RT tasks to one or another
[03:46:46] <cradek> If you bot witd isolcpus no linux task will be on the isolated cpu, just =
[03:46:57] <SWPadnos> what?
[03:47:00] <cradek> Pretty sure of that as it is the way to get single digit us latency
[03:47:06] <cradek> https://mail.rtai.org/pipermail/rtai/2006-February/014376.html
[03:47:20] <cradek> so I think it is how I remember
[03:47:23] <SWPadnos> ah, with isolated CPUs ...
[03:49:05] <SWPadnos> interesting. so you can do that if you want. I wonder if the isoalted CPUs become non-isolated when you unload rtai_hal
[03:49:34] <cradek> that would sure be nice
[03:49:41] <SWPadnos> indeed it would
[03:49:50] <jmkasunich> cradek: would you like a dual P3-600 box?
[03:50:06] <jmkasunich> free if you are willing to work on smp rtai :-)
[03:50:25] <jmkasunich> I think it even has ubuntu on it, don't recall what version tho
[03:50:29] <SWPadnos> isolated CPUs is only one option though, isn't it? (ie, you can still use RTAI/SMP like normal SMP Linux, but with higher latencies than isolated would give)
[03:50:44] <cradek> jmkasunich: not sure, I have a dual PII-300 already, but both are pretty unsuitable for building a bunch of kernels
[03:50:56] <SWPadnos> I have a pair of Opteron 244's if anyone wants them
[03:51:07] <SWPadnos> you'll just need a dual 940 board to hold them
[03:51:10] <cradek> SWPadnos: yes I think there are lots of options
[03:51:17] <jmkasunich> just need a mobo, and ram, and a PS, and a case, and. and
[03:51:44] <jmkasunich> maybe I'll bring the 600x2 to the workshop
[03:51:48] <cradek> SWPadnos: (I couldn't get any to boot)
[03:51:53] <jmkasunich> see if I can sneak it into your car the last day
[03:51:55] <SWPadnos> hmmm
[03:52:04] <cradek> jmkasunich: maybe one of us will feel like working on smp there
[03:52:19] <jmkasunich> maybe
[03:52:30] <SWPadnos> well, I haven't done any RTAI patching in a long time, but I'll give it a whirl when I get back from Las Vegas
[03:52:29] <jmkasunich> I actually have two very different dual P3-600s
[03:52:48] <jmkasunich> one is a 3.5" tall but very deep rackmount
[03:52:50] <jmkasunich> the other is a tower
[03:53:05] <SWPadnos> rackmount == shelf :)
[03:53:34] <jmkasunich> 3.5 x 19 x 27 or something like that
[03:53:52] <cradek> I should try again, but do the rtai/smp hacking separately from the dpkg hacking
[03:54:07] <cradek> it's frustrating to try to do both together
[03:54:16] <cradek> one is bad enough
[03:56:31] <SWPadnos> indeed
[03:56:49] <SWPadnos> I started to go through the RTAISteps page, but never finished
[03:57:56] <cradek> that doesn't even talk about dpgk
[03:58:23] <SWPadnos> right
[03:58:31] <SWPadnos> another issue/headache, as you said
[03:58:32] <cradek> just building for one machine isn't very hard (assuming it boots when you're done)
[03:58:40] <SWPadnos> heh
[03:59:22] <cradek> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?UbuntuBreezyPackages
[03:59:26] <SWPadnos> we can certainly fiddle with my Opteron machine at Fest, and I may upgrade the A64 to dualcore as well
[03:59:27] <cradek> here are my very old breezy notes
[04:00:04] <SWPadnos> hmmm. I think it's bedtime ;)
[04:00:06] <cradek> cool, it would be nice if you would bring some horsepower
[04:00:19] <SWPadnos> I'll do that, assuming the van seems to work well enough
[04:00:28] <cradek> and jmk would have that machine for testing
[04:00:39] <cradek> I'll have only a PII or PIII
[04:00:51] <SWPadnos> hmm
[04:00:55] <cradek> or maybe even just my laptop, not sure yet.
[04:01:17] <cradek> I think we may use my (smaller) car this year
[04:01:22] <SWPadnos> not the big turbine case?
[04:01:38] <cradek> that huge box I had last time is a PIII
[04:01:55] <cradek> the other huge box currently running my mill is a PII
[04:03:41] <jmkasunich> cradek: does the fact that my dual cpu boxes are scsi make things easier or harder?
[04:04:00] <SWPadnos> not if they have IDE controllers as well ...
[04:04:20] <cradek> I have no problem with scsi, all my old server class junk is scsi
[04:04:24] <jmkasunich> the tower does, the 3.5" one nope
[04:04:36] <cradek> I have (many) more spare scsi drives than ide
[04:05:15] <cradek> scsi cdroms are a little rare I guess
[04:05:22] <cradek> that's the only possible problem
[04:05:40] <cradek> but I could find some if you/we/I need them
[04:05:57] <jmkasunich> the cdrom is ide
[04:06:20] <jmkasunich> there are 2x9G scsi disks, IDE cdrom, floppy
[04:06:54] <cradek> nice
[04:07:10] <SWPadnos> if the CDROM is IDE< then IDE HDs should be possible as well (unless it's an IDE plug-in card)
[04:07:09] <jmkasunich> only 256M of ram tho, and its rambus, so we aren't gonna just toss more in
[04:07:25] <jmkasunich> its mobo ide
[04:07:33] <jmkasunich> there are two connectors, one cable, one device
[04:07:37] <jmkasunich> so adding more would be easy
[04:07:48] <SWPadnos> ok, that must not be the 3.5" machine then :)
[04:08:16] <jmkasunich> no
[04:08:31] <jmkasunich> that one has a two drive hotplug cage, with 2x18G drives
[04:08:45] <jmkasunich> no IDE, and really really lame video
[04:08:55] <jmkasunich> (1M video ram, maybe 2)
[04:09:13] <jmkasunich> definitely a server, not a game box
[04:12:24] <jmkasunich> the tower is more balanced, it was an engineering workstation
[04:19:28] <SWPadnos> well, it's now really bedtime for me. good night guys
[04:19:51] <jmkasunich> goodnight
[17:14:42] <jmkasunich> did we ever figure out a consistent way to have _u32 and friends as types?
[17:15:00] <jmkasunich> IIRC, we have __u32 in kernel space, but not in sim, and maybe nothing in user space?
[17:16:38] <SWPadnos> there's a C99 header file that defines those - lemme find the name of it
[17:18:06] <jmkasunich> ./hal/hal.h:typedef volatile u32 hal_u32_t;
[17:18:05] <jmkasunich> ./rtapi/rtapi_types.h:typedef u32 __u32 __attribute((deprecated));
[17:18:31] <jmkasunich> ./rtapi/rtapi_types.h:typedef uint32_t u32;
[17:18:48] <jmkasunich> looks like u32 is now the preferred version, and is available anywhere rtapi.h is included
[17:18:55] <SWPadnos> we can take that out though, I'm pretty sure there's a standard header that gives it to us
[17:19:18] <jmkasunich> even in kernel space?
[17:19:38] <SWPadnos> hmmm. there may need to be some of those machinations for kernel space
[17:19:42] <jmkasunich> stdint.h might be that header
[17:20:03] <jmkasunich> see rtapi_types.h
[17:20:13] <SWPadnos> could be. I'm trying to remember what class told me about that, rather than searching some include directory for it ;)
[17:20:28] <jmkasunich> it includes stdint.h and defines u32 as uint32_t for sim and user space
[17:20:38] <jmkasunich> and includes asm/types.h in kernel space
[17:24:32] <SWPadnos> actually, it should be able to include linux/types.h, for kernel or userspace
[17:24:46] <SWPadnos> then use the __u32 versions in userspace or uint32_t in kernel code
[17:24:56] <SWPadnos> according to this: http://lwn.net/Kernel/LDD2/ch10.lwn
[17:25:14] <jmkasunich> the whole point of rtapi_types.h is to have a type that can be used in either space interchangably
[17:26:47] <SWPadnos> right, but rtapi_types can include only linux/types.h, then typedef the HAL_* types from that one header (according to that article)
[17:26:54] <jmkasunich> oh
[17:27:11] <SWPadnos> or maybe I'm misunderstanding the article. I'm multitasking a bit here ;)
[17:27:53] <jmkasunich> I have no issue with how rtapi_types implements the types really, I just want to know A) what is the preferred fixed size type, and B) what do I need to include to get it
[17:28:04] <jmkasunich> the answer is A) u32 and B) rtapi_types.h
[17:28:14] <jmkasunich> (I think)
[17:28:32] <jmkasunich> I also need 8 and 16, and they aren't in rtapi_types.h (yet)
[17:32:41] <SWPadnos> they were removed, actually
[17:32:50] <jmkasunich> I wonder why?
[17:32:56] <SWPadnos> when the shorter HAL ints were taken out
[17:33:03] <SWPadnos> "too many HAL types" ...
[17:34:00] <jmkasunich> are you sure... cvs shows rtapi_types.h at version 1.1
[17:34:05] <jmkasunich> they were never in there
[17:34:23] <jmkasunich> the hal_u8 types were removed, but not plain old u8
[17:34:44] <SWPadnos> ah, ok
[17:35:08] <SWPadnos> sorry - I'm trying to print the Sonja McFarlane paper for my mother, and the laser printer decided that it can't detect paper in the tray
[17:35:19] <jmkasunich> thats ok
[17:35:24] <SWPadnos> which is a PITA when you're trying to print the back side of a 164 page paper
[17:35:31] <SWPadnos> back sides
[17:35:36] <jmkasunich> ouch
[17:36:00] <SWPadnos> beep beep beep - press go button - one page prints - beep beep beep ...
[17:36:08] <jmkasunich> that requires concentration, if you don't want page 120 on the back of 115 - I'll leave you alone ;-)
[17:36:12] <SWPadnos> much slower than 17 PPM that way
[17:36:12] <SWPadnos> heh
[17:36:40] <SWPadnos> and you never know when it'll reprint the last page (if it detects an error), or decide it was OK and go on to the next one ...
[17:43:08] <jmkasunich> hmm, it seems like we should really be using __u32, not u32
[17:43:37] <jmkasunich> * __xx is ok: it doesn't pollute the POSIX namespace. Use these in the
[17:43:36] <jmkasunich> * header files exported to user space
[17:43:44] <jmkasunich> thats regarding __xx
[17:43:55] <jmkasunich> * These aren't exported outside the kernel to avoid name space clashes
[17:44:04] <jmkasunich> thats regarding xx
[17:44:31] <jmkasunich> seems like we should standardize on the __xx ones, for both kernel and user
[20:27:28] <jmkasunich> I managed to break something:
[20:27:39] <jmkasunich> Depending emc.1
[20:27:38] <jmkasunich> make: Failed to remake makefile `Makefile'.
[20:27:38] <jmkasunich> make: Failed to remake makefile `Makefile'.
[20:27:38] <jmkasunich> make: Entering directory `/home/jmkasunich/emcdev/emc2head/src'
[20:28:09] <alex_joni> there was a thing jepler said earlier about how to debug that
[20:28:17] <SWPadnos> don't do that!
[20:28:19] <SWPadnos> :)
[20:28:41] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?FailedToRemakeMakefile
[20:28:54] <alex_joni> yay, glad it was a cache-hit
[20:30:20] <jmkasunich> ah, so make clean fixes it
[20:30:52] <jmkasunich> and thats why the farm didn't barf - its been 12 hours since the last commit, so the farm did a complete build (with make clean)
[20:30:55] <jmkasunich> thanks!
[20:32:15] <alex_joni> np