Making Pause faster

[_Jens_]

Hi,

I have a few questions and hope you can help me with that. I am writing a C-program and use the MS Flight Simultor 2002 and FSUIPC version 2.87. The program starts the Flight Simulator, gives it 200 ms and stops it. For that I use the offset 0262. For pause I write 1 and for un-pause I write 0 to it. This works but it takes too long to set or unset the pause (50 ms on average). So I try to find a faster way to set or unset the pause.

First I tried to write a faster setPause function in the IPCUser.c file (see below).

void 
FSUIPC_setPause(gboolean bval)
{
  DWORD *pdw;
  DWORD dwError;

  FS6IPC_WRITESTATEDATA_HDR *pHdr =   (FS6IPC_WRITESTATEDATA_HDR *) m_pNext;

  // Initialise header for write request
  pHdr->dwId = FS6IPC_WRITESTATEDATA_ID;
  pHdr->dwOffset = 0x0262;
  pHdr->nBytes = 1;

  // Copy in the data to be written
  CopyMemory(&m_pNext[sizeof(FS6IPC_WRITESTATEDATA_HDR)], &bval, 1);

  // Update the pointer ready for more data
  m_pNext += sizeof(FS6IPC_WRITESTATEDATA_HDR) + 1;

  ZeroMemory(m_pNext, 4); // Terminator
  m_pNext = m_pView;

    SendMessageTimeout(m_hWnd, m_msg, m_atom, 0, SMTO_BLOCK, 2000, &dwError);


  if (dwError != FS6IPC_MESSAGE_SUCCESS) {	
    MDL_WARNING("ERROR setting MS/FS to pause.");
    return;
  }

  // Decode and store results of Read requests
  pdw = (DWORD *) m_pView;
  *pdw = 0;

  m_pNext = m_pView;

  return;
}

That works, but I still have the problem that it takes too long. With the command

SendMessageTimeout(m_hWnd, m_msg, m_atom, 0, SMTO_BLOCK, 2000, &dwError);   

you can set the time, the system is waiting for set or unset the pause (2000 ms by default). I set this value to 0 but it doesn't have any effect. Perhaps someone of you know why or where I make a mistake.

My second idea was to suspend all FS threads after 200 ms and then, if the FS should get the next 200 ms, resume all FS threads. Unfortunately it doesn't realy work. Somehow the FS notices that its threads where suspended and tries to retrieve this time. Does anyone know how the FS notices the suspending of its threads?

I hope you have any ideas and can help me with my problems. Thanks! [/code]

[Pete Dowson]

The program starts the Flight Simulator, gives it 200 ms and stops it. For that I use the offset 0262. For pause I write 1 and for un-pause I write 0 to it. This works but it takes too long to set or unset the pause (50 ms on average). So I try to find a faster way to set or unset the pause.

FSUIPC works at the FS frame rate. If the frame rate is 20 fps then an average of 50 mSecs is what you may expect. Most of the variables being read by FSUIPC are read once per frame (at most).

I cannot really support version 2.87 of FSUIPC, it is several years old and the code is almost completely different now. If you want to ask any more specific technical questions please upgrade to the current version (3.45) or wait for 3.47 which is being released tomorrow.

Regards,

Pete

[_Jens_]

Hi,

I now use FSUIPC version 3.45 but I have still the same problems. I have written a scheduler which schedules some programs. I want each of this programs to get 200 ms of processor time and then went to sleep.

In the case of the FS2002 I first tried to use the pause function by writting 0 or 1 to offset 0262 as I already described.

Unfortunately setting the FS to pause mode takes too long (50 .. 100 msec). Because of this result I tried to write a faster pause function (see my first posting).

To find the point where I loose this time I measured the time at different points within my function. So I find out that the execution of

SendMessageTimeout(m_hWnd, m_msg, m_atom, 0, SMTO_BLOCK, 2000, &dwError);   

takes between 10 and 100 msec.

My first question is, if there is a Windows function faster then SendMessageTimeout that I can use?

My second question concerns using threads. I want to now, how the FS notice that I suspend its threads. Is there an internal clock or something. If so, how can I take control of it?

I hope you can help me with that. Thanks

[Pete Dowson]

I find out that the execution of

SendMessageTimeout(m_hWnd, m_msg, m_atom, 0, SMTO_BLOCK, 2000, &dwError);   

takes between 10 and 100 msec.

That will likely nearly all be Windows process switching (x 2). Some may be time wasted whilst in the FS message queue waiting to be processed. The time actually inside my code, in FSUIPC, is very rarely as much as 1 millisecond -- it only gets that high when I have to call some function in FS which accesses disk files and loads or saves things.

My first question is, if there is a Windows function faster then SendMessageTimeout that I can use?

I think the question you need to ask is "is there any way to make Windows switch processes faster?". And I don't know the answer. You could try a 3.8 GHz Pentium 4 with hyperthreading, arranged such that your are in one virtual processor and FS is in the other. Or even a dual processor machine. But I don't really know if that switches processes that much faster either.

My second question concerns using threads. I want to now, how the FS notice that I suspend its threads. Is there an internal clock or something. If so, how can I take control of it?

I hope you can help me with that. Thanks

Sorry, no. I don't know anything about how FS is threaded at all.

Regards,

Pete

[_Jens_]

I found out that it is possible to stop the threads of the FS.

What I want to do is to develop a scheduler that schedules three processes and the FS is one them. Each process shall run 200 MS in each scheduling cycle. To achieve this for the FS, my intention was to resume the FS threads, let it run 200 ms and then stop the threads again. The problem is that FS catches up the time it was stopped as soon as it running again - of course it does so, because it is real-time processing. What I need is a possibility to reset or manipulate the internal FS timer to prevent it fom cataching up time. Otherwise I can't temporally synchchronise the three processes.

Or do you know of any other method to control the simulation time of FS from outside? Maybe my idea of stopping and starting threads is not the best way.

As I told, I also tried setting the FS to pause = FALSE, let it run 200 MS, and set pause to TRUE again. But setting to pause sometimes already takes even more than 100 MS.

Curiously waiting for your answer, thank you and regards,

Jens

[Pete Dowson]

What I need is a possibility to reset or manipulate the internal FS timer to prevent it fom cataching up time. Otherwise I can't temporally synchchronise the three processes.

It won't be possible for FS to "miss" 200 mSecs of its processing, as each new value of each flight parameter will be derived from the accelerations and forces calculated before. This is a continuous process which may be synchronised to some time (quantum), but certainly a lot smaller than 200 mSecs.

Just altering the time by adding 200mSecs someplace is not the same thing. That's just a clock. you don't affect reality by moving the hands on a clock.

Same with pausing of course. After however long it is paused for, it continues from where it was, not from where it might have been.

Or am I misunderstanding what you are trying to do? It seems very mysterious and odd.

Or do you know of any other method to control the simulation time of FS from outside?

Apart from pause, you can also change the time (but only by year/day/hours/mins/secs), the simulation rate (even down to a sim rate of zero, which is like pause but not the same), and you can put it into slew mode.

All these will have some effect on time in the Sim, but I really don't know what effect you are after.

As I told, I also tried setting the FS to pause = FALSE, let it run 200 MS, and set pause to TRUE again. But setting to pause sometimes already takes even more than 100 MS.

You should be able to get more consistency and a faster process switch by stopping windows doing anything else at all (delete all other non-essential processes), using a very fast, preferably HT otr dual processing machine, and, maybe, by raising the priority of your own and FS's processes to the one just below critical.

Pete