[RyanZAG]

I get what you're saying about how it's definitely going to be slower, but I don't understand why the read/write time to the hardware matters if the hardware is buffering the last 100 timings or so. What I'm trying to point out is that you don't have to make your entire system down to the keyboard real time - you only need to make the tiny piece that is doing the physical process real time (with some very simple logic gates that can run far faster than any general purpose CPU), and then sending the results over the PCI/whatever bus in batches later to be processed.

[valarauca1]

The only real time component of the software stack is the kernel. If you want another real time module your screwed because you need to run it in kernel space, but if you have a kernel you can't.

Or you run a real time OS which may have problems because they aren't developed with security but IO timing in mind.

It's a fundamental flaw of time shared OS's.

:.:.:

Second security works in a simple way.

Cost to secure vs money lost.

Lab equipment is expensive. The loss of an entire calibration bench could run into the $250,000 to $1million and beyond range.

But redeveloping and entire OS to do this? Your talking about spending 20 to 100x MORE on security then your losses. That's idiotic at best.

[LukeShu]

    > The only real time component of the software stack is
    > the kernel. If you want another real time module your
    > screwed because you need to run it in kernel space, but
    > if you have a kernel you can't.

I think you're confused about what RyanZAG is saying. If I'm reading correctly, he's saying "don't run the real-time stuff on the CPU." Have that stuff run on a much simpler piece of hardware that is real-time, and runs the real-time code, then have the non-real-time userland on the CPU talk to it in not-real-time.

To take your example:

    > When you access hardware on say a PCI bus (which you would in
    > this scenario). Your call to the PCI bus does not take place
    > WHEN you call for it to take place. You call the Kernel, which
    > calls the scheduler, which calls the hardware manager, which
    > calls the driver, which finally processes your request.

Design the PCI card to have it's own, smaller CPU (or FPGA, or whatever), that does the real-time interaction with the "32,600,000 pulses per second." Don't have the real-time bits depend in any way with the code running on the CPU. Have it buffer the data. The, when the PCI card is accessed by the userland program on the CPU, it dumps the buffer onto the PCI bus. The userland would obviously have be fast enough that the buffer doesn't fill up, but that speed is much less than "real time". You can then work with the data in the userland, running in non-real time.

[valarauca1]

      >don't run the real-time stuff on the CPU.

You have to is what I'm saying.

      >that does the real-time interaction with the data...

I already gave an example where I literally said I do this. What your not understanding is the time to poll and respond are part of this real time system.

As I said before. The amount of time between "Kernel, I need this time stamp." and "PID 1337 here is your time stamp" is not instant, and is not constant. There are several stages of blocking I/O, which are not always given priority over other threads. This amount of time I stated will not be instant, nor constant. While for 100% accuracy it needs to both. This part, the collection and storage, needs to ALSO take place in real time BUT BEING IN USERLAND, it can't.

So to outline

      Topic: UserLand   Kernel                      RealTimeCard
     Stage
      1)     Request                                Counting Pulses (You Want This)
      2)                Unknown time                Counting Pulses (Additional Error)
      3)                Spent Doing I/O             Counting Pulses (Additional Error)
      4)                Changing Tasks              Counting Pulses (Additional Error)
      5)                etc.                        Counting Pulses (Additional Error)
      7)                                            Near Instant Response 
      8)                Unknown time (+Error)
      9)                Changing Tasks (+Error)
     10)                Managing Memory (+Error)
     11)                Higher Priority Threads (+Error)
     12)     Data received

What this example boils down to you get a time stamp 8 'cycles' after you thought you'd get it. But that actual time stamp is really 5 'cycles' off of what you should have gotten.

Those 2 unknowns between your real time and userland are where your error comes from. You have both pre-call and post call error added. Neither are avoidable.

No matter whats on the other end of your bus unless your bus moves faster then light.