My experience of the race-to-idle on n810 is that some applications will essentially lock the cpu at 100%, with the device become unresponsive until it has completed what it needed to do, and we get back to idle.

Application Manager is a good example of this.

What would this mean in terms of a voice call? I am assuming that freemantle doesn't have quite the same gung-ho approach with rti, and will leave a few cycles ready so I can hit "answer" on the incoming call.

Have you beagle players seen anything to suggest the scheduler in freemantle will guarantee cycles for core processes?

I am assuming it is there, but this becomes more imperetive when we are talking about a phone.

it's probably I/O and not CPU that's blocking other apps from responding when app manager is doing things..

Yeah, undoubtedly I/O Wait, but still - a block is a block, so what are the protections in place to prevent this happening when we have something as time critical as a phone call in play?

I suspect pm_qos is part of the answer. On the scheduler front, the SDK kernel is configured like this:

so maybe (just guessing) telephony will run as a different uid to get its fair share of CPU cycles?

The other side of this is memory management. If the telephony app isn't already in RAM (eg it hasn't been started or it gets swapped out by another memory-hungry process) when a call comes in it could take a while before it can start playing the ringtone and display an answer button, and you might even miss the call. This is what happens currently with SIP or Jingle calls on the N8?0s.

Conversely, if you don't want to use the device as a phone that's a waste of perfectly good RAM. This could be a significant factor in choosing a "phone" vs "tablet" Fremantle device for some people.

My Windows Mobile devices used to take it one step further and sometimes crash when you tried to answer a call. Assuming that you hadn't flattened the battery playing pocket-doom or reading e-books. That was about the time that I started carrying a basic phone, just for calls and SMS.

I like the idea of converged devices, but I like the idea of a simple, small, reliable phone too. That's the major benefit of the original phone system - it takes an awful lot to take it out of commission.

I'm not so afraid of that. Have been carrying Nokia Communicators in the last - say ten? years, and these gizmos failed to answer to a call for apparent cpu overactivity say ten times - once a year or so.
But I don't know if they have had one cpu for all activity or a dedicated cpu for telephony.

My initial reaction to the "N900" specs was sceptical, the form factor didn't seem to meet the needs of tablet users or phone users.

But interestingly enough, I had been considering the idea of getting an android based phone to finally converge my phone tablet, and so really, the n900 spec actually steps in the right direction. I'd prefer the screen to be larger of course, but if is is similar to the iphone screen in physical size, it will be tolerable.

Because what I want more than anything is an open platform, maemo has inspired all kinds of creativity that symbian et al because of its open nature. Far better than having to write goddamn java on android. Or objective C on iphone once jailbroken.

The problem with the Communicator comparison is that symbian is a phone OS first, and a general purpose OS second. With maemo it is the other way around, and so the fact that it works well on one tells us little about telephone performance on the other.

I am staying out of the 1000 post specs leak thread as it seems to have become a life form of its own. Self-sustaining.

But damn if the form factor is right, then this is going to be yet another clunky phone from Nokia, and while I am sick of carrying two devices around, one BIG one doesn't make up for it too well. But I will be more than happy to not have to manually initiate a tethered bluetooth session via my phone to get internet access.

But all this requires that the telephoney works flawlessly.