CPU pinning in Windows

“meeting time-critical constraints on Windows systems” (as well as on ANY system that is not designed for this purpose) sounds sort of nonsensical in itself

Stop. Breathe. Think. Just for once. OK?

Have you ever done work in this space? Because it sounds to me like your spouting a lot of bullshit, with no practical experience to back it up.

As I’ve so often said, average ISR and even DPC latency on most typical Windows systems is actually very good. The problem, really, for most soft real-time tasks is worst case latency. The distribution of latency values is very wide… there tend to be, in my experience, lots of outliers.

This does not necessary, in and of itself, preclude consistently meeting many time-critical constraints. We normally define real-time as "responding to an external event as it occurs. But in implementation, it’s about how you frame the problem to be solved. Every problem has constraints, parameters, and limits. For a problem like “you have to hit a register on each 100us clock pulse” you have to ask “within what time period must I hit the register to be considered on-time?” You have to do this on a true real-time system as well, of course. You see an event, you react to it.

Other problems involving time constraints relate to providing predictable response to long series of events without significant data loss. For some “significant”, right?

So, in fact, “meeting time-critical constraints on Windows systems” is something that every single person who has ever used Media Player, or streamed a video has experienced. Today, there are tons of systems with soft real-time requirements that use regular, out of the box, Windows embedded (Ugh… Windows IoT Enterprise, I think is the name du jour). Lots of “sensor notices something, driver forwards notice to program, programs responds to that thing” – I worked on one quite a while back in which a piece of paper was pushed down a “high speed” conveyor belt. When it broke a light-beam sensor, the (MFC based!) program that controlled the process needed to actuate some arms to fold the paper, then… having done that… open an envelop and stuff it in. The responses here are, indeed, time critical. They’re just not time-critical within very short intervals. This system worked quite well, for many, many, years and hundreds of millions of cycles. If you’ve received a hard-copy of a credit card bill in the past 20 years, this system probably stuffed your credit card statement into the envelope.

The ability for Windows to provide some actual guarantees regarding worst-case latency isn’t so far fetched. The guarantees might not be in nano-seconds. That doesn’t mean they can’t be useful guarantees.

So… relax.

Peter

Have you ever done work in this space?

Of course not - as I have already said in my previous post, I’ve got no interest in getting into something that I can prove with a mathematical certainty to be infeasible even in theory…

Basically, there are 3 types of possible RT-related programming

  1. Hard RT. Look at the example below

The ability for Windows to provide some actual guarantees regarding worst-case latency isn’t so far fetched. The guarantees
might not be in nano-seconds. That doesn’t mean they can’t be useful guarantees.

You don’t seem to realise that the above statement provides just a classical definition of a hard RT system. There is a deadline, and
missing it will result in a computation error. Therefore, the OS has to ensure that the deadline is met. This is what hard RT is all about - it does not necessarily imply that this deadline has to be in a nanosecond range. However, the OS has to ensure that a certain deadline is met no matter what. This kind of RT programming is done on fixed-priority basis, i.e. so-called rate-monotonic scheduling. Although it may be not optimal as far as meeting all the deadlines is concerned, it allows you to prioritise your deadlines and to make sure that the most important ones are met. For example, the ones of your air navigation system have to be met no matter what, and the ones of a music player may be missed sometimes

Therefore, if your statement was true, Windows NT would be a hard RTOS. I really hope you agree that it is not.

  1. Soft RT. With this type of RT programming the system allows missing deadlines, but tries to maximise the number of deadlines that are met using the dynamic scheduling ( Earlies Deadline First, Least Slack Time, etc). This type of scheduling potentially allows all the deadlines to be met, at least in theory. However, it does not allow you to prioritise your deadlines according to the significance of a particular task, and, hence, is unsuitable for hard RT requirements. I really hope you agree that Windows does not utilise this type of scheduling. Therefore, it is not a soft RTOS either

  2. Meeting the deadlines on “AS-IS” basis, with no guarantees whatsoever concerning either priorities of met (or missed) deadlines or percentage on the met deadlines. Look at the example below

So, in fact, “meeting time-critical constraints on Windows systems” is something that every single person who has ever used
Media Player, or streamed a video has experienced.

I am afraid you are going to be disappointed, but there is absolutely nothing even remotely “time-critical” here…

Just to give you an idea, multimedia apps work perfectly well under Linux most of the time as well. Please note that Linux happens to be, probably, the most unsuitable for RT tasks system out of all major GPOSes - it is much worse than Windows, let alone Mac, in this respect. Under the normal circumstances, multimedia apps work just fine under Linux. However, when the file system starts returning deleted blocks to the pool of available ones, even GUI may become “not-so-usable”

There are simply no guarantees here. Full stop. This is nothing more than just a mere luck. As long as the system is not busy everything works fine, so that you are getting an illusion of some imaginary “guarantees”. However, when the system gets busy, all your deadlines start getting missed one after another.

I did quite a bit of work in NDIS space, and from my practical experience I can assure you that latencies due to heavy network traffic alone may be HUGE. Just to give you an idea, MiniportSend() and/or MiniportSendPackets()handlers may get invoked at elevated IRQL,
which means that the bound protocols may be (and are) sending packets in response to the completion of the previous send operation and/or to an indication of ingress packets right in context of miniport’s DPC routine.Therefore, if network traffic is heavy, you may be almost 100% sure that miniport’s DPC will be already in a queue by the time a DPC routine returns control, so that the whole thing may be repeating itself again and again and again, and all the tasks that are meant to be “meeting time-critical constraints” have no option other than waiting till it is all over…

Actually, I think you can try a simple experiment.Try to simultaneously upload something to the server X and download something from the server Y (preferably choose the ones with data rates sufficient for saturating your connection both upstream and downstream) while watching a movie or listening to the music on the same machine. Let’s see what your “multimedia user experience” is going to be like…

Because it sounds to me like your spouting a lot of bullshit, with no practical experience to back it up.

I thought someone was complaining about “the (rude and annoying) personal attacks” earlier on this thread. It looks like I am getting too old, but I cannot immediately recall who it was…

Anton Bassov

You’re not reading my post, Mr. Bassov… you’re pontificating.

Have you ever heard the quote “casting pearls before swine”?

Another thread I’m out of.

Peter

Have you ever heard the quote “casting pearls before swine”?

Well, you have said it yourself…

It seems to be, indeed, exactly the thing that I am doing here.

You know, if someone does not agree with me on some technical issue, I would expect them (I assume someone of at least some intelligence) to present a technical counter-argument that I may or may not find convincing. However, the only things that I am getting from you are
ad hominem “arguments” and personal attacks, instead of technical counter- arguments.

I just tried to explain to you that your understanding of the "meeting time-critical constraints " concept is totally wrong. It has nothing to do with either “nanosecond range” or “responding to an external event as it occurs”. What it means is that you have to finish your computation before a certain deadline, and do it regardless of the system load - if you fail to do so, the end result is going to be a failure. In other words, the usefulness of the computed result after a missed deadline is already zero. For example, if you have missed a deadline while recording music in a studio it already does not make sense to proceed with the recording. Instead, you have to apologise to the musicians and ask them to play the song in question again, because the record in question has been already corrupted by the missed deadline beyond any repair.

However, in your example of a Media Player, the result of the computation is still going to be valid even if you miss a deadline. The worst thing that may possibly happen is getting slightly annoyed - you are not going to lose the plot of a movie if the screen freezes for a few seconds, no matter how often it happens, are you. Therefore, this is not an example of the situation when time-critical constraints are presented…

Anton Bassov

your understanding of the concept is totally wrong

You’re right Mr. Bassov. I’m wrong. Mr. Terhell is wrong. You’re right. Don’t worry. No need to read what I posted. It’s, you know, not like Mr. Terhell or I have been doing this kind of work for, you know, 20 or so years. No, you… who’ve never done work in this space… are certainly correct. My bad for not listening to you more closely. I shall henceforth strive and endeavour to pay closer attention when you pontificate.

Peter

Peter_Viscarola_(OSR) wrote:

> your understanding of the concept is totally wrong
You’re right Mr. Bassov. I’m wrong. Mr. Terhell is wrong. You’re right. Don’t worry. No need to read what I posted. It’s, you know, not like Mr. Terhell or I have been doing this kind of work for, you know, 20 or so years. No, you… who’ve never done work in this space… are certainly correct. My bad for not listening to you more closely. I shall henceforth strive and endeavour to pay closer attention when you pontificate.

Oh, great; the sarcasm detector on my computer just blew out. Now I have
ironic smoke everywhere.  Thanks, Peter.

You’re right Mr. Bassov. I’m wrong. Mr. Terhell is wrong. You’re right. Don’t worry. No need to read what I posted. It’s, you know,
not like Mr. Terhell or I have been doing this kind of work for, you know, 20 or so years. No, you… who’ve never done work
in this space… are certainly correct. My bad for not listening to you more closely. I shall henceforth strive and endeavour
to pay closer attention when you pontificate.

Yet another example of a faulty logic that, in context of this discussion, has reached truly comical and ridiculous proportions …

For the purpose of this conversation I am going to overlook the obvious fact that this argument in itself is logically faulty by virtue of being a combination of ad hominem and ad verencundiam ones. In the end of the day, this kind of an argument may, indeed, have a certain (in fact, quite high) degree of validity in the vast majority of practical everyday-life situations, so that I am going to assume it to be logically valid.

Furthermore, I am going to overlook your indirect allusion to having been trying to use unmodified Windows NT as a RTOS for the last 20 years alongside/independently from/in direct competition with Mr.Terhell. I am going to take it just as a “poetic exaggeration in the heat of an argument”, and assume that, in actuality, Mr.Terhell is a sole and exclusive owner of all proprietary rights and patents in this exciting and revolutionary field.

Instead, I am going to look at this argument solely in context of this particular discussion. For example, what would you say about the following (what a pity the new platform does not seem to allow XML-style comments - I am going to try the square brackets for this purpose)

[begin statement]

" You say the perpetual motion is infeasible. You’re right Mr. Bassov. I’m wrong. Mr. XYZ is wrong. You’re right. Don’t worry. No need to read what I posted. It’s, you know, not like Mr. XYZ has been doing this kind of work for, you know, 20 or so years. His perpetual engine can work for the entire 20 fucking seconds after the battery gets disconnected. No, you… who’ve never done work in this space… are certainly correct. My bad for not listening to you more closely…(etc)."

[end statement]

Sorry, but this is EXACTLY the kind of thing you are saying…

You know, when it comes to certain types of projects, the duration of the experience with them is not necessarily an indicator of a profound knowledge and expertise in the field. Sometimes it can be an indicator of exactly the opposite. The longer one is involved with certain types of projects, the more obvious it becomes that this person simply lacks the profound understanding of the problems that the projects in question attempt to solve, which directly results from the superficiality of this person’s knowledge of the target field and its underlying principles. Otherwise, they would have realised that the project in its current form is simply infeasible, and the problem has to be addressed differently

This is exactly what happens on this thread…

In any case, once you seem to be unwilling to (or just unable to) accept any reasonable and logically valid arguments, I am going to resort to a logically fallacious ad verencundiam one, and “Appeal to an Ultimate Authority” of MSFT employee. Please read Mr.Tippet’s post earlier on this thread - he makes it clear that unmodifoed Windows NT, in its current form, it unsuitable for handling ANY RT requirements, including even the soft ones.

I guess this argument must be more than sufficient here…

Anton Bassov

I guess we eventually had to test the ban hammer.

Mark Roddy

Mr. Bassov,

I, in a rare paroxysm of magnanimity, gave you one “get out of jail free” card, for something that I no longer remember.

You’ve just used that card.

You couldn’t leave it alone, could you.

So… here’s where we find ourselves: One more idiotic, misbegotten, fucktarded rambling from you on this board and you’re history. It just has to be enough to annoy me, Mr. Bassov. Maybe I awaken one morning to discover a gem posted in your so-called “ironical-mode”, and I read it before I’ve had my second cup of coffee, and that’ll do it. Or my dog farts (a not uncommon occurrence) while I happen to be reading a post you’ve authored about something you know nothing about, but at which you’ve chosen to hold forth at length. That’ll be sufficient. Or, I happen to be hangry and I see that you’ve “gone off” on some poor noob… and I’ll think to myself “c’est assez!”… and you’ll be done.

I guess we eventually had to test the ban hammer.

I just don’t know why it’s taking me so long. There are sooo many good moderation features on this forum.

Peter

Maybe I awaken one morning to discover a gem posted in your so-called “ironical-mode”, and I read it before I’ve had my
second cup of coffee, and that’ll do it. Or my dog farts (a not uncommon occurrence) while I happen to be reading a post you’ve authored

OMG…

It looks like we simply have totally different understanding and definitions of the very concept of predictability, Peter. No wonder we are VERY unlikely to ever reach a consensus on such topics as realtime constraints and guarantees, as well as any other issues where predictability is a must…

According to “The Hanging Judge’s” own words, the factors that may directly affect the clarity of his judgment, as well as a degree of impartiality of his final verdict, are totally out of my control. They may include, but are not limited to, quantity and type of food and beverages that he had consumed on any particular “judgment day”; neurotoxicity of the fumes that his dog produces upon any particular discharge; precise timing and frequency of above mentioned discharges; etc,etc,etc

Therefore, any of my posts, including this one, may become the final one. Taking into consideration the above, I would like to use my chance to apologise to Mr.Terhell while I am still in a position to do so. He seems to have dropped out of this discussion quite a while ago,and hence, all my subsequent sarcastic and otherwise “not-so-favourable” comments concerning his work and overall knowledge were totally unnecessary. This becomes particularly true if we take into account his attempts to stay on the technical side, and to provide some technical justification to the things he was saying.

I am sorry, Daniel, and I really mean it - I just got provoked into a pointless “discussion” yet another time, and eventually went further than I should nave had, accidentally expressing the thoughts that I most definitely should have kept to myself. I DO sincerely apologise for this…

Anton Bassov