Stopwatch and nano second timer resolution in the logs

[GoogleCodeExporter]

In the Loggers Notify() clones the structure. We can add method
TimeStamp() to the relevant Loggers (or to the parent class) which
knows to add correct time stamp to any structure which contains two
fields - Ticks and Nanos (interface with two properties)
TimeStamp can be a static method
If we choose timestamp interface option we will do something like

FMRShell.MarketDataMaof

interface ITimeStamp
{
       int Ticks
       {
             get;
             protected set;
       }

       int Nanos
       {
             get;
             protected set;
       }
}

public struct MarketDataMaof : ICloneable, ITimeStamp
{
 ...
}

Sink (for example, logger) will log the time stamps in the log file or
process them in any appropriate way

Original issue reported on code.google.com by larytet@gmail.com on 10 Nov 2009 at 7:19

[GoogleCodeExporter]

Code which provides the support. 

    interface ITimeStamp

    {

        DateTime Date

        {

            get;

            set;

        }

        //// <value>

        /// always in microseconds 

        /// </value>

        long Ticks

        {

            get;

            set;

        }        

    }

    class TimeUtils

    {

        public static void TimeStamp(ref ITimeStamp o)

        {

            o.Date = System.DateTime.Now;

#if WINDOWS

            o.Ticks = DateTime.Now.Ticks;

#else

            // in Linux 10 ticks is a micro

            o.Ticks = (long)((double)DateTime.Now.Ticks / (double)(10 * 1));

#endif

        }

Original comment by larytet@gmail.com on 10 Nov 2009 at 8:06

[GoogleCodeExporter]

Just one thing regarding the code - DateTime.Now.Ticks at Windows machines has 
the
same resolution as DateTime.Now - that is, 15-16 ms. Need to use
System.Diagnostics.Stopwatch GetTimestamp() method -
http://msdn.microsoft.com/en-us/library/system.diagnostics.stopwatch.gettimestam
p.aspx
using System.Diagnostics; directive is needed.

Original comment by jerusale...@gmail.com on 10 Nov 2009 at 8:24

[GoogleCodeExporter]

Eventually I found it - another option is to use unmanaged Win32 APIs -
QueryPerformanceFrequency and QueryPerformanceCounter.

Original comment by jerusale...@gmail.com on 10 Nov 2009 at 8:31

[GoogleCodeExporter]

And here are the links:
http://msdn.microsoft.com/en-us/library/ms644904%28VS.85%29.aspx
http://msdn.microsoft.com/en-us/library/ms644905%28VS.85%29.aspx

Original comment by jerusale...@gmail.com on 10 Nov 2009 at 8:35

[GoogleCodeExporter]

Part 
#if WINDOWS
            o.Ticks = DateTime.Now.Ticks;
#else
Should be replaced by call to System.Diagnostics.Stopwatch GetTimestamp() 
method or
by call to Windows API (unmanaged).  Generally I would avoid unmanaged call 
unless it
is absolutely necessary. 

In Linux (under Mono) DateTime.Now.Ticks keeps resolution 100 nano as required 
by
.Net specifications.

Another approach would be to define proprietary class TimeStamp which knows to 
return
objects of type DateTime with correct ticks count. 

Original comment by larytet@gmail.com on 10 Nov 2009 at 8:44

[GoogleCodeExporter]

I thought of a third way (very close to the first) - defining a struct instead 
of
interface - the struct is easily converted to a delimited string using
Utils.StrutToString method. On the other hand, no problem to define a method
ToString(string delimiter) within the interface. I suspect that adding TimeStamp
class is not the most efficient solution in terms of application's speed? I 
mean -
the computations can be easily performed when I process the log data at the end 
of
day? And what about the algorithm that eventually will use the corrected time 
stamp?
remember that logging is not the main task of the system, but trading. Any cons 
and
pros regarding each approach? Which one would you prefer?

Original comment by jerusale...@gmail.com on 10 Nov 2009 at 9:06

[GoogleCodeExporter]

I am not sure if there is any performance penalty when use of interface 
comparing
struct. 

I suggested to time stamp the incoming data as soon as the data enters the sink 
and
before we forward the data to the task which do the processing. We can clone 
and time
stamp the data right in the FMR hooks OnMadad&friends if we think that all all 
most
of the data sinks (data processors) require our local time stamps. 

I think that performance considerations in this case are less important. We 
should
choose the simplest from the design and coding point of view approach. 

Original comment by larytet@gmail.com on 10 Nov 2009 at 12:13