
Windows only????
Pathetic. I would have thought that Nokia would at least have a Mac version. I know many Mac users that have Nokia handsets. This may put them off getting another one.
Nokia has posted a software update for its N95 handset which, it claimed, makes the "multimedia computer" load applications more quickly and play music for three more hours on a single battery charge. The update, version 20.0.015, focuses on "battery, stability and performance improvements". Among them is the addition of "on- …
I have an N95 (product code 0546659) and the updater tells me my version, 20.0.13, is the latest.
Presumably I have my friendly network provider to thank for this delay, while they stamp their logo all over my shortcuts, steal one of my app buttons to run some bloated "value added" menu and "repair" my homepage bookmark?
When, oh when will I be able to load the full front page of cuteoverload.com without an out-of-memory error?
the updater tells me my version, *12*.0.013, is the latest
.. and upon further reading I find "0546659" is the product code for my operator, who shall not be named.. but if it's anything like the delays I experienced with my P910 (no updates in 2 years), I'm won't be holding my breath :-)
I have this phone, and the battery life is appalling, I am soon to be selling this phone to get back to the old skool and a nokia with a battery life of 4 days on standby rather than less than a day with the N95! This badly needs sorting out before they bother making phones any more powerful!
Whilst the new firmware is definitely worth having, N95 users need to be aware of an "update" to nokia maps. In the former version you could plan a route then "start tracking" this would track your position in relation to the route shown on the map. This has been purposefully removed in the new version.
Conspiracy theorists (including me) will see this as a blatant attempt to force more users to buy into the - frankly stupid - pay as you navigate options that are available from Nokia in granular payment models but - unless you count normal position tracking - the N95 no longer has real time updates to show where you are on the route.
Yup, it sucks big time and renders most of the N95 GPS functionality pointless without paying more to Nokia - something I wouldnt do on principle. Your options are basically to wait for Tomtom to get their act together and wait for a release that works with the N95 internal GPS, try nav4free (if you have a good data model - so not o2 customers then - and,er, thats it really since route66 which looked very promising isnt legally available for uk only for some reason (yes, I know theres a dodgy version on the net but thats not for discussion here and its not going to be on my phone).
Anyhoo, the other updates - especially the camera fixes and updates - are very much worth updating for since they speed up the phone no end and make it a much better experience. Just dont rely on using Nokia maps for navigation any more unless you dig into your pockets of course.
Over and out
Edz
Thanks to the person who posted the link to the *real* description of what's going on here. It's not "demand paging" in the usually used sense of "virtual memory", where there is a pagefile for things to be paged *out* to, it's merely an incremental improvement such that a whole executable doesn't have to be loaded at once, on an "all or nothing" basis, as it previously was.
After the update, pages of code can come in as they are needed, and be discarded if memory is short and they are not actively in use. Then they get paged in again if they are needed again (assuming something else can be paged out to make room :)). Which is nice, but it's not yer traditional demand paged virtual memory. Yet.
Much as I'd love to load the update, I can live without it in favour of keeping the tracking feature.
I'm not completely clear, but it looks like with the updated version of Maps you don't get the 'Start tracking' option even if you pay for the navigation option - can anyone confirm if this is true or not?
I'd not be particularly happy about having to finally stump up for the full navigation option, but I guess I'd do it if it meant I could use the update AND still have tracking enabled for those times when following a route on foot AND get the voice routing.
If not, Nokia can take their update and shove it. Adding and modifying features is fine, but deleting them is NOT on.
The GPS is a joke as it is, even with the update before this current one, it still takes ages to get a fix.
Nokia could of had a killer phone if they included the voices with the sat nav. But as it is you have to pay for it and your stuck having to look at the fucking screen all the time. Many a turn off have been missed do to watching the road and not having any audio.
Shame nokia are fixed on going backwards instead of forwards.
They could of had the phone sat-nav market conquered.
If the Nokia software updater says you can still only get an old version, then why not change your N95's product code??:
http://www.allaboutsymbian.com/forum/showthread.php?t=67130
p.s. I'm an N95 & Mac user and don't really give a shit that the Nokia updater is Windoze only - I just leave XP quietly running in VMware Fusion for the odd thing that might need it - or the odd quality app that runs on Windoze (I think there might be 2 of em...). Best of both worlds!
As for the Jesus phone, it doesn't even dangle...
I've published quite a lot of posts on virtual memory. Let me copy my post from http://www.howardforums.com/showthread.php?t=1277861 :
Unfortunately, the OS itself doesn't support paging and swapping. The reason for this is simple: the creators of Symbian did have to reduce the size of the core. The virtual memory controller does eat up a lot of memory and CPU; this is why it's, generally, not utilized in low-RAM devices like Windows Mobile and Symbian ones.
IIRC, the Linux-based but memory-constrained (64M? 128M?) Sharp Zaurus-line doesn't support virtual memory / swapping for exactly the same reason.
This is the main reason for virtual memory not being implemented, not because of the finite writing cycles of flash ROM. The latter isn't an issue because modern flash controllers make sure they "map out" the cells that have gone wrong. That is, they don't fail; all you perceive is a capacity loss over the years.
Apps can of course, implement swapping on their own. A Windows Mobile example: some picture viewers / editors; most importantly, Conduits Pocket Artist; some other pic viewer apps also do file system caching to free up memory, but this caching is VERY slow and, generally, pretty unreliable.
all in all: there isn't and will NOT be real virtual memory. It's a low-memory, low-CPU operating system, after all.
Firstly, SymbianOS has supported "virtual memory" in the sense of "a paged environment in which the operating system uses a memory management unit to form noncontiguous regions of addressible memory from one or more contiguous pieces of physical memory" since the very beginning. The new EKA2 kernel architecture present since SymbianOS 8.1b has extended this, with support for pluggable memory models and new, more sophisticated process isolation (to allow better security for wireless signalling stacks).
Secondly, "demand paging" means that application binaries are only loaded from backing store (in this case, Flash memory) into RAM when they need to be, reducing application load times, helping the RAM controller keep physical pages closed (in retention mode or even switched off!), and making things much more efficient at the expense of some compromises in realtime performance and fairly wide-ranging complication to the message-passing architecture of the kernel. Most SymbianOS devices load entire binaries into RAM at a time, which makes more sense when you understand that SymbianOS is an intrinsically object-based environment and code objects were not expected to get large, ie., each app was expected to comprise many small binaries. Large facilities such as the UI layer would run directly from NOR (parallel) Flash memory, and not have to be loaded. Things didn't quite work out that way. NAND Flash is far denser and generally faster than NOR, but it has semantics much more like a disc than like a memory array, and so binaries have to be loaded from it and held in RAM- including the OS.
Thirdly, the new features in N95's memory architecture are certainly supported by the kernel- indeed, they are substantially implemented in the OS nanokernel. SymbianOS may be intended for resource-constrained platforms, but it is far from feature-poor.
Finally, the real reason that there isn't page swapping is that writing to Flash is slow, power-hungry, and wears it out. You don't want to write to Flash too often. Swapping to microdrives has been discussed a few times, and they don't wear out so fast, but until someone comes up with a way to make phone batteries last a lot longer, it's still not really an option.
Hope this clears up some misconceptions.
Constant re-writing of the page file may(depending on use cases) wear the NAND prematurely aging the phone and cause relocation of the page file all over the chip which will may eventually cause the device to behave like a jellyfish swimming through treacle.
So for mobile, one way paging of code may prove a lot more sensible than your "virtual memory".
I'm not sure how big the problem of wearing from a user perspective.
It can be demonstrated by mounting a swap file on a MMC card on a Nokia770 or N800 (Linux based).
Some users report excessive wearing after a few months, but other are fine 6 months + on. There are many variable though, for instance if your file system updates the modified date of each file each time it accesses it, then that can also cause excessive writes over time.
It seems to depend on the use case and configuration of the device.
Despite Nokia's 'multimedia computer' tag. The engineering challenges in building reliable mobile terminals are not the same as a PC.
Jasmine, thanks for your post, particularly on the flash memory's wearing out. In the Wiki (see http://en.wikipedia.org/wiki/Flash_memory ), the following is stated:
"Another limitation is that flash memory has a finite number of erase-write cycles (most commercially available flash products are guaranteed to withstand 100,000 write-erase-cycles for block 0, and no guarantees for other blocks). This effect is partially offset by some chip firmware or file system drivers by counting the writes and dynamically remapping the blocks in order to spread the write operations between the sectors; this technique is called wear levelling. Another mechanism is to perform write verification and remapping to spare sectors in case of write failure, which is named bad block management (BBM). With these mechanisms in place, some industry analysts[1] have calculated that flash memory can be written to at full speed continuously for 51 years before exceeding its write endurance, even if such writes frequently cause the entire memory to be overwritten. This figure (51 years) involved a worst-case scenario using specific data parameters and should not be confused with a particular "shelf life" for a flash memory device. The bottom line is that a typical user using a commercial device, such as a camera, with a flash drive will probably not wear out the memory for the effective life of the camera."
Are you sure the Flash memory you refer to didn't use wear leveling and/or BBM? Most (if not all) Flash memories do it nowadays.
(BTW, have you checked out my last posts / questions at http://www.reghardware.co.uk/2007/12/01/power_monitor/comments/ ? ;) )
It certainly *does* use wear levelling and bad block management (they are mandatory for NAND devices, since not all blocks are good from the factory). However there is no getting around the fact that writes to NAND are slow (in comparison to writes to RAM) and power hungry (consuming thousands of times more energy than reading).
I haven't spotted your power monitor comments- I will check them out.
Yup, no doubt writing to Flash isn't as fast as to RAM, albeit current Flash memories can be written at 5-20 Mbyte/s, which is almost on par with current HDD's (particularly on mobile platforms).
As far as power consumption (when writing) is concerned, writing to Flash is indeed power-hungry. However, continuously and actively writing to Flash memory, IMHO, doesn't (wouldn't) *drastically* reduce the battery life of a device.
Back in 2003, I've made several related tests with an HP iPAQ 2210 running on a 950 mAh and recording an MP3 stream directly to a card. I've run the test till the device has disabled acccessing the card. The constant (!), unbuffered writing to the card has turned out to reduce battery life by 5...10% (depending on the card used) as opposed to writing to RAM. That is, it woulnd't have THAT bad an effect on the overall battery life. Certainly less effect than utilizing a HDD / Microdrive.
Richard, you suggested enabling 'assisted GPS' to speed up position locking - could you say how to acces this option? I've found the options for 'Bluetooth GPS', 'Integrated GPS' and 'Network Based' under the 'Positioning Settings' menu in the 'GPS Data' tool and have all but Bluetooth enabled (set that way automatically after update)and it still can take minutes to figure out where it is! Help!