> On 9 Mar 2019, at 00:02, [email protected] wrote: > > 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.
When you have hyperthreading enabled, then on a 4 core pc the pairs would 0 & 1 and 2 & 3. > > 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. -- 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.
