I haven’t followed this thread at all.
I’m not sure that what you claim qualifies as data.
I believe what you have is “data” that you did not collect yourself, a long
time ago and some that you’re not allowed to share any context about.
Neither one of those, IMO, constitutes data to an external reader.
Just my opinion.
Mm
On Jul 17, 2012 3:10 PM, wrote:
> > Joseph M. Newcomer wrote:
> >
> >> Create a dialog-based app with two buttons, marked “Run”
> >> and “Stop”. When the “Run” button is clicked, you start a
> >> Priority 15 thread whose thread function is
> >>
> >> UINT thread(LPVOID)
> >> {
> >> while(running);
> >> return 0;
> >> }
> >
> > Forgetting about your “worst case” figure of 450ms for a moment, in your
> > original post, you said, without qualification or elaboration, that the
> > “average” case for interrupt latency to userspace was 225ms.
> >
> > Now you’re saying, well, if you fire up N threads (for N cores) all
> > spinning in a tight loop all at time critical thread priority, that your
> > system will become sluggish. Well, no kidding. However, that is hardly
> > the “average case” for a given application. So the example you’re giving
> > is one gigantic straw man. Sorry, no takers.
>
> What qualification or elaboration would you have liked? This experiment
> was conducted some years ago, not by me, so I have no access to the
> original source. The person doing it was a senior researcher at a local
> university. The average case was 225ms, interrupt-to-app-run.
>
> The point of the example was that you said that the mouse would be
> sluggish if the numbers I quoted were true. Key here is that you seem to
> think that the mouse behavior you see would be subject to the same lags as
> I reported, and I pointed out that it didn’t. Under normal operating
> conditions, there are several threads that can be running, including file
> system and other kernel threads. The consequence of these threads is a
> significant delay, interrupt-to-run, in the app, which were above the
> “real time window” that could be accepted. Yes, I know, Windows is not a
> “real time” system, but “real time” is subject to a number of
> interpretations, such as “timely response to the events in the problem
> domain”. The study was done because the system was not being responsive
> in a satisfactory manner, and the researcher decided to get some numbers
> to see what was going on. He got the numbers. He and I were both amazed
> at the values.
>
> Some years later, I was involved in a similar problem, and we were getting
> “jitter” in excess of 100ms on a fairly modern 2.2GHz uniprocessor. With
> a bit of cleverness, I reduced the “jitter” to under 100us, which is what
> they needed. So again, I have the numbers to show that delay, but I am
> not permitted to publish them (the nature of the experiment dealt with
> product development for the company I was consulting for at the time, and
> therefore are covered by my NDA, which has not expired yet).
>
> So you have opinion, and I have data. Who’s right?
> joe
>
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
> >
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
