Re: [Iaxclient-devel] Some data related to the new bug...

[Steve K. <st...@st...>]

On Apr 16, 2004, at 9:37 PM, Adam Hart wrote:

> Sorry :| That's pretty bad and I've never heard of it before (I guess 
> it's a hardware issue) 90% of games run on QueryPerformanceCounter() 
> so I guess it can't be too common. I'll fix up firefly, thanks for the 
> information.

I guess they must compensate in some way for the jumps;  You could use 
QueryPerformanceCounter along with GetTickCount, and when they don't 
match, reset your "baseline" to what GetTickCount returns.  Then you'd 
still sometimes be off by up to 10ms.

All I know is that I have two or three machines which seem to suffer 
from this.   I only actually saw it happening on one, but three suffer 
from the same symptoms, and the fix fixed all three.

-SteveK

>
> Anything else I can 'help' you with :)
>
> -Adam
>
> Steve Kann wrote:
>
>>
>> Hey Adam,
>>
>>     We took you advice here [thanks!], and used something based on 
>> your code below, which was nice _most_ of the time.
>>
>>     However, in my office, I have 3 different machines [out of only 
>> about a dozen or so we've been using this code on regularly], where 
>> this fails spectacularly.
>>
>>     The problem is described here, and it is not theoretical.  It 
>> causes real problems for timing!
>>
>> http://support.microsoft.com/?id=274323
>>
>>     So, I've disabled this in iaxclient for now.  My suggestion to 
>> you for firefly is to just use GetTickCount, and deal with it's 10ms 
>> accuracy.   The 10ms for us isn't a problem, but the 5 second jumps I 
>> saw really are!
>>
>>
>> -SteveK
>>
>>
>> Adam Hart wrote:
>>
>>> Why don't you guys just use my code from firefly, it's has nanosecond
>>> accuracy. Beats the hell out of 10ms accuaracy
>>>
>>> static __int64 freq,start;
>>> static int inited = 0;
>>>
>>> //static time_t startuptime;
>>>
>>> BOOL APIENTRY DllMain( HANDLE hModule,
>>>                       DWORD  ul_reason_for_call,
>>>                       LPVOID lpReserved
>>>      )
>>> {
>>> if(!inited)
>>> {
>>>
>>>  inited = 1;
>>>  QueryPerformanceFrequency((LARGE_INTEGER*)&freq);
>>>  QueryPerformanceCounter((LARGE_INTEGER*)&start);
>>> }
>>>    return TRUE;
>>> }
>>>
>>> void gettimeofday(struct timeval *tv, struct timezone *tz)
>>> {
>>> __int64 time;
>>> double elapsed;
>>>
>>> QueryPerformanceCounter((LARGE_INTEGER*)&time);
>>>
>>> elapsed = (double)(time - start) / (double)freq;
>>>
>>> tv->tv_sec = (long)elapsed;
>>> tv->tv_usec = (long)((elapsed-tv->tv_sec) * 1000000);
>>> }
>>>
>>> enjoy,
>>>    Adam
>>>
>>> ----- Original Message ----- From: "Steven Sokol" 
>>> <ss...@so...>
>>> To: <iax...@li...>
>>> Sent: Thursday, February 05, 2004 11:34 AM
>>> Subject: RE: [Iaxclient-devel] Some data related to the new bug...
>>>
>>>
>>>
>>>> Yes.  Guilty as charged.  It always happens UNDER WINDOWS.
>>>>
>>>> I believe that the gettimeofday() is being replaced by a function 
>>>> based on
>>>> GetTickCount().  I wonder if that doesn't have something to do with 
>>>> it.
>>>>
>>>> Steve S
>>>>
>>>> -----Original Message-----
>>>> From: iax...@li...
>>>> [mailto:iax...@li...] On Behalf Of 
>>>> Steve
>>>> Underwood
>>>> Sent: Wednesday, February 04, 2004 5:48 PM
>>>> To: iax...@li...
>>>> Subject: Re: [Iaxclient-devel] Some data related to the new bug...
>>>>
>>>> Steven Sokol wrote:
>>>>
>>>>
>>>>> More notes:
>>>>>
>>>>> 1.  It ALWAYS happens.  It is not an intermittent issue.  This 
>>>>> happens
>>>>>
>>> for
>>>
>>>>> EVERY IAX2-to-IAX2 call made using iaxClient.
>>>>>
>>>>>
>>>>>
>>>> Not EVERY call. I make hour long calls using iaxclient IAX2-to-IAX2 
>>>> and
>>>> have no trouble. I use Linux. Is that the difference?
>>>>
>>>>
>>>>> 2.  The timing is uncanny.  It ALWAYS happens after 65-67 seconds.
>>>>>
>>>>> 3.  The audio dies but the call in not immediately torn down.  The 
>>>>> call
>>>>> eventually is eventually killed when the PING/PONG cycle times out 
>>>>> some
>>>>> seconds later (perhaps over a minute in some of my tests).
>>>>>
>>>>> 4.  In EVERY case, the Asterisk kicks out the aforementioned voice 
>>>>> frame
>>>>> retransmit message.
>>>>>
>>>>>
>>>>>
>>>> As Adam said, there is something wrong if a voice frame is being
>>>> retransmitted at that point in the call. Perhaps checking places 
>>>> where
>>>> the frame is tagged for retransmission would home in on the problem.
>>>>
>>>>
>>>>> 5.  I don't see registration messages coming through at the same 
>>>>> time.  I
>>>>> was originally guessing that this happened during the re-reg 
>>>>> process.
>>>>>
>>> Not
>>>
>>>>> so (or at least that doesn't seem to be the case -- could be that 
>>>>> the
>>>>>
>>>> re-reg
>>>>
>>>>> that takes place prior to the error causes a problem).
>>>>>
>>>>>
>>>>>
>>>> Regards,
>>>> Steve
>>>>
>>>>
>>>>
>>>>
>>
>