(empty message)
So, this is very interesting. It sounds like Windows is finally getting on the page of accommodating real-time solutions.
Nope…
I order to be able to get anywhere close to RTOS capabilities Windows needs to get rid of DPCs (i.e. the code that runs in context of a software interrupt), and replace it with interrupt threads that are subjected to dispatcher’s policies.
In the ideal case the same should apply to ISRs as well. This part may be a bit problematic, because in order to put ISRs under the control of a dispatcher, interrupt handler stub has to ACK an interrupt to the controller before invoking an ISR. It is understandable that, as long as we are speaking about level-triggered interrupts, an interrupt source has to be disabled in the stub if you ACK an interrupt prior to actually handling it - otherwise the machine will get into an interrupt storm. Although it may work fine for most platforms and interrupt controllers, taking this approach with APIC under x86 and x86_64 is, probably, not the best idea , because you may get quite a few spurious interrupts if you attempt something like that.
Never mind - let’s imagine guys in Redmond try to do it at some point in some OS version. You would not want to rewrite the entire OS, including all drivers, would you. Therefore, they have to maintain backwards compatibility
When it comes to interrupt threads, this part can be introduced transparently to the drivers - they can be easily made believe that their ISRs and DPCs run in context of a hardware/software interrupt, while, in actuality, running in context of a high-priority thread. Then, these dispatcher-controlled threads have to minimise their use of spinlocks, and replace them with mutexes. Certainly, as long as driver code treats spinlocks and mutexes as opaque data structures, you may be able to keep everything backwards-compatible at the source level if you do a bit of header editing, so that a call to KeAcquireSpinlock() will, in actuality, lock a real-time mutex,rather than a spinlock, behind the scenes.
However, no matter how you look at it, you would be unable to maintain backwards compatibility at the binary level. Taking into consideration that binary-level backwards compatibility is taken almost as a religious thing in Redmond, such “bold and revolutionary” changes are very unlikely to ever take place…
Anton Bassov
Anton, did you comment on the wrong thread ? By mistake perhaps ?
Anton, did you comment on the wrong thread ? By mistake perhaps ?
Well, I just explained to you what Windows kernel guys would, at the very minimum, have to do if they were about to start, in your words,
“getting on the page of accommodating real-time solutions”. This is the very, very,very minimum that would have to be done - as long as you allow certain execution units to be out of the scheduler’s control you have absolutely no means of providing latency guarantees that are required for RT tasks. Therefore, they would have to ensure that no execution unit in existence is out of the scheduler’s control (and, hence, that no one has a chance, at any point, to disable it)…
Anton Bassov
Your message sounds a bit like a rant and doesn’t seem to touch on the topic of reserving/isolating CPUs.
to be able to get anywhere close to RTOS capabilities Windows needs to get rid of DPCs
That is exactly why CPU isolation is a great idea. You get rid of unwanted interrupts and DPCs on your isolated CPU. Of course unless the DPCs are yours and part of your solution, then you have them executed exactly where you want.
//Daniel
Your message sounds a bit like a rant…
Not at all - you know, this posting platform reportedly has an extensive list of troll-managing capabilities, so that these days I try my best to avoid going into a rant mode in order to avoid “The Hanging Judge’s” wrath. What you have read is just a technical analysis of the problem
…an doesn’t seem to touch on the topic of reserving/isolating CPUs.
Indeed, it does not, simply because reserving the CPUs has nothing to do with RT, as you seem to believe. Although it may have a wide range of applications covering anything from load balancing and improving CPU utilisation to making use of NUMA capabilities of the target machine, handling RT tasks is not among them…
You get rid of unwanted interrupts and DPCs on your isolated CPU. Of course unless the DPCs are yours and part of your solution,
then you have them executed exactly where you want.
OK, let’s say you “got rid of unwanted interrupts and DPCs on your isolated CPU”. You also got an extra scheduler class that allows you to do RT scheduling, so that your RT threads can be scheduled according to your requirements. Even more, let’s assume that the OS has also introduced RT mutexes that support priority inheritance protocols. Do you really think you are in a position to handle RT tasks now?
Well, lets look at the practical example. Let’s say one of your high-priority RT threads running on a “ISR/DPC-free” CPU makes a system call that relies upon a mutex behind the scenes. This mutex is currently held by a thread that runs on another CPU that allows ISR and DPCs. Certainly, once we are speaking about RT mutex we can always adjust the owner thread’s priority accordingly. However, if interrupt occurs while the target thread holds a mutex, the owner thread is going to be unable to resume its execution( and, hence, unable to release the mutex) until the CPU flushes the entire DPC queue, and things are going to work this way regardless of the owner thread’s priority.
Therefore, your RT thread running on CPU A will have to wait until DPC queue on CPU B gets flushed.
In other words, as you can see it yourself, a delay introduced by handling ISRs and DPCs on CPU A may easily propagate itself to the CPU B in some cases, even when the latter one is spared from handling interrupts and DPCs, and all scheduler’s policies like adjusting thread priorities et al cannot do anything about it. As I have already said in my previous post, as long as you allow certain execution units to be out of the scheduler’s control you have absolutely no means of providing latency guarantees that are required for RT tasks. Full stop.
Now let’s assume something that is much, much,much worse as far as RT requirements are concerned - let’s say the target system call relies upon an event or a semaphore, rather than a mutex,behind the scenes. Unlike mutexes (and potentially RW locks) , priority inversion problems that these constructs introduce cannot be resolved, because, unlike mutexes and RW locks, they don’t have owners so that you just don’t know who is going to signal them. At this point all your RT expectations literally go to dogs - your high-priority thread may be left waiting for a low-priority one to signal an event or semaphore, and you are unable to do anything about it, despite all your CPU reservations and RT scheduling classes. Therefore, in order to avoid this unfortunate scenario, the system call in question has to be re-written with RT requirements in mind. The same applies to all other system calls, as well as kernel subsystems that they rely upon.
In other words, in order to be in a position to provide RT guarantees, the entire Windows kernel has to be re-written. How come that you don’t understand it???
I am really, really sorry for saying it, Daniel, but sometimes I am just amazed how superficial your knowledge of the system-level concepts still is - after all, you had been posting here for more than 10 years…
Anton Bassov
Let’s say one of your high-priority RT threads running on a “ISR/DPC-free” CPU makes a system call that relies upon a mutex behind the scenes.
let’s say the target system call relies upon an event or a semaphore, rather than a mutex,behind the scenes
Yes, you typically want to design your solution so that it does not have dependencies on the rest of the OS. And if it does, you make sure you work your way around them. You’re probably not going to make file system calls either from a RT thread. Not every service in the OS needs to respond within a guaranteed timeframe for it to accommodate real-time solutions.
You could have a RT thread responding to interrupts (and DPCs). Or a thread which only does a DeviceIoControl periodically. Or even a thread
which only reads and write to device registers. Without being dependent on what the rest of the OS is doing.
If you need to share or save data, you delegate that work to another CPU+thread. If a normal lock would ever become a problem, you could simply use a try/lock or even a lock-free structure.
Sometimes I am just amazed how superficial your knowledge of the system-level concepts still is - after all, you had been posting here for more than 10 years…
I can take that, for I know who’s saying it.
//Daniel
Yes, you typically want to design your solution so that it does not have dependencies on the rest of the OS. And if it does,
you make sure you work your way around them. You’re probably not going to make file system calls either from a RT thread.
Not every service in the OS needs to respond within a guaranteed timeframe for it to accommodate real-time solutions.
True, but there is a “minor” problem here - although it may all sound fine in theory, in practical terms you are limited, at the very most, to the subset of API that may be called at DIRQL if you want to run your RT tasks within Windows. Even API fnctions that are callable at DISPACH_LEVEL are, apparently, out of your reach because of the possible use of spinlocks that is not adjusted to the RT requirements, behind the scenes. All API calls that are not allowed at elevated IRQL (and, hence, all userland API in existence) are most definitely out of your reach because of the possibility of blocking calls and page faults behind the scenes.
In other words, you don’t seem to have that many practical possibilities if you go this way under Windows OS in its currently existing form, don’t you think.
In any case, you have expressed a reasonable (apparently, for the first time in this discussion) idea that RT apps need a well-defined set of special RT API functions that they are allowed to call, while all other API calls have to be prohibited for them. More on it below
You could have a RT thread responding to interrupts (and DPCs).
Well, in order to be in a position to do so, you need to put ISR and DPC handling under the control of a dispatcher, and to handle interrupts and DPCs in context of dedicated threads, rather than in the one of a hardware/software interrupt that runs out of dispatcher’s control. Now go and read again my very first post on this thread, i.e. the one that you seem to be arguing with, for some reason…
Or a thread which only does a DeviceIoControl periodically
DeviceIoControl() is just a userland function, and, hence, may touch the pageable memory or just go blocking behind the scenes. Therefore, you cannot use it from an app that requires any RT guarantees. The same is true for any other userland API in existence…
Or even a thread which only reads and write to device registers.
This part, indeed, may be done. However, " if(interrupt_occurs) goto statement_above;"
If you need to share or save data, you delegate that work to another CPU+thread. If a normal lock would ever become a problem,
you could simply use a try/lock or even a lock-free structure.
What you really need here is a well-defined set of “RT-to-non-RT-and vice-versa-communication” channels and API functions that may be called by both RT and non-RT tasks, which ensures that RT and non-RT tasks can communicate in such a way that non-RT task cannot ever block the RT one
Sure there are some ways to make GPOS and RTOS coexist on the same machine, and even work alongside one another within exactly the same application. Basically, you have to design a small kernel with its own RT scheduling/synch/etc API that is in full control of interrupts and timers. This kernel have to think about the rest of the OS as of a low-priority task, and give it a chance to run whenever no RT tasks are in sight.
As long as we are speaking about the third-part solutions, this kernel is just a module/driver that does not make any calls to the OS, from the GPOS’s perspective. All its client apps also have to be KM drivers. I am not sure you can do it with Windows these days - in order to do it you need to write your own HAL, and I am not sure HAL Developer Kit is still available. If it came from MSFT, it could be done simply as a kernel extension/modification, i.e. the one that I spoke about in my very first post on this thread. In such case one could, possibly, even expect to do RT programming in the userland. This part would require quite a bit of integration with the existing OS, and, hence, quite a few modifications to the existing kernel would be needed, so that I am not sure it would be reasonable to allow RT tasks to get out of the kernel.
However, you just cannot run your RT tasks within GPOS, and simply pinning tasks to certain CPUs while still relying upon GPOS scheduler and interrupt handling mechanism is not going to help you here in any possible way.
I can take that, for I know who’s saying it.
Well, such a reaction explains quite a lot…
You know, literally the other day I heard a truly brilliant thing from someone. The bloke said “When you speak you are just repeating something that you know already, and, possibly, re-iterating your misconceptions and erroneous beliefs. However, when you listen you may learn something new”…
Anton Bassov
sometimes I am just amazed how superficial your knowledge of the system-level concepts still is
And sometimes I’m amazed at what an absolute asshole you can be, Anton.
Mr. Terhell is one of the preeminent authorities on the practical aspects of meeting time-critical constraints on Windows systems. Of this there can be no doubt. And you and I both can learn a lot from him on this subject.
Despite the (rude and annoying) personal attacks and some random utter stupidity, this is actually a pretty-good discussion.
There are of course real-time extensions to Windows. Several are commercially available. There’s absolutely nothing that would prevent Microsoft from building such extensions and making them extremely effective.
But that’s not the point, I don’t think.
The point, rather, is how you can provide the ability to meet some soft real-time constraints on a general purpose system, without writing your own “OS within an OS.” The ability to do this would make a lot of people happy, not the least of which would be the audio production/editing community (who almost exclusively use Macs today).
Peter
And sometimes I’m amazed at what an absolute asshole you can be, Anton.
Well, certainly you are going to blame everything one me, no matter what and no matter how - this is out of question. Who would even get any doubts about it…
Mr. Terhell is one of the preeminent authorities on the practical aspects of meeting time-critical constraints on Windows systems. Of this >there can be no doubt.
I dunno, but the very phrase “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, don’t you think. I would rather refer you to your own article in “NT Insider” about sticking wings to a pig. I don’t know about you, but if I was in Mr.Terhell’s place I would take this “title” as a complete piss-taking, derision and mockery, rather than a compliment…
And you and I both can learn a lot from him on this subject.
Well, I don’t know about you, but I don’t really want to learn anything on the topic that can be easily PROVED with mathematical certainty to be infeasible in itself. Just consider the scenario when your payment depends upon the delivery of a workable product. Would you really want to waste your time on something that you know for sure cannot be made work all the time, or would you prefer to explain to your clients the amount of work that the delivery of a truly workable product involves, and give them a chance to consider all pros and cons?
The point, rather, is how you can provide the ability to meet some soft real-time constraints on a general purpose system,
without writing your own “OS within an OS.”
Again, go and check the above mentioned article in “NT Insider”…
OTOH, everything depends on what you define as " meeting soft real-time constraints"…
If you define it as a " failure rate of anything from 1% to 99% on any particular run of a program, depending solely upon the
external factors/ pure luck, and being totally out of your control"…well, then you can discuss it with Mr.Terhell. Otherwise, I would refer you to Mr.Tippet’s post than makes it clear that Windows, in its current form, is unsuitable for any RT requirements, including even the soft ones.
The ability to do this would make a lot of people happy, not the least of which would be the audio production/editing community
Again, I would refer you to Mr.Tippet’s post - he makes it clear that making Windows suitable for soft RT tasks would require tight integration of the third-party drivers. Therefore, even if it gets introduced at some point it will affect mainly SOCs and other tightly-coupled systems - you are very unlikely to see it anywhere on the commodity-grade systems…
Despite the (rude and annoying) personal attacks
Actually, I did not attack anyone -objectively, all the things that Mr.Terhell has said on this thread reveal his lack of in-depth understanding of the general OS concepts, which I find surprising for someone who has been working in this area for 10+ years. Probably, I should not have pointed it out to him, but it was not me who started speaking about “rants” and “posts on the wrong thread”, was it…
Anton Bassov
“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
- 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.
-
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
-
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