On 9/7/2012 4:20 PM, Peter C. Wallace wrote: > On Fri, 7 Sep 2012, Stephen Dubovsky wrote: > >> Date: Fri, 7 Sep 2012 14:05:06 -0400 >> From: Stephen Dubovsky <smdubov...@gmail.com> >> Reply-To: "Enhanced Machine Controller (EMC)" >> <emc-users@lists.sourceforge.net> >> To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net> >> Subject: Re: [Emc-users] [OT] measuring real-world latency, >> was Re: worsk: sim parport component >> >> Any scope (esp PC based ones) have a blanking period while they are moving >> data, processing, then looking for the next trigger. They will do jitter >> analysis just fine on one screen of data but will miss outliers. Even >> megabuck agilent/tek/lecroy scopes don't get 100%. >> >> So... Why not just write some code for a mesa fpga board? Cheap, fast, >> 100% data coverage. > I dont think you need much, just set a stepgen to velocity mode at say 5 > MHz and sample the stepgen.feedback pin every thread invocation and feed to > hal-sampler, then process the file. (extract deltas --> run statistics) > > This is liable to be much more realistic than reading the CPU clock cycle > counter as the CPU clock is always readable but ISA/LPC/PCI/PCIE/Memory > access may be blocked by other processes > > > >> On Fri, Sep 7, 2012 at 1:52 PM, Joachim Franek <joachim.fra...@pibf.de>wrote: >> >>> What about: >>> >> ... >>
Gentle people: You've given a number of good ideas, but I think these last few suggestions are more in the ball park for what I had in mind than digital storage oscilloscopes, digital logic analyzers, or capacitor-charging circuits. I had been idly noodling about an external auditing device which I could connect to the output of whatever pulse generator I might want to characterize, like a doctor using an EKG to look at my sinus rhythm. It would continuously monitor pulse-to-pulse times and accumulate the data for such purposes as a running "what's the worst that can happen" meter like we have in the existing latency-test, stripchart displays like we have in the existing latency-plot, binning the data on graphs like we have in the osadl site, running ever-popular statistical characterizations, whatever. Why do it? Because I get a lot of time to sit in waiting rooms and idly noodle. One of the things I noodle about is the regularity or lack thereof of our different pulse-generation schemes and the way we currently "wing it" with our measurements. Once a researcher, always a researcher. How to do it? Well, back when Richard Nixon was President, I would have rigged up something that conceptually would consist of a discriminator circuit to trigger on some criterion, say the 50-percent point on the leading edge of the input pulses; the output of this circuit would gate two counters alternately. Each counter would be counting the output of a high-frequency clock. One would be counting when the other was being read and reset. Ancillary circuitry would take care of error situations like when the pulse train slowed (or stopped) to the point of causing the current counter to overflow. Orders of magnitude: the fastest pulse train might be 100Kp/s (kilopulse per second), or 10us/cycle.The clock would be 10 to 100 times faster, say 1MHz to 10MHz. Assuming no range selection, if the slowest pulse train to be considered were 1Kp/s, then with a 10MHz clock the largest count would be about 10000, requiring the counters to be at least 14-bits wide. Allowing for short-cycling, the fastest I'd have to read and clear a counter would be about 5us. If I just blindly stored all the samples, I'd accumulate roughly 2 gigabytes in 24 hours. None of this sounds tough even with the electronics I understood many decades ago (well, ok, not that 2GB business, not back then). Basically, Peter is describing the same process. Like I said before, It would be fun to have a go with FPGA. I just don't have enough hours in the day so I noodle instead. As an aside, I've been known to charge a high-quality capacitor from time to time but this application seems to call for an all-digital solution. I've also been known to attack such problems by digitally transforming from the time domain to the frequency domain (by then Gerald Ford was President), but...naagh. As another aside, there are laser researchers who worry about attosecond pulses and comparable latencies!!!! Thanks. Regards, Kent ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
