> The use case is clear IMO. It's for financial trading software. I > don't think they really care about details like whether it's the start > or end packet, or completion, or whatever. They need a tie breaker > between when they have two different buy or sell orders on the same lot > of stock. Any deterministic timing/ordering method will do as long as > they consistently apply it I think. And the faster and lower overhead > the process, the better. He doesn't really want a timestamp, he merely > wants a sequence ordering. But a timestamp is what they are using to > get him what he needs. > > Is that a fair guess Christoph?
I get Christoph's usage model. But AFAIK, he uses UD packets, often with multicast. So the timestamp ends up associated indirectly with an actual packet. That model makes sense to me. It’s the generic time stamping of a work completion (for, say, a 2 GB transfer over RC using an SRQ) that doesn't make sense to me. That's the part I'm struggling with.
