No, no, you misunderstood. I have been thinking about getting myself a new board for software generated stepper pulse signals. I don't have the J5005 yet. But I have recently upgraded my notebook from a 1x8GB stick of DDR4 memory to 2x16GB sticks and as the notebook only has 2 ports I now have unused DDR4 SO-DIMM stick. So if buying a new toy I would like to utilize it and J1900 systems use DDR3 type, so incompatible. That's the reason I have been thinking about J5005s or J4005s.
I will try to test it on multicore Desktops which I have on my disposal. (Not the same as I use for my play with Machinekit, these are too electrotrashy.) Do you have any recommendation on how to determine which cores are connected by shared cache? As datasheets are not really that informative about this part. I cannot say that I am knowledgeable enough about your accident, so I will ask full force: are these POSIX threads in RT kernel behaving the same as in vanilla kernel? Would you be able to reach this result on the vanilla kernel? C. Dne pátek 8. března 2019 4:18:45 UTC+1 John Morris napsal(a): > > I wrote the cgroups stuff, but in fact have very little experience on > different systems (and understand very little the ins-and-outs of shared > cache, memory banks, NUMA architecture, etc.). I can say that on the > J1900, though, where two L2 caches are each shared by two of the CPU's four > cores, allowing OS processes to run on a core sharing cache with the core > running the RT threads killed our excellent results, and jitter > measurements returned to those for conventional configurations without CPU > isolation. > > Your guess about memory infighting seems to make sense in our tests, but > if it's not too difficult, maybe it's still worth a try since your system > isn't exactly the same? Also, I don't understand your comment about the > DDR4 memory; is that a second stick you'd add to the J5005? (Our J1900s > have only one SODIMM.) In any case, I'd appreciate hearing about any > results on any CPU. > > OT, we encountered one interesting result entirely by accident: With CPU > isolation on the same J1900, a misconfiguration caused POSIX thread > selection instead of the intended RT_PREEMPT; however we didn't notice > because we still saw the same excellent sub-7uS jitter! > > John > > > ________________________________________ > From: [email protected] <[email protected]> on behalf of > [email protected] <[email protected]> > Sent: Wednesday, March 6, 2019 9:28 PM > To: Machinekit > Subject: Re: [Machinekit] cgroups and isolating CPU’s > > Yes, thank you. I have been reading this document since before it was > merged. > > I know that usability for me is currently zero, but I am interested in > technology and development. I have one unused DDR4 stick from notebook > upgrade, but the J5005 seems like no good choice as by datasheet the L2 > cache is shared across all cores. (So I guess memory infighting would > occur.) > > C. > > Dne středa 6. března 2019 13:04:06 UTC+1 John Morris napsal(a): > Bas is right. Here's the referenced documentation in context. > > http://<http://www.machinekit.io/docs/hal/threads-and-latency/> > www.machinekit.io<http://www.machinekit.io/docs/hal/threads-and-latency/ > >/docs/<http://www.machinekit.io/docs/hal/threads-and-latency/>hal< > http://www.machinekit.io/docs/hal/threads-and-latency/>/< > http://www.machinekit.io/docs/hal/threads-and-latency/>threads-< > http://www.machinekit.io/docs/hal/threads-and-latency/>and-latency< > http://www.machinekit.io/docs/hal/threads-and-latency/>/< > http://www.machinekit.io/docs/hal/threads-and-latency/> > > If you have no CPUs to spare, though, this will be of no use to you. > > John Morris > Dovetail Automata LLC > > From: Bas de Bruijn > Sent: Thursday, February 28, 13:43 > Subject: [Machinekit] cgroups and isolating CPU’s > To: [email protected] > Cc: Machinekit > > > So as not to hijack the thread, a new thread > > On 28 Feb 2019, at 19:20, [email protected] wrote: > > BTW, did someone else (than Zultron) try to use the core isolation feature > to "turn on" back the step signal generation in software? My electrotrash > which I use for Machinekitdoes not have cores to spare. > > Yes, you’re probably referring to this? > https<https://github.com/machinekit/machinekit/pull/1426>://< > https://github.com/machinekit/machinekit/pull/1426>github.com< > https://github.com/machinekit/machinekit/pull/1426>/< > https://github.com/machinekit/machinekit/pull/1426>machinekit< > https://github.com/machinekit/machinekit/pull/1426>/< > https://github.com/machinekit/machinekit/pull/1426>machinekit< > https://github.com/machinekit/machinekit/pull/1426>/pull/1426< > https://github.com/machinekit/machinekit/pull/1426> > > Although i dont use software step generation. The latency obtained is very > good (6-7 us). > > What was done here is to force the thread to run on designated cpu’s. > Because these cpu’s were isolated during startup (isolcpus= kernel > parameter) there are no other processes running on these cpu’s. > These cpu’s must be the pair that share their L2 cache, or hyperthreading > should be disabled and that cpu used. > > A setup that was historically used with iolcpus= kernel parameters was to > run everything on 1 cpu (disabling all but one), so that the cpu was hogged > and that got good latency results. > > This cgroups setup is the other way around, you’ll only run HAL on the > isolated cpu’s, the /RT cpuset. > > I’m no expert on this so there might be some more clarification needed > from the experts :) > > Bas > -- > website: http://<http://www.machinekit.io>www.machinekit.io< > http://www.machinekit.io> blog: http://<http://blog.machinekit.io> > blog.machinekit.io<http://blog.machinekit.io> github: https< > https://github.com/machinekit>://<https://github.com/machinekit>github.com > <https://github.com/machinekit>/<https://github.com/machinekit>machinekit< > https://github.com/machinekit> > --- > You received this message because you are subscribed to the Google Groups > "Machinekit" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > Visit this group at https<https://groups.google.com/group/machinekit>://< > https://groups.google.com/group/machinekit>groups.google.com< > https://groups.google.com/group/machinekit>/group/< > https://groups.google.com/group/machinekit>machinekit< > https://groups.google.com/group/machinekit>. > For more options, visit https<https://groups.google.com/d/optout>://< > https://groups.google.com/d/optout>groups.google.com< > https://groups.google.com/d/optout>/d/<https://groups.google.com/d/optout > >optout<https://groups.google.com/d/optout>. > > -- > website: http://www.machinekit.io blog: http://blog.machinekit.io github: > https://github.com/machinekit > --- > You received this message because you are subscribed to the Google Groups > "Machinekit" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]<mailto: > [email protected]>. > Visit this group at https://groups.google.com/group/machinekit. > For more options, visit https://groups.google.com/d/optout. > > -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
