No worries,
Time slices are in microseconds not milliseconds (us v. ms), regarding 10 us microseconds versus 1 us microsecond to process interrupts: Few tools can monitor, verify or validate timings at these speeds.
Throwing another wrench into the timing debate are the dual and quad core processors standard today, some of the new hardware implementations utilize a separate hardware timer.
Regardless of how ever fast you are able to process price data you are always bound to the slowest process of the overall trading system. Probably more important for performance is how your application multi-threads.
Time slices are in microseconds not milliseconds (us v. ms), regarding 10 us microseconds versus 1 us microsecond to process interrupts: Few tools can monitor, verify or validate timings at these speeds.
Throwing another wrench into the timing debate are the dual and quad core processors standard today, some of the new hardware implementations utilize a separate hardware timer.
Regardless of how ever fast you are able to process price data you are always bound to the slowest process of the overall trading system. Probably more important for performance is how your application multi-threads.
Quote from gastropod:
Hello PocketChange, I hope you do not think I am arguing with you on this thread. My discussion/rant on time slices may or may not concern what you are working on.
I do not know whether you care about the added time slice time. I believe your calculations will show you your "total" time for processing in microseconds. My whole beef is that calculations may not show (which is OK, if you don't care about them showing up and latency is not a problem for you) latency, which (if you care) is included in packet processing on any OS.
The scenario is this...
Begin time slice - you get packets - you process packets - near the end of first time slice - you get "tick C" - you begin processing "tick C" and have added a "time stamp" to it - oh oh - time slice over - wait 1 time slice for "other" program to run - now trading app runs again - "tick C" finishes processing
Does your calculation include the time of the time slice or does it just show the time of processing? Some people (who watch the latencies) care about the latency time and others (those who don't care about latencies) don't care about the added time slice.
Sorry about my lack of good communication here, but I will try an example to explain what I am saying...
The world record for the 100 meter dash is around 10 seconds. How about if I "sprint" 5 meters in 0.5 seconds...take a one hour break...come back and "sprint" another 5 meters in 0.5 seconds...repeating this sprint/break pattern for a total of 20 of my "sprints." In the end, yes, I have "run" 100 meters in about 10 seconds...but, did the 19 hours of breaks I took in between count???? My total calculation is a "10 second 100 meter run" - but my "elapsed" time is close to 1 day!
Just a thought or two
-gastropod
