Gui timer v/s Async timer priority

Hi NI,
I am trying to build an application where in i am communicating with an automotive ECU over RS-232 periodically. I am using an aysnc timer to do the communications part and a GUI timer to do the graphical object update. I have three questions for your team.
1. What RTOS and PC configuration do you recommend for using a RT Async Timer with Prority ? (preferably whats available in the market today in terms of "cheap" hardware)
2. What is the priority of the GUI timer when compared to the Async timer? Is is possible for the GUI timer to inetrrupt the Async timer fucntion call ? If yes...is there an exclusion mechanism that would stop this from happening ?
3. I am using a two linked list concept...the first list populates while the other's data is being drawn on the strip chart...and then i flip over to populating the second linked list while the first lists data is being plotted. The communications(population of data in a structure in a linked list) is being done in the Async thread while the plotting is being done in the GUI thread. The issue i am facing is that i do not have a clean linked list population, plotting and freeing of data sequence...i feel this is due to some un-predictability in the timer function calls.(hence Q2 above). Do you recommend only using thread safe queues or do you think this is do-able with linked lists.
Looking forward to your reponse.
-Ashish

I don't know what degree of certainity you need but a "fixed calling and execution sequence" is just a dream in a Windows environment.
Windows will operate your threads together with many more of its own, all with varying priorities.
So, you should think of priority as a vague way of making one thread to be operated more/less than another lower/higher degree thread.
No thread priority class guarantees a certain frequency of thread execution.
GUI timer callbacks are executed in the main program thread while async timers are executed in a seperate thread.
So, yes their execution times may coincide. Hence the need to protect your global data.
Data accessed by multiple threads should be protected so that, no thread would be interrupted in the middle of a write/read operation on that data.
TSQs do that for you. Otherwise you cannot be sure about the integrity of the data you are plotting.
If you need do some more reading about this. But TSQs stand out as a more elegant way to solve your problem.
S. Eren BALCI
www.aselsan.com.tr

Similar Messages

  • Front End network time and GUI time

    Hello,
    I am having a few doubts on the performance monitoring of SAP servers.
    GUI time - is the time taken for several communication steps between the SAP R/3 server and the local SAP R/3 frontend.
    After this definition i have a few doubts.
    1) what is the difference between, GUI time and front end network time?
    2) While calculating the processing time do we substract GUI time from the actual respone time?
    Please help.
    Thanks.
    Regards,
    Siddhartha

    Hi,
    F1 help provides the exact information of the each time specified in st03n..
    Further for your information:
    Frontend time:
    The front-end network time (FE Net time, fenettime, sometimes also called guinettime) is the time span that is consumed for sending data from/to the front end.
    However, no roundtrips (RFCs) for the GUI are included. These are entered in the GUITIME.
    If RFCs are involved on the server side, this time is specified with an incorrect value.
    The FE Net time is formed by the difference that arises between the response time from the view of the frontend and from that of the application serve
    GUI time:
    The GUI time is the time used in the network and the local front end for these communications steps (not the time in the application server, however). The GUI time does not contain the front end network time.
    Regarding the Processing Time:
    Please Refer following note 8963.
    For Response time Refer note 1063061 which gives clear idea of What is response time.
    Thanks and Regards,
    Balaji.S

  • High roll wait time, gui time and processing time

    Hi all,
    We are having a performance issue with the system at the moment. After running ST03N and STAD, we have determined that we are having abnormally high roll-wait, GUI and processing times.
    Here are some results from STAD:
    CPU time: 2956ms
    Processing time: 4417ms
    Roll wait time: 1319ms
    GUI Time: 2859ms
    Can someone direct me towards finding the problem?
    If you need more information please let me know. I would post a screenshot if I was able to.
    Thanks,
    HL

    Hi,
    Regarding Performance Of SAP system it will not be possible to Come to conclusion with the one Single data.
    GUI time is basically the time spent in front end i.e Your Network load or such time
    Coming to CPU time Can you see ST06 what is the CPU Utilization of your system?
    Roll Wait time is the time Spent in buffer if you can share us the OS and Memory configuration.
    We can Try to tune the Roll memory ( extended memory tuning) so that we can try to reduce the Roll time.
    If possible try to find the Top Dialog Response Time Transaction Is it Standard or for Z Programs.
    https://cw.sdn.sap.com/cw/docs/DOC-14387
    Go through this link you might get clear idea of performance.
    Thanks & Regards,
    Balaji.S

  • High GUI Time - Causing high Response time

    Hi All,
    Average GUI Response time is approx 400 ms in my ECC 6.0 system, OS - HP UX, Database - Oracle 10.2.0.5.
    I expect it should always be approx 200 ms, but as it is high it is contibuting to high overall response time.
    I expect there are normally two ways of high GUI time :
    1)  High network time between Presentation layer( User System) and Application Layer(SAP Server).
    2) High amount of time in Loading User Screen
    For Option 2 I have checked we are using SAP access menu so there should not any problem with loading of User Access Menu.
    Average Response time for session_manager is 2 Secs.
    Please suggest me what all other ways available to improve GUI time,
    Can there be other reasons of high GUI time and how can we make sure that high GUI time is only because of high Network time.
    Please suggest.
    Shivam

    I believe in case you have multiple roundtrips per step, then the client performance comes into play as well. So if you have slow clients this could be an issue too.
    Basically you are already looking in the right place (network connection), but i recommend you also check:
    - roundtrips per step and amount of data sent to the client
    - are all transactions having high gui times, or only a few?
    - how is the situation on the clients?
    - if you have clients working on prod and qas check the values on the qas system too
    Cheers Michael

  • High GUI time in ST03

    I found high GUI time in ST03.
    Example: In last minute's load --> workload overview -->
    Start of interval  27.10.2008  07:43:00
    End of interval    27.10.2008  07:58:00
    Time period        0   Day(s)  00:15:01
    I found 1280ms Roll wait time and 1280 GUI time. It seems too high. How can I find what cause it? how can I locate the root case?
    Please advise. Thanks so much.
    James

    Hi,
    Here are the few things to check when the GUI time is high.
    1. Check in ST03--> Transaction Profile the Tx SESSION_MANAGER may be on top id yes, the load caused by the transaction SESSION_MANAGER, combined with the high roll in + wait time could indicate that the SAP Easy Access menu might not be configured correctly and should be tuned to improve overall response times. It is also possible that your users have been assigned disproportionately large user menus. We advise you to ensure there are a reasonable number of entries (nodes) in the User Menu.
    Generally, its recommended that users should have no more than 1000 and as an absolute maximum 2000 menu nodes configured, (for comparison, the complete SAP menu contains 70,000 entries).  A high number of entries may lead to high memory consumption on the server and to long response times for the menu. Refer to SAP Notes 203617 and 203994 for details
    2. ST06 --> Detail Analysis Menu --> Lan check by Ping with more than 10 Presentation
    servers.
    See the Average and Loss coloumn and check wether is there any problem exits.
    However, review the following recommendations to identify any network issues. Given below are the response times which are thresholds for a good network performance.
    Recommendation: Characteristic response times are:
    -  In a local area network (LAN) : <20 milliseconds
    -  In a "fast" Wide Area Network (WAN) (for example, 256 or 384 KBit/sec):   < 50 milliseconds
    -  In a "slow" wide area network (WAN) (For example, 128 KBit/sec or less): < 250 milliseconds
    -  Losses of data packets ("Loss") should not occur at all.
    Review SAP Notes 203924 (under subheading 'General Performance Analysisu2019), 8963 and 578118 for further information on SAP GUI and response time components.
    In case of long response times due to performance problems in the network (in particular when using SAPGUI in WAN), you should use configuration "Low Speed Connection" in SAPLOGON. As a result, menus are only transferred on request, and the quantity of the transferred data is reduced correspondingly. This measure reduces the network load significantly. You can find this setting option under: SAPLOGON -> PROPERTIES -> ADVANCED.
    Option for a low speed connection:
    On a low speed connection (LSC) to the network, the benefits of the improved interaction design may be outweighed by increased response times due to the heavier network traffic. To counterbalance this effect, SAP has introduced the option for a low speed connection to the network in Release 4.6. A flag can be set in the options of an SAP logon connection item or on the SAP GUI command line. This action has the following effects:
    -  Menus are loaded only on demand as before
    -  Background Bitmaps are not transferred (depending on the application)
    -  The list control transfers only the lines that are visible on the screen
    -  The application can query the flag to react to the network condition individually.
    Examine the following SAP Notes and verify that the SAP recommendations contained are fully implemented:
    -  SAP Note Number 161053   Low Speed Connection is in use
    -  SAP Note Number 164102   Network load between application servers +camera front end
    -  SAP Note Number   62418   Network Load of SAPGUI Frontend Communication (Required Bandwidth).
    Please let me know if the performance improves.
    Thank you,
    Tilak

  • Async timer slows operation down

    Having previously used asynchronous timers to resolve another problem that I had, I'm now looking at an issue that has got me stumped
    Here is a code snippet which has had an asynchronous timer applied
    int CVICALLBACK ParentEvent (int reserved, int control, int event, void *callbackData, int eventData1, int eventData2)
    static int iInfoFlag = 1;
    //If Com Timer event has occurred then:
    if (event == EVENT_TIMER_TICK)
    SetAsyncTimerAttribute(control,ASYNC_ATTR_ENABLED, 0);
    //First, has sonde configuration changed?
    if (iSondeConfigure_HasChanged() == YES)
    //Re-initialise displays etc, if true
    InitialiseSondeSystems(iFloatingPanels);
    //Get Sonde data
    if (ProgStatus.bComTimerEvent == TRUE)
    CompactDataControl (hParentPanel, iInfoFlag, &ProgStatus, NULL);
    //If Com events are disabled then set Sonde Info flag for next data
    //acquisition sequence
    if (ProgStatus.iComEnable != ENABLED)
    iInfoFlag = 1;
    SetAsyncTimerAttribute(ParentTimer,ASYNC_ATTR_ENABLED, 1);
    return(0);
    This routine was previously handled by a conventional timer but as these sit at the bottom of the pile when it comes to scheduling, as soon as the interface was manipluated it shut up. The timer in each case is set at 0.1 second, and if the bComTimerEvent flag is set to true, which is controlled by another (currently traditional timer) it goes away and grabs data from an external source. Using traditional timers, I can clock this 'grab the data' timer quite happily at 0.25 seconds. However with the code shown, it wont grab data any faster than about 1.5 seconds. I have timed how long it takes to call and return from CompactDataControl. With traditional timers its about 0.2 seconds, with the code as shown, its about 1.45 seconds.
    Any thoughts as to what I've missed or messed up.
    Regards
    Gavin
    Solved!
    Go to Solution.

    All I'm doing is calling Timer() before and after a particular function, and working out how long it takes... I've done this with both normal, and async callbacks and got significant differences. I think due to the nature of what has been done already, this code will need the same treatment as the last project I worked on that required async timers, which was a complete rewrite from the ground up. What is interesting is that that project does make changes to the GUI based on the async timers, without any obvious performance issues, despite of the fact that elements of the GUI are created in the main thread. However this project is doing an awful lot more, which might in someway explain this.
    I'd be interested to know if there is any way you can use traditional timers without the problems of timers stopping, when moving or resizing the GUI - the thing I am try to prevent by using async timers
    However I think what youre saying about your use of Async timers for number crunching, and standard timers for GUI update is a good idea, and I'm pretty sure would work for me.

  • Table name for dialog response time without GUI in ST03?

    In SWNC_COLLECTOR_GET_AGGREGATES, cnt00x (x =1,2,3... 9) gives me the proportion of transaction steps with a response time between 0s and the upper  limit of the individual response time categories (includes GUI time), broken down by task type. But where is the data without GUI time store? any ideas?

    Hello Surya
    here screenshots from my test:
    ST03 for my instance before I have executed something on it, no dialog task type:
    here I have connected to the instance through SM51, still no dialog task type:
    and here I have connected directly through SAP Logon to this instance, now my actions on the instance are displayed as dialog task type:
    If your users connect through RFC to the instance, then all their actions are RFC task type actions. As soon as a user logons directly to the instance, dialog task type will appear in ST03.
    regards,
    Alwina

  • Strange response time for an RFC call viewed from STAD on R/3 4.7

    Hello,
    On our R/3 4.7 production system, we have a lot of external RFC calls to execute an  abap module function. There are 70 000 of these calls per day.
    The mean response time for this RFC call is 35 ms.
    Some times a few of them (maybe 10 to 20 per day) are way much longer.
    I am currently analysing with STAD one of these long calls  which lasted 10 seconds !
    Here is the info from STAD
    Response time :                10 683 ms
    Total time in workprocess : 10 683 ms
    CPU time  :                               0 ms
    RFC+CPIC time :                       0 ms
    Wait for work process           0 ms
    Processing time           10.679 ms
    Load time                            1 ms
    Generating time                   0 ms
    Roll (in) time                        0 ms
    Database request time         3 ms
    Enqueue time                      0 ms
    Number      Roll ins            0
                     Roll outs           0
                     Enqueues         0
    Load time   Program             1  ms
                      Screen              0  ms
                     CUA interf.          0  ms
    Roll time    Out                 0  ms
                      In                  0  ms
                    Wait                0  ms
    Frontend    No.roundtrips       0   
                      GUI time            0  ms
                      Net time            0  ms
    There is nearly no abap processing in the function module.
    I really don't uderstand what is this  10 679 ms processing time especially with 0 ms cpu time and 0 ms wait time.
    A usual fast RFC call gives this data
    23 ms response time
    16 ms cpu time
    14 ms processing time
    1 ms load time
    8 ms Database request time
    Does anybody have an idea of what is the system doing during the 10 seconds  processing time ?
    Regards,
    Olivier

    Hi Graham,
    Thank you for your input and thoughts.
    I will have to investigate on RZ23N and RZ21 because I'm not used to use them.
    I'm used to investigate performance problems with ST03 and STAD.
    My system is R/3 4.7 WAS 6.20. ABAP and BASIS 43
    Kernel 6.40 patch level 109
    We know these are old patch levels but we are not allowed to stop this system for upgrade "if it's not broken" as it is used 7/7 24/24.
    I'm nearlly sure that the problem is not an RFC issue because I've found other slow dialog steps for web service calls and even for a SAPSYS technical dialog step  of type <no buffer>. (what is this ?)
    This SAPSYS dialog step has the following data :
    User : SAPSYS
    Task type : B
    Program : <no buffer>
    CPU time                       0 ms
    RFC+CPIC time              0 ms
    Total time in workprocs    5.490 ms
    Response time               5.490 ms
    Wait for work process           0 ms
    Processing time             5.489 ms
    Load time                            0 ms
    Generating time                   0 ms
    Roll (in+wait) time                0 ms
    Database request time          1 ms ( 3 Database requests)
    Enqueue time                       0 ms
    All hundreds of other SAPSYS <no buffer> steps have a less than 5 ms response time.
    It looks like the system was frozen during 5 seconds...
    Here are some extracts from STAD of another case from last saturday.
    11:00:03     bt1fsaplpr02_PLG RFC     R     3     USER_LECKIT     13     13     0     0
    11:00:03     bt1sqkvf_PLG_18      RFC     R     4     USER_LECDIS     13     13     0     0
    11:00:04     bt1sqkvh_PLG_18      RFC     R     0     USER_LECKIT     19     19     0     16
    11:00:04     bt1sqkvf_PLG_18      RFC     R     4     USER_LECKIT     77     77     0     16
    11:00:04     bt1sqkve_PLG_18      RFC     R     4     USER_LECDIS     13     13     0     0
    11:00:04     bt1sqkvf_PLG_18      RFC     R     4     USER_LECDIS     14     14     0     16
    11:00:05     bt1sqkvg_PLG_18      RFC     R     0     USER_LECKIT     12     12     0     16
    11:00:05     bt1sqkve_PLG_18      RFC     R     4     USER_LECKIT     53     53     0     0
    11:00:06     bt1sqkvh_PLG_18      RFC     R     0     USER_LECKIT     76     76     0     0
    11:00:06     bt1sqk2t_PLG_18      RFC     R     0     USER_LECDIS     20     20     0     31
    11:00:06     bt1sqk2t_PLG_18      RFC     R     0     USER_LECKIT     12     12     0     0
    11:00:06     bt1sqkve_PLG_18      RFC     R     4     USER_LECKIT     13     13     0     0
    11:00:06     bt1sqkvf_PLG_18      RFC     R     4     USER_LECKIT     34     34     0     16
    11:00:07     bt1sqkvh_PLG_18      RFC     R     0     USER_LECDIS     15     15     0     0
    11:00:07     bt1sqkvg_PLG_18      RFC     R     0     USER_LECKIT     13     13     0     16
    11:00:07     bt1sqk2t_PLG_18      RFC     R     0     USER_LECKIT     19     19     0     0
    11:00:07     bt1fsaplpr02_PLG RFC     R     3     USER_LECKIT     23     13     10     0
    11:00:07     bt1sqkve_PLG_18      RFC     R     4     USER_LECDIS     38     38     0     0
    11:00:08     bt1sqkvf_PLG_18      RFC     R     4     USER_LECKIT     20     20     0     16
    11:00:09     bt1sqkvg_PLG_18      RFC     R     0     USER_LECDIS     9 495     9 495     0     16
    11:00:09     bt1sqk2t_PLG_18      RFC     R     0     USER_LECDIS     9 404     9 404     0     0
    11:00:09     bt1sqkvh_PLG_18      RFC     R     1     USER_LECKIT     9 181     9 181     0     0
    11:00:10     bt1fsaplpr02_PLG RFC     R     3     USER_LECDIS     23     23     0     0
    11:00:10     bt1sqkve_PLG_18      RFC     R     4     USER_LECKIT     8 465     8 465     0     16
    11:00:18     bt1sqkvh_PLG_18      RFC     R     0     USER_LECKIT     18     18     0     16
    11:00:18     bt1sqkvg_PLG_18      RFC     R     0     USER_LECKIT     89     89     0     0
    11:00:18     bt1sqk2t_PLG_18      RFC     R     0     USER_LECKIT     75     75     0     0
    11:00:18     bt1sqkvh_PLG_18      RFC     R     1     USER_LECDIS     43     43     0     0
    11:00:18     bt1sqk2t_PLG_18      RFC     R     1     USER_LECDIS     32     32     0     16
    11:00:18     bt1sqkvg_PLG_18      RFC     R     1     USER_LECDIS     15     15     0     16
    11:00:18     bt1sqkve_PLG_18      RFC     R     4     USER_LECDIS     13     13     0     0
    11:00:18     bt1sqkve_PLG_18      RFC     R     4     USER_LECDIS     14     14     0     0
    11:00:18     bt1sqkvf_PLG_18      RFC     R     4     USER_LECKIT     69     69     0     16
    11:00:18     bt1sqkvf_PLG_18     RFC     R     5     USER_LECDIS     49     49     0     16
    11:00:18     bt1sqkve_PLG_18     RFC     R     5     USER_LECKIT     19     19     0     16
    11:00:18     bt1sqkvf_PLG_18     RFC     R     5     USER_LECDIS     15     15     0     16
    The load at that time was very light with only a few jobs starting :
    11:00:08 bt1fsaplpr02_PLG RSCONN01                     B 31 USER_BATCH     39
    11:00:08 bt1fsaplpr02_PLG RSBTCRTE                     B 31 USER_BATCH     34
    11:00:08 bt1fsaplpr02_PLG /SDF/RSORAVSH                B 33 USER_BATCH     64
    11:00:08 bt1fsaplpr02_PLG RSBTCRTE                     B 33 USER_BATCH     43
    11:00:08 bt1fsaplpr02_PLG RSBTCRTE                     B 34 USER_BATCH     34
    11:00:08 bt1fsaplpr02_PLG RSBTCRTE                     B 35 USER_BATCH     37
    11:00:09 bt1fsaplpr02_PLG RVV50R10C                    B 34 USER_BATCH     60
    11:00:09 bt1fsaplpr02_PLG ZLM_HDS_IS_PURGE_RESERVATION B 35 USER_BATCH    206
    I'm thinking also now about the message server as there is load balancing for each RFC call ?
    Regards,
    Olivier

  • Timer callback executes in XP but not Windows7

    I have a GUI Timer created using the Timer control in the Main Panel of my GUI.  The callback sends commands to a device attached by USB and the device uses an FTDI chip to translate our serial commands to USB and back.  We're testing the code on both XP and Windows 7 machines that are each connected to their own devices.  Both computers have a driver for the FTDI chip that allows this.
    The release executable is installed on both computers (these are test machines on which we never run the development software or debuggers - strictly release software).  Both computers can connect to the devices and the main thread runs perfectly.  However, we're having problems with the Timer thread on Win7.  The Timer callback fires off perfectly under XP and sends its commands to the device which then trips and LED from green to blue and back so we can see that it's working. but nothing seems to be going through on the Win7 machine - no change in LED and no response to the commands the Timer callback sends.
    Has anyone else seen issues with threads not running in Win7 but working in XP?
    Thanks, for any help,
    Judy

    Hi Judy,
    What version of CVI are you using? Are you running your code on 32-bit or 64-bit machines? Are you having problems with all multithreading programs? Do you have a development computer with Windows 7 that also has problems running this code?
    Rohama K.

  • CDHDR table entry updation with different Time Stamp

    Hi Experts,
    I'm changing the Contract Partner First Name. The time stamp updation in Change Document Object DEBI is with UTC but the BUPA_BUP Object with Local Time Stamp.
    We want both time stamp with the UTC.
    Time Zone mentioned at SPRO level is UTC.
    Have anyone faced such situation earlier?
    Thanks and Regards,
    Jyoti Shankar

    Jyothi,
    I'm not sure whether this answers your query or not but suggest you to look at these 2 FMs'
    BUS_CUA_VARI_FUNCTION_CONVERT
    BUS_LOCATOR_OKCODE
    Ist FM uses table TBZ4 that uses GUI.
    Probably this is the reason you view object BUPA_BUP in the table with GUI time.
    Rgds
    Rajendra

  • Online response time in discoverer viewer?

    Dear sir,
    Can anyone help me,
    In discoverer view and plus,how to maximise the response time for the viewer,while n-number of visitors requesting the same report.
    How to analyse that? what settings are there?
    Plz help me , its urgent for my project?
    Regards
    chandrakumar

    In case this helps anyone else - this is the reply I got when I asked SAP this question:
    the total user response time is response time + frontend network time.
    GUI time is already included in the response time (it is the roll in andwait time from the application server's point of view).
    The 'FE (Frontend) net time' is the time consumed in the network for thefirst transfer of data from the frontend to the application server andthe last transfer of data from the application server to the frontend
    (during one dialog step).

  • SESSION_MANAGER  using more response time

    Dear Experts ,
    My SAP Production Server performance these days show very slow.I check in Early Watch Report that Top 5 Transistion.
    The "Top 5 transactions" diagram  show the average response time in dialog tasks for the top 5 transactions
    In this upper one is SESSION_MANAGER .
    Rest all is for Z development.
    Transaction     Type     Dialog Steps     Total Resp. Time in %     Avg. Resp. Time in ms     Avg. CPU Time in ms     Avg. DB Time in ms     Avg. GUI Time in ms
    Total          752009     100,0     1.213,7     177,1     758,1     229,5
    SESSION_MANAGER     DIA     34155     5,7     1.524,6     164,7     595,5     627,5
    Now How to analyses and solve  for  SESSION_MANAGER .
    thanks in advanced
    pooja

    in most companies, SESSION_MANAGER always show as one of the slowest transaction. This is usually not an issue.
    check other reports and analyze them but do not lose your time on SESSION_MANAGER.

  • High Response time

    Hi All ,
    In my SANDBOX , in time of transaction code execution it's OK. But after that in the time of any customization, table viewing it is using much more response time & even sometimes session is going terminated . How to fix & solve this problem. Can anybody help me ?
    Regards
    Asad

    Hi,
    I would look into following areas in st03n which would give you idea which transactions are taking more time and which area its struggling such as db time, cpu time, number of db reads, gui time and this would give an idea.
    Also check if your system has sufficient resources in terms of memory, cpu and paging files(swap size). Please check the paging out/paging rates as this would indicate problem areas.
    You can do a trace as mentioned earlier and check for the st22 dumps and system logs sm21 on what the errors messages indicate. This should really make it clear on what the core issues are and if you have any queries, pls post it here so that we can check it for you.
    Cheers Sam

  • Dialog response time comaprison between cities

    Is there any way where we can compare dialog response time  in different cities for the same transaction?
    As we are facing issues with response time in 2 different cities and response time in 1 city is lesser comared to other city while fetching the same data.
    System is an ABAP ECC 6.0 R/3 system.
    We checked that GUI time is also different in both cities.

    Hi,
    Check the network times from each city with the SAP utility niping.
    Check also if people from the different cities are connected to the same application servers.
    Regards,
    Olivier

  • Relation between RFC time and Roll wait time

    Hello
    What is the relation between RFC time and Roll wait time?
    In a diagram from E2E100 training I took recently the relationship is made out to be:
    RFC+CPIC = some processing time + Roll wait time
    Something like this
    Processing----
    Roll wait-------
    Roll in
    RFC+CPIC----
    In the diagram I saw it shows that roll out occurs during processing.
    Assumming that the user context rolls out and then rolls in again, wouldn't "Wait" time occur when the request comes back and the dispatcher has to assign the request to a work process?
    Is this wait time calculated as "Wait" time or is it calculated as "Roll wait" time?
    I was forced to think about this because of a STAD record I have with high Roll wait time, but with low RFC time as well as zero GUI time. If "Wait" time when the request comes back from RFC is included in "Roll wait" then it might explain what i'm seeing.
    Kind regards,
    Peter

    Hello Santosh,
    Thank you for your reply.
    I would like to know how time spend in the dispatcher by a request coming back from an RFC is calculated.
    When the RFC is made the user context is rolled out of the work process so the work process becomes free. When the RFC comes back it has to be assigned to a new work process. This means that a bit of time would need to be spent in the dispatcher. Would this time be measured as "wait" time or is it part of "Roll wait time?
    From the definition you gave of "Roll wait time", "it is the time dedicated by the R/3 system to waiting for the return value of an RFC call plus the CPIC time required to create the connection for that RFC to an outside system", one would think that the time spent in the dispatcher by a returning RFC would be measured as "wait time" the same as when the dialog request first comes in from the front end. I've never seen a diagram that explained this satisfactorily.
    Kind regards,
    Peter

Maybe you are looking for