Math or Time bug?

  • Thread starter Thread starter TDC
  • Start date Start date
T

TDC

Anyone know why this would fail?

Note that the log file timestamps shows that these all happened witin
the same second!

=======================================================

Dim lMillisElapsed As Long
Dim lStartTicks As Long = DateTime.Now.Ticks

mTracer.Trace("ReceiveMsg::RecvTimeout is " & iRecvTimeout)

LOG READS> ReceiveMsg::RecvTimeout is 60000

While lMillisElapsed < iRecvTimeout

mTracer.Trace("ReceiveMsg::MillisElapsed = " & lMillisElapsed)


LOG READS> ReceiveMsg::MillisElapsed = 0

'DATA READ OFF A SOCKET

Dim lCurrTicks As Long = DateTime.Now.Ticks

mTracer.Trace("ReceiveMsg::CurrTicks is " & lCurrTicks)

LOG READS>ReceiveMsg::CurrTicks is 632828638200000000

lMillisElapsed = (lCurrTicks - lStartTicks) \
TICKS_PER_MILLISECOND

mTracer.Trace("ReceiveMsg::MillisElapsed (2) = " &
lMillisElapsed)

LOG READS> ReceiveMsg::MillisElapsed (2) = 3600000

'AT THIS POINT THE 3600000 (which is 1 hour) CAUSES An ERRONEOUS
TIMEOUT

=======================================================

TICKS_PER_MILLISECOND is declared as in Integer (Int32), but I can't
see how that would be a problem. This problem happens very
intermittenly and it is always an hour (3600000) when it happens. SQL
CE is being populated by the data being communicated and as it happens,
if we comment out all DB code we don't seem to hit this (or perhaps not
as often anyway). In fact, just adding the trace code (which appends
to a ArrayList of strings, not to a file) seemed to have reduced these
false timeouts.

Any advice is appreciated.

Tom
 
Tom,

A few things - it is not normal to use DateTime.Now.Ticks for this sort of
operation.
Instead, System.Environment.TickCount() will give you somewhere between
..1 and .5 sec resolution assuming what you are trying to do is calculate a
duration.

Here is a sample class you can leverage:

Public Class PerformanceSampling

Const NUMBER_SAMPLERS As Integer = 8

Private Shared _perfSamplesNames(NUMBER_SAMPLERS) As String
Private Shared _perfSamplesStartTicks(NUMBER_SAMPLERS) As Integer
Private Shared _perfSamplesDuration(NUMBER_SAMPLERS) As Integer

Public Shared Sub StartSample(ByVal sampleIndex As Integer, ByVal
sampleName As String)

_perfSamplesNames(sampleIndex) = sampleName
_perfSamplesStartTicks(sampleIndex) = System.Environment.TickCount()

End Sub

Public Shared Sub StopSample(ByVal sampleIndex As Integer)

Dim stopTickCount As Integer = System.Environment.TickCount()
If (stopTickCount >= _perfSamplesStartTicks(sampleIndex)) Then
_perfSamplesDuration(sampleIndex) = stopTickCount -
_perfSamplesStartTicks(sampleIndex)
Else
_perfSamplesDuration(sampleIndex) = stopTickCount + _
(Integer.MaxValue - _perfSamplesStartTicks(sampleIndex)) + 1
End If

End Sub

Public Shared Function GetSampleDuration(ByVal sampleIndex As Integer)
As Integer

Return _perfSamplesDuration(sampleIndex)

End Function

End Class


--
Darren Shaffer
..NET Compact Framework MVP
Principal Architect
Connected Innovation
www.connectedinnovation.com
 
I am aware of this actually (this code is not originally mine). The
accuracy of the original is only 1000ms.

That being said, why does this single line:

lMillisElapsed = (lCurrTicks - lStartTicks) \ TICKS_PER_MILLISECOND

Jump to 3600000?

Are you saying that DateTime.Now.Ticks has a bug in it/is not
reliable/etc?

Again, I understand that it is not really accurate, but being off by a
whole hour in 1 out of say 1000 calls when the system has a heavy load
does seem like a problem.

Tom
 
Back
Top