[10:23:50] -!- logger[psha] [logger[psha]!~loggerpsh@195.135.238.205] has joined #linuxcnc-devel
[10:24:08] -!- logger[psha] [logger[psha]!~loggerpsh@195.135.238.205] has joined #linuxcnc-devel
[10:24:23] -!- logger[psha] [logger[psha]!~loggerpsh@195.135.238.205] has joined #linuxcnc-devel
[10:24:40] -!- logger[psha] [logger[psha]!~loggerpsh@195.135.238.205] has joined #linuxcnc-devel
[10:24:54] -!- logger[psha] [logger[psha]!~loggerpsh@195.135.238.205] has joined #linuxcnc-devel
[10:58:29] -!- mhaberler has quit [Quit: mhaberler]
[11:10:02] -!- steaksinger has quit [Ping timeout: 255 seconds]
[11:16:54] -!- toastyde2th has quit [Read error: No route to host]
[11:33:26] <jepler> all night long!
[11:37:31] <jepler> (no bad latencies in an overnight run)
[11:51:44] -!- ashcan_ has quit [Client Quit]
[12:09:17] <KGB-linuxcnc> 03Jeff Epler 05jepler/revive-usrmot a79b413 06linuxcnc 10src/emc/usr_intf/Submakefile 03src/emc/usr_intf/usrmot.c Revert "usrmot: it was broken; remove it" * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a79b413
[12:09:17] <KGB-linuxcnc> 03Jeff Epler 05jepler/revive-usrmot 96df8b8 06linuxcnc 10src/emc/usr_intf/usrmot.c Fill out new required fields in emcmot_command_t * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=96df8b8
[12:17:00] -!- Guest92530 has quit [Quit: Page closed]
[12:19:21] amnesic_away is now known as amnesic
[12:19:27] -!- rob_h has quit [Ping timeout: 245 seconds]
[12:20:27] -!- mhaberler has quit [Quit: mhaberler]
[12:24:21] -!- ITChap has quit [Ping timeout: 240 seconds]
[12:41:27] -!- syyl has quit [Ping timeout: 245 seconds]
[12:50:39] amnesic is now known as amnesic_away
[12:51:15] amnesic_away is now known as amnesic
[12:57:03] -!- rob_h [rob_h!~robh@176.254.109.173] has joined #linuxcnc-devel
[13:07:20] <jepler> hm, pretty short list of master branch contributors in august
[13:26:17] -!- Thetawaves has quit [Quit: This computer has gone to sleep]
[13:39:48] -!- ler_hydra has quit [Remote host closed the connection]
[13:42:24] -!- Servos4ever has quit [Quit: ChatZilla 0.9.90.1 [SeaMonkey 2.26.1/20140612173529]]
[13:48:37] -!- lexano has quit [*.net *.split]
[13:48:37] -!- tom_o_t has quit [*.net *.split]
[13:49:00] -!- tom_o_t has quit [Changing host]
[13:50:24] -!- leavessteep has quit [Write error: Connection reset by peer]
[13:55:57] -!- memleak has quit [Quit: Leaving]
[13:58:53] -!- skunkworks_ has quit [Ping timeout: 240 seconds]
[14:03:06] amnesic is now known as amnesic_away
[14:05:33] -!- karavanjo has quit [Ping timeout: 240 seconds]
[14:23:01] -!- skunkworks_ [skunkworks_!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[14:30:38] -!- kwallace1 [kwallace1!~kwallace@smb-222.sonnet.com] has joined #linuxcnc-devel
[14:41:45] -!- Valen has quit [Quit: Leaving.]
[14:49:06] amnesic_away is now known as amnesic
[14:59:37] -!- f1oat [f1oat!~f1oat@AMontsouris-553-1-74-230.w92-151.abo.wanadoo.fr] has joined #linuxcnc-devel
[15:04:16] -!- ITChap has quit [Quit: Leaving.]
[15:13:28] <jepler> http://emergent.unpythonic.net/files/sandbox/spi-goodlatency-14h.png
[15:13:57] <jepler> oh maybe only 13 hours :-P
[15:14:40] -!- mle has quit [Ping timeout: 250 seconds]
[15:22:21] -!- basiclaser has quit [Excess Flood]
[15:36:53] -!- JLuc69 has quit [Ping timeout: 260 seconds]
[15:43:01] -!- ktchk [ktchk!~eddie6929@n219073007143.netvigator.com] has joined #linuxcnc-devel
[15:53:37] -!- mhaberler has quit [Quit: mhaberler]
[16:07:18] -!- Tecan has quit [Quit: piano time]
[16:13:04] -!- md-2 has quit [Quit: Leaving...]
[16:27:18] -!- phantoxe has quit []
[16:31:22] -!- amiri has quit [Ping timeout: 250 seconds]
[16:41:14] <pcw_home> Thats a lot better, what are the units of tmax? (on x86 they are CPU clocks)
[16:43:25] -!- larryone has quit [Quit: This computer has gone to sleep]
[16:43:57] -!- roh has quit [Ping timeout: 240 seconds]
[16:49:06] -!- PetefromTn_ has quit [Quit: I'm Outta here!!]
[16:50:58] -!- ktchk [ktchk!~eddie6929@n219073007143.netvigator.com] has parted #linuxcnc-devel
[17:04:12] -!- thealch3m1st has quit [Quit: Textual IRC Client: www.textualapp.com]
[17:25:56] -!- dieter_ has quit [Client Quit]
[17:28:02] tronwzrd is now known as tronwizard
[17:38:53] <jepler> pcw_home: units of ns
[17:43:12] -!- gonzo__ has quit [Ping timeout: 245 seconds]
[17:44:54] <pcw_home> ahh so different than on x86
[17:45:09] -!- rob_h has quit [Ping timeout: 240 seconds]
[17:50:40] <jepler> there's not a timestamp counter that's available in userspace, so it just calls clock_gettime which returns ns regardless of what the underlying time source counts in
[17:50:45] <jepler> .. which is nice because you know what the units mean
[17:56:03] <pcw_home> Yeah I always mentally divide the tmax figure by CPU clock speed...
[17:56:12] <jepler> the downside is each clock_gettime call is like an I/O, takes about a us
[17:58:55] <pcw_home> I guess the x86 timestamp is a CPU register so almost 0 overhead
[18:01:03] <jepler> there might be some registers that can be optionally enabled in userspace. not sure if they're architectural or vary from part to part. http://neocontra.blogspot.com/2013/05/user-mode-performance-counters-for.html
[18:03:35] <jepler> I guess his notes imply they're part of the arm 7a architecture
[18:08:11] <pcw_home> I guess 1 usec adds up if every component does it
[18:11:51] <pcw_home> I still think there is some interrupt affinity/priority magic that could improve latency
[18:11:52] <pcw_home> (you can see latency spikes on any components time with video access for example )
[18:13:23] <pcw_home> Ideally all (non required) interrupts should be deferred until linuxcncs thread is done
[18:14:53] <jepler> the file /proc/interrupts can be used to monitor where IRQs are being delivered
[18:14:54] amnesic is now known as amnesic_away
[18:16:49] <jepler> and /proc/irq/#/smp_affinity_list can be used to read and set the IRQ's CPU affinity
[18:17:08] <jepler> so for instance you could try putting (highest CPU #) in the ethernet card's irq affinity file
[18:17:36] <jepler> and removing it from the affinity of e.g., the video card (I've got an irq for i915@pci:0000:00:02.0)
[18:19:12] <jepler> in the case of the odroid, I can see by /proc/interrupts that only a few interrupts are delivered to CPU3 -- MCT (system timer), rescheduling interrupts, and just a few function call interrupts
[18:19:40] <jepler> and that spi-s3c64xx doesn't see any interrupts even though it has a /proc/interrupts line
[18:21:02] -!- sumpfralle has quit [Ping timeout: 245 seconds]
[18:22:18] -!- gleapsite has quit [Read error: Connection reset by peer]
[18:24:09] -!- gleapsite has quit [Read error: Connection reset by peer]
[18:26:11] -!- gleapsite has quit [Read error: Connection reset by peer]
[18:29:51] Khetzal_ is now known as Khetzal
[18:30:07] <pcw_home> What I think is desirable but probably not easily accomplished would be to
[18:30:08] <pcw_home> disable _ALL_ interrupts to _all_ CPUs except required synchronous interrupts
[18:30:10] <pcw_home> (say Ethernet or base threads) during the time linuxcncs servo thread is running
[18:32:05] -!- gleapsite has quit [Read error: Connection reset by peer]
[18:32:17] <pcw_home> though there might be deadlock potentials by doing that
[18:37:48] -!- dimas has quit [Ping timeout: 255 seconds]
[18:37:49] -!- gleapsite has quit [Read error: Connection reset by peer]
[18:39:39] -!- gleapsite has quit [Read error: Connection reset by peer]
[18:40:34] <jepler> oh you think delivering the IRQs to whatever CPU can be bad
[18:40:43] <jepler> not just stopping them from being delivered from the RT CPU
[18:42:55] <pcw_home> Just trying to understand spike eve in non/io related component times
[18:43:00] <pcw_home> even
[18:43:19] <pcw_home> even in RTAI
[18:45:08] <pcw_home> plot pid time and do some fancy video or just move mouse: spike forest
[18:48:46] <CaptHindsight> "interrupt affinity/priority magic" I think some of that kernel magic is broken
[18:49:41] -!- sylphiae has quit [Read error: Connection reset by peer]
[18:50:09] <CaptHindsight> and some video drivers use "tricks" to cut in irq line
[18:51:01] -!- rob_h [rob_h!~robh@176.254.109.173] has joined #linuxcnc-devel
[18:51:30] <CaptHindsight> DMA's should not be long enough to violate any real time threads
[18:52:46] <CaptHindsight> and setting irq affinity should really set it to the core that is set
[18:53:43] <CaptHindsight> and irq priority should really set priority, but we were seeing some odd behaviors while testing the new RTAI on the 4 core APU's
[18:53:44] -!- Loetmichel has quit [Ping timeout: 260 seconds]
[18:54:21] <CaptHindsight> I think in time we'll get this all sorted out
[18:55:20] -!- gleapsite has quit [Read error: Connection reset by peer]
[18:55:49] <CaptHindsight> i don't anyone has been playing latency watchdog for the kernel, it only gets attention when there is some noticeable regression
[18:56:40] <pcw_home> It seems pretty clear the linuxcnc's thread gets interrupted, causing "hal latencies" for lack of a better term
[19:06:11] <jepler> going to try a new kernel with userspace performance counters enabled
[19:06:20] <jepler> .. 17 hours and no bad latencies
[19:06:54] <jepler> http://paste.debian.net/118794/
[19:07:02] <pcw_home> what did you change that got rid of the 10 ms latencies?
[19:07:16] <jepler> pcw_home: moved dma acquisition to spi driver registration time
[19:07:21] <jepler> rather than every spi transaction
[19:08:54] -!- gleapsite has quit [Read error: Connection reset by peer]
[19:09:01] <pcw_home> looks like it would just about run at 2 KHz
[19:09:25] <jepler> it'll help when I rebase onto a branch that is rid of pet_watchdog
[19:09:39] <jepler> not sure how long motion typically runs..
[19:10:42] <jepler> t1 = rdtsc32();
[19:10:42] <pcw_home> how many cores does the Odroid CPU have?
[19:10:42] <jepler> t2 = rdtsc32();
[19:10:42] <jepler> printf("%u %u %u\n", t1, t2, t2-t1);
[19:10:45] <jepler> 2147499433 2147499470 37
[19:10:46] <jepler> whee
[19:10:46] <jepler> pcw_home: 4
[19:11:34] <pcw_home> 37 is a lot better than the 1000s the system call probably takes
[19:12:28] <jepler> I assume these are now units of CPU cycles (CPU speed = 1.7GHz)
[19:12:41] -!- gleapsite has quit [Read error: Connection reset by peer]
[19:12:41] <jepler> rdtsc32() reports 14213 cycles for clock_gettime()
[19:12:56] <jepler> that's more than I thought
[19:13:02] <pcw_home> wow thats an expense
[19:13:25] <jepler> hmm
[19:13:46] <jepler> 1 call is ~14k, 100 clock_gettime calls in a row is only 99k
[19:14:23] <jepler> first call in a program is very slow
[19:14:29] <jepler> second call is fast
[19:14:35] <jepler> or maybe "most" calls are fast
[19:14:40] <pcw_home> caching?
[19:15:00] <pcw_home> maybe you just had a bad one
[19:25:55] amnesic_away is now known as amnesic
[19:36:38] Cylly is now known as Loetmichel
[19:38:09] -!- gleapsite has quit [Read error: Connection reset by peer]
[19:47:46] -!- gleapsite has quit [Read error: Connection reset by peer]
[19:50:33] -!- SpeicusZ has quit []
[19:51:39] -!- gleapsite has quit [Read error: Connection reset by peer]
[19:51:47] Guest7135 is now known as hendrik
[19:59:27] amnesic is now known as amnesic_away
[20:09:49] -!- WyrM has quit [Ping timeout: 272 seconds]
[20:13:42] -!- grummund has quit [Changing host]
[20:16:27] -!- gonzo_ has quit [Ping timeout: 245 seconds]
[20:18:29] <jepler> the timestamp counter must be virtualized or something, it doesn't seem to count during sleeps
[20:19:49] <jepler> t1 = rdtsc; usleep(1000*i); t2 = rdtsc; print t1-t2
[20:19:58] <jepler> this always prints about the same value, even though it gets slower as i gets bigger
[20:20:47] -!- gleapsite has quit [Read error: Connection reset by peer]
[20:28:54] -!- Tecan has quit [Changing host]
[20:29:33] -!- FreezingCold has quit [Ping timeout: 240 seconds]
[20:30:19] <jepler> well, for posterity: http://emergent.unpythonic.net/files/sandbox/0001-THIS-DOESN-T-WORK-use-performance-counter-for-timest.patch
[20:35:08] <skunkworks_> jepler: still going?
[20:35:27] <jepler> skunkworks_: interrupted a few times to try various things
[20:38:18] -!- gleapsite has quit [Read error: Connection reset by peer]
[20:38:38] <jepler> now trying it with a 500us servo thread
[20:39:50] <jepler> I'm certainly seeing larger variations in the single-cycle velocity estimation
[20:41:22] -!- micges [micges!~captain_p@aeit150.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[20:43:03] <jepler> rtapi_app runs about 25% CPU according to top
[20:44:27] <pcw_home> I will have a DPLL latched stepgen sometime today
[20:48:30] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[20:48:32] -!- FreezingCold has quit [Ping timeout: 245 seconds]
[20:50:27] -!- Deejay has quit [Quit: bye]
[20:50:47] -!- ve7it has quit [Remote host closed the connection]
[20:50:52] <jepler> pcw_home: cool
[20:51:09] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[20:51:33] <jepler> pcw_home: did you say that via spi, it's not actually possible to reprogram the eeprom?
[20:51:57] <jepler> .. if it were possible, I'd put it on my list to look what it takes to accomplish that in mesaflash
[20:55:52] -!- gleapsite has quit [Read error: Connection reset by peer]
[21:00:15] -!- mhaberler has quit [Quit: mhaberler]
[21:03:39] -!- gleapsite has quit [Read error: Connection reset by peer]
[21:05:16] -!- PCW [PCW!~chatzilla@99.88.10.65] has joined #linuxcnc-devel
[21:06:30] <PCW> I don't think mesaflash knows how to program via SPI though the firmware does support it
[21:09:24] <PCW> (lack of standard high level SPI interface)
[21:09:24] <PCW> you can jumper for secondary (EPP), connect to EPP host, cycle power, jumper for primary, load SPI config though
[21:11:00] <PCW> its easy to forget and program both EEPROMS with SPI
[21:11:32] <jepler> /dev/spidev is the "standard" I would write to
[21:12:04] <micges> PCW: how can you program via spi? you have 2 commands according to 7i90 doc: read and write
[21:13:34] <PCW> Flash interface hardware is the same as on PCI cards (two 8 bit registers at 0x70 and 0x74)
[21:14:07] <micges> ahh
[21:14:26] <PCW> (in hm2 space so need 32 bit access)
[21:16:00] <micges> jepler: so code to write flash is in mesaflash, just need to add spi support
[21:16:31] <jepler> may not be very fast unless it's batched up
[21:17:25] <PCW> I think you can write the page data without any polling except at 256 byte intervals
[21:17:36] -!- Thetawaves has quit [Quit: This computer has gone to sleep]
[21:19:29] <micges> yeah that way it works on 7i80 programming
[21:19:33] <PCW> even at 100 MHz SPI clock (640 ns/64 bit command) the 8 bit shift out will be done before the next hm2 write command
[21:20:07] -!- WyrM has quit [Ping timeout: 272 seconds]
[21:22:43] <PCW> the 7I80 is a bit smarter since the processor waits for the shift to complete, but it has to, its next data is already in local RAM
[21:23:18] -!- asah has quit [Quit: asah]
[21:23:19] -!- gleapsite has quit [Read error: Connection reset by peer]
[21:24:11] <PCW> and the parsers overhead for loops is ~160 ns per hm2 write, faster then the flash interface shift register
[21:24:44] <micges> I see
[21:24:50] -!- WyrM has quit [Changing host]
[21:25:19] <PCW> actually the 7I80 doesnt go through HM2 space for that, but in any case it polls locally
[21:26:09] <PCW> but the SPI interface cant outrun the flash SPIinterface so bursts should be OK
[21:27:29] <jepler> ok
[21:29:10] <PCW> long bursts (so only 32 bits per 8) would limit SPI clock to 50 MHz (with no handshaking or no-op SPI commands inserted)
[21:33:32] -!- FreezingCold has quit [Ping timeout: 245 seconds]
[21:36:40] <jepler> closing in on 1 hour at 2kHz (thread max-time 315124 [ns])
[21:37:11] <PCW> very promising
[21:38:15] <PCW> micges: what do you want for a ICAP cookie?
[21:38:37] -!- gleapsite has quit [Read error: Connection reset by peer]
[21:39:29] <micges> probably something with 5 and A ;)
[21:39:44] <PCW> I can put "ICAP" in text"
[21:39:54] <micges> 1CAB
[21:40:15] <PCW> done
[21:40:59] <PCW> will add to cards that have write only ICAP
[21:41:28] <micges> ok
[21:41:30] <PCW> (SP6 PCI,SPI,EPP)
[21:42:53] <PCW> HM2_serial is different since its basically the same as Ethernet and so has a read/write port in separate address space
[21:43:08] -!- FreezingAlt has quit [Ping timeout: 260 seconds]
[21:45:54] <PCW> actual ICAP cookie = 0x1cab1cab
[21:46:22] <micges> I like it
[21:46:24] -!- gleapsite has quit [Read error: Connection reset by peer]
[21:52:42] <PCW> the latest 7I90s have 16 mbit flash chips so have room for 4 configs each
[21:53:32] <PCW> with ICAP it becomes possible to test a config in "free" flash space without risk
[21:54:23] -!- gleapsite has quit [Read error: Connection reset by peer]
[21:54:29] <micges> seems to be worth adding directly addressing prace to read/write flash and reboot to
[21:54:35] <micges> space
[21:54:51] <micges> I mean block
[21:58:08] <jepler> pulling the plug on spi also triggers the encoder velocity estimation errors
[21:58:25] <jepler> I mean, pulling the cable
[22:01:34] <PCW> Yeah so any bad data
[22:03:57] -!- gleapsite has quit [Read error: Connection reset by peer]
[22:03:59] <PCW> if the 0xAAAAAAAA is not read the whole hm2 data processing section could be skipped
[22:04:08] <jepler> I sure could add that
[22:06:14] <PCW> I will look into on CRCs (maybe CCITT16 for TX and RX in last 32 bits of data in a frame (no CRC for last 32 clocks of course)
[22:08:27] <jepler> seems like you really only need to crc one side
[22:08:32] <jepler> "the correct side"
[22:08:37] <jepler> but maybe that's harder
[22:09:22] -!- FreezingAlt has quit [Ping timeout: 245 seconds]
[22:11:23] <PCW> for the short cable lengths used CRC is probably a bit of overkill (and without buffering the frame the interface will have already written data with bad CRCs)
[22:11:24] <PCW> so there no telling what has happened
[22:21:29] -!- gleapsite has quit [Read error: Connection reset by peer]
[22:25:17] -!- FreezingAlt has quit [Quit: Out]
[22:25:19] -!- gleapsite has quit [Read error: Connection reset by peer]
[22:34:02] -!- f1oat has quit [Ping timeout: 255 seconds]
[22:36:59] -!- gleapsite has quit [Read error: Connection reset by peer]
[22:37:23] <jepler> pcw_home: I don't think I can go looking for the 0xAAAAAAAA magic cookie. except when debugging it, I read back zeros
[22:38:24] <jepler> I suspect that /CS is being managed behind my back
[22:38:34] <jepler> and there aren't big enough delays for it to actually get deasserted
[22:38:59] <jepler> it's inconvenient to attach a probe, boo
[22:40:43] -!- micges has quit [Quit: Leaving]
[22:42:27] <jepler> if it weren't actually reading back correctly almost all of the time, I'd see feedback velocity glitches; it reads back a zero cookie much more frequently than that
[22:43:47] <PCW> the 0xAAAAAAAA could be echoed whenever a command was expected instead
[22:46:36] <PCW> all that frame timeout is good for is recovering from a aborted burst transfer (resync-ing)
[22:47:43] -!- Thetawaves has quit [Quit: This computer has gone to sleep]
[22:50:39] -!- gleapsite has quit [Read error: Connection reset by peer]
[22:52:48] -!- BellinganRoy has quit [Quit: Konversation terminated!]
[22:53:23] -!- rob_h has quit [Ping timeout: 255 seconds]
[22:54:30] -!- gleapsite has quit [Read error: Connection reset by peer]
[22:55:21] <PCW> the timeout could be much shorter assuming all data for one frame fits in the FIFO
[22:55:22] <PCW> but what is the actual CS timing?
[23:12:03] -!- gleapsite has quit [Read error: Connection reset by peer]
[23:25:38] -!- gleapsite has quit [Read error: Connection reset by peer]
[23:36:47] <jepler> weeks ago in the logic analyzer it seemed like CS was deasserted between each transaction
[23:37:05] <jepler> today I can't conveniently attach the logic analyzer, the second board doesn't have the extra pins I had put on for that purpose
[23:38:14] -!- tjb1 has quit [Read error: Connection reset by peer]
[23:39:56] -!- Tecan has quit [Remote host closed the connection]
[23:40:11] <jepler> > All SPI transfers start with the relevant chipselect active. Normally it stays selected until after the last transfer in a message. Drivers can affect the chipselect signal using cs_change.
[23:40:56] <jepler> maybe I should try setting cs_change
[23:42:03] <jepler> > (ii) When the transfer is the last one in the message, the chip may stay selected until the next transfer. On multi-device SPI busses with nothing blocking messages going to other devices, this is just a performance hint; starting a message to another device deselects this one. But in other cases, this can be used to ensure correctness. Some devices need protocol transactions to be built from a series of spi_message submissi
[23:42:10] <jepler> https://www.kernel.org/doc/htmldocs/device-drivers/API-struct-spi-transfer.html
[23:47:22] -!- asdfasd has quit [Ping timeout: 245 seconds]
[23:47:54] <jepler> no, that doesn't seem to make a difference in whether I read the cookie back.
[23:48:37] -!- kfoltman has quit [Quit: Ex-Chat]
[23:48:49] -!- tchaddad has quit [Remote host closed the connection]
[23:49:13] -!- JLuc69_ has quit [Ping timeout: 260 seconds]
[23:52:49] <jepler> hm2_tp_pwmgen_read is the source of the zero-byte read operation
[23:54:24] <jepler> PCW: I expect that if you enable some tp_pwmgens on ethernet you'll get more packets as well
[23:54:39] <jepler> I guess ethernet is guarded against sending zero-length reads somewhere or other
[23:54:53] <jepler> but my code merrily encodes the SPI transaction for "read zero words starting at..."
[23:54:58] <jepler> or did until now, anyway
[23:57:17] -!- asah has quit [Quit: asah]
[23:57:58] <jepler> well, bug entered. cheers, andy
[23:59:00] <jepler> yay, that pushes a typical read transaction down to 80us