#linuxcnc-devel Logs

Oct 09 2017

03:06 AM -!- #linuxcnc-devel mode set to +v by ChanServ
03:12 AM -!- #linuxcnc-devel mode set to +v by ChanServ
10:23 AM skunkworks: I doubt the red dye in sata cables are causing corrosion...
10:23 AM skunkworks: http://electronicsam.com/images/matsuura/20171009_090153.jpg
10:24 AM jepler: if not, how do you explain the exposed wires? you expect me to believe a knife or razor blade did that?
10:24 AM hazzy: That is what I was thinking, the sheathing is not the only insulation :D
10:24 AM skunkworks: :)
10:26 AM hazzy: But there does seems to be a correlation between the color and longevity, but it is proly not do to the color
10:27 AM skunkworks: I cannot say that I have ever had a sata cable go bad.. That I know of anyway
10:29 AM skunkworks: (I do IT for a small company.. few hundred computers.)
10:31 AM skunkworks: more times than not it is a hd going bad or blown caps on the motherboard.
10:31 AM skunkworks: followed by bad memory. (that is very rare though)
10:32 AM archivist: memory sockets and fan bearings
10:32 AM hazzy: I have had the flat (usually red) cables get flaky, but likely do to physical abuse. Never had a problem with the round ones though, but I have fewer of those and they are newer
10:32 AM skunkworks: oh - fans... forgot about those..
10:33 AM archivist: one pc I have all the fans minus the retaining clip, can pull out oil while on
10:35 AM archivist: for a while that ran with a clamp on the bga on the video card to keep it viewable
10:36 AM skunkworks: Hmm - I am sure I posted to the emc-users email correctly. but it hasn't shown up.
10:37 AM skunkworks: pretty sure
10:39 AM skunkworks: oh - there it is.
10:39 AM skunkworks: cradek, was that you?
10:40 AM skunkworks: that was exactly 1 hour delay
11:53 AM cradek: ?
11:57 AM seb_kuzminsky: cradek, stop making sourceforge slow
11:59 AM cradek: what
12:00 PM seb_kuzminsky: did you also break the power button on my phone?
12:01 PM hazzy: yeah, and my PC is giving me seg faults, what are you doing?
12:01 PM seb_kuzminsky: and my cat got autism
12:05 PM archivist: I got low steam pressure yesterday on the engine what did you do to the crew firing the boiler?
12:06 PM skunkworks: cradek, I mentioned that the email to the list didn't go through - then it did right after. Thought maybe you checked and did something :)
12:06 PM seb_kuzminsky: he finally took his finger off the sourceforge pause button he has hidden in his basement
12:07 PM cradek: I don't really have much power over the sf lists. I can't even see the subscriber list (and therefore the user-specific preferences) anymore.
12:07 PM cradek: I used to be able to tell some things, like whether mails were bouncing for a certain person, but now I can't even see that.
12:08 PM skunkworks: well poop
12:46 PM -!- #linuxcnc-devel mode set to +v by ChanServ
04:50 PM jepler: minor joomla update to install
04:54 PM jepler: skunkworks: fwiw debian just updated the kernel in stretch to be based off 4.9.51
04:54 PM jepler: which, I think unusually for stable kernel updates in debian, gets a new installed package name due to ABI changes, linux-image-4.9.0-4-rt-amd64 (was -3-)
04:57 PM jepler: but I didn't understand whether you ere saying that 4.9.47 was better, worse, or the same as 4.9.30 for your hardare
04:57 PM jepler: +w
05:03 PM seb_kuzm1nsky: i wonder what changed in the abi
05:04 PM jepler: I dunno
05:05 PM jepler: it came with 4.9.47-1, debian/changelog states "* Bump ABI to 4"
05:15 PM jepler: I don't exactly know what constitutes the kernel ABI, but the ed diff between abi/4.9.0-3/amd64_rt_amd64 and abi/4.9.0-4/amd64_rt_amd64 is about 31500 lines long
05:31 PM mozmck: It looks like from the code, that the "Unexpected realtime delay" error when using prempt-rt is not triggered unless you miss an entire period - does this sound right?
05:31 PM jepler: mozmck: yes I suspect that's right
05:32 PM mozmck: if(ts_less(task->nextstart, now))
05:32 PM mozmck: Looks like if the next start time is less than the current time, it errors.
05:32 PM mozmck: ok, thanks.
05:35 PM jepler: in this case there's simply no delay, so it will run the realtime code repeatedly until it thinks it's caught up
05:38 PM mozmck: What do you mean?
05:38 PM jepler: rather than saying "oh well I missed 3 servo periods, I'll just forget about them"
05:40 PM mozmck: Looks like it does not actually stop code running, but just issues the error message?
05:41 PM mozmck: I'm looking at the Posix::wait() function in uspace_rtapi_app.cc
05:41 PM jepler: yes
05:41 PM jepler: in 2.7
05:41 PM mozmck: yes
05:43 PM jepler: (the code has the same intent in master, but it's reworked a bit)
05:45 PM jepler: say that on arriving at the if(), task->nextstart is 1.001, period is .001, and now is 1.003. It'll print the delay message (just once per session), skip sleeping, and return to the caller of wait(). This basically causes the thread's functions to run, until wait() is called again
05:45 PM jepler: now task->nextstart is advanced to 1.002, which is still less than now() (say, 1.0033 by now), and so it skips waiting again
05:45 PM jepler: and so on until it's caught up
05:45 PM jepler: then it'll go back to sleeping until the nextstart time
05:46 PM mozmck: Ah, I see. So the wait function sleeps for any extra time remaining in the period.
05:47 PM jepler: you'd have to analyze your whole system to decide whether it would be better in this hypothetical case to advance task->nextstart to 1.003 right off the bat
05:47 PM mozmck: Yeah, probably not I would guess. I was just trying to understand exactly when that message gets sent - how bad the latency had to be.
05:48 PM jepler: (and to change that policy you'd have to change rtapi)
05:49 PM jepler: OK, I hope that helped clear up what the intent of the code was
05:49 PM jepler: afk
05:50 PM mozmck: It did, thanks.
08:15 PM skunkworks: jepler, I compiled linux-4.9.47 with the realtime patches patch-4.9.47-rt37.patch
08:15 PM skunkworks: it didn't work for me - but I may have had an issue with that kernel and virtualbox