[omgps] collect feature requests

[Laszlo KREKACS]

On Wed, Jul 1, 2009 at 7:44 AM, W.Kenworthy<billk at iinet.net.au> wrote:
> 1/2 an hour is no problem (often use GPS daily on the way to work - coz
> I can :) - longest drive was ~5 hours, which needed power at about the
> 3.5 hour mark - was 6 months ago and it should go longer now.  fsck does
> take an hour or so, but i only do it once a month as programmed
> maintenance - rarely finds an error UNLESS there has been a nasty crash
> which is rather rare these days (shr-unstable, built by myself).  Yes it
> sometimes used to happen that I get a call or SMS when using tangogps
> and have had crashes so need to take the battery out to reset - almost
> always no errors (using ext3, for at least the past two months).  If you
> are worried about fsck speed, put the SD card in a usb key and use a
> desktop/laptop to fsck it - much faster.

When I use gps, I dont have laptop....

>
> Try reducing the clock speed as I suggested - thats the most likely
> cause of your problems.  Your symptoms sound very like what happens to
> me (on any SD card) when running with the standard clock speed.  While
> the speed drop is ~1/3, its unnoticeable in my usage pattern.  Also make
> sure that the card is mounted async - sync is dismally slow and any gain
> in stability is lost because transfers are exposed as they take much
> longer to complete.  Swap will also add a degree of reliability in
> normal use, but if using a lot of swap, the phone can slow down
> dramaticly as thrashing starts - manually flushing swap gets things back
> on an even keel.

Yepp, but the problem only occurs with tangogps....

>
> There are some "tar" based compressed file systems out there (when
> tested, ~3.3gbytes of png's will compress down to ~550Mbytes as tar.bz2,
> but you need a lot of cpu cycles to extract) and they are not reliable
> at all.  the problem is that OSM maps are either png (lots of small
> files) or vector based which adds a real and critical processing load as
> seen by navit.  I actually symlink similar files (many are just
> ocean/desert - South Western Australia) and symlinks less than a certain
> size get stored in the inodes (fast symlinks) so dont take any disk
> space - the problem then becomes that ext3 has an upper limit to
> inodes :(

I dont want to compress at all. The 118MB for me is perfect. I only
want to pack the directory into a file. But not compressing.
Im thinking about tar or ar.


> In short, you are barking up the wrong tree if you think that large
> numbers of files are causing your problem.

Maybe. But if I wouldnt have any problem with those crash, I
would like to see implemented. If nothing else, the inode usage.
(for me, the fast copying to sd card).

Im extra-paranoid about this kind of file-access. I dont like
to stressing the filesystem to the limit.

I have this experience in normal computer usage:
Compressing a directory into zip and copyying a single
file to the pen drive, takes several time less, then copying the
directory as-is.
If you ever tried a pendrive like 16 or 32GB you know what
Im talking about. And it is independent of OS (windows vs. linux),
and the filesystem of the pendrive (vfat vs. ext2)

I didnt brother to reinstall tangogps since a month, because
exactly of the above issue.

To bad it seems that Im the only one in this boot.

Laszlo