Back
[02:25:55] <memleak> good night all!
[02:26:16] <mhaberler> cu!
[02:28:20] <memleak> oh yeah if anyone wants to have real-time support for the cubieboard2 i'll be working on a RT kernel tree for the board, in the meantime you can use preempt_rt kernel patches with this wiki as a guide line:
https://code.google.com/p/neo-technical/wiki/Cubieboard2
[02:29:07] <memleak> xenomai hasn't been tested with the cubieboard2
[02:29:14] <memleak> (not on my part)
[02:30:02] <mhaberler> hm, thats all based on 3.4.9?
[02:31:05] <memleak> the wiki is based off of 3.4.79
[02:31:31] <memleak> xenomai might still be way behind with 3.4.9 kernel release
[02:31:58] <memleak> me and some other devs might be working on porting RTAI 3.x kernels to ARM though :)
[02:40:35] <mhaberler> that's a big bite to take
[08:47:29] <CaptHindsight> http://fridge.ubuntu.com/2014/02/13/community-council-statement-on-canonical-package-licensing/ in the news today
[08:48:17] <CaptHindsight> http://www.muktware.com/2014/02/need-license-canonical-create-derivatives/21066
[08:58:42] <norbert__> Hi There: I just finished gmoccapy as stand alone, so it is now separated from gscreen. I want to push the changes, but bevore I need some help according to scr/Makefile. How can I add there, that my gmoccapy.mo files will be copied in case of install from /share/locale/de , es and rs folders to the correct place? Next I need help to get also the buildbot stuf to work correct. you can see what I have done so far here:
http://git.mah
[08:58:42] <norbert__> .priv.at/gitweb?p=emc2-dev.git;a=shortlog;h=refs/heads/gmoccapy_1_0
[08:58:52] <norbert__> http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=shortlog;h=refs/heads/gmoccapy_1_0
[14:01:59] <KGB-linuxcnc> 03John Morris 05zultron/ubc3-dev 771757a 06linuxcnc 10scripts/linuxcnc.in 10tests/toolchanger/toolno-pocket-differ/shared-test.sh Fixup for 17b665d5: remove 'sleep' hack & fix race condition in tests * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=771757a
[14:19:23] <quitte> since finally the live system is mostly usable I guess it's time to ask about the proper way to load the ppdev module
[14:19:53] <quitte> my problem is that I can "launch my-mill" only after running modprobe ppdev
[14:23:17] <linuxcnc-build> build #1776 of lucid-amd64-sim is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1776 blamelist: John Morris <john@zultron.com>, Michael Haberler <git@mah.priv.at>
[15:01:30] <linuxcnc-build> build #1777 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1777 blamelist: John Morris <john@zultron.com>, Michael Haberler <git@mah.priv.at>
[15:43:56] <zultron> 只要差不多就可以了吧
[15:46:57] <KGB-linuxcnc> 03John Morris 05unified-build-candidate-3 771757a 06linuxcnc fast forward * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=771757a
[16:57:17] <linuxcnc-build> build #43 of deb-precise-rtpreempt-binary-x86 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rtpreempt-binary-x86/builds/43 blamelist: John Morris <john@zultron.com>
[16:57:26] <linuxcnc-build> build #43 of deb-precise-rtpreempt-binary-amd64 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rtpreempt-binary-amd64/builds/43 blamelist: John Morris <john@zultron.com>
[17:19:50] <linuxcnc-build> build #44 of deb-precise-xenomai-binary-amd64 is complete: Failure [4failed apt-get-update shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-xenomai-binary-amd64/builds/44 blamelist: John Morris <john@zultron.com>
[17:52:16] <linuxcnc-build> build #1378 of deb-lucid-rt-binary-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-lucid-rt-binary-i386/builds/1378 blamelist: John Morris <john@zultron.com>
[18:40:30] <micges> pcw_home: raw sockets: average time of read 60us, write 30us
[18:40:48] <micges> pcw_home: spikes up to 300us
[18:41:50] <micges> pcw_home: on atom 525mw 1.8GHz
[18:41:52] <micges> skunkworks: ^^
[18:51:49] <pcw_home> OK so noticeably better but still big spikes (wonder what those are caused by)
[18:54:59] <micges> but in the log I can't find read packet which took longer than 35us
[18:56:31] <pcw_home> maybe its something else in the read part of the code thats delayed
[18:56:32] <pcw_home> (I just assumed it was network but maybe not...)
[19:02:50] <micges> I'll check
[19:03:10] <micges> does 7i76e check udp checksum?
[19:03:12] <pcw_home> I also wonder if the MAC address is needed (maybe that can be read from the ARP table)
[19:03:35] <pcw_home> Yes it should
[19:04:36] <pcw_home> (the Ethernet chip does and I'm pretty sure I enabled checking)
[19:06:03] <micges> it would drop packet if crc was wrong?
[19:07:11] <micges> if yes then even in raw sockets kernel will calculate crc of udp header for me
[19:07:39] <micges> that's good bcouse crc code is buggy and I needed to disable it to make raw sockets tests
[19:10:00] <pcw_home> Ethernet CRC yes and UDP checksum pretty sure
[19:10:02] <pcw_home> (the badrx packet count will be incremented also)
[19:11:10] <pcw_home> CRCs are almost always generated by the Ethernet chip itself (no software involvement)
[19:14:13] <micges> yep correct, I can drop all crc code
[19:43:13] <pcw_home> I wonder if some finer grain timing hal parms would help (read split into I/O time and processing time for example)
[19:44:09] <micges> yeah doing it right now
[19:57:06] <pcw_home> looks like you can use SIOCGARP to get the MAC address so it should not be needed on the command line
[19:58:28] <pcw_home> (though you have to ping or some coms before doing that)
[20:00:04] <micges> I think it's doable to ping board first in init friver
[20:00:07] <micges> driver
[20:01:07] <micges> I've dropped eth_read function to 20-30 us
[20:01:45] <micges> but system went unstable strangely
[20:02:02] <pcw_home> Yeah At least it not windows that drops UDP packets if the ARP cache is empty (and it does not refresh unless empty)
[20:02:50] <pcw_home> oops
[20:06:45] <micges> yep removing delays leads to hang on my atom too
[20:07:16] <micges> but not on 2.8GHz 2 cores cpu
[20:21:26] <pcw_home> Strange seems like polling at the maximum rate should not hurt anything
[20:22:45] <pcw_home> might be an argument for packet_mmap (where you poll a memory location)
[20:25:01] <micges> I'll start messing with it tomorrow, now I'm trying to squeeze maximum from raw sockets
[20:25:39] <pcw_home> I wish I understood why the polling delay is needed
[20:44:37] <micges> me too
[20:45:13] <micges> also why there is no trace of overrun when read took more than 2.8mln cycles (1.5ms)
[20:45:23] <micges> (got spikes like that)
[21:09:28] <pcw_home> I have not seen any spikes like that
[21:11:04] <pcw_home> I think the worst I had was maybe 400 usec on read (read_tmax after a week or so)
[21:14:09] <micges> I get to 30us and now got 1ms spikes, I've no idea what cause this
[21:15:28] <pcw_home> Hmm 1ms thread time?
[21:16:08] <pcw_home> might try with a different thread time. maybe its related
[21:20:46] <micges> hmm how did you know?
[21:20:49] <micges> :)
[21:21:08] <micges> max spikes 450us at 2ms thread
[21:24:13] <pcw_home> on what machine?
[21:24:16] <skunkworks> did we forget that the read times are in clock cycles?
[21:24:55] <skunkworks> (why it doesn't trip an overrun...)
[21:25:21] <micges> skunkworks: nope, I've calculate every time
[21:25:27] <skunkworks> heh - ok
[21:25:35] <micges> atom 525mw
[21:25:56] <micges> d525
[21:26:38] <pcw_home> hmm thats worse than I have
[21:30:28] <micges> read.tmax = 472us
[21:31:29] <pcw_home> 32774 s32 RW 498710 hm2_7i76e.0.read.tmax
[21:31:30] <pcw_home> (2 GHz)
[21:31:41] <pcw_home> so ~250 usec
[21:31:53] <micges> yep
[21:32:29] <pcw_home> wonder what got worse
[21:34:24] <pcw_home> up to 360 usec watching you tube video
[21:36:31] <pcw_home> (on 2 GHz core duo/ rtk8139)
[21:36:52] <micges> 630us on firefox
[21:38:04] <micges> 1.8ms now
[21:39:25] <pcw_home> must be something basic wrong (never seen anything like that on the previous version)
[21:53:08] <micges> pcw_home: timing changes between runs, once it is flat line and other I have 1ms spikes
[21:53:51] <micges> we will se what packet_mmap can do
[21:54:35] <micges> nite
[21:55:34] <pcw_home> nite