Bug 10778 - Incoming call notification is too slow (causes missed call)
: Incoming call notification is too slow (causes missed call)
Status: RESOLVED DUPLICATE of bug 10613
Product: Chat & Call & SMS
Call Application UI
: 5.0:(20.2010.36-2)
: N900 Maemo
: Unspecified normal with 13 votes (vote)
: ---
Assigned To: rtcomm@maemo.org
: call-ui-bugs
:
:
:
:
  Show dependency tree
 
Reported: 2010-06-25 00:36 UTC by Srikanth Agaram
Modified: 2012-07-24 17:48 UTC (History)
9 users (show)

See Also:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description Srikanth Agaram (reporter) 2010-06-25 00:36:16 UTC
SOFTWARE VERSION:
(Settings > General > About product)

EXACT STEPS LEADING TO PROBLEM: 
(Explain in detail what you do (e.g. tap on OK) and what you see (e.g. message
Connection Failed appears))
1. Put N900 under load (running some browsers or media seems to be good enough)
2. Call the N900 from another phone
3. Try to take the call

EXPECTED OUTCOME:
The incoming call is immediately shown and the "accept" button is responsive.

ACTUAL OUTCOME:
The phone rings and the screen goes black, but the incoming call doesn't show
or the buttons are not responsive.

REPRODUCIBILITY:
(always, less than 1/10, 5/10, 9/10)
Under load, always.

EXTRA SOFTWARE INSTALLED:

OTHER COMMENTS:
The phone application should have higher priority than other applications. Even
if there are a lot of applications running, calls should not be missed due to
lag.

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-US)
AppleWebKit/534.0 (KHTML, like Gecko) Chrome/6.0.408.1 Safari/534.0
Comment 1 julien.me 2010-06-25 03:07:18 UTC
*** This bug has been confirmed by popular vote. ***
Comment 2 Martin Grimme 2010-06-25 10:34:14 UTC
Even if the call window with the accept button manages to appear in time, under
load clicking the accept button shows no reaction and touching the screen
produces no feedback (click sound or vibration depending on your settings).
Comment 3 paulaner 2010-06-25 11:24:31 UTC
Seems like current heavy load isn't need to miss the call.
My scenario as follows:
1. Switch on Auto Logon in IM (I have skype/jabber enabled for now)
2. Go to place with WiFi (home in my case)
3. Leave N900 a while (it connects to wifi and goes online with IM)
4. Receive incoming call after 10-50 minutes
5. See the Phone application trying to pop up.
6. Miss the call or accidently hang it, because interface is in transitional
phase (you know -- switching from landscape to portrait, re-layouting widgets)
Comment 4 Andre Klapper maemo.org 2010-06-25 13:11:51 UTC
(In reply to comment #0)
> The phone rings and the screen goes black, but the incoming call doesn't show
> or the buttons are not responsive.

This is contradictive to me - if the screen is blank you cannot see any buttons
anyway? The blank screen sounds like bug 10250 which is bug 7772.

(In reply to comment #2)
> touching the screen produces no feedback (click sound or vibration depending

I'd surprised if this ever worked - see bug 8455.

(In reply to comment #3)
> 6. Miss the call or accidently hang it, because interface is in transitional
> phase (you know -- switching from landscape to portrait, re-layouting widgets)

Reminds me of bug 10613 which should be fixed by a future update.
That's a different issue than described in this report.
Comment 5 Sathish 2010-06-25 17:28:33 UTC
(In reply to comment #4)
> (In reply to comment #0)
> > The phone rings and the screen goes black, but the incoming call doesn't show
> > or the buttons are not responsive.
> This is contradictive to me - if the screen is blank you cannot see any buttons
> anyway? The blank screen sounds like bug 10250 which is bug 7772.
> (In reply to comment #2)
> > touching the screen produces no feedback (click sound or vibration depending
> I'd surprised if this ever worked - see bug 8455.
> (In reply to comment #3)
> > 6. Miss the call or accidently hang it, because interface is in transitional
> > phase (you know -- switching from landscape to portrait, re-layouting widgets)
> Reminds me of bug 10613 which should be fixed by a future update.
> That's a different issue than described in this report.

Thanks Andre for your time.

This bug report resulted from the dicussion
http://talk.maemo.org/showthread.php?t=57029

This is what happened. I was playing Angry Birds and no other Applications were
running. A call came in, screen went blank for some time. By the time the phone
application appeared and I could touch it, the call was missed.

Please let me know if you need more info. I will be glad to test any fix.

Thanks everyone following up this bug...
Comment 6 Srikanth Agaram (reporter) 2010-06-25 17:48:54 UTC
(In reply to comment #4)
> (In reply to comment #0)
> > The phone rings and the screen goes black, but the incoming call doesn't show
> > or the buttons are not responsive.
> 
> This is contradictive to me - if the screen is blank you cannot see any buttons
> anyway? The blank screen sounds like bug 10250 which is bug 7772.

I think the screen goes black just before the buttons show up. So depending on
the load, the call may be missed before the buttons ever show, or after they
are drawn on the screen (but before they are responsive). HTH
Comment 7 Robert Chambers 2010-08-09 22:58:41 UTC
Coming out of dark screen standby mode the device rang twice and the call was
missed. Caller is frrequent caller and lets it ring five to seven times before
hanging up. 

Device was sluggish in response with the screen transition halting midway for
over a second while changing from landscape phone call screen to the portrait
phone call screen. Also some lag between touching the "Answer" button and the
phone responding.

Six applications were running in the back ground Battery Graph, cpufrequi,
Conky, Inbox-e-mail, Web bookmark screen, a web site with static content.
Comment 8 Andre Klapper maemo.org 2010-09-08 15:55:42 UTC
Still sounds like bug 7772 to me...

*** This bug has been marked as a duplicate of bug 7772 ***
Comment 9 Srikanth Agaram (reporter) 2010-09-08 19:16:34 UTC
This has nothing to do with sunlight. Every time I've had this problem was
indoors. I do not think this is a duplicate of Bug 7772.

This is a problem of software scheduler prioritization in my opinion. The
problem is that the running apps are hogging resources and the phone app is not
able to get the cpu cycles/memory to be able to render itself in time. Perhaps
the phone app is even being moved to swap. Running all user apps in a lower
priority level might solve this problem. I do not think that it is a hardware
limitation.

Please reconsider your evaluation of this situation.
Comment 10 Kai Hult 2010-09-09 08:22:46 UTC
There is tunings done for Call Ui timing in next SW release which could help in
this case
Comment 11 Andre Klapper maemo.org 2010-09-09 13:57:15 UTC
*** Bug 11263 has been marked as a duplicate of this bug. ***
Comment 12 Andre Klapper maemo.org 2010-10-25 18:06:59 UTC
Today Nokia released the Maemo5 update version 20.2010.36-2 for public (also
called "PR1.3" sometimes).

(In reply to comment #10)
> There is tunings done for Call Ui timing in next SW release which could help in
> this case

If you have some time we kindly ask you to test again if the problem reported
here still happens in this new version - just leave a comment (and feel free to
update the "Version" field to the new version if it's still a problem).
Comment 13 paulaner 2010-10-25 19:16:12 UTC
Still in PR1.3
I open browser and call my phone from other.
Phone app pops up with buttons Answer/Cancel and with NO info about incoming
call.
Then UI was relayouted (moved upper) and in few seconds UI was relayouted back.
During this transition, phone rings, UI was unresonsible.
ps: can't update Version field.
Comment 14 Andre Klapper maemo.org 2010-10-26 01:14:48 UTC
This still sounds like a duplicate of bug 10250 to me.
Comment 15 Andre Klapper maemo.org 2010-10-27 17:56:48 UTC
Covered by bug 10613 it seems.

*** This bug has been marked as a duplicate of bug 10613 ***
Comment 16 Knut 2012-02-13 21:59:36 UTC
ReOPEN and set Critical.

Fixes has reintroduced the bug, which I relate to TRANSITIONS now.
The phone is set in PORTRAIT mode - where the top is where the ear goes, and
bottom is where the microphone is located. With the Qt Screenlock active, I can
see the call come in by hering the ring and watching the vibration. 

GSM has a timeout of 10 seconds to respond, and now I see the Screenlock
application going from landscape, to Portrait and back to landscape, and since
I touch the phone, it tries to activate the Phone app. However, with other
windows open, the window manager mucks around from landscape - the keyboard is
open, to portrait until I miss the call.

However, with a Bluetooth headset, I can press to respond. I can then see the
havoc go on, but this is the only way the havoc can be resolved within the 10
seconds after presing "Accept" to the N900 actually can connect the call.

Drop all "Transitions" and fancy UI, if NOKIA has to take the phone out of the
Hildon Desktop, just do it and if there is a problem from "ACK" to "CONNECT" -
drop rotation. Drop showing picture. ENABLE the camera button to accept a call
- press twice to reject.

The N900 is a mobile phone, and first priority is to be able to place and
receive voice calls.
If this cannot be done, its a device failure.

Priority is CRITICAL.

Reproductivity is 10 of 10.

The Bug is not solved, but some other similar bug may have been solved. It may
be related to screen orientation that is in a mess at the moment, where every
window is allowed to decide. There must be a cut-off for critical things, such
as responding to an incoming call. DISABLE transitions. I see that one solution
is to place the Phone application in permanent LANDSCAPE. Until they have moved
the microphone and earpiece, let us have the name and status in the direction
that match this.

And a mobile phone should be capable of receiving GSM calls.
Comment 17 Andre Klapper maemo.org 2012-02-13 22:16:22 UTC
(In reply to comment #16)
> The Bug is not solved

Of course not, as you can see in the status of the report that it is a
duplicate of. Feel free to contact Nokia Customer Care.
Comment 18 Leandro Lucarella 2012-07-23 12:30:11 UTC
Why is this a duplicate of bug 10613? This bug seems to be related to the phone
app being swapped out, a different issue. I'm also getting this when the phone
has several applications opened.

I think the best would be to use mlockall() with both MCL_FUTURE and
MCL_CURRENT in the phone app so it's never swapped out. Remember the device is
a *phone*, you should never, ever, miss a call because you had a browser
opened.

http://linux.die.net/man/2/mlockall
Comment 19 Knut 2012-07-24 17:48:48 UTC
Well, this is no duplicate and seems to originate from ignorance of how the
handset is made and coded by Nokia - and how some individuals muck around with
it.

Whoops, be careful!
The "mlockall()" is supposed to be used to lock e.. real-time data in memory to
be shared by others. It will not work as long as the Window manager "forks()" a
new process to drive the UI (in portrait or landscape) when a call is received,
causing the memory management system to go crazy swapping out and in. The call
to block memory is intended for the core GSM code, to expose to the "Phone
Application" to link to this. According to the GSM standard, a "CONNECT_REQ()"
event must be responded in 10 sec. or the operator can consider the handset
"Out of reach". They again can customize in their IN the time to respond,
typically double this time according to location and model (IMEI code). 

A simple solution to the problem is to use a Bluetooth headset, and receive the
call here. This is activated by the proprietary Nokia code and does not involve
the Phone application to be started in Landscape. 

Solution: a patch in the Window Manager, maybe using the "Transitions" to
change timeslice class of the Phone application to RT.

See: http://linux.die.net/man/2/ioprio_set

The timeslice class to the Phone applications (IOPRIO_WHO_PROCESS = "Phone")
can be set to RT(IOPRIO_CLASS_RT). The memory management should then try to
keep the "Phone" special.  When the application terminates, a new instance of
"Phone" is created, something the Window Manager keeps track of, and just as
"Transitions" are set to the various applications at their initiation /
start-up, it should be possible to identify the Phone as a "special"
application.

There are more bugs here, e.g. the WLAN driver that Skype use through the Phone
application does not get the resources it needs and cause the talk to be broken
- "chitter is high". It is just the same with data interface - which should not
be a priority service on GSM - this is the GSM definition. But then the phone
application has to notify the OS that it requires WLAN or the "non-priority
data service". That may result in that emails are not received while you talk,
which is just the purpose.

Bear in mind that during 1 second, you can do 600 million instructions, which
is a lot. What is needed is to tell the short-term scheduler what is important.
Just to make many timeslice classes will improve performance exponentially,
since the dispatcher will search the processes for candidates for swapping out
to make room for what needs to be loaded. In the worse case the OS will just
spin around in these queues searching for candidates, and once our, their
"nice" delta will be raised, which makes it more likely that the process is
swapped in again - just to be swapped out. That overclocking seems to be one
remedy often sought to, indicates to me that the execution queue is too long,
with too many processes have the same priority. The problem is that this search
in the execution queue is something that always can be done, so the OS will
spend most of the time in "IOWAIT" for things being swapped out and in.

Not even Oracle will allocate all of memory, only "SGA" - the shared global
area. Then the applications will use the dispatcher to be placed in the correct
time-slice class.

Use the mechanisms provided in Linux carefully. The best way to help the
dispatcher is to make it easy to identify victims quickly. To lock an
application in memory that needs resources once every 30 minutes does not make
sense. To tell the dispatcher that "when this is executing it needs resources
fast" - but depends on the RT Phone process in the background, and also the
X/window resources needs this, allowing us to press "ANSWER" - or "HANGUP".
Beware that there is a RT phone driver that runs and holds the memory that is
needed. The "Phone Application" is the X/Window session that is triggered wen
you want to place a call - or someone calls you.