Your analogy makes my point again. The user decides to go that fast by
pressing the accelerator. In the case of the video driver shortcuts, it
would be like the car always goes full throttle every time it is put in
gear. I may and it may not crash before the operator turns off the
ignition, but hey, it was one hell of a ride!
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Klaus Gerlicher
Sent: Tuesday, August 07, 2001 5:04 PM
To: NT Developers Interest List
Cc: NT Developers Interest List
Subject: [ntdev] RERE: System stability was: Mapping scattered pages
into process address sp ace
There’s a point to what you’re saying with your car analogy. But MS’
restrictions have nothing to do with what the public/customer wants. In
Germany thousands of people get killed every year because there’s no speed
limit on highways. Still people want cars that can go up to 200 mph. Same
goes for computer users. They still (while whinning about bluescreening and
hanging systems) want hardware that goes way beyond reasonable stability.
Your point taken in a perfect world, why would anyone want to buy hardware
that is strained to its physical limits. It’s not in the design of things,
it’s in the minds of their users. People enforce those limits and there is
absolutely nothing a sensible engineer can do. I can only give an adrenalin
junkie what he thinks he needs.
Klaus P.
ATi
-----Ursprüngliche Nachricht-----
Von: Gregory G. Dyess [SMTP:xxxxx@pdq.net]
Gesendet am: Dienstag, 7. August 2001 23:48
An: Klaus Gerlicher
Betreff: RE: [ntdev] System stability was: Mapping scattered pages
into process address sp aceIt’s amazing how those with an opposing view keep proving my point with
almost every example you cite. Your point is exactly why MS put those
restrictions in place to begin with!Let’s look at the car analogy again. The automobile vendor does have to
work with 3rd parties: tires, head lamps, oil, gas, etc, not to mention
the
existing highways and refueling nozzles. Let’s say Exxon doesn’t like the
restrictions imposed by GM for the octane, volatility or whatever and
decided to sell rocket fuel for use in automobiles. What do you think
would
happen? What if Ford decided they knew better than the people who
designed
the roads and they built a truck that was 30 feet long and 10 feet wide
and
weighed 10 tons? Their truck could go down the road easily enough, but it
would force every other vehicle off the road. Have I made my point yet?
This is exactly what happens when you decide to write a driver that
bypasses
the rules of proper behavior within an NT/W2K system. Your device MUST
play
well with every other device in the system and that is exactly why MS
placed
those restrictions to begin with.And no, I don’t always have complete control over the exact hardware.
Yes,
the failure of a real time system is usually catastrophic. That is why we
don’t permit such shortcuts and have very stringent integration cycles. I
wish all PC hardware/software vendors did as well. Just think of the
amount
of money that could be saved in support calls alone!Greg
-----Original Message-----
From: Klaus Gerlicher [mailto:xxxxx@ati.com]
Sent: Tuesday, August 07, 2001 4:31 PM
To: ‘xxxxx@pdq.net’
Cc: ‘NT Developers Interest List’
Subject: RE: [ntdev] System stability was: Mapping scattered pages into
process address sp aceGregory,
just a question: How do you make sure everything is stable? Working on
real-time and process stuff normally makes it easier for you. There’s
probably only specialized hardware in the system and not much of software
you would see on a mainstream system. You have full control of the system.On a enduser OS you don’t have those benefits. You must take into account
that half of the system doesn’t work well together anyway. While most
software doesn’t crash the system right away a driver will as it
potentially
can access anythings and needs to control its associated hardware. How can
there possibly be a connection to your “act like a good engineer” thesis?
Car designers have full control of the system architecture, mainstream OS
driver writers don’t. We depend on all others behaving nicely. And I mean
there’s an awful lot of others running concurrently with you at the same
time. Mainboard buggy, soundcard buggy, graphics boards locks up the
system.
Is there anything in the PC world that’s not buggy. I have not seen one
graphics chip that isn’t and I’ve seen every single one in the last 5
years,
S3, Number nine, C&T, 3DLabs, E’n’S, IBM, none is fine, released with
Pandoras box inside. 50 million transistors on a chip. NVIDIA have
problems,
ATi do, memory makers do, can you finish that list for me. I have not seen
a
single piece of hard- and software that is not buggy. Remember the crash
of
the European ARIANE 5 rocket. There’s your real-time and process control.
Luckily noone died (just a cow that was struck by a piece of metal), it
just
cost zillions of dollars. HOW CAN WE EVER IMPROVE?Sound like a prayer and maybe this is one. No offense meant.
Klaus P.
ATi
> -----Ursprüngliche Nachricht-----
> Von: Gregory G. Dyess [SMTP:xxxxx@pdq.net]
> Gesendet am: Dienstag, 7. August 2001 22:26
> An: NT Developers Interest List
> Betreff: [ntdev] RE: Mapping scattered pages into process address
> sp ace
>
> Your description describes my point exactly. A short-cut in the driver
> causes unnecessary support calls. I’m not comparing your expertise
> against
> the people who wrote the OS. I am saying they are in a superior
position
> to
> understand the interactions between the various drivers. This is simply
> because you couldn’t possibly have as much contact with all the other
> devices as they do. They don’t arbitrarily make edicts and restrictions
> just for the hell of it. It’s also not a matter of them not being
bright
> enough to figure out how to give you free reign. There is a reason for
> the
> restriction or it wouldn’t be there. It’s usually there to prevent your
> device from negatively impacting the overall system. Your device is not
> the
> entire computer and it must play well with all the other devices in the
> system. Otherwise the entire system, including your device is useless.
> It’s a bit presumptuous of you to assume that your device is absolutely
> the
> most important thing in the world and ignore all rules of system
> etiquette.
> Again, I point to the Matrox lockup problem.
>
> Now, try working in my field of real-time and process control for a
while.
> The system cannot go down, period. It also cannot be randomly hit with
> unknown latencies. It has to be there and running correctly. NT/W2K is
> laughed at by control engineers for this very reason. I would love to
> still
> be using VMS because it didn’t go down, unless it had a 3rd party device
> with a buggy driver. That’s just not an option in today’s climate.
>
> Also, if you get to 99% complete 5 times faster and always crash at 99%
> complete, you’ve gained nothing over the slower solution that always
> completes. All I’m saying is play well and don’t crash the system or
you
> should face stiff consequences. This is the way all of engineering
works.
>
> Greg
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@ATi.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: xxxxx@pdq.net
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com