[andyukguy]

Hi,

Say I come out of a shop where I have lost 3G signal on Three. When I come back out into the open where I know there is a strong 3G signal the iPhone will sit on No Service or "Searching..." for seemingly an age before finally reconnecting to the 3G network.

I suspect part of this is due to my habit of turning the phone off each night therefore losing the cached network information (who the phone is allowed to connect to) and therefore the first time in the day that signal is lost a full scan has to be performed and each network queried for access rights.

Do you think that if I take my phone off "Automatic" and select the 3 (3G) only network that I can avoid this "first run" searching that takes so long each day? I just want the phone to not search for any other networks and just try and connect directly to the Three 3G network within seconds of it being in an area where 3G is available (I will manually force it onto Orange if I find myself in a dead spot for an extended period of time).

I assume one further factor is the length of time I'm sitting on No Service. Clearly the iPhone won't be checking every 5 seconds or whatever for hours on end as that'd kill battery life. Is anyone familiar with the timings here? Are there any ways to adjust this (e.g. via a jailbreak tool)?

Thanks.

[Ben]

I just use airplane mode at night, much quicker :)

If I recall, the 3GS is just a bit slow at logging back on. I don't notice it on my iPhone 4, but when I was with O2 I really noticed the bad reconnect lag on iPhone 3G/S.

[Hands0n]

I would agree that Airplane mode is better than switching the handset off completely. In my case I never turn the phone off, ever, unless I need to restart it for some reason or other. Otherwise the handset is left powered on throughout its life with me. I charge up every single night in the study by plugging in to the Mac USB which has the additional benefit of creating a daily backup. For those who want the phone to be silent, I would recommend switching it to ringer off.

NB: My Android handset gets the same treatment ... never gets turned off ... ever.

[Ben]

O/T I've had to turn mine off a few times in the last few days due to Vodafone's antics - lately in Canterbury I'll get no data at all, but sometimes a few restarts brings it back. I'd think it was my phone but a friend's was suffering too. Airplane mode doesn't seem to cut it for this particular issue!

[DBMandrake]

Unfortunately I'm pretty sure this is a bug in the iPhone firmware which is triggered by Three's selective (location area based) rejection on Orange 2G.

(You've probably seen my thread about this on 3g.co.uk a while ago Andy...)

I get the same thing from time to time, and what seems to happen is that when the phone comes out of a no coverage area, if it happens to attempt to register on Orange 2G first, and it's an area where Three block access to Orange 2G, sometimes the phone will only partially register on 3G.

In this case the phone appears to be out of service (displays No Service at the top left and no signal bars) but in fact it's registered on the 3G network and can make and receive calls and send and receive texts despite saying No Service! (I have screen shots to prove it if anyone wants me to post them :D )

The phone can remain in this state indefinitely unless you go out of and back into coverage or cycle airplane mode/reboot. In this state data and mms will not work, only calls and sms work.

If the phone can make and receive calls whilst all the while displaying No Service then it must clearly be a bug in the firmware. :rolleyes:

The reason it's only happening on Three, and only in the last few months is because Three are the only UK network with a national roaming agreement, and also the only UK network with a roaming agreement where roaming service is rejected in some LA's ("location areas") but allowed in others - something that the iPhone firmware obviously wasn't tested against.

It's only since Three have started selectively blocking 2G roaming in some areas that the issue has come to light, even though technically speaking Three aren't doing anything wrong. With each firmware update I cross my fingers that Apple will fix this issue but as of 4.3.2 the problem was still present, and I see no reason why 4.3.3 will have addressed it as it's purely a location tracking update...

Andy - next time it happens to you, after you've been back in a coverage area for a couple of minutes, if it still says No Service try placing a call (for example to 444) and see if it goes through! You might be surprised. Until Apple addresses this (good luck with that one, since it's such an obscure network dependent problem) the best solution is to quickly toggle Airplane mode on and off if you think it's sitting excessively long in "No Service".

Another thing that might help is if you manually select 3 (3G) then leave it on that the phone wont attempt to register on 2G and so the bug shouldn't be triggered. Of course you'd lose 2G fall back coverage, and get "Network Lost" popups constantly when moving out of coverage, so it's not something I'd be willing to do myself...

[andyukguy]

Thanks for all the replies.

DBMandrake: That's interesting, I will test if I can make a call if it happens again. For now though I'm happier on the 3 (3G) network it seems to reconnect more quickly if I do wander out of service temporarily. Are you familiar with the timeouts here? e.g. how often the iPhone checks for service within the first X minutes of being out of service and then how often after that? Can this be adjusted in any way?

Regarding leaving the phone on all the time, I dunno, that never seems to work out too well for me. Maybe one of the apps I use has a memory leak because the phone does get sluggish after a day of use and only a restart seems to fix that!

[DBMandrake]

I don't know what the exact figures are but I believe the retry timer is an exponential back-off, if you've only been out of coverage for a few seconds it looks every few seconds. By the time you've been out of coverage for 10 minutes or more it seems to settle at about 2 minutes between searches, so if you've been out of coverage for a long time, "up to" about 2 minutes is normal for a phone to "find" service again if left to it's own devices.

I doubt you could modify the timers, even if it was jailbroken as I'm sure they're dictated by the GSM/UTMS standards, and are controlled by the baseband processor.

The way I test the lost signal behaviour is to place the phone propped up in a small bowl in a microwave, yes, a microwave, which is unplugged from the wall to avoid nasty accidents... :D The microwave makes an excellent Faraday cage whilst still allowing you to see through the door so as soon as you fully close the door any 1800/2100Mhz signal will be almost completely blocked and the phone will lose service, so you can easily observe the behaviour of suddenly lost or regained signal. (900Mhz will not be blocked much by the door due to the size of the holes in the metal shield, so this test doesn't work well on O2 or Vodafone...)

[andyukguy]

I just had the most fantastic mental image of you switching your phones about in the microwave! The things we do... :D

My pocket/leg seems to be a sufficient enough signal blocker for 2100Mhz as it turns out :)

Thanks for your detailed answers.

[Hands0n]

Regarding leaving the phone on all the time, I dunno, that never seems to work out too well for me. Maybe one of the apps I use has a memory leak because the phone does get sluggish after a day of use and only a restart seems to fix that!

Yup, that sounds like a classic case of resource drain, either connections or memory generally. And fairly typical with languages like Objective-C where you have to pay attention to little matters like releasing memory when you've finished with it. That is one of the very first lessons in the iPhone developers manual. Too often developers forget such little things, focussing more on functionality of the app which overshadows the non-functional requirements that should really be burned into their DNA ;)

[DBMandrake]

The sluggishness after not rebooting for a day or two (especially on the 3GS) seems to be related to the multitasking model IMHO, as it was never present in 3.1.3 and earlier - which ran flawlessly smoothly on my 3GS. (It also seems to have got progressively worse from 4.1 through to 4.3.3)

The way the multitasking works, as you "exit" apps, they're (by and large) left suspended in ram until such time as there are enough apps suspended in ram that the system runs low on free memory. (Remember iOS has no swap file)

At that time an algorithm is called to decide which idle suspended apps are ejected from memory to make room for newly launched apps, based on criteria such as how much ram they're occupying, how long since they were last used and so on. This sounds great on paper but the implementation leaves something to be desired. Without delving too deeply into it my gut feeling is that the threshold value of free ram before background apps are purged is set too low.

This means that once enough different, large apps have been run since last reboot the system is in a constant state of low memory, only ejecting background apps from memory at the last possible moment before memory exhaustion, rather than being a little bit more proactive and leaving a healthy buffer of free ram. (At the expense of more frequently flushing background apps from memory)

Thus every little memory allocation the foreground app tries to do (and nearly everything you do in iOS dynamically allocates memory - including scrolling list views and navigating from one UI page to another) stalls while the system scrapes up little scraps of ram here and there to satisfy the memory requests of the foreground app - terminating background apps is a "last resort" action, before that the OS will politely send running background apps (such as safari and mail) requests to free up as much memory as they can, (as well as other actions) but this takes time.

The end result is the sluggishness that andyukguy notes - something I notice a lot after I've run several large memory intensive apps such as World of Goo (love that game :) ) which immediately goes away if I manually terminate the most recent large app I used. It's pretty much the same sluggishness we always used to see on the iPhone 3G which with it's 128MB of ram always ran "to the wire" to the point that memory alert messages sent to apps were a constant and "normal" occurrence. (And could be seen when using the phone whilst monitoring the console log via USB cable)

Apple really needs to tweak the low memory thresholds to make the background app killer more aggressive and keep a larger free memory pool at all times - yes, background apps would get purged from memory more frequently, but it would maintain enough of a memory buffer that foreground apps would not be constantly stuttering due to waiting on slow memory allocations.

This mini-rant has actually got me wondering whether there are any Jailbreak tweaks to adjust the low memory thresholds... I haven't heard of any but then I haven't looked :)

Another thing that can cause sluggishness is background apps that "cheat". Apple's multitasking guidelines basically state that you can't continue to run in the background unless you have a damn good reason.

Those damn good reasons are codified in the API's and include background audio, background VoIP, background turn by turn notifications, and "task completion" which allows an app to continue to run for up to 10 (?) minutes to "finish" a file upload.

Unfortunately some apps cheat. I've noticed that my beloved Instacast is one of them - it's a podcast catcher/player, which does legitimately support background audio playback, however I've caught it red-handed "playing" silence to remain running in the background when it shouldn't. (It's probably using this to do "unlimited" downloading of queued podcasts in the background beyond the 10 minute "task completion" limit)

iOS thinks it's playing audio, so it continues to allow it to run in the background (no play symbol in the top right either) but I know it's still running because the volume buttons try to adjust the playback volume instead of the ringer volume, which only happens when an app is actively outputting audio. In this case silent audio...

A lot of apps abuse the task completion API too - it's supposed to be specifically for things like finishing saving an image to the camera roll, finishing uploading an image to a server etc, things you definitely don't want interrupted by pressing the home button, but unfortunately the way the API is written it pretty much gives any app carte blanche to continue running in the background for up to 10 minutes - doing whatever it feels like.

I'm sure all of these things contribute towards overall system sluggishness.