I am getting sick of this kind of arguments. Reminds me very much the
old
days when large chorus of people in comp.os.qnx (except Armin) argued
to me
how unnecessary and unwanted would it be to have SMP and threads in
QNX.
Until Dan Dodge came up and told them otherwise, lol.
I recall this argument. IIRC you were arguing that real-time systems
need SMP, and that QNX4 could, and should support SMP, and that ASMP
would be totally useless for realtime. You don’t honestly believe that
those working at QSSL didn’t know that Dan was working on SMP do you ?
It appears that you confused the owners perogative to make product
announcements with some sort of retribution of employees.
Now it is 5 years later, and how many SMP QNX6 systems are there as a
percentage of total QNX6 systems ? If SMP were so vitally important (as
you made it out to be at the time) don’t you think that more than (some
small number here)% of the (paying customer) QNX6 systems would be
shipping SMP systems ? QNX6 was designed to be SMP from the very
beginning (which btw was a long time before your SMP tirade), so
actually implementing it was relatively low cost.
Our industry has no requirement for SMP today. You continuously
complain that QNX is “not advanced” yet it has many features that the
vast majority of customers still don’t use, and probably won’t use for
years. I don’t disagree with you about the technical coolness of SMP or
a HPFS, but where is the customer base ?
Yes, QNX has better realtime technology, but that’s not the only issue
considered when decisions are made. If general-purpose OSes are
getting more
realtime capabilities, QNX needs to counter that with more
general-purpose
features, especially as technology evolves and new opportunities
arise.
Or perhaps the M$ strategy might be to get QSSL to spend inordinate
amounts of it’s R&D effort trying to provide something that is
essentially useless to their market, and to bleed off their customer
base ?
We use queueing into circular buffers to write logs and billing
information
(potentially coming from thousands of calls). Since those data are
produced
by realtime components, we did not want those components to be held by
undeterministic I/O operations.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
OK. Now let’s get back to the root of the discussion here. You want
QSSL to invest a lot of time and effort in to producing a HPFS, not a
deterministic file system. If you were calling for a deterministic
filesystem I would still say it isn’t that high a priority, but I would
concede that it is a higher priority than a HPFS. Please note that a
deterministic filesystem would be much slower than the current QNX
filesystem (since determinism would require an acknowledgement that the
data is on the media before proceeding with any addition output
operations), which would (most likely) mean that you would need to
provide queuing, which is what your complaining about having to have
done.
Writing into queue is deterministic and then
there are multiple low-priority ‘dequeuers’, such as remote log
readers (who
potentionally have different connection speed and) and flush daemon
which
saves all that stuff to disk as CPU cycles permit.
If your system is a hard real-time system then you must know exactly how
many CPU cycles it takes to flush “all that stuff” to disk. If you do,
then there is absolutely no point in having queues, simply allocate a
single buffer big enough to hold “all the stuff” that could be produced
in the number of CPU cycles it takes to write “that stuff” to disk, and
your done (if you don’t have enough memory in your system to accomodate
that single buffer, then your H/W is inadequate to support the
application, since the queues would ultimately allocate that much memory
at some point anyway - all you are doing by providing queues along with
inadequate memory is designing failure into your system).
The entire concept of dynamically allocated queues flies in the face of
predictability (which is a synonym for determinism), they are, in fact,
an admission by the programmer, that he can’t predict how much memory is
required.
People who use queues in HRT systems remind me of people who buy into
pyramid schemes, they think that as long as they can keep recruiting
more memory they’ll be OK (both approaches ultimately lead to failure).
If you’re so advanced realtime designer as to tell us that queues are
bad
even without knowing our requirements, please educate me how would you
implement that thing better.
There are always exceptions to rules, but I don’t think what you’ve
described counts as one. My guess is that the system to which you refer
above is soft real-time.
Notice, the new ‘slogger’ manager in QNX6 is
basically similar thing. Our solution was just more flexible and
scalable
(multiple queues and multithreaded manager).
slogger is a standard unix thing, it has nothing to do with QNX’s
real-time features.
‘Telecom’ is not limited to routers. Our system is mobile phone
switching
center.
Certainly telecom is not limited to routers, neither is it limited to
mobile phone switch centers.
We do process control. We need deterministic behavior from our
controllers, but our engineering and operator workstations all run on
NT. Just because QNX is aimed at the process control industry doesn’t
mean they perfectly address all of the applications within that domain
(IMO QNX addresses its part of our system better than NT addresses its
part of our system).
I will just quote one QNX employee (who I will not name): ‘Anyone
who’s
defending our disk I/O system is lying to themselves’.
I am not defending any part of the disk I/O system. All I am saying is
that it’s good enough for my requirements, and those of most current QNX
customers; and before investing a lot of effort in making it better, I’d
like to see all the real-time features of QNX working flawlessly first.
