> If you want low latency/low jitter (i.e., down into the single-digit > millisecond range), you have to store the data in memory. There's > just no way around that problem, at least not with the latest > technology we have available to us today.
I'm pretty sure that the processing time (CPU or disk or whatever) taken by the server is not critical to getting the right answer. Probing a database would probably impact the number of clients a server can handle but that's a different issue. The client grabs the time and stuffs that into the request packet. It does that as late as it can in the sending code. The server grabs the time as soon as it can after the packet arrives. Both of those timestamps go back in the response. The server also puts a sending timestamp into the response, again as late as it can in the processing path. The client grabs the time as soon as it can when the response arrives. That gives the client enough info to subtract out the time the packet was sitting on the server. That structure is already needed to keep things like crypto crunching from causing problems. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam. _______________________________________________ timekeepers mailing list [email protected] https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
