[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.