CPU faster, but OS2008 slower?

[RedMist]

Firstly, I understand that upgrading the firmware in the N800 increases the speed of the CPU. I don't understand why Nokia did not set the speed to 400mhz in the first place, rather than limit it to 320mhz. Also, it begs the questions.. is it is possible to run OS2007 @ 400mhz, or even OS2008 at (say) 480mhz. (I'm assuming clock frequency is software selectable for sake of argument, I don't know if it's a FSB multiplier, or anything else - I'm not a hardware guy!)

But the real reason for this post is to say that the zoom function on my N800@OS2008 now appears to be slower than it was on OS2007. So I'm not even sure that it really is running at 400Mhz anyway. Everything else is just as quick, and so speed differences are not noticable.

Flash movies (Youtube) seem to run much faster, but that maybe the flash 9 update. But ordrinary movies seem to run about the same speed.

Maybe I am expecting too much from a 25% speed increase? :)

Any thoughts?

( BTW, I'm Rob, how do you do? )

[Rocketman]

If you are having speed/ui fluidity issues, I highly recommend turning off the rss reader, or at least its scrolling features.

As far as the additional clock cycles not making an apparent difference in video playback, I have heard multiple times from the Mplayer developers that the video subsystem on the N800 has some serious limitations such that video playback is constained by that fact, rather than the CPU being the limiting factor. In fact, the 770, the N800's predecessor had a better video subsystem. The N810 is almost identical to the N800 in terms of hardware internals, so there is no reason to expect that there will be much improvement in that area. I am sure the MPlayer folks are hard at work squeezing every bit of performance out of those additional clock cycles that they can, but I don't expect to be play high resolution XVID movies on my N8xx anytime soon.

I am interested in the idea of a overclocking system tray applet which would allow one to situationally increase/decrease the max clock rate. I can imagine this would be of much use when one has an external source of power and using an app which is CPU limited (Quake 2 anyone?) and correspondingly one could decrease the clock rate for better battery life when using the N8xx as a book reader or other undemanding task.

[GeneralAntilles]

I am interested in the idea of a overclocking system tray applet which would allow one to situationally increase/decrease the max clock rate. I can imagine this would be of much use when one has an external source of power and using an app which is CPU limited (Quake 2 anyone?) and correspondingly one could decrease the clock rate for better battery life when using the N8xx as a book reader or other undemanding task.

The idea behind CPU throttling here is that it's entirely transparent to the user. If the system needs more power, its given more power, if it doesn't, the CPU is throttled back (as with ebook reading). Adding a control for this behavior isn't really a good UI decision. I can understand wanting to have it prefer battery life, but things are much cleaner if we don't burden the user with this sort of decision making. Check out the PDF on maemo.org regarding power saving in OS2008 for more detail on the subject.

[thoughtfix]

Turn off the RSS reader and other unused toys, plus wait and see how the N800 official image actually performs. I am fortunate enough to have both devices here so will do side-by-side tests.

[dblank]

If the system needs more power, its given more power

Unless it needs more than 400MHz! :)

I wonder if they'll add support for higher clocks in the future. It sounds like the CPU supports up to 1GHz, I'd love to see that, even if I did have to plug in the AC.

[RedMist]

Turn off the RSS reader and other unused toys, plus wait and see how the N800 official image actually performs. I am fortunate enough to have both devices here so will do side-by-side tests.

Yes, that would be interesting to see. Although I guess you need three devices to do a proper comparison ;)

[igor]

Unless it needs more than 400MHz! :)

Then you are out of luck.

I wonder if they'll add support for higher clocks in the future. It sounds like the CPU supports up to 1GHz, I'd love to see that, even if I did have to plug in the AC.

Where did you get this information from? We are already using speed-binned processors to get 400MHz and I'm not aware of TI providing any higher option.

[ragnar]

Firstly, I understand that upgrading the firmware in the N800 increases the speed of the CPU. I don't understand why Nokia did not set the speed to 400mhz in the first place, rather than limit it to 320mhz. Also, it begs the questions.. is it is possible to run OS2007 @ 400mhz, or even OS2008 at (say) 480mhz. (I'm assuming clock frequency is software selectable for sake of argument, I don't know if it's a FSB multiplier, or anything else - I'm not a hardware guy!)
Any thoughts?

Since this seems to be public information already, in slide 15:

https://s3.amazonaws.com/ppt-download/power-management-for-the-nokia-internet-tablets565.pdf

The CPU and DSP speeds are (effectively) tied together. A faster CPU speed drops the available DSP speed. So you would see in some DSP heavy applications the CPU speed going back to 330mhz.

Anyway, in general I do think you can feel the speed improvement. A difference in certain feature speeds, for instance zooming in the browser, can be attributed also to the new open browser engine compared to the previous Opera one.

Anyway, OMAP2420 has definite maximums on its speed. :)

[Serge]

As far as the additional clock cycles not making an apparent difference in video playback, I have heard multiple times from the Mplayer developers that the video subsystem on the N800 has some serious limitations such that video playback is constained by that fact, rather than the CPU being the limiting factor.
Well, I doubt you have heard exactly this information directly from me, more likely that was just someone's exaggeration or (mis)interpretation :)

Below is my old explanation to somebody who asked a similar question (whether video bandwidth is a major problem) taken from maemo-developers mailing list:
http://www.gossamer-threads.com/lists/engine?do=post_view_printable;post=19711;list=maem o
"There is one important thing to note. Screen updates are asynchronous and
are performed simultaneously with CPU doing some other useful things at
the same time. Screen updates do not introduce any overhead or affect
performance (at least I did not notice any such effect). So insanely boosting
graphics bus performance will not provide any improvements at all once it is
capable to sustain acceptable framerate. And what is acceptable depends
on applications. Video may require higher framerate, but it is both high
resolution and high framerate movies that may exceed graphics bus
capabilities, in this case video will be still played (if cpu is fast enough
to decode it, that's another story) but with some frames skipped and
many people will not even notice any problems. Quite a lot of people
are even satistied with 15fps transcoded video, so getting maybe 20-25fps
(random guess) on some videos instead of 30fps is not so bad. "

To sum everything up. N800 (and probably N810) has slower graphics bus than Nokia 770, but that is just one extra limiting factor (which did not exist on Nokia 770) to take into account in addition to many others. Initial release of OS2007 firmware had inefficient code in the kernel framebuffer driver which resulted in hitting this limitation for any video, no matter what resolution it had:
"On N800 (OS2007 2.2006.51-6), every YUV screen update (OMAPFB_COLOR_YUY422)
takes about 41ms without tearsync enabled and 41-58ms with tearsync. It does
not matter what video resolution we try to watch, the result is the same."

That's why the problem with the graphics bus speed was immediately spotted and video playback was not very enjoyable running initial revision of OS2007 firmware .

Later firmware releases got framebuffer driver fixed and now we will hit graphics bus throughput limitation only on very high resolution videos (close to 800x480) and with tearsync enabled. CPU performance becomes much more severe bottleneck even at lower resolutions.

[Moonshine]

..... Later firmware releases got framebuffer driver fixed and now we will hit graphics bus throughput limitation only on very high resolution videos (close to 800x480) and with tearsync enabled. CPU performance becomes much more severe bottleneck even at lower resolutions.

Any chance you could explain the last sentence a bit more? I'm not sure I understand.

Are you saying that now that the framebuffer driver is fixed, the CPU become the limiting factor most of the time? Even on low resolution video (ie. 320x240)

[Serge]

Any chance you could explain the last sentence a bit more? I'm not sure I understand.
It's just 'lower != low'.

CPU performance becomes a limiting factor even for resolutions lower than 800x480, for example 640x480 or 704x400. And these video resolutions stress graphics bus less than 800x480. So while graphics bus does not have any 'margin of safety', we are at the point where video output performance is (barely) enough to sustain needed framerate.

Are you saying that now that the framebuffer driver is fixed, the CPU become the limiting factor most of the time? Even on low resolution video (ie. 320x240)
I'm saying that video output is not introducing any troubles for low video resolutions at all. While CPU power may be or may be not sufficient depending on the codec, the settings used for encoding and bitrate.

[jmk]

Serge, what is the status of Mplayer port for OS2008? I bet it is one of the most wanted apps.

[Serge]

Serge, what is the status of Mplayer port for OS2008? I bet it is one of the most wanted apps.
I hope to release a package for OS2008 in a few hours. Have been tweaking code since morning today. MPlayer is basically working, but there are still numerous small issues. I'll post a separate thread with announcement once the package is ready to test.

[dblank]

Where did you get this information from? We are already using speed-binned processors to get 400MHz and I'm not aware of TI providing any higher option.

http://focus.ti.com/pdfs/wtbu/TI_omap2420.pdf

Isn't that what the N800 uses? I also seem to remember posts about it in the forums.

[igor]

http://focus.ti.com/pdfs/wtbu/TI_omap2420.pdf

Isn't that what the N800 uses? I also seem to remember posts about it in the forums.

And if you read the pdf from the link you sent, you can see that the highest standard frequency is 330MHz.

As I said we are using a speed sorted type of 2420, which is validated for using the ARM core @400MHz, but that's it. Higher core frequencies would also end up forcing higher dividers on the L3 bus and that would lower the memory clock.

Of course you can play with the dividers and I'll probably setup a page about it when I have some spare time and the code is officially out, but there are quite good chances to wipe the flash and without the means to coldflash the device, you end up with a nice brick.

The most interesting change would probably be to run the system at the (unsupported) configuration ARM@400, DSP@266, which would make it possible to avoid the current weird op selection mechanism.

[dblank]

And if you read the pdf from the link you sent, you can see that the highest standard frequency is 330MHz.


The pdf doesn't seem to say much, but I don't see where it says the highest standard freq is 330MHz, I just saw this:
"ARM11 architecture from 330 MHz to 1 GHz"

but this brief document doesn't mention anything more about 1GHz, or what kind of drawbacks there are running at this speed.

[Serge]

The CPU and DSP speeds are (effectively) tied together. A faster CPU speed drops the available DSP speed. So you would see in some DSP heavy applications the CPU speed going back to 330mhz.
Does CPU speed go back to 330MHz only for dsp tasks which really require DSP core running at more than 133MHz? For example dsppcm task will be running for any application producing sound output but it is hardly computationally intensive on DSP side. Are there many dsp tasks which require more than 133MHz?

[ragnar]

Does CPU speed go back to 330MHz only for dsp tasks which really require DSP core running at more than 133MHz? For example dsppcm task will be running for any application producing sound output but it is hardly computationally intensive on DSP side. Are there many dsp tasks which require more than 133MHz?

Igor can probably answer this one best, but afaik it's done so that 400/133mhz is the default in which OS2008 runs and then certain applications can call for the higher DSP value, for instance some RTCOMM apps seem to do this. So yes, I think it's not for all DSP usage.

[lardman]

The most interesting change would probably be to run the system at the (unsupported) configuration ARM@400, DSP@266, which would make it possible to avoid the current weird op selection mechanism.

This sounds interesting, I look forward to seeing your page on the dividers.

Are there many dsp tasks which require more than 133MHz?

We could always work it out by testing I suppose. If Nokia could tell us the dsp cpu load profile that would be even better :)