Back
[00:00:11] <rayh> Some might think that was a big exception.
[00:00:13] <steve_stallings> Doze has the equivalent, but you know that.
[00:00:25] <SWPadnos> heh - tep, somewhere in the TCP/IP dialogs
[00:00:28] <SWPadnos> yep, that is
[00:01:28] <SWPadnos> any mail shenanigans going on there?
[00:02:32] <rayh> What sort of shenanigans we talking about?
[00:02:32] <SWPadnos> Not sure
[00:02:32] <SWPadnos> there are mail servers set up on Dreamhost by default
[00:02:45] <SWPadnos> I wasn't sure if there area ny mail accounts on the current machine
[00:02:52] <SWPadnos> ... are any ...
[00:02:58] <rayh> No
[00:03:08] <rayh> not for linuxcnc.org
[00:03:08] <SWPadnos> ok. would you like some? ;)
[00:03:30] <rayh> eh. We've done without for quite a while.
[00:03:35] <SWPadnos> heh
[00:03:55] <rayh> How does dreamhost handle these?
[00:04:02] <SWPadnos> how do you mean?
[00:04:30] <rayh> If we did setup a webmaster@linuxcnc.org would there be a charge.
[00:04:44] <SWPadnos> nope
[00:05:01] <SWPadnos> I might be limited to 3000 email addresses
[00:05:10] <rayh> Then I want doG@linuxcnc.org;
[00:05:14] <SWPadnos> though it could also be unlimited - I don't remember
[00:05:17] <SWPadnos> heh
[00:05:42] <steve_stallings> There is mail service currently supported for webmaster@linuxcnc.org
[00:06:00] <rayh> Ah. We would need to transfer that?
[00:06:01] <SWPadnos> is it forwarded?
[00:06:04] <steve_stallings> It is currently a mailing list with steves, rayh, and danf subscribed
[00:06:24] <SWPadnos> ok. I think I can add that, though I'm not sure how to do it yet
[00:06:40] <rayh> That sounds good to continue.
[00:07:16] <rayh> SWPadnos, You around tomorrow morning?
[00:07:24] <SWPadnos> I should be for a little bit
[00:07:36] <rayh> Perhaps we can get with alex and finalize the details.
[00:07:45] <SWPadnos> ok - I see the page. I'll set up the mail forwarding right now
[00:07:55] <SWPadnos> steve - do you want to remain on the list?
[00:08:18] <SWPadnos> oh, and what's dave-e's address?
[00:08:40] <rayh> ??
[00:08:46] <SWPadnos> email address
[00:09:02] <SWPadnos> for the distribution list for webmaster@linuxcnc.org
[00:09:35] <SWPadnos> ok. dengvall@charter
[00:09:36] <rayh> dengvall@charter.net
[00:10:04] <SWPadnos> I suppose I should replace steves with steveWP ;)
[00:10:24] <rayh> But the list of webmasters was danfalck not davee
[00:10:29] <SWPadnos> oops
[00:10:36] <rayh> np
[00:10:38] <SWPadnos> ok, so how about his address instead ;)
[00:11:13] <SWPadnos> dave might have gotten surprised ;)
[00:11:52] <rayh> Dan Falck <dfalck@verizon.net>
[00:12:09] <rayh> He'd be on the phone to me in minutes.
[00:12:14] <SWPadnos> ok, thanks
[00:12:21] <rayh> thank you.
[00:14:03] <SWPadnos> oh, it's 12000 email accounts
[00:14:10] <SWPadnos> but only 375 shell accounts
[00:14:35] <rayh> That ought to be enough for a while.
[00:14:45] <SWPadnos> one or two thousand years, I think ;)
[00:15:22] <steve_stallings> SWP - I have set up my spare domain "metalworking.net" so that the old LinuxCNC contents will continue to show up there so you can pull off stuff even after the switch, just ignore the admin subdirectory.
[00:15:34] <SWPadnos> ok. thanks
[00:16:12] <SWPadnos> I think Alex has copied over most everything
[00:16:26] <SWPadnos> out of curiosity, what is your internet connection?
[00:16:52] <steve_stallings> current box is on 384K SDSL business with fixed IPs
[00:17:04] <SWPadnos> hmmm. ok
[00:17:22] <steve_stallings> Also have a cable modem for regular use.
[00:17:56] <SWPadnos> I was wondering about the total monthly data transfer you can do
[00:17:59] <rayh> wow network solutions is a regular spam generator.
[00:18:08] <steve_stallings> Not sure what I will be getting at the new place.
[00:18:10] <SWPadnos> so 384k is the number
[00:18:27] <SWPadnos> rayh, yeah - they love to send you notices that your domain is about to expire
[00:18:36] <SWPadnos> especially when you're registered elsewhere
[00:18:41] <steve_stallings> Current SDSL account is bandwidth limited, but no transfer limits other than that.
[00:18:48] <rayh> Well I've got a few years yet.
[00:18:50] <SWPadnos> right
[00:19:02] <SWPadnos> how long is the domain registered for?
[00:19:27] <rayh> couple more years.
[00:19:38] <rayh> They had a special a few back.
[00:19:56] <SWPadnos> good. just remember your handle ;)
[00:20:24] <SWPadnos> by the way, if I ever actually need to use my bandwidth, Dreamhost does 1/2 price hosting for non-profits
[00:20:54] <SWPadnos> (not that I expect to need it, since it goes up by 64GB/month every month)
[00:21:13] <steve_stallings> Yea, and the EMC bunch is gonna set up a legal non-profit real soon now.....
[00:21:50] <SWPadnos> heh
[00:22:04] <steve_stallings> You missed that meeting 8-)
[00:22:11] <SWPadnos> there's so much spare time for that kind of thing
[00:22:23] <SWPadnos> lucky me ;)
[00:23:03] <SWPadnos> ok. rayh if I'm not around tomorrow morning, then let Alex know that he should fix the references to cncgear.com
[00:23:23] <rayh> I don't know what you mean.
[00:23:25] <SWPadnos> I just loaded up the page as linuxcnc.org, and there are a lot of images and things that get loaded from cncgear
[00:23:29] <rayh> phone
[00:23:31] <SWPadnos> ok
[00:31:21] <jmk_cf> when you change the DNS for linuxcnc.org, the compile farm is probably gonna barf
[00:31:39] <jmk_cf> unless we set up a compile_farm/ dir under the root level dir
[00:31:48] <SWPadnos> I can do that
[00:31:51] <jmk_cf> and populate it with a few choice files
[00:32:17] <jmk_cf> I'm in the middle (well, maybe early) stages of moving the farm to new HW
[00:32:25] <jmk_cf> or at least experimenting with it
[00:32:42] <jmk_cf> got the dual P3-600 HP server running ubuntu
[00:32:46] <SWPadnos> cool
[00:32:48] <jmk_cf> with an SMP kernel
[00:32:52] <SWPadnos> did lvm ever work?
[00:33:09] <jmk_cf> I did the install without it, left lots of free space on the disks
[00:33:25] <jmk_cf> since then I've created PVs, a VG, and a LV
[00:33:35] <jmk_cf> and made a fs on that LV
[00:33:39] <jmk_cf> just need to mount it now
[00:33:51] <jmk_cf> I'm wondering something tho...
[00:33:56] <jmk_cf> you can probably help ;-)
[00:34:00] <SWPadnos> uh-oh
[00:34:03] <SWPadnos> :)
[00:34:05] <jmk_cf> I want to mount the new partition on /home
[00:34:19] <jmk_cf> right now /home isn't a partition, its just part of /
[00:34:31] <jmk_cf> but it does have my home dir in it, and a few files
[00:34:44] <jmk_cf> how to I avoid messiness when I mount over top of that
[00:35:05] <jmk_cf> do I mount the new volume elsewhere first and copy the directories into it?
[00:35:11] <SWPadnos> you should probably move all the files/dirs over to the other partition, then mount it on an empty /home
[00:35:13] <SWPadnos> yes
[00:35:32] <jmk_cf> something like thisL
[00:35:34] <jmk_cf> :
[00:35:35] <SWPadnos> there are unionfs options, but I suspect they're messy to set up
[00:35:49] <SWPadnos> mount /dev/sdb1 /mnt/temp
[00:35:58] <jmk_cf> mount /dev/cf_vg/home_lv /mnt/temo
[00:36:21] <jmk_cf> /mnt/temp even
[00:36:31] <jmk_cf> then for the move, can I literally do a mv?
[00:36:36] <SWPadnos> yep
[00:36:49] <SWPadnos> or cp -R (and whatever else to preserve permissions)
[00:36:50] <jmk_cf> mv /home /mnt/temp
[00:37:10] <SWPadnos> you may need /home/* /mnt/tmp
[00:37:17] <SWPadnos> to prevent a home dir under the root
[00:37:22] <SWPadnos> (of the second volume)
[00:37:30] <jmk_cf> yeah
[00:37:38] <jmk_cf> I really only want to copy the user dir
[00:37:46] <SWPadnos> and there's likely a recursive option, if it isn't on by default
[00:38:31] <jmk_cf> if I do mv, that means that as soon as the mv completes, there is no longer a /home/john
[00:38:42] <SWPadnos> I guess it's recursive, and you can't tell it not to be
[00:38:44] <jmk_cf> since john is logged in, isn't that a problem?
[00:39:06] <SWPadnos> as long as you're not there, it shouldn't be a problem for long
[00:39:16] <jmk_cf> so cd to somewhere else
[00:39:20] <jmk_cf> do the mv
[00:39:29] <SWPadnos> I'd do that, but it's probably not necessary
[00:39:45] <SWPadnos> you could log in as root, so you'd be in the /root dir anyway
[00:39:53] <jmk_cf> then umount /mnt/tmp, and mount /dev/cf_vg/home_lv /home
[00:40:01] <SWPadnos> system management is after all a root function
[00:40:36] <jmk_cf> ubuntu strongly discourages a root account
[00:40:58] <jmk_cf> to the extent that the initial root account has no password and can't be logged into
[00:41:04] <SWPadnos> it'll likely work either way
[00:41:14] <jmk_cf> there are workarounds, but I'd have to go googing for them
[00:41:17] <SWPadnos> yes, they're emulating OSX
[00:41:41] <jmk_cf> well, here goes nuttin
[00:41:46] <SWPadnos> it's in GDM setup - "allow root logins", and I can't remember if the password is the initial user or blank
[00:44:40] <jmk_cf> well it seems to have worked
[00:44:48] <SWPadnos> cool
[00:44:54] <jmk_cf> now I need an fstab entry to do it automagically on boot
[00:45:00] <SWPadnos> yep
[00:46:16] <jmk_cf> isn't mtab supposed to tell you the current mounts?
[00:46:28] <SWPadnos> yes
[00:46:45] <SWPadnos> but I think it's a link to /proc/mtab or /proc/mounts now
[00:47:11] <SWPadnos> nope - I guess not
[00:47:16] <SWPadnos> at least not on a BDI
[00:47:16] <jmk_cf> thanks, its /proc/mounts (I had already tried /proc/mtab
[00:47:37] <jmk_cf> mtab and /proc/mtab don't exist on ubuntu
[00:47:59] <SWPadnos> ah - it's a link in /proc
[00:48:17] <SWPadnos> interesting - I still have /etc/mtab
[00:49:07] <SWPadnos> any specific files you want in comple_farm/ ?
[00:50:02] <jmk_cf> everything that is in linuxcnc.org/compile_farm/
[00:50:18] <SWPadnos> I can't get a listing, unless it's available via anonymous ftp
[00:50:21] <jmk_cf> except the farm_scripts subdir, thats obsolute
[00:50:28] <jmk_cf> obsolete even
[00:50:39] <jmk_cf> stand by
[00:51:06] <rayh> SWPadnos, I can give you my login info for linuxcnc.
[00:51:16] <jmk_cf> or I could do that
[00:51:25] <SWPadnos> ok. any username / password will do it, then I can scp the files over
[00:51:37] <SWPadnos> I can try wget -r as well
[00:51:51] <jmk_cf> does that get non-html files?
[00:51:57] <SWPadnos> dunno
[00:52:05] <SWPadnos> it probably doesn't get anything that has no links
[00:52:10] <jmk_cf> actually, looking at the dir theres a lot of cruft in there
[00:52:35] <SWPadnos> I'll copy all the cruft then ;)
[00:52:39] <jmk_cf> try wget on index.html
[00:52:44] <jmk_cf> that should avoid the cruft
[00:52:52] <jmk_cf> it if isn't linked to the main page, it doesn't matter
[00:53:17] <SWPadnos> true enoug
[00:53:19] <SWPadnos> h
[00:54:49] <jmk_cf> the more I look, the more cruft I see - wget is the right way to do it I think
[00:55:56] <SWPadnos> almost done via wget (though it's stopped for some reason)
[00:56:30] <jmk_cf> wonder if the farm is doing an ftp put
[00:56:35] <SWPadnos> ah - there it goes again
[00:56:43] <SWPadnos> 1.6M - impressive
[00:57:33] <jmk_cf> 95% of that is probably the build logs
[00:57:50] <SWPadnos> yep
[00:57:56] <jmk_cf> which get replaced after each build
[00:58:00] <SWPadnos> all but 4283 bytes, in fact
[00:58:05] <SWPadnos> (index.html)
[00:58:21] <jmk_cf> well, the ones called foo_history are a different log
[00:58:23] <SWPadnos> the histories are only around 5-7k each
[00:58:35] <jmk_cf> the histories gain one line for every build
[00:58:40] <jmk_cf> so they grow
[00:58:50] <jmk_cf> the logs get replace, so they don't grow
[00:58:59] <SWPadnos> right
[00:59:21] <SWPadnos> so ~35k or so is slolwly growing
[00:59:30] <jmk_cf> yeah, very slowly
[00:59:40] <jmk_cf> 30 bytes per build perhaps
[00:59:43] <SWPadnos> yep
[01:00:05] <jmk_cf> times 4 slots and an absolute max of 24 builds/day = 2K per day
[01:00:33] <jmk_cf> realistically we have maybe 6-8 builds on a busy day, 2-3 on a normal day
[01:00:42] <SWPadnos> even with the farm doing a build every hour, and saving the entire log, the rate is only ~1G every 3 weeks
[01:01:00] <SWPadnos> that's less than the increase in storage that I get, which is 480M / week
[01:01:11] <jmk_cf> I still work in a world where you don't say "only 1 gig" ;-)
[01:01:18] <SWPadnos> heh
[01:01:26] <SWPadnos> me too, most of the time
[01:01:36] <SWPadnos> it's more like "I get 128k - wow!!"
[01:01:58] <SWPadnos> but then again, I was asked to estimate the feasibility of saving all data from 75 HD cameras
[01:02:24] <SWPadnos> I think it was 40 TB per event
[01:02:33] <SWPadnos> (or per hour - I forgot)
[01:02:37] <jmk_cf> HD as in high def tv? or stills?
[01:02:41] <jmk_cf> video I guess
[01:02:47] <SWPadnos> yep - video
[01:02:51] <SWPadnos> uncompressed
[01:03:21] <jmk_cf> 1TB = 4 big harddisks = $600-800, right?
[01:03:42] <SWPadnos> you need about 150 hard disks to be able to store the data fast enough though
[01:03:58] <SWPadnos> actually, 2 hard disks, $600
[01:04:01] <jmk_cf> 2 disks per camera?
[01:04:05] <SWPadnos> if you do it as 3, it's only $400
[01:04:07] <SWPadnos> yep
[01:04:10] <SWPadnos> 150MB/second
[01:04:18] <jmk_cf> doing it as 3 gives you more bandwidth too
[01:04:21] <SWPadnos> way too much for streaming to a single drive
[01:04:24] <SWPadnos> yep
[01:04:27] <jmk_cf> (but more power and space)
[01:04:42] <SWPadnos> that would be the full rack in the production van
[01:04:50] <SWPadnos> plus 75 fiber line sto the cameras
[01:04:55] <SWPadnos> lines to
[01:05:11] <rayh> bbl
[01:05:20] <jmk_cf> seems like you want to modularize it - one box per camera, rather than a huge thing
[01:05:25] <rayh> rayh is now known as rayh_away
[01:06:15] <SWPadnos> I mentioned that it would probably cost an extra $1.2 million or so, so I think it's not going to be an issue ;)
[01:06:17] <jmk_cf> seems the real bottleneck would be the cpu in the "fiber -> cpu -> disk" pipeline
[01:06:41] <SWPadnos> I'd use a SAN-style array
[01:06:53] <SWPadnos> I found one that can do 3.2GB/second, I think
[01:07:02] <SWPadnos> it uses 1120 hard disks to get that
[01:07:22] <jmk_cf> thats still only 18-20 cameras
[01:07:27] <SWPadnos> ok, it was 40TB/hour
[01:07:40] <SWPadnos> it's half the bandwidth I'd need
[01:07:52] <SWPadnos> oops, 1/3
[01:08:11] <jmk_cf> the network seems like the bottleneck
[01:08:17] <SWPadnos> that was a direct-connect infiniband array, too
[01:08:35] <SWPadnos> infiniband can do 10 Gb/sec, per channel
[01:08:51] <SWPadnos> and it's normally used with 4x connectors, or 40gb/sec (or so)
[01:08:51] <jmk_cf> the fiber from the channel is what? inifiniband?
[01:09:07] <jmk_cf> s/channel/camera
[01:09:09] <SWPadnos> I'd do 10gig-E for each camera
[01:09:10] <jmk_cf> brainfarts
[01:09:36] <SWPadnos> then aggregate something like 15 or 25 into a single array
[01:09:51] <jmk_cf> can a "PC" handle one camera's worth of data, or does it require dedicated hardware
[01:10:29] <jmk_cf> duh, a PCI bus tops out at 166MB/sec, right?
[01:10:34] <SWPadnos> it depends. there's actually an open-source effects program that can do effects on full HD (1080p) in realtime
[01:10:41] <SWPadnos> PCI is 132M
[01:10:54] <jmk_cf> can't get 150MB/s in and back out over a PCI bus then
[01:11:14] <SWPadnos> most newer computers don't have the network connected to the PCI bus
[01:11:40] <jmk_cf> what about the disk controller(s)?
[01:11:49] <jmk_cf> how fast is serial ATA?
[01:11:55] <SWPadnos> those are often on HT as well, in Opteron systems
[01:12:05] <SWPadnos> SATA is 150 or 300MB/sec (bytes)
[01:12:19] <jmk_cf> can you stripe the incoming data to a pair of SATA disks then
[01:12:32] <jmk_cf> that is a one CPU, two disk per camera solution
[01:12:32] <SWPadnos> yes, for each camera ;)
[01:12:36] <jmk_cf> use blades
[01:12:44] <jmk_cf> very scalable that way
[01:12:58] <SWPadnos> yep, though you need blades with 2 disks
[01:13:02] <jmk_cf> bringing it all into one massive SAN doesn't scale as well
[01:13:33] <SWPadnos> actually, it does, since you add SAN hardware if you want more cameras
[01:13:54] <jmk_cf> guess I don't understand SAN very well
[01:14:09] <SWPadnos> that's just the interconnect, really
[01:14:14] <jmk_cf> isn't there a backbone that everything travels over?
[01:14:24] <SWPadnos> there can be multiple interconnects
[01:14:25] <jmk_cf> blades means there is no common pipeline
[01:15:06] <SWPadnos> I think you could have a single backbone that connects all the storage devices and the computers, then connect another port(s) on each storage unit to some section of the camera array
[01:15:07] <jmk_cf> seems like 75 blades, even if they're $5000 each, still comes in at "only" $375K
[01:15:26] <SWPadnos> that's true
[01:15:40] <SWPadnos> but then you have no eassy way of archiving all that data (to tape or whatever)
[01:16:00] <SWPadnos> the SAN-style solution has all the data in a central store
[01:16:33] <SWPadnos> but it's a moot point anyway (as far as I know), because they won't want a 75-fiber cable going to the camera array
[01:16:42] <jmk_cf> what would be used for archiving anyway?
[01:16:56] <SWPadnos> digibeta or other video storage tape
[01:16:58] <jmk_cf> unless you have 75 tape drives, it would take years to copy it all
[01:17:06] <SWPadnos> indeed it would
[01:17:18] <SWPadnos> there were a number of problems with the "total archiving" idea
[01:18:04] <jmk_cf> you have mentioned both fiber and 10G ethernet as camera conns
[01:18:11] <jmk_cf> or is 10G ethernet a fiber?
[01:18:27] <SWPadnos> 10G ethernet can be fiber, I'm not sure about copper
[01:18:55] <SWPadnos> it has to be fiber due to distance, and it's more noise immune anyway
[01:19:04] <jmk_cf> they don't want 75 fibers going to the camera array tho...
[01:19:12] <jmk_cf> what about a blade at each camera?
[01:19:37] <SWPadnos> no, in the current plan, there will be one fiber per "set" of cameras (25 maybe), and those will come back to a fiber switch
[01:19:44] <SWPadnos> way way too heavy
[01:19:58] <jmk_cf> what are the cameras watching anyway?
[01:20:15] <SWPadnos> this thing is going to be suspended from 200' cables, and it needs to be around 200 pounds or less
[01:20:21] <SWPadnos> sports and things
[01:20:42] <jmk_cf> is this that thing that "flys" over stadiums
[01:20:44] <jmk_cf> ?
[01:20:50] <SWPadnos> SkyCam?
[01:20:55] <jmk_cf> I gues
[01:21:03] <SWPadnos> no, but it could be one day ;)
[01:21:06] <jmk_cf> the one that sometimes can be seen during a football game
[01:21:23] <SWPadnos> I think we'll be working with them, actually
[01:21:35] <jmk_cf> but you're putting 25 cameras up there?
[01:21:41] <SWPadnos> 75
[01:21:43] <jmk_cf> is this for "bullet time" effects?
[01:21:47] <SWPadnos> yep
[01:22:03] <SWPadnos> do you remember when CBS did their "EyeVision" array at some superbowl?
[01:22:10] <jmk_cf> no
[01:22:15] <SWPadnos> ok, me either ;)
[01:22:33] <SWPadnos> anyway, I helped design a film "bullet time" system
[01:22:50] <SWPadnos> and if my customer ever gets the financing in order, we'll do a digital one
[01:22:55] <jmk_cf> if a block of 25 cameras is connected to one fiber, you can't possibly get all the data from all the cameras in RT can you?
[01:23:15] <SWPadnos> nope. the cameras will each have a buffer, probably around 4G
[01:23:27] <SWPadnos> you tell them to stop capturing whn you're outputting the effect
[01:24:00] <jmk_cf> so the effect is assembled locally, and you output a single video stream?
[01:24:11] <SWPadnos> yep
[01:24:12] <jmk_cf> local to the array
[01:24:35] <jmk_cf> and the "save everything" was a bonus feature, not a main goal
[01:24:36] <SWPadnos> I think I'll have each camera "pre-process" its images, and a single box that takes the images and outputs an HD datastream
[01:24:39] <SWPadnos> right
[01:25:24] <jmk_cf> when you say you'll have a "camera" do pre-processing, I assume you mean some hardware hooked to the camera?
[01:25:27] <SWPadnos> saving everything is good if you want to make DVDs later
[01:25:33] <SWPadnos> FPGA in the camera
[01:25:35] <jmk_cf> a camera's just a camera
[01:25:41] <SWPadnos> I'm designing the camera as well
[01:25:47] <jmk_cf> oh
[01:26:01] <jmk_cf> I was wondering where you were gonna get small, light HD cameras
[01:26:12] <jmk_cf> how far "down" into the camera are you designing?
[01:26:24] <jmk_cf> CCD interfaces and such, or is that available prepackaged?
[01:26:26] <SWPadnos> there are some available, but they're in the $7k to $12k range
[01:26:34] <SWPadnos> from the CMOS sensor out
[01:26:41] <jmk_cf> wow
[01:26:41] <SWPadnos> but not the sensor
[01:26:48] <SWPadnos> yeah - it's a big project
[01:27:05] <SWPadnos> I wish the guy would get in gear - I may starve before he gives the go-ahead
[01:27:39] <jmk_cf> question - since you are getting deep into the camera, have you consideded embedding a disk in the camera itself?
[01:27:59] <SWPadnos> I did, but there would need to be two or three of them, and the weight / power are issues
[01:28:06] <jmk_cf> let the fpga pipe data direct to the disk
[01:28:19] <SWPadnos> still got that 150MB/sec problem
[01:28:33] <SWPadnos> and that's the raw data. processed, it's close to 3x that
[01:28:50] <SWPadnos> maybe 2x if I reduce it to 8 or 10 bit color
[01:29:08] <jmk_cf> what processing?
[01:29:23] <SWPadnos> converting from bayer-pattern RGB to "stacked" RGB
[01:29:36] <jmk_cf> whats bayer pattern?
[01:29:58] <SWPadnos> a 1024x1024 color array only has 1024^2 sensors, and there's a color filter over them
[01:30:09] <SWPadnos> so you get RGRGRGRG on one ro, and GBGBGBGBGB on the next
[01:30:12] <SWPadnos> row
[01:30:30] <SWPadnos> so you have to interpolate the 3 color channels to get RGB at each pixel location
[01:30:35] <jmk_cf> 4 sensor cells per pixel then?
[01:30:47] <SWPadnos> but you also triple the anmount of data (before you compress it ;) )
[01:31:00] <SWPadnos> yes, but they're all called "pixels", not "subpixels"
[01:31:15] <jmk_cf> oh, you don't make a 2x2 array into one pixel
[01:31:19] <SWPadnos> there are a couple of sensors that sense more like film, with stacked wells
[01:31:27] <SWPadnos> nope, you cut the resolution to 1/4 that way
[01:31:28] <jmk_cf> you use each cell for 4 pixels
[01:31:33] <SWPadnos> yep
[01:31:47] <SWPadnos> that's what "unsharp mask" is for in photo editing programs
[01:32:02] <SWPadnos> it gets rid of the slight blurriness that results from the interpolation
[01:33:12] <SWPadnos> damn - Dreamhost has "one-click-install" for subversion now :O
[01:33:23] <jmk_cf> so the bayer to RGB conversion is done in the camera FPGA?
[01:33:28] <SWPadnos> yes
[01:33:51] <SWPadnos> along with rotation, scaling, and translation, in this case (and color correction)
[01:33:59] <SWPadnos> and noise elimination
[01:34:21] <jmk_cf> given the issues you have with bandwidth, wouldnt' it be better to defer data bloating processing until as late as possible?
[01:34:47] <SWPadnos> it would, unless you have a hard time processing everything with a single "CPU"
[01:34:59] <SWPadnos> (which could be a 16-core machine)
[01:35:28] <SWPadnos> scaling / rotation requires about 16x the bandwidth of raw storage of data
[01:36:01] <steve_stallings> steve_stallings is now known as steves_logging
[01:36:08] <SWPadnos> the color correction and other stuff is probably about 8x or more, so I'm probably looking at 25-30x bandwidth for all the processing
[01:36:25] <SWPadnos> if that results in 2x the data, it's still a win at the central controller
[01:36:38] <jmk_cf> how so?
[01:37:02] <jmk_cf> X processing chips at the camera vs X processing chips at the central controller seems a wash
[01:37:03] <SWPadnos> well, the controller only needs to move 2x the data, instead of doing processing and moving it around 30x
[01:37:16] <jmk_cf> but 2x data transfer between the two..
[01:37:16] <SWPadnos> lots more cables if you use remote processing
[01:37:47] <SWPadnos> if you process at the camera, then the total needed bandwidth is 30 frames/second, regardless of the array size
[01:38:26] <jmk_cf> either I don't understand the environment very well, or we're not communicating very well
[01:38:33] <SWPadnos> heh - could well be ;)
[01:38:51] <SWPadnos> first, leave out the idea of "total storage"
[01:39:16] <SWPadnos> we have 75 cameras, and we want 3 live feeds (from some selected cameras on the "floating" platform)
[01:39:39] <jmk_cf> sensor - "wire" - sensor signal conditioning - "wire" - bayer-RGB - "wire" - transforms, etc - "wire" - demux to one of 25 cameras - "wire" - output
[01:39:59] <jmk_cf> some wires are very short (on the same PCB, or even the same chip) others are long
[01:40:15] <jmk_cf> you are talking about having all but the very last wire at the array?
[01:40:30] <SWPadnos> I'm not sure I understand the "demux to 25 cameras" step
[01:40:37] <SWPadnos> one of 25 ...
[01:40:50] <jmk_cf> pick one of 25 camera, toss the rest of the data in the bitbucket
[01:40:59] <jmk_cf> mux, not demux, my mistake
[01:41:03] <SWPadnos> nope - we want some data from all cameras
[01:41:06] <SWPadnos> ok
[01:41:26] <jmk_cf> "some" data from "all" cameras?
[01:41:26] <SWPadnos> every camera contributes one frame for the final effect
[01:41:43] <jmk_cf> all that means is you switch the mux every frame
[01:41:52] <SWPadnos> and the transforms have different coefficients for each camera
[01:41:55] <jmk_cf> its still muxing down to one channel
[01:41:58] <SWPadnos> yes
[01:42:11] <SWPadnos> bit at some point, you haev "wires", not "wire"
[01:42:30] <SWPadnos> and the number of wires can be significant if it's fiber on a 1000 foot spool
[01:42:43] <jmk_cf> "wire" = wire, fiber, bus, whatever
[01:42:49] <SWPadnos> (since you have to reel it in and out during setup)
[01:42:56] <jmk_cf> traces on a PCB, or interconnect on a chip
[01:43:17] <jmk_cf> given the 25:1 muxdown, I see why you want everything remote
[01:43:20] <SWPadnos> sure, but the cost of a PCB trace is very different from the cost of a 1000 foot fiber
[01:43:31] <jmk_cf> (remote from the controller, not remote from the camera)
[01:43:34] <jmk_cf> exactly
[01:43:37] <jmk_cf> thats what I was getting at
[01:43:46] <jmk_cf> when you divide things up you look at wire costs
[01:44:00] <jmk_cf> some wires have to be "fat" because the data is fat, so you make them short
[01:44:01] <SWPadnos> also, if the cameras can process their own frames, the datacan still be stored raw, it just causes a small altency before the data goes down the pike
[01:44:04] <SWPadnos> yep
[01:44:43] <jmk_cf> physically, the array isn't one box is it?
[01:45:02] <SWPadnos> no, it's a trss with cameras on it, plus some extra stuff
[01:45:05] <SWPadnos> truss
[01:45:29] <jmk_cf> you can mount each camera in a different spot, and they get tied to the mux part with moderate length "wires", then from the mux back to the van or whatever with a long "wire"?
[01:45:37] <SWPadnos> and if you want 100 cameras, it makes a lot of sense to have extra processing power, that doesn't drive you out of your van
[01:45:51] <SWPadnos> I hope so
[01:46:02] <SWPadnos> the idea is to put a switch on the truss
[01:46:07] <jmk_cf> so you are distributing the processing - seems natural
[01:46:13] <SWPadnos> yep
[01:46:21] <jmk_cf> distributed storage would make sense too
[01:46:28] <SWPadnos> plus the extra weight makes sense on the camera, not really in the van
[01:46:40] <jmk_cf> ?
[01:46:47] <jmk_cf> seems the other way around
[01:46:47] <SWPadnos> it would, but it's impractical due to power and weight reasons
[01:47:00] <jmk_cf> weight in the van doesn't get hung from the ceiling
[01:47:06] <SWPadnos> ie, if I have 300 cameras at one event, I don't want 4 racks in my van that's designed for 2
[01:47:14] <SWPadnos> so I still have room for my chair
[01:47:34] <jmk_cf> and how do the camera's get to the event? in another vehicle I suppose?
[01:47:37] <SWPadnos> it's expected that a 100-foot long truss will be heavier than a 50-foot long truss
[01:48:21] <SWPadnos> the truss itself witll be pretty small - around 25 feet for 75 cameras, and maybe 4 inches square in cross-section
[01:48:32] <SWPadnos> so it folds up pretty small
[01:49:12] <jmk_cf> what you have is a primary goal that is O(1), and a secondary goal that is O(n)
[01:49:21] <SWPadnos> yep
[01:49:36] <jmk_cf> if you mux at the truss, you really don't care how many cameras there are
[01:49:50] <jmk_cf> but to store anywhere other than the truss, it gets nasty
[01:50:08] <SWPadnos> right - every section (of 25 cameras, for instance) can have its own downlink. it needs support anyway, so more cables make sense
[01:50:12] <jmk_cf> you can only do the effects more-or-less live, right?
[01:50:18] <SWPadnos> that's the current plan
[01:50:25] <SWPadnos> 30-second buffer or thereabouts
[01:50:38] <jmk_cf> IOW, if you went right-to-left, and later changed your mind, you can't go back and do left-to-right
[01:50:39] <SWPadnos> it will be fun to order 300G of RAM though ;)
[01:50:58] <jmk_cf> better get a quantity discount
[01:51:03] <SWPadnos> as long as the system is paused (in effect output mode), you can go left, right, up, down , etc
[01:51:07] <SWPadnos> I hope so
[01:51:19] <SWPadnos> they may get 12 systems as well
[01:51:24] <SWPadnos> and they were talking about 30 before
[01:51:31] <jmk_cf> left/right/up/down? the array is 2?
[01:51:36] <jmk_cf> (I was thinking 25 in a row)
[01:51:40] <SWPadnos> time is one axis
[01:51:55] <SWPadnos> play from one camera, then shift across the array, then play again
[01:52:30] <SWPadnos> the captured images are basically a 2D array in (time, position)
[01:53:05] <jmk_cf> got it - 25 columns of 1800 frames (30 secs, 60 frames/sec) or something like that
[01:53:12] <SWPadnos> right
[01:53:20] <SWPadnos> only 75 per system ;)
[01:53:28] <jmk_cf> 75x1800 then
[01:53:31] <SWPadnos> yep
[01:53:56] <jmk_cf> and the goal with the bulk storage was to make it 75x216000
[01:54:00] <jmk_cf> (1 hour)
[01:54:03] <SWPadnos> 3 hours
[01:54:15] <SWPadnos> 40.5 TB/hour
[01:54:57] <jmk_cf> I find it easier (and interesting) to think in terms of 75 pipelines processing individual frames
[01:55:07] <jmk_cf> the cameras are fixed mount?
[01:55:22] <SWPadnos> they actually need some adjustment
[01:55:33] <SWPadnos> but not too much, I think (hope)
[01:55:35] <jmk_cf> but during the event they're not swinging all over the place
[01:55:45] <SWPadnos> no
[01:56:00] <SWPadnos> though that was one idea - 3-axis mounts for each one
[01:56:21] <jmk_cf> could you do delta compression in an FPGA? massively parallel if you can, per-scanline maybe
[01:56:43] <SWPadnos> yes, but that would increase readout latency
[01:57:04] <SWPadnos> since the requested frame would need to be built from the last key frame onward
[01:57:24] <jmk_cf> 4G of ram holds 1800 frames uncompressed, compressed data streams into disks for offline work where latency isn;t such a big factor
[01:57:39] <SWPadnos> true enough, for the storage option
[01:58:02] <jmk_cf> thats what I've been thinking about - for the core you're already way ahead of me
[01:58:04] <SWPadnos> though it still needs high bandwidth bursts for key frames and sudden changes
[01:58:19] <SWPadnos> heh - I hope so. I've been thinking about it for years
[01:58:43] <jmk_cf> a quarter gig holds several seconds uncompressed, that could ease the surges
[01:58:59] <jmk_cf> well, 1.7 seconds or so ;-)
[01:59:21] <jmk_cf> wait a minute - did you say that 4G would hold 30 seconds?
[01:59:47] <SWPadnos> looking at a section of 25 cameras, if they get 10:1 compression, they still need 25 * 150M / 10 = 375M / second - not bad
[01:59:49] <SWPadnos> yes
[01:59:53] <SWPadnos> roughly
[01:59:58] <SWPadnos> that's raw data
[02:00:00] <jmk_cf> sorry, I had a brainfart
[02:00:40] <jmk_cf> one fiber for the effect stream, another fiber or two for the storage stream
[02:00:41] <SWPadnos> so 1G/second for all cameras if compression is used
[02:00:45] <SWPadnos> yeah
[02:00:47] <jmk_cf> the additional fibers could be optional
[02:00:49] <SWPadnos> hat may be doable
[02:00:55] <SWPadnos> that
[02:01:42] <SWPadnos> it even makes it only 4 TB/hour - only a small array needed for that
[02:01:44] <jmk_cf> is the 4G ram going to be in each camera, or in the mux box?
[02:01:50] <SWPadnos> each camera
[02:02:06] <SWPadnos> I'd like to have as much as possible in each camera, because it makes it more generically usable
[02:02:28] <jmk_cf> so there will be 27/75 "wires" from camera to mux box each capable of handling a full video stream
[02:02:34] <SWPadnos> a camera that has ethernet for raw data only isn't as reusable as a camera that has an image processing FPGA in it
[02:02:47] <jmk_cf> even tho during effects playback the sum of all 25 is still only one stream
[02:03:06] <SWPadnos> there are other complications, but for the most part, yes
[02:04:31] <jmk_cf> let me see if I have the pipeline right
[02:04:37] <jmk_cf> sensor first of course
[02:04:53] <jmk_cf> then bayer/rgb translation
[02:05:06] <jmk_cf> then transforms, ram, and finally effects playback?
[02:05:23] <SWPadnos> kinda. here's my version:
[02:05:26] <SWPadnos> sensor
[02:05:32] <SWPadnos> noise elimination
[02:05:43] <SWPadnos> bayer / colorspace conversion
[02:05:53] <SWPadnos> geometric transforms
[02:06:12] <SWPadnos> storage, and possibly output of a live video stream
[02:06:19] <SWPadnos> (RAM storage, that was)
[02:06:25] <jmk_cf> right
[02:06:45] <SWPadnos> then effects playback, which requires some means of thimbnails or other indication to the operator of what they're going to play back
[02:06:53] <SWPadnos> thumbnails
[02:07:06] <jmk_cf> what are the geo transforms for?
[02:07:22] <SWPadnos> it's impossible to correctly align all the cameras by hand
[02:07:39] <SWPadnos> also, the truss bends a little as you lift it
[02:07:44] <jmk_cf> ok, but they're not for effects or anything dynamic - you set them and forget them
[02:08:16] <jmk_cf> (at the beginning of the event)
[02:08:24] <SWPadnos> yes, sort f
[02:08:26] <SWPadnos> of
[02:08:40] <jmk_cf> so the path from sensor to ram is constant
[02:08:42] <SWPadnos> basically, you can't aim perfectly by hand
[02:08:59] <jmk_cf> I think of this thing as a digital scope - running in roll mode most of the time
[02:09:11] <SWPadnos> it can be, because all the other processing can be done at the effect output stage
[02:09:17] <SWPadnos> yep
[02:09:27] <jmk_cf> 25/75 "traces" rolling across the screen
[02:09:32] <SWPadnos> then every once in a while, you hit stop, and you want to zoom in on a particular region
[02:09:35] <jmk_cf> live feed, you pick one
[02:09:53] <jmk_cf> or you stop, and swerve around the screen, from trace to trace and back/forth in time
[02:09:59] <SWPadnos> right
[02:10:15] <jmk_cf> ok, at the edge of the screen where the trace is about do fall off into the bitbucket
[02:10:17] <SWPadnos> so you need "cursors" to select what to play back for the effect
[02:10:21] <jmk_cf> do the delta compression
[02:10:39] <jmk_cf> toss it into another short buffer so keyframes and sudden action don't screw you
[02:10:58] <jmk_cf> and send that thru a lower bandwidth channel in parallel with the main feed, to a disk
[02:11:13] <SWPadnos> yep - that's doable
[02:11:29] <jmk_cf> dedicate X% of your ram to buffer, remove data at a constant rate
[02:11:42] <jmk_cf> if the buffer starts getting empty, take advantage of that by making another keyframe
[02:12:04] <SWPadnos> I'm not sure if it's in budget, but if I buy you a beer at Fest, you'll know they went for it ;)
[02:12:18] <jmk_cf> ok
[02:12:43] <jmk_cf> I wonder how much FPGA is actually needed to do delta compression on a stream like that
[02:13:20] <SWPadnos> not too much, I imagine. but an extra memory bus would take about 150 more pins
[02:13:32] <SWPadnos> (for DDR or the like)
[02:13:50] <jmk_cf> you're trying to do everything in one fpga?
[02:13:53] <SWPadnos> I'd like to use off-the-shelf memory if possible, for cost reasons
[02:13:59] <SWPadnos> per camera, yes
[02:14:13] <SWPadnos> something like a Xilinx Virtex or Lattice ECP/SC
[02:14:34] <jmk_cf> seems like the hard part isn't computing the delta frames, its compressing the resulting sparse data
[02:14:36] <SWPadnos> the 1-2M gate, 700+ pin beasts
[02:14:47] <SWPadnos> RLE is easy on an FPGA
[02:15:03] <SWPadnos> and it should be OK for sparse sets like that
[02:15:37] <jmk_cf> the FPGA->RAM path needs to handle full bandwidth tho, for the keyframes and other bursts
[02:15:45] <jmk_cf> the RAM->output path can be slower
[02:15:45] <SWPadnos> the problem becomes one of noise - a single bit difference isn't really a difference, but if you ignore them, then eventually you may have gone full scale
[02:15:51] <SWPadnos> yes
[02:16:11] <jmk_cf> don't ignore them, defer them
[02:16:16] <SWPadnos> I think the Lattice SC has 2 gigabit MACS and many DDR ports
[02:16:19] <SWPadnos> right
[02:16:34] <SWPadnos> I was thinking that - keep an "error term", and when it gets too high, it's a delta
[02:16:44] <jmk_cf> simpler (I think)
[02:16:54] <jmk_cf> normally for delta, you do:
[02:17:06] <jmk_cf> delta = new - old
[02:17:10] <jmk_cf> old = new
[02:17:15] <jmk_cf> but you could do
[02:17:18] <SWPadnos> or, keep the "reference" value, even if there's a small difference that you didn't output
[02:17:26] <jmk_cf> delta = new-old
[02:17:41] <jmk_cf> delta = ignore small(delta)
[02:17:48] <jmk_cf> old = old + delta
[02:17:57] <jmk_cf> yeah, thats what I was saying
[02:18:00] <SWPadnos> if (delta<X) { delta=0 } else {old=new}
[02:18:13] <jmk_cf> yes
[02:18:56] <SWPadnos> that's good, because it still uses only one "counter" per pixel
[02:18:57] <jmk_cf> you could get fancy - change X as a function of buffer space
[02:19:14] <jmk_cf> full buffer, raise X so you ignore more minor changes
[02:19:24] <jmk_cf> empty buffer, lower X for better quality
[02:24:59] <jmk_cf> you got very quiet....?
[02:28:26] <SWPadnos_> now *that* was annoying
[02:28:47] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[02:28:49] <SWPadnos> in fact, it still is annoying
[02:29:21] <jmk_cf> I wondered why you got so quiet
[02:29:23] <SWPadnos> I guess I need to see why my UPS suddenly decided to shut down my computer
[02:29:55] <jmk_cf> did you get the part about "change X as a function of buffer space"?
[02:29:57] <SWPadnos> it's especially bothersome because it's my main machine (Windows), and I had about 17 programs running
[02:30:03] <SWPadnos> nope
[02:30:06] <jmk_cf> ouch
[02:30:11] <jmk_cf> you could get fancy - change X as a function of buffer space
[02:30:15] <jmk_cf> full buffer, raise X so you ignore more minor changes
[02:30:18] <jmk_cf> empty buffer, lower X for better quality
[02:30:22] <SWPadnos> ah - right
[02:31:13] <jmk_cf> that assumes that you're streaming data out of the buffer to disk at a fixed rate
[02:31:31] <SWPadnos> yes
[02:31:44] <jmk_cf> I wonder how much compression you can get?
[02:31:51] <SWPadnos> I think the fastest drives today are in the 100M/sec range (believe it or not)
[02:32:02] <jmk_cf> MByte?
[02:32:12] <SWPadnos> yes
[02:32:22] <jmk_cf> a full stream is 150MYbte/sec, right
[02:32:29] <SWPadnos> per camera
[02:32:51] <jmk_cf> if you get 5:1 compression, that means 30Mbyte/sec
[02:33:08] <jmk_cf> or at least a couple cameras per disk, instead of a couple disks per camera
[02:33:08] <SWPadnos> that 100M is peak, not sustained. sustained is roughly 65-70 on those drives
[02:33:12] <SWPadnos> yes
[02:33:42] <SWPadnos> a single U360 channel could do maybe 10 cameras
[02:33:45] <jmk_cf> is the "mux box" mounted on each truss big enough for 10-20 disks?
[02:33:59] <SWPadnos> I don't think so
[02:34:27] <SWPadnos> ideally, it'll be a gigabit switch with PoE, and a 10G uplink or two
[02:34:31] <SWPadnos> plus a power supply
[02:34:41] <jmk_cf> so you'd still have to pipe the data all the way back to the van (or at least to the ground)
[02:34:47] <SWPadnos> yes
[02:35:12] <SWPadnos> I don't like the idea of needing to transfer data after the crew has taken the rig down
[02:35:18] <SWPadnos> people are usually tired at that point
[02:35:30] <jmk_cf> the switch is intended to be an off-the-shelf item?
[02:35:34] <SWPadnos> ideally
[02:35:57] <jmk_cf> IOW, its not doing the effects "muxing", each camera knows when its supposed to deliver a frame
[02:35:58] <SWPadnos> this is a <$1M project at this point. the fewer things I have to design, the better
[02:36:16] <SWPadnos> right - using a normal mux doesn;t work, as CBS found out
[02:36:17] <jmk_cf> and the switch just hands the frames down to the van
[02:36:20] <SWPadnos> right
[02:36:45] <jmk_cf> one packet per frame, MTU 3Mbytes ;-)
[02:36:48] <SWPadnos> the van still has some control over things, and can upload corrections to the geometric transform parameters, color correction tables, etc.
[02:36:49] <SWPadnos> heh
[02:37:14] <SWPadnos> well - thanks for the discussion. the delta / compression idea is really great
[02:37:21] <SWPadnos> I need to see what's wrong with my UPS
[02:37:23] <jmk_cf> hope it works out
[02:37:26] <SWPadnos> thanks
[03:19:02] <jmkasunich> jepler, you around?
[03:26:35] <jepler> jmkasunich: what's up?
[03:31:41] <jmkasunich> trying to understand make stuff
[03:31:54] <jmkasunich> Make.rules is no longer used at all is it?
[03:32:06] <SWPadnos> dunno
[03:32:15] <SWPadnos> I'm trying to understand my UPS ;)
[03:32:26] <jmkasunich> SWP: I was asking jepler.....)
[03:32:30] <SWPadnos> heh
[03:33:02] <jepler> jmkasunich: I think you're right that it's no longer used.
[03:33:05] <SWPadnos> I wondered that, but discounted the idea because it had been 2 minutes ;)
[03:34:04] <jepler> --cuddle-do-while
[03:34:14] <jmkasunich> what about Makefiles in other than the top level? you use Submakefiles now, right?
[03:34:25] <jepler> Yeah. I thought I'd removed all the top-level Makefiles, in fact
[03:34:42] <jepler> but I see that I didn't.
[03:34:57] <jmkasunich> john@ke-main-ubuntu:~/emcdev/emc2head/src$ find . -name Makefile
[03:34:57] <jmkasunich> ./hal/user_comps/vcp/Makefile
[03:34:57] <jmkasunich> ./Makefile
[03:34:57] <jmkasunich> ./rtapi/examples/extint/Makefile
[03:34:57] <jmkasunich> ./rtapi/examples/fifo/Makefile
[03:34:57] <jmkasunich> ./rtapi/examples/semaphore/Makefile
[03:34:59] <jmkasunich> ./rtapi/examples/shmem/Makefile
[03:35:01] <jmkasunich> ./rtapi/examples/timer/Makefile
[03:35:10] <jepler> and also several Makefile.lib
[03:35:55] <jmkasunich> in Makefile.inc, there is "RTFLAGS := -I$(INC_DIR) -I/usr/realtime-2.6.12-magma/include -I. $(RTFLAGS) -DRTAPI -D_GNU_SOURCE -Drealtime -D_FORTIFY_SOURCE=0"
[03:36:20] <jmkasunich> the -I$(INC_DIR) gets changed to -I <nothing>
[03:36:30] <jmkasunich> because INC_DIR is no longer used either
[03:37:39] <jepler> Yes.
[03:37:56] <jmkasunich> on my ubuntu box, emc2/include is full of headers (after a make)
[03:38:07] <jmkasunich> on the TNG box its empty
[03:38:12] <jepler> Interesting.
[03:38:14] <jmkasunich> (lemme double check that)
[03:39:13] <jmkasunich> yep, completely empty except the CVS subdir and .cvsignore
[03:39:19] <jepler> that's odd.
[03:39:38] <jepler> everything listed in HEADERS should be copied by the 'userspace' target
[03:39:43] <jmkasunich> there's no longer a "make headers" target, so how do the headers get copied?
[03:40:01] <jepler> TARGETS += $(patsubst %,../include/%,$(foreach h,$(HEADERS),$(notdir $h)))
[03:40:06] <jepler> userspace: $(TARGETS)
[03:41:07] <jmkasunich> and userspace is invoked before any actual compile targets (including realtime ones)?
[03:41:38] <jepler> userspace includes compile targets too (e.g., ../bin/halcmd)
[03:41:55] <jmkasunich> but headers get copied first?
[03:41:57] <jepler> the files in ../include aren't used in the build of emc2 itself, but they are used by the build of AXIS
[03:42:14] <jmkasunich> so how does emc2 itself get its includes?
[03:42:29] <jmkasunich> we have two errors during TNG compile:
[03:42:30] <jepler> Those directories are all -I'd
[03:42:40] <jmkasunich> 1) Depending rtapi/rtai_rtapi.c
[03:42:40] <jmkasunich> + egcs -M -I -I/usr/src/rtai-24.1.10/include -I. -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -march=i586 -DMODULE -DRTAI=1 -DEXPORT_SYMTAB -DRTAPI -D_GNU_SOURCE -Drealtime -D_FORTIFY_SOURCE=0 -D__MODULE__ -I/home/John/farm/emc2head/src -I/home/John/farm/emc2head/src/libnml/linklist -I/home/John/farm/emc2head/src/libnml/cms -
[03:42:40] <jmkasunich> I/home/John/farm/emc2head/src/libnml/rcs -I/home/John/farm/emc2head/src/libnml/inifile -I/home/John/farm/emc2head/src/libnml/os_intf -I/home/John/farm/emc2head/src/libnml/nml -I/home/John/farm/emc2head/src/libnml/buffer -I/home/John/farm/emc2head/src/libnml/posemath -I/home/John/farm/emc2head/src/rtapi -I/home/John/farm/emc2head/src/hal -I/home/John/farm/emc2head/src/emc/nml_intf -I/home/John/farm/emc2head/src/emc/kinemat
[03:42:44] <jmkasunich> ics -I/home/John/farm/emc2head/src/emc/motion -I/usr/include rtapi/rtai_rtapi.c
[03:42:44] <jmkasunich> rtapi/rtai_rtapi.c:102: rtai.h: No such file or directory
[03:42:46] <jmkasunich> rtapi/rtai_rtapi.c:103: rtai_sched.h: No such file or directory
[03:42:48] <jepler> what version of 'make' is on this system?
[03:42:48] <jmkasunich> rtapi/rtai_rtapi.c:107: rtai_shm.h: No such file or directory
[03:42:53] <jmkasunich> rtapi/rtai_rtapi.c:108: rtai_fifos.h: No such file or directory
[03:43:14] <jmkasunich> 3.79.1
[03:43:40] <jmkasunich> 2) Compiling libnml/inifile/inifile.cc -fPIC
[03:43:41] <jmkasunich> In file included from libnml/inifile/inifile.cc:27:
[03:43:41] <jmkasunich> libnml/inifile/inifile.hh:27: `LINELEN' was not declared in this scope
[03:44:00] <jmkasunich> LINELEN is #defined in config.h.in and config.h
[03:44:17] <jmkasunich> and config.h is included by inifile.hh, about 10 lines before the error
[03:44:30] <jepler> Maybe some other config.h is being included instead
[03:45:21] <jepler> Probably "-I -I/usr/src/rtai-24.1.10/include" is the reason rtai.h isn't being found.
[03:45:25] <jmkasunich> find emc2head -name config.h finds only the one in emc2head/src
[03:45:36] <jmkasunich> the extra blank I?
[03:45:40] <jepler> Yes
[03:45:47] <jmkasunich> I manually removed that, and it did seem to solve that problem
[03:45:56] <jmkasunich> no effect on the LINELEN one
[03:46:23] <jmkasunich> if INC_DIR isn't used anymore, I'll remove it from Makefile.inc.in
[03:46:43] <jepler> I sure don't see where INC_DIR would ever be set
[03:46:57] <jepler> do you want me to commit that change?
[03:47:21] <jmkasunich> I just made the change to Makefile.inc.in, so I'll commit
[03:47:27] <jepler> OK
[03:47:38] <jmkasunich> can you delete the unused subdir Makefiles and commit that?
[03:47:44] <jepler> yes
[03:49:04] <jmkasunich> CIA died, but my commit is done
[03:49:26] <jepler> mine too
[03:51:04] <jepler> is there a config.h in /usr/src/linux/include?
[03:51:13] <jmkasunich> lemme check
[03:51:23] <jepler> or rtai-*/include
[03:51:50] <jepler> if this isn't getting through the "depend" stage then it's no surprise that the include files aren't being copied.
[03:52:05] <jmkasunich> /usr/src/linux/include/linux/config.h
[03:52:42] <jmkasunich> I'll cvs up on the farm slot and see what happens
[03:53:40] <jepler> in depends/..../inifile.d does it give a path to config.h?
[03:53:57] <jepler> I'm also not sure why you got to a Compiling step if the Depending step failed
[03:57:16] <jmkasunich> gawd that computer is slow
[03:57:42] <jmkasunich> the "missing includes during the depends stage" problem is gone
[03:57:49] <jmkasunich> the LINELEN is still there
[03:58:12] <jmkasunich> lemme check that depends thing
[03:58:25] <jepler> OK .. I'll only be here for a few more minutes tonight
[04:00:03] <jmkasunich> it has a path to a config.h in /usr/src/......
[04:00:22] <jepler> that's probably not right
[04:00:33] <jmkasunich> nope
[04:00:44] <jepler> 'make -n' or removing a "@" will let you see the full commandline
[04:00:44] <jmkasunich> we want our own config.h
[04:00:49] <jepler> maybe something will pop out at you
[04:00:56] <jepler> like the order of the -I directives or something
[04:01:09] <jepler> is the other config.h the linux/include/linux/config.h one?
[04:01:14] <jepler> or something else?
[04:01:25] <jmkasunich> the one we want is emc2head/src/config.h
[04:01:29] <jepler> I know the one you want
[04:01:33] <jmkasunich> oh
[04:01:35] <jepler> I'm wondering which one you got
[04:03:02] <jmkasunich> either /usr/src/linux/include/linux/config.h or /usr/src/rtai-24.1.10/include/config.h
[04:03:10] <jmkasunich> actually they might be the same
[04:04:12] <jmkasunich> nope, /usr/src/linux is a symlink, but not to the rtai dir
[04:04:13] <jepler> the latter may correspond to an actual -I .. maybe it's the order of -I, or maybe I lost a -I-
[04:04:26] <jmkasunich> ok, I'll try make -n
[04:04:27] <jepler> compared to the old build system
[04:04:36] <jepler> I gotta go .. I'll be paying attention to irc at least part of the day tomorrow.
[04:07:02] <jmkasunich> I'll be in milwaukee tomorrow
[04:07:07] <jmkasunich> :-(
[04:07:23] <jmkasunich> the very first -I is the rtai one, the second one is -I.
[04:07:31] <jmkasunich> I suspect that -I. should be first
[04:08:02] <jmkasunich> cradek, you here?
[04:08:52] <cradek> yes
[04:09:29] <jmkasunich> I have the advantage of being able to access the farm slot, but the disadvantage of being stupid about the build system
[04:09:45] <cradek> that puts you one ahead of me
[04:10:00] <jmkasunich> I see that the first -I in the compile flags is the RTAI dir, and the second one is -I.
[04:10:05] <jmkasunich> should -I. be first?
[04:10:19] <cradek> what file are you trying to get? it does search them in order
[04:10:31] <jmkasunich> emc2head/src/config.h
[04:10:46] <cradek> but there's another config.h in the rtai directory?
[04:10:53] <jmkasunich> it seems to be getting /usr/src/rta-blah/include/config.h
[04:11:04] <jmkasunich> s/rta-blah/rtai-blah
[04:11:20] <cradek> what file is trying to include it?
[04:11:25] <cradek> sorry I wasn't paying attention
[04:11:37] <jmkasunich> inifile.hh, which is included from inifile.cc
[04:13:03] <cradek> seems like -I. first will fix that
[04:13:19] <jmkasunich> gonna try
[04:13:25] <jmkasunich> hope it doesn't break anything else
[04:13:33] <cradek> INCLUDE := -I$(RTDIR)/include $(patsubst %,-I%, $(INCLUDES))
[04:13:41] <cradek> is this the line you're changing?
[04:13:55] <jmkasunich> RTFLAGS := -I. -I@RTDIR@/include $(RTFLAGS) -DRTAPI -D_GNU_SOURCE -Drealtime -D_FORTIFY_SOURCE=0
[04:14:06] <jmkasunich> in Makefile.inc.in (already changed)
[04:14:16] <jmkasunich> and another one about 6 lines down, ULFLAGS
[04:14:34] <cradek> I don't see ULFLAGS being used
[04:14:54] <jmkasunich> well shit, another leftover from the original build system
[04:15:04] <cradek> maybe?
[04:15:17] <cradek> I think you need to change INLCUDE:= in the Makefile
[04:15:22] <jmkasunich> ok
[04:15:32] <cradek> reverse the two things
[04:15:53] <jmkasunich> right
[04:16:28] <jmkasunich> testing with a build here, make sure it doesn't break things
[04:16:33] <cradek> me too
[04:19:00] <cradek> mine looks good so far
[04:19:04] <jmkasunich> seems to work here, committed
[04:19:16] <jmkasunich> now to test on the ssssslllllloooooooooooowwwwwwww box
[04:19:47] <cradek> any luck on the new farm?
[04:20:11] <cradek> not that it would necessarily be faster
[04:23:40] <jmkasunich> I have ubuntu installed, LVM providing 30G of /home, and qemu installed
[04:23:56] <jmkasunich> no virtual machines defined yet, I'll tackle that when I get home on thursday
[04:24:02] <cradek> cool
[04:24:06] <cradek> so you figured out lvm finally
[04:25:25] <jmkasunich> yeah, it was actually pretty easy once I was in a command line environment
[04:25:31] <jmkasunich> the installer's interface to it sucks
[04:25:36] <cradek> I agree
[04:25:49] <jmkasunich> so I have 3G non-LVM on one disk for /
[04:25:57] <jmkasunich> 3G non-LVM on the other for swap
[04:26:11] <cradek> sounds good
[04:26:12] <jmkasunich> and the remainder of both disks is a striped LVM for /home
[04:26:23] <jmkasunich> 10K rpm disks too... ;-)
[04:26:40] <jmkasunich> oh, and I installed the smp kernel already too
[04:27:01] <cradek> does it work?
[04:27:08] <jmkasunich> the kernel?
[04:27:13] <cradek> yeah do you get smp?
[04:27:14] <jmkasunich> seems to
[04:27:16] <jmkasunich> yes
[04:27:19] <cradek> cool
[04:27:37] <jmkasunich> there's an app (forget the name) that prints loads on each cpu
[04:27:42] <cradek> maybe someday I'll find another PIII666 for my mill's machine
[04:27:58] <cradek> I think even top shows that
[04:28:04] <jmkasunich> they share user/sys etc, pretty well, but CPU0 gets most of the interrupts
[04:28:41] <jmkasunich> it runs around 998-1040 per second (the jiffies interrupt is 1KHz I think) the other CPU only had about 50 per second
[04:29:17] <cradek> I've seen some talk about setting up rtai with rt on one processor and user on the other
[04:29:23] <cradek> might be interesting to try
[04:29:28] <jmkasunich> this is just the stock ubuntu SMP kernel... a RTAI smp kernel is a whole nother beast
[04:29:31] <cradek> but ... also might be painful
[04:29:33] <cradek> right
[04:29:43] <cradek> I understand you don't care about running rt on it
[04:30:07] <jmkasunich> actually, that box is the only one I have without a RT kernel
[04:30:28] <jmkasunich> I actually have an idea for how to do sim RT on a non-rt box, I might test it using that box
[04:30:38] <jmkasunich> thats a few weeks down the road tho
[04:30:42] <cradek> yeah
[04:30:47] <cradek> jepler's also interested in that I think.
[04:31:06] <jmkasunich> yeah, he started looking at my very early attempt and fixed some bitrot
[04:31:17] <jmkasunich> but the actual guts haven't been touched
[04:31:18] <cradek> it would sure be nice to have
[04:32:14] <cradek> I have now found out that that resistor I replaced was really supposed to be 4.7
[04:32:23] <cradek> (I put in a .51)
[04:32:26] <jmkasunich> how'd you find that?
[04:32:27] <cradek> it's fusible
[04:32:31] <cradek> the internet told me so
[04:32:35] <jmkasunich> ah
[04:32:42] <jmkasunich> amazing what the internet can tell you
[04:32:47] <cradek> I think it's meant as a fuse, not a resistor, so I've probably defeated both purposes
[04:32:51] <jmkasunich> you can even believe some of it
[04:33:01] <jmkasunich> probalby
[04:33:12] <cradek> not even sure I'd have a 4.7 to put in there
[04:33:20] <cradek> oh well I'm probably going to just leave it
[04:33:24] <jmkasunich> get a 10 and cut it in half
[04:33:38] <jmk_cf> hello from the new compile farm (someday)
[04:33:47] <cradek> I sure like the 85Hz on this screen
[04:33:57] <cradek> I don't see any flicker at all, just like my LCD, very nice
[04:34:02] <jmkasunich> this = the one you just fixed?
[04:34:04] <cradek> yes
[04:34:48] <jmk_cf> btw, I also got this thing to run 1280x1024x16bit color
[04:34:51] <cradek> wonder if my encoder will come tomorrow...
[04:34:59] <cradek> cool
[04:35:32] <jmk_cf> either the video card only has 4M (even tho the labeling and chip count says 8) or the driver can't figure out the memory and only uses 4
[04:35:49] <jmk_cf> I was originally gonna use 24 bit color, but it said not enough ram
[04:36:32] <jmk_cf> not worth fighting with, extra color depth is meaningless, and extra pixels won't work on any monitor except my LCD
[04:36:34] <cradek> 24 bit color is slower for no good reason
[04:36:54] <cradek> unless you're working with photographs or something
[04:36:57] <jmk_cf> right
[04:37:23] <jmk_cf> I should shut things down...
[04:37:46] <jmk_cf> I want to get the linux laptop out, make sure I have all the stuff that goes with (power brick, etc)
[04:38:00] <jmk_cf> I'm gonna take it so I can do something in the hotel room besides watch tv
[04:38:09] <jmk_cf> and I need to pack
[04:38:16] <jmk_cf> and get up at 5am to catch a flight
[04:38:17] <cradek> stop by and you can borrow my wireless card
[04:38:46] <jmk_cf> nebraska isn't on the way from clevland to milwaukee
[04:38:54] <cradek> darn
[04:39:00] <cradek> eat some cheese while you're there
[04:39:04] <jmk_cf> heh
[04:39:50] <jmkasunich> woot!
http://linuxcnc.org/compile_farm/
[04:40:08] <cradek> kick ass
[04:40:13] <cradek> big local maximum here
[04:40:21] <jmkasunich> wonder what slot 2 is gonna do?
[04:40:35] <cradek> it's make is too old, it'll never work
[04:40:39] <jmkasunich> ok
[04:40:57] <SWPadnos> buh-bye kernel 2.2 ;)
[04:41:10] <cradek> in all seriousness, it would probably work with a make upgrade
[04:41:16] <cradek> there may even be an rpm ... somewhere
[04:41:24] <jmk_cf> bye rtlinux patent
[04:41:48] <SWPadnos> indeed
[04:42:45] <jmkasunich> I bet the new farm uses less electricity than the old one...
[04:43:16] <SWPadnos> 1/10 the fan power
[04:43:32] <jmkasunich> not so sure about that
[04:43:50] <jmkasunich> the old one has 2 4" fans above the disks and one in each PS
[04:44:14] <jmkasunich> this one has 3 3" fans pulling thru the disks and over the cpus, and one 3" in the PS
[04:44:23] <jmkasunich> but this box has 2 disks, that one has 8
[04:44:24] <SWPadnos> hmm
[04:44:34] <SWPadnos> I guess DP server hardware can be loud
[04:45:55] <jmkasunich> sound wise they're probably about the same
[04:55:23] <jmkasunich> how do you make an ubuntu box go out and get a dhcp lease?
[04:55:39] <jmkasunich> I tried ifconfig eth0 down ; ifconfig eth0 up
[04:55:41] <jmkasunich> no luck
[04:55:43] <cradek> do you mean you installed without dhcp and now you want it?
[04:56:22] <SWPadnos> /etc/init.d/dhclient restart ?
[04:56:24] <jmkasunich> etc/network/interfaces says :" iface eth- inet dhcp"
[04:56:34] <SWPadnos> /etc/init.d/network restart ?
[04:56:41] <jmkasunich> but the pcmcia card wasn't in at boot
[04:56:43] <jmkasunich> trying that
[04:56:52] <cradek> that should all happen when you insert the pcmcia card
[04:59:36] <jmkasunich> seems I had an intermittent connection in the pcmcia to rj45 cable
[04:59:56] <jmkasunich> wiggled it till the light came on, then removed and replaced the card and it works
[05:00:14] <jmkasunich> I think I have another on of those cables
[05:00:41] <jmkasunich> (thats what happens when you pick them out of the trash, sometimes they really belong there)
[05:47:13] <SWPadnos> SWPadnos is now known as SWP_Away
[13:34:10] <alex_joni> hello
[13:34:29] <jepler> hi alex
[13:35:55] <alex_joni> hi jeff
[13:37:49] <rayh> Hi guys.
[13:38:47] <rayh> alex_joni, I'm ready to change the DNS for linuxcnc.org whenever you and SWP are ready to go.
[13:41:41] <jepler> I could supply a copy of the make 3.80 I compiled for bdi2. Installation would consist of "gunzip make.gz; mv make /usr/bin; chmod +x /usr/bin/make"
[13:41:53] <jepler> I think that gets the bdi2 slot compiling again
[13:42:31] <jepler> -rwxr-xr-x 1 root root 64348 Mar 27 07:42 make.gz
[13:48:54] <jepler> did jmk say how long he'll be gone?
[13:50:10] <jepler> hm, I can't reach the farm page
[13:51:21] <jepler> ... can't reach linuxcnc.org at all
[13:59:57] <rayh> I believe that SWP copied it over to his site last night.
[14:05:04] <alex_joni> rayh: one more thing
[14:05:09] <alex_joni> didn't know about the historic stuff
[14:05:14] <alex_joni> 2000-2003
[14:05:58] <alex_joni> but we can move that lateron too
[14:06:21] <alex_joni> steves_logging said he put up another domain so we can still reach the site
[14:07:50] <rayh> You bet. Anytime you think the new is ready I can make the DNS change.
[14:08:10] <rayh> Looks like linuxcnc.org is down now.
[14:11:19] <alex_joni> ok, then lets move it
[14:14:55] <cradek> jepler: I think he's out for a whole week
[14:15:31] <rayh> logger_devel, bookmark
[14:15:32] <rayh> See
http://solaris.cs.utt.ro/irc/irc.freenode.net:6667/emcdevel/2006-03-27#T14-15-31
[14:15:53] <alex_joni> jepler: I think till thursday or so
[14:16:50] <rayh> I'm not certain that we need to move very much of the history stuff. I should look.
[14:17:36] <cradek> alex, ray: did you get everything done that you want in the new TESTING release? I didn't make it last night because I didn't know if everyone was ready
[14:23:36] <rayh> I'm stuck on saving the changes to the ini file.
[14:23:44] <rayh> The rest works.
[14:24:17] <rayh> I just don't know enough to program that little bit.
[14:24:40] <rayh> Perhaps I should commit as is and you guys could look.
[14:24:49] <SWP_Away> SWP_Away is now known as SWPadnos
[14:25:00] <SWPadnos> howdy
[14:25:18] <rayh> alex_joni, SWP said something about needing to change some links to images in linuxcnc
[14:25:24] <rayh> Hi steven.
[14:26:37] <SWPadnos> right - all the images on the joomla page are from cncgear.com/joomla, even if I access the site as linuxcnc.org (using ns1.dreamhost.com in resolv.conf)
[14:26:58] <SWPadnos> I'm not sure if this is the "site root" or equivalent in the joomla configuration
[14:40:56] <alex_joni> SWPadnos: shouldn't be
[14:41:05] <alex_joni> I tried that, and images showed up fine
[14:41:21] <alex_joni> let me try again
[14:41:22] <SWPadnos> they show up, but they come from cncgear.com/joomla
[14:41:49] <alex_joni> did u use linuxcnc.org or www.linuxcnc.org ?
[14:41:59] <SWPadnos> I'm not sure
[14:42:15] <SWPadnos> I know it came from the dreamhost site though
[14:43:06] <SWPadnos> apparantly, I used linuxcnc.org (no www)
[14:43:45] <SWPadnos> apparently, that was supposed to be
[14:44:48] <alex_joni> hrmm.. I see what you mean
[14:45:32] <SWPadnos> I think the CSS style sheets come from cncgear as well
[14:46:28] <alex_joni> hang on 2 mins
[14:55:05] <alex_joni> ok, it seems www.linuxcnc.org @ cncgear is fully functional
[14:55:17] <alex_joni> rayh: whenever you'll do the DNS move, the site will be ready
[14:55:30] <alex_joni> but this means cncgear.com/joomla/ won't work properly from now on
[14:57:18] <alex_joni> cradek: are you around?
[15:00:17] <cradek> yes
[15:00:26] <alex_joni> what time is it there?
[15:00:30] <cradek> 9am
[15:00:32] <alex_joni> hello, btw ;)
[15:00:33] <cradek> hi
[15:00:51] <alex_joni> 6pm here
[15:00:58] <alex_joni> going home ;)
[15:01:17] <rayh> okay. I'll do that now. ns1.dreamhost.com and ns2.dreamhost.com is what we want.
[15:01:19] <alex_joni> we moved 1h+ on saturday night
[15:01:24] <alex_joni> rayh: yes
[15:01:26] <SWPadnos> rayh, right
[15:01:38] <alex_joni> 1-2 days it'll propagate
[15:01:56] <SWPadnos> alex - have you tested wiki.linuxcnc.org with the dreamhost nameservers?
[15:02:18] <alex_joni> hang on..
[15:02:34] <alex_joni> juve@proxy:~> dig wiki.linuxcnc.org @ns1.dreamhost.com
[15:02:34] <alex_joni> ; <<>> DiG 9.2.2 <<>> wiki.linuxcnc.org @ns1.dreamhost.com
[15:02:34] <alex_joni> ;; global options: printcmd
[15:02:34] <alex_joni> ;; Got answer:
[15:02:34] <alex_joni> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 6453
[15:02:37] <alex_joni> ;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
[15:02:39] <alex_joni> ;; QUESTION SECTION:
[15:02:42] <alex_joni> ;wiki.linuxcnc.org. IN A
[15:02:44] <alex_joni> ;; ANSWER SECTION:
[15:02:47] <alex_joni> wiki.linuxcnc.org. 14400 IN CNAME vhost.sourceforge.net.
[15:02:49] <alex_joni> it's ok
[15:02:57] <SWPadnos> ok
[15:03:04] <SWPadnos> how about in a browser? ;)
[15:03:26] <alex_joni> not sure how to set that up here, I'm on doze now
[15:03:31] <alex_joni> and going home
[15:03:31] <alex_joni> :D
[15:03:35] <alex_joni> I'll bbl
[15:03:37] <SWPadnos> ok - I'll do it here
[15:03:39] <SWPadnos> see you
[15:29:22] <rayh> Okay. I believe the DNS server has been changed.
[15:29:40] <SWPadnos> cool. let's see how long it takes to update
[15:31:59] <cradek> my cache must have been empty, because I get the new site
[15:32:14] <SWPadnos> cool
[15:32:41] <SWPadnos> oops - I still have dreamhost listed as my first nameserver ;)
[15:33:35] <rayh> Oh darn. Don't you hate it.
[15:33:51] <SWPadnos> well, it worked, but that's to be expected
[15:34:14] <SWPadnos> unfortunately. wiki.linuxcnc.org may not work for a little while
[15:34:27] <SWPadnos> cradek, can you get to the wiki?
[15:34:54] <rayh> I still get the old front page.
[15:36:09] <cradek> SWPadnos: yes
[15:36:13] <SWPadnos> ok, good
[15:36:27] <SWPadnos> note in the dig output from alex, the status is SERVFAIL
[15:36:40] <jepler> http://linuxcnc.org/ gives a joomla "site unavailable" message
[15:37:00] <SWPadnos> hmmm
[15:37:01] <jepler> nevermind, that only happened once
[15:37:11] <cradek> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16892
[15:37:18] <SWPadnos> ok, great
[15:37:38] <SWPadnos> I get the same SERVFAIL as alex, using ns1.dreamhost.com for the lookup
[15:37:55] <jepler> wiki... worked for me just now
[15:38:10] <jepler> but it's possible that's cached because I used the wiki from this machine within the last hour
[15:38:14] <cradek> SWPadnos: looks fine from here
[15:38:15] <SWPadnos> great - maybe I didn't need to send in that support request
[15:38:35] <cradek> mine wasn't cached because it took forever to load the picture
[15:39:14] <SWPadnos> it's working fine from external nameservers, but the DH ones seem to fail
[15:45:29] <SWPadnos> cradek, what was the lifetime (?) of the CNAME record in your dig output?
[15:45:53] <cradek> I don't see a CNAME but the linuxcnc.org. A record is 14400 (4hr)
[15:46:23] <SWPadnos> ok. I get 3600 from my normal DNS, and 14400 from dreamhost
[15:46:30] <SWPadnos> but I still get SERVFAIL
[15:46:31] <cradek> ah wiki.linuxcnc.org. is a CNAME, also 14400
[15:47:05] <cradek> % dig @ns1.dreamhost.com linuxcnc.org.|grep status
[15:47:05] <cradek> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24036
[15:47:26] <SWPadnos> ok, that's fine. it's the wiki I'm concerned about
[15:47:31] <cradek> ohhh
[15:47:41] <jepler> the AUTHORITY SECTION for 'dig wiki' is all sourceforge stuff here .. like it's cached from before the change
[15:48:04] <SWPadnos> localhost:~# dig @ns1.dreamhost.com wiki.linuxcnc.org | grep -i status
[15:48:06] <SWPadnos> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 7724
[15:48:09] <cradek> yes it's sourceforge stuff
[15:48:22] <jepler> $ dig @ns1.dreamhost.com linuxcnc.org.|grep status
[15:48:22] <jepler> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43513
[15:48:45] <cradek> I got SERVFAIL the first time
[15:49:08] <SWPadnos> it's always the first time for me, I guess
[15:50:00] <jepler> ok .. on my home system I did a 'service named restart' and then a 'dig @ns1.dreamhost.com wiki.linuxcnc.org.|grep status'. I get SERVFAILs
[15:50:20] <jepler> 10 servfails
[15:50:52] <SWPadnos> ok. well, I've opened a support ticket with DreamHost. let's see how good they are
[15:51:10] <jepler> dig -t cname @ns2.dreamhost.com wiki.linuxcnc.org.
[15:51:13] <jepler> this succeeds
[15:51:59] <jepler> in fact, when I get SERVFAILs there's still a CNAME in the results
[15:52:40] <SWPadnos> I noticed that
[15:52:54] <SWPadnos> it just doesn't bother looking up the CNAME
[15:53:04] <cradek> flags "rd" means recursion denied
[15:53:15] <SWPadnos> hmmm
[15:54:01] <jepler> OK, this is probably no bug
[15:54:28] <jepler> ns1.dreamhost.com is serving the CNAME
[15:54:58] <cradek> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21203
[15:54:58] <cradek> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
[15:55:08] <cradek> on the one that worked for me, I got "recusion denied" "recursion available"
[15:55:17] <jepler> but it won't go fetch the A for you, because that's recursion, and recursion is bad for outwards-facing DNS servers
[15:55:42] <cradek> arg, crap, RD is recursion DESIRED
[15:55:53] <cradek> I think it means "now go get this yourself"?
[15:55:53] <SWPadnos> hmmm - I just got an email from support. mostly "it works for me"
[15:55:55] <jepler> that's why this fails:
[15:55:56] <jepler> dig @ns1.dreamhost.com google.com. | grep status
[15:55:56] <jepler> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 47069
[15:56:09] <jepler> everything is fine. nothing is broken.
[15:56:15] <cradek> worksforme
[15:56:38] <cradek> SWPadnos: that was sure fast
[15:56:42] <SWPadnos> he suggested waiting a few hours for DNS to propagate a bit more, and see if it still fails for me
[15:56:52] <SWPadnos> yeah - they seem good so far
[15:57:04] <jepler> SWPadnos: You shouldn't have ns1.dreamhost.com listed in /etc/resolv.conf; it's no surprise if you can't browse the web with that configuration.
[15:57:24] <SWPadnos> 18 minutes response time - that was good
[15:57:33] <SWPadnos> it was listed by number
[15:59:52] <rayh> Anyone want to open a pool on when my ISP's nameserver will catch on?
[16:00:17] <SWPadnos> July 2, 2009 11:32:53 AM
[16:00:22] <cradek> rayh: dig will tell you that answer
[16:00:48] <rayh> How do I use that?
[16:00:54] <cradek> dig linuxcnc.org
[16:01:00] <SWPadnos> ok. it looks like it's working from here
[16:01:05] <cradek> look for ANSWER SECTION
[16:01:06] <SWPadnos> but not on the Linux machine
[16:01:13] <rayh> Okay. I think SWP has a pretty good guess.
[16:01:13] <cradek> the number in the second column is the timeout in seconds
[16:01:30] <cradek> I am guessing it will be <= 4 hours
[16:03:16] <SWPadnos> exit
[16:03:18] <SWPadnos> oops
[16:03:25] <cradek> EXIT
[16:03:38] <SWPadnos> ok - it's working from the Linux machine now as well
[16:04:17] <rayh> ;; ANSWER SECTION:
[16:04:18] <rayh> linuxcnc.org. 15568 IN A 64.124.155.133
[16:04:36] <rayh> Whatever that means.
[16:04:36] <cradek> 4.3 hrs
[16:05:34] <rayh> so the 155xx is seconds.
[16:06:36] <SWPadnos> yep
[16:07:20] <rayh> * rayh twiddles his thumbs for 4.3 hours.
[16:09:17] <rayh> What is the plan for the dropbox?
[16:09:34] <cradek> I think you're the only one who knows how to use it
[16:09:38] <SWPadnos> good question
[16:09:54] <rayh> We have upload ability now.
[16:10:00] <SWPadnos> hopefully joomla provides some upload functionality
[16:10:08] <SWPadnos> I'm not sure how to congifure it
[16:10:10] <rayh> Which is what was intended for the dropbox.
[16:10:28] <rayh> It just moves that to the wiki location.
[16:11:21] <SWPadnos> congifure - I need more caffeine
[16:15:38] <rayh> Trivia question. Name the movie "needs unguint!"
[16:16:22] <SWPadnos> Soylent Green
[16:16:24] <SWPadnos> ?
[16:16:41] <rayh> Fargo
[16:16:47] <SWPadnos> heh
[16:16:56] <SWPadnos> I don;t remember that line
[16:17:11] <rayh> soylent green is people!
[16:17:38] <SWPadnos> heh - yep
[16:17:43] <SWPadnos> never seen that one
[16:17:44] <rayh> The dumb killer after the victim cut him.
[16:18:00] <SWPadnos> hmmm
[16:19:09] <rayh> doesn't hardly look like we are using the same sf repository today.
[16:20:00] <SWPadnos> how so?
[16:20:38] <rayh> couple hundred lines of change with cvs up.
[16:20:58] <SWPadnos> that's good ;)
[16:21:10] <SWPadnos> lots of translation going on, it appears
[16:21:18] <SWPadnos> and all the makefile stuff from last night
[16:22:45] <jepler> the removed Makefiles is a whole lot of nothing. They'd already been unused for weeks.
[16:23:20] <SWPadnos> lots of changes though
[16:23:47] <rayh> I see that flo has been busy.
[16:33:22] <cradek> I hope his changes work when emc2 is packaged up
[16:33:32] <cradek> I think he has never talked to any of us?
[16:41:50] <jepler> that's a question?
[16:42:14] <cradek> it's meant to say I'm not sure
[16:47:39] <rayh> I'm seeing quite a few new names using emc(2) these days.
[17:16:04] <SWPadnos> SWPadnos is now known as SWP_Away
[17:32:57] <alex_joni> hi guys
[17:34:48] <rayh> Hi alex.
[17:38:26] <alex_joni> hello ray
[17:42:35] <rayh> Does the new web site work from there?
[17:47:05] <alex_joni> let me check
[17:54:34] <alex_joni> it seems to, but I'm not sure if I don't have the name locally cached
[17:58:26] <alex_joni> I need to sleep, think I catched a cold :(
[17:58:28] <alex_joni> I'll be around later
[18:13:11] <anonimasu> where is the new website?
[18:21:56] <rayh> see you alex
[18:22:30] <rayh> anonimasu, The new DNS is propagating
[18:22:50] <anonimasu> the old one still works here
[18:23:12] <rayh> If you are running linux there open a terminal and issue the command "dig linuxcnc.org"
[18:24:33] <rayh> In the answers section you'll see something like "linuxcnc.org. 7092"
[18:25:05] <rayh> The number is the number of seconds until your dns lookup catches up.
[19:07:48] <steves_logging> steves_logging is now known as steve_stallings
[19:09:03] <steve_stallings> Sorry about the outage this morning. Server crashed in the early AM, and since I had a very long night I didn't get to it until around noon.
[19:09:49] <steve_stallings> I now see the new site including the resolution of the CNAME for the wiki.
[19:10:01] <steve_stallings> Traffic on the old server has dropped to almost nil.
[19:10:56] <steve_stallings> The old LinuxCNC site has been mirrored onto www.metalworking.net for a few days just in case you need to pick the bones.
[19:15:10] <steve_stallings> DNS propogation should be fast for those nameserver that honor TTL as I had set it very short in anticipation of the move.
[19:17:15] <jepler> steve_stallings: Yeah, I think everything is fine
[19:17:39] <jepler> thanks for hosting the linuxcnc.org site 'till now.
[19:24:38] <steve_stallings> Glad to have helped EMC pass from the world of NIST into the public domain. It is great to see people with more time and skill take over.
[19:35:09] <rayh> Thanks Steve.
[19:35:34] <rayh> The new has not propagated to me yet but a couple more hours and it should.
[19:38:48] <rayh> steve_stallings,
[19:41:02] <alex_joni> steve_stallings: thanks again for hosting ;)
[19:41:20] <alex_joni> I think we (I personally) will make some use of metarworking.net in the next few days
[19:41:33] <alex_joni> rayh: hello, you around?
[19:42:25] <rayh> Yep
[19:44:32] <alex_joni> there are some pages I didn't move forward.. wanted to know if I should
[19:45:20] <alex_joni> rayh:
http://metalworking.net/EMC_news_history/index.html
[19:45:33] <alex_joni> photos from Names 2000 & 2002
[19:45:37] <rayh> I don't think I have access to the new for another 45 minutes.
[19:45:46] <alex_joni> that's still the old one
[19:46:02] <alex_joni> emc - 2003 Meeting report
[19:46:14] <alex_joni> emc - 2004 fest & meetings report
[19:46:16] <alex_joni> etc.
[19:46:26] <alex_joni> think I should move those?
[19:47:18] <rayh> phone
[19:52:32] <steve_stallings> Alex - It seems some photo links do not work on the metalworking.net environment. All content still exists, just let me know if there is any you want.
[19:53:17] <cradek> argh
[19:53:44] <jepler> cradek: ?
[19:53:52] <cradek> I just edited "static content item" (main page) but clicking preview, upload, save, apply all do nothing
[19:57:22] <cradek> however, cancel works
[19:58:41] <alex_joni> save should work
[19:58:54] <cradek> it sure didn't
[19:59:01] <alex_joni> cradek: also, be sure to always use www.linuxcnc.org not linuxcnc.org
[19:59:07] <cradek> wonder if it's my web proxy
[19:59:12] <cradek> why? is that what was wrong?
[19:59:28] <alex_joni> cradek: I had issues inserting links when using without www.
[19:59:45] <alex_joni> it's a problem between joomla & the wysiwyg editor
[19:59:57] <alex_joni> can you tell me the exact steps you were doing?
[20:00:31] <cradek> logged in as cradek
[20:00:34] <cradek> static content manager
[20:00:40] <cradek> Home (Homepage)
[20:00:46] <cradek> changed some stuff in the text widget on the left
[20:00:50] <alex_joni> did you login under administrator?
[20:00:52] <cradek> clicked Save at the top
[20:01:01] <alex_joni> you can also edit from the frontend (e.g. the website)
[20:01:06] <cradek> no, as cradek, but cradek is an administrator
[20:01:15] <alex_joni> I wasn't clear
[20:01:20] <cradek> what do you mean?
[20:01:31] <alex_joni> if you go to the menu to "Admin" then you are using the backend interface
[20:01:43] <cradek> yes that's what I did
[20:01:44] <alex_joni> if you go to "Documentation" and login, then you can edit most pages
[20:01:49] <alex_joni> directly
[20:01:54] <cradek> I want to edit the main front page
[20:02:23] <alex_joni> ok, both ways are allowed ;)
[20:02:31] <alex_joni> * alex_joni tries it too
[20:02:48] <alex_joni> what did you want to change?
[20:02:51] <cradek> looks like I am using linuxcnc.org, not www.linuxcnc.org, if that matters
[20:03:04] <alex_joni> I think it matters, but not for editing text
[20:03:13] <cradek> I just want to rephrase some things
[20:05:03] <alex_joni> cradek: try the frontend
[20:05:11] <alex_joni> go to Documentation, and log-in
[20:05:29] <cradek> I'm going to try the same thing again after a change in my proxy
[20:05:31] <alex_joni> then go to the page you want to change, and you'll have a new icon on that page
[20:05:44] <cradek> ok I'll try that method too
[20:07:31] <alex_joni> cradek: some references are still through cncgear.com/joomla/ so that might confuse some software (like proxies)
[20:07:42] <alex_joni> we'll change that once DNS has fully propagated
[20:07:48] <cradek> save and apply still don't do anything
[20:07:59] <alex_joni> that's odd.. what browser?
[20:08:15] <cradek> firefox 1.0.4
[20:08:20] <rayh> 15 minutes here.
[20:08:30] <cradek> preview loads for a while, but then does nothing
[20:09:20] <alex_joni> very odd, firefox works just right here
[20:09:41] <cradek> ok I'm trying this other method now
[20:10:29] <alex_joni> 1.0.7 though
[20:10:47] <cradek> hmm, same problem
[20:11:07] <alex_joni> rayh: you can see exactly the same thing at www.cncgear.com/joomla/
[20:11:33] <rayh> Okay.
[20:11:49] <alex_joni> cradek: do you have javascript enabled?
[20:11:57] <cradek> yes
[20:12:08] <cradek> I turned off my proxy, trying again
[20:12:09] <alex_joni> do you see the fancy editor?
[20:12:09] <rayh> Looks to me like most of the stuff at
http://metalworking.net/EMC_news_history/index.html
[20:12:22] <rayh> would be good to move.
[20:12:39] <alex_joni> rayh: I moved only the history
[20:12:47] <alex_joni> I'll move the other stuff too
[20:13:09] <rayh> We can weed stuff out if we need.
[20:13:09] <cradek> now it says the front page is being edited by someone else, but it doesn't tell me who
[20:13:37] <alex_joni> hang on, let me do a global checkin (or you can from the backend)
[20:13:50] <alex_joni> err..I was editing ;)
[20:13:54] <alex_joni> try now
[20:14:25] <cradek> what did you add? I have my edits that I was going to paste in
[20:15:21] <cradek> doesn't matter, I still can't save.
[20:16:41] <rayh> crap the notebook widget does not issue a command with the active page.
[20:17:16] <alex_joni> cradek: :(
[20:17:55] <rayh> Oh I found it. I think.
[20:18:08] <chinamill> Hello, is there something funny with the follow-printing in emc2-axis_1.2rc3-1.0_i386.deb? (running metric)
[20:18:21] <jepler> rayh: this is bwidget NoteBook?
[20:18:50] <cradek> chinamill: do you mean the Fxxxx status display on the MDI tab?
[20:19:21] <cradek> chinamill: if so, that is an EMC bug (not an AXIS bug) and has been fixed; the fix will be in the next release
[20:19:25] <jepler> rayh: I believe there's a "-raisecmd" which you can specify when creating the tab
[20:19:55] <jepler> (or later on)
[20:19:57] <jepler> ${pane_top}.tabs itemconfigure mdi -raisecmd [list focus ${_tabs_mdi}.command]
[20:20:06] <chinamill> cradek: no I'm thinking of the printing of the movements of the milling, the lines does not follow the white ones.
[20:20:09] <jepler> In axis, this is how I ensure the mdi entry field is focused when that tab is shown
[20:20:39] <cradek> chinamill: try putting a G21 in your gcode program
[20:21:54] <chinamill> cradek: Oh... yes, I forgot, that was the fix
[20:23:50] <chinamill> I there a way of seting xyz to a certain value in axis, like with mini, the interface for offsets where very useful?
[20:24:33] <cradek> yes jog the axis to the place you want to be 0, and press Offset
[20:24:52] <jepler> the keyboard shortcut for Offset is Shift+Home
[20:25:54] <chinamill> I really liked that it was possible to enter a value for a position on the mill. Not possible with axis?
[20:26:11] <cradek> chinamill: you can use MDI to jog
[20:26:55] <cradek> chinamill: of course you can also program it with the gcode offset command like G10 L2 P1 X123.456
[20:28:01] <steve_stallings> steve_stallings is now known as steves_logging
[20:28:53] <chinamill> OK I think you are missing what I want to do, say that I have clamped a piece on the table. Then I can move the mill untill it just touches the side face. Then I want to set the X value something like -40 - mill/2, get it?
[20:29:16] <cradek> yes
[20:29:34] <chinamill> So not possibe with axis?
[20:29:40] <cradek> you can hit offset, move the tool up, MDI g0x20, hit offset again
[20:30:16] <cradek> or, at MDI enter G10 L2 P1 X-40
[20:30:55] <chinamill> ok, I'll study some more g-code thanks for the hint
[20:31:32] <cradek> we have talked about adding a feature that allows you to do this, but we haven't come up with a good, clean way to do the gui
[20:31:44] <chinamill> ok
[20:32:09] <cradek> I could also use it when I touch the workpiece with a feeler gauge to set Z offset
[20:32:37] <cradek> but currently I just use incremental jog to jog down the thickness of the feeler
[20:34:25] <cradek> since my thinnest feeler gauge is .002 and I have a .001 incremental jog, this is very simple
[20:40:58] <anonimasu> hm, I usually use a paper..
[20:41:13] <anonimasu> and jog down about 0,03..
[20:41:24] <anonimasu> mm
[20:55:09] <cradek> anonimasu: I cut PCBs .0045" deep, so I need it to be more precise than that for repeatability
[20:55:18] <cradek> .11mm
[20:58:21] <rayh> I'm there.
[21:01:22] <rayh> What's block user?
[21:06:40] <anonimasu> cradek: ah, yeah
[21:10:18] <alex_joni> what do you guys think? should we announce the new page on the lists?
[21:10:27] <alex_joni> or just let them figure out for themselves?
[21:12:26] <rayh> They'll raise more of a rucus if we let them discover.
[21:14:35] <alex_joni> rucus?
[21:15:19] <jepler> "ruckus", maybe?
[21:16:00] <jepler> http://www.answers.com/ruckus
[21:16:19] <jepler> "Perhaps blend of RUCTION and RUMPUS."
[21:16:23] <jepler> I've never heard those words!
[21:16:29] <alex_joni> jepler: bet that is your favourite page
[21:17:12] <alex_joni> kidding, there are tons of words I never heard
[21:17:50] <alex_joni> rumpus is very clear though (A noisy clamor)
[21:17:54] <alex_joni> wth is a clamor?
[21:18:44] <alex_joni> oh, a clamor is a hubbub
[21:18:54] <jepler> yeah, exactly what I was going to say
[21:19:04] <jepler> "what's the hubbub, bub?" -- bugs bunny
[21:19:12] <alex_joni> :)
[21:19:45] <rayh> I'm seeing a lot of stuff coming from cncgear. Is that supposed to be?
[21:19:53] <alex_joni> rayh: yes
[21:20:10] <alex_joni> just for a few days, till everyone knows who linuxcnc.org is
[21:20:15] <alex_joni> then we'll get rid of that
[21:20:40] <rayh> Oh I see.
[21:20:55] <alex_joni> it's a one-line change, trivial
[21:21:15] <alex_joni> SWP & I tried it sooner, but put it back in order not to cause any problems
[21:21:23] <jepler> rayh: did you see what I said earlier about -raisecmd?
[21:21:34] <rayh> k Glad that you guys know what you are doing.
[21:21:56] <rayh> looking
[21:22:13] <alex_joni> jepler: and hubbub comes from ' ub ub ubub'
[21:22:18] <alex_joni> that makes sense ;)
[21:22:20] <jepler> 14:19:53 <jepler> ${pane_top}.tabs itemconfigure mdi -raisecmd [list focus ${_tabs_mdi}.command]
[21:22:31] <rayh> Got it thanks jepler
[21:22:49] <rayh> It works fine for keeping track of activeaxis.
[21:23:33] <rayh> I'm going to commit what I've got. Perhaps you can give me a bit of help to finish.
[21:24:11] <jepler> maybe I'll have the time to take a look tonight
[21:27:11] <rayh> Thanks.
[21:31:09] <alex_joni> steves_logging: guess you're not around anymore?
[21:37:33] <alex_joni> night all
[21:38:40] <jepler> night alex
[21:46:01] <cradek> Error in startup script: bad window path name ".linenumber"
[21:46:01] <cradek> while executing
[21:46:01] <cradek> "wm geometry .linenumber 275x180-60+100"
[21:46:01] <cradek> (file "/home/cradek/emc2.cvs/tcl/mini.tcl" line 2511)
[21:56:47] <rayh> That is wierd indeed.
[22:02:22] <rayh> And yesterday it ran.
[22:08:21] <rayh> found a typo but more is wrong.
[23:28:14] <cradek> looks like he committed some untested stuff?