**** BEGIN LOGGING AT Thu May 08 02:59:58 2014
May 08 04:18:40 <DocScrutinizer05> ~cauldron
May 08 04:18:52 <DocScrutinizer05> ~wiki cauldron
May 08 04:18:55 <infobot> At http://en.wikipedia.org/wiki/Cauldron (URL), Wikipedia explains: "{{Other uses}} in a traditional ""bogrács"" (cauldron)]] A 'cauldron' (or 'caldron') is a large metal pot (kettle) for cooking and/or boiling over an open fire, with a large mouth and frequently with an arc-shaped hanger. The word cauldron is first recorded in Middle English as "caudroun" (13th century). It was borrowed from Old Northern French or Anglo-Norman "caudron" T. F. Hoad, ...
May 08 06:37:48 <Maxdamantus> add thereto a tiger's chaudron for the ingredients of our cauldron.
May 08 06:50:58 <DocScrutinizer05> ~dict chaudron
May 08 06:51:01 <infobot> Dictionary 'chaudron' (2): \Chau"dron\, n. See {Chawdron}. [Obs.] [1913 Webster] ;; kaldaunen guts, bowels, LL. calduna intestine, W. coluddyn gut, dim. of coludd bowels.] Entrails. [Obs.] [Written also {chaudron}, {chauldron}.] --Shak. [1913 Webster].
May 08 06:58:20 <DocScrutinizer05> the heck, wikipedia doesn't even know the words used to explain what's chaudron
May 08 06:59:25 <DocScrutinizer05> well, I know guts and intestine
May 08 07:00:11 <DocScrutinizer05> but wtf is kaldaunen, calduna, coluddyn, coludd ?
May 08 07:00:33 <Maxdamantus> They're not words in common use.
May 08 07:02:19 <DocScrutinizer05> ooh, Kutteln
May 08 07:03:27 <DocScrutinizer05> seems a tiger doesn't have any those
May 08 07:04:16 <DocScrutinizer05> ruminant has rumen
May 08 07:06:49 <Maxdamantus> Apparently that means tripe, which is basically intestines as a dish.
May 08 07:07:20 <Maxdamantus> usually lamb/mutton afaik
May 08 07:09:11 <DocScrutinizer05> http://en.wikipedia.org/wiki/Tripes yep
May 08 07:09:34 <DocScrutinizer05> http://en.wikipedia.org/wiki/Saure_Kutteln
May 08 07:09:46 <Maxdamantus> Oh, no, it's the stomach, not intestines.
May 08 07:09:59 <Maxdamantus> Maybe haggis is the intestines.
May 08 07:10:07 * Maxdamantus hasn't eaten either.
May 08 07:10:20 <DocScrutinizer05> well, stomach is intestines as well in my book
May 08 07:10:47 <Maxdamantus> intestines are below the stomach.
May 08 07:10:50 <DocScrutinizer05> me neither °°*°D-:
May 08 07:12:28 <DocScrutinizer05> ooh, you're right. My idea of what are intestines been flawed
May 08 07:13:36 <DocScrutinizer05> seems Miriam Webster is also kinda mistaken on Kaldaunen then
May 08 07:14:36 <Guest98402> I'm having trouble mounting my n900 HDD on my GNU/Linux desktop. When I connect it and select mass storage mode, I get a /dev/sdb, but no /dev/sdb1 or 2 or something. There's nothing to actually mount.
May 08 07:14:39 <DocScrutinizer05> http://de.wikipedia.org/wiki/Kutteln
May 08 07:14:57 <DocScrutinizer05> Guest98402: HDD?
May 08 07:15:24 <Maxdamantus> Guest98402: mount that.
May 08 07:15:48 <kerio> mass storage mode doesn't export a whole device
May 08 07:15:49 <kerio> just a partition
May 08 07:15:52 <Maxdamantus> Guest98402: it normally provides the single partition.
May 08 07:16:06 <DocScrutinizer05> when your uSD has no partitions then it will show as /dev/sdb and be so called superfloppy format
May 08 07:16:22 <Maxdamantus> Guest98402: the whole device would include swap and /home, which is in use by Maemo, so you don't want to mount that.
May 08 07:16:28 <DocScrutinizer05> also what kerio said
May 08 07:16:49 <kerio> i wonder if the exported swap partition is actually writeable
May 08 07:16:51 <kerio> i never tried
May 08 07:16:53 <kerio> for obvious reasons
May 08 07:18:22 <Maxdamantus> it doesn't export it.
May 08 07:18:36 <kerio> my swap partition is on the uSD
May 08 07:18:39 <kerio> it's exported
May 08 07:18:42 <Maxdamantus> Ah.
May 08 07:18:44 <DocScrutinizer05> hah!
May 08 07:18:50 <Maxdamantus> Then sure, it would be.
May 08 07:18:59 <kerio> isn't it locked or something like that?
May 08 07:19:12 <kerio> i would expect the kernel to be quite strict with stuff like that
May 08 07:19:21 <DocScrutinizer05> I'd think it's hard to get exported and same time used by system
May 08 07:19:31 <kerio> why's that?
May 08 07:19:39 <kerio> the swap partition is a readable device file
May 08 07:19:45 <kerio> i was wondering if it's writeable
May 08 07:19:48 <Maxdamantus> Hm. Linux (maybe POSIX, can't remember) has a mechanism to lock parts of files.
May 08 07:19:51 <DocScrutinizer05> and you had to think what for you want to mount it anyway
May 08 07:19:58 <Maxdamantus> dunno if it works on devices.
May 08 07:20:00 <DocScrutinizer05> unless you wanna write to raw device
May 08 07:20:59 <Maxdamantus> it shouldn't be hard to export it.
May 08 07:21:44 <Maxdamantus> I'd be surprised if the OS refused to export the SD device while part is used as swap.
May 08 07:21:52 <DocScrutinizer05> I'd rather worry if system still can write to swap when it got exported
May 08 07:21:59 <Maxdamantus> probably just unmounts /media/mmc*
May 08 07:22:20 <DocScrutinizer05> :nod:
May 08 07:22:20 <Maxdamantus> It can.
May 08 07:22:48 <Maxdamantus> neither using swap nor exporting with g_file_storage locks anything.
May 08 07:23:03 <DocScrutinizer05> right
May 08 07:23:44 <DocScrutinizer05> kerio: so go ahead write some mp3 or wav data to swap, watch your N900 starting to sing and dance! ;-P
May 08 07:24:27 <Maxdamantus> phones as mass storage devices is silly anyway.
May 08 07:24:28 <DocScrutinizer05> I'd honestly blacklist any swap partition from export
May 08 07:24:52 <DocScrutinizer05> I mean there's a reason why I pushed that blacklist into CSSU ;)
May 08 07:24:53 <Maxdamantus> It's already powerful enough to run a filesystem server.
May 08 07:25:24 * Maxdamantus just loads g_ether on boot.
May 08 07:25:40 <DocScrutinizer05> hey!
May 08 07:25:49 <DocScrutinizer05> H-E-N?
May 08 07:25:58 <Maxdamantus> No.
May 08 07:26:18 <Maxdamantus> it's the Linux kernel module that acts as an ethernet device.
May 08 07:26:29 <DocScrutinizer05> ooh, so the device pretends to be a NIC
May 08 07:26:37 <Maxdamantus> Yes.
May 08 07:27:01 <kerio> phones as network cards is silly anyway.
May 08 07:27:24 <Maxdamantus> Yes, but it's better than as block devices.
May 08 07:27:24 <kerio> why isn't g_null the default behaviour anyway?
May 08 07:27:25 <DocScrutinizer05> well, unless you use the modem
May 08 07:27:53 <DocScrutinizer05> to actually access "the internet"
May 08 07:28:09 <DocScrutinizer05> which is best served via ethernet
May 08 07:28:24 <DocScrutinizer05> err network
May 08 07:28:30 <Maxdamantus> wire
May 08 07:29:03 <DocScrutinizer05> yeah
May 08 07:29:15 <DocScrutinizer05> TCP/IP
May 08 07:29:34 * Maxdamantus uses it for rsync and for Bluetooth.
May 08 07:30:00 <DocScrutinizer05> rsync? that's running via cronjob and WLAN here
May 08 07:30:22 <Maxdamantus> rsync over ssh.
May 08 07:30:30 <DocScrutinizer05> real joy to read the cronjob's mails to root
May 08 07:30:39 <Maxdamantus> just for one-off things, not periodic syncs/backups.
May 08 07:31:10 <DocScrutinizer05> ~jrtools
May 08 07:31:10 <infobot> somebody said jrtools was http://wiki.maemo.org/User:Joerg_rw/tools
May 08 07:31:28 <DocScrutinizer05> actually http://wiki.maemo.org/User:Joerg_rw/tools#backup
May 08 07:31:45 <DocScrutinizer05> extremely convenient
May 08 07:33:13 <kerio> offline backups are the one true way
May 08 07:33:39 <DocScrutinizer05> offline?
May 08 07:34:52 * DocScrutinizer05 idly wonders if somebody already pondered to create a striped raid from eMMC and uSD
May 08 07:35:25 <Guest98402> Maxdamantus: DocScrutinizer05 yeah, I mean the regular 28GB partition
May 08 07:35:52 <kerio> DocScrutinizer05: after a successful halt
May 08 07:36:11 <DocScrutinizer05> Guest98402: mount /dev/sdb /media -t vfat
May 08 07:36:41 <Maxdamantus> I'm going to eventually run btrfs across the eMMC and SD.
May 08 07:36:50 <DocScrutinizer05> :-D
May 08 07:37:12 * Maxdamantus should get around to writing that alternative phone thing so he can stop using Maemo and use a newer kernel.
May 08 07:37:30 <Guest98402> Thanks DocScrutinizer05 that worked
May 08 07:37:36 <DocScrutinizer05> yw :)
May 08 07:37:56 <Guest98402> I just wonder why pcmanfm and other file managers can't mount it themselves anymore, though
May 08 07:37:58 * Maxdamantus wrote most of a 9p implementation in Go with a better interface than the other 9p implementations.
May 08 07:38:01 <Guest98402> That used to work without problems
May 08 07:38:15 <DocScrutinizer05> don't forget to sync and umount before you unplug!
May 08 07:38:27 <Guest98402> Is sync still necessary if you umount?
May 08 07:38:50 <Maxdamantus> No.
May 08 07:38:53 <DocScrutinizer05> good question
May 08 07:38:59 <DocScrutinizer05> prolly not
May 08 07:39:01 <Maxdamantus> assuming it is fully unmounted.
May 08 07:39:15 <Maxdamantus> You can mount the same filesystem in different places.
May 08 07:39:26 <Maxdamantus> so if you "unmount" one, it's not actually unmounted.
May 08 07:39:39 <antithesis_> Yeah, well, I won't do that
May 08 07:39:57 <antithesis_> What about the other way around? Can you sync, then unplug without umounting?
May 08 07:40:10 <Maxdamantus> Depends on the filesystem.
May 08 07:40:39 <antithesis_> FAT filesystems
May 08 07:40:54 <Maxdamantus> Should be fine.
May 08 07:41:04 <Maxdamantus> as long as you don't write anything after the sync.
May 08 07:41:18 <DocScrutinizer05> dd if=image.bin of=/dev/sdc to flash a complete image to a uSD took >60s for sync. 
May 08 07:41:21 <kerio> answer = NO
May 08 07:41:28 <DocScrutinizer05> after dd finished
May 08 07:41:41 <kerio> there's so much shit going on in a modern linux system
May 08 07:41:43 <kerio> you can't be sure
May 08 07:42:20 <DocScrutinizer05> mount -o remount,ro /media
May 08 07:42:48 <kerio> DocScrutinizer05: i would expect that to not necessarily sync
May 08 07:42:51 <Maxdamantus> Yes, you can do that.
May 08 07:43:07 <DocScrutinizer05> sure it doesn't sync, but after sync you can be sure
May 08 07:43:18 <Maxdamantus> It does necessarily sync.
May 08 07:43:54 <DocScrutinizer05> the device can't go r/o before all buffers got flushed
May 08 07:44:05 <kerio> the mounted partition is going r/o
May 08 07:44:07 <Maxdamantus> So the mount call hangs until that happens.
May 08 07:44:47 <DocScrutinizer05> dunno if it forces sync, or just idles and waits
May 08 07:45:08 <DocScrutinizer05> prolly should force
May 08 07:45:15 <Maxdamantus> It wouldn't just idle and wait.
May 08 07:45:25 <Maxdamantus> but imo, that's what sync should do.
May 08 07:45:34 <Maxdamantus> It's not usually :(
May 08 07:46:18 <DocScrutinizer05> no, sync actively flushes the buffers
May 08 07:46:23 <zGrr> moin :)
May 08 07:46:28 <DocScrutinizer05> moinmoin
May 08 07:47:12 <Maxdamantus> Not really.
May 08 07:47:24 <DocScrutinizer05> sync takes no parameters afaik, and that sucks
May 08 07:47:40 <Maxdamantus> The system will continuously be writing dirty stuff as long as there's stuff to write.
May 08 07:48:23 <Maxdamantus> so sync/fsync means "wait until the writeback cache has passed the current moment in time"
May 08 07:48:36 <Maxdamantus> but they usually additionally send some sort of commit to the filesystem.
May 08 07:49:03 <DocScrutinizer05> wut? there's a dirty-flush-timeout that's up to 1 minute on laptops etc
May 08 07:49:07 <Maxdamantus> and fsync might actually prioritise things.
May 08 07:49:37 <DocScrutinizer05> I'd expect sync to "increase the pressure"
May 08 07:50:02 <DocScrutinizer05> sync(1) that is
May 08 07:50:05 <Maxdamantus> Ah yeah, when the writeback cache isn't stressed.
May 08 07:50:29 <antithesis_> oshit what did I ignite
May 08 07:50:33 <antithesis_> still about sync
May 08 07:51:45 <DocScrutinizer05> echo 500 > /proc/sys/vm/dirty_expire_centisecs
May 08 07:52:14 <DocScrutinizer05> rcS
May 08 07:52:56 <Maxdamantus> I think it should only be up to the computer operator to "increase the pressure".
May 08 07:53:17 <Maxdamantus> so calls like fsync should be there for processes to know when the stuff they wrote has been written.
May 08 07:53:22 <DocScrutinizer05> which he did, by issueing a sync command
May 08 07:54:28 <DocScrutinizer05> I'm not talking about fsync(2)
May 08 08:02:06 <DocScrutinizer05> anyway all info about sync, fsync and fdatasync seem to suggest that those function calls are kernel and executed immediately
May 08 08:02:38 <DocScrutinizer05> "the kernel flushes all buffers"
May 08 08:06:41 <Maxdamantus> Wonder if Linux provides a passive version of fsync.
May 08 08:07:08 <Maxdamantus> If you only want to know when some data has been written.
May 08 08:07:44 <DocScrutinizer05> doesn't seem so. But I just learned that (f)sync even is supposed to flush drive cache
May 08 08:08:04 <Maxdamantus> eg, in a CoW system, you'd do that to know when a revision has been completed, so you can know that it's safe to reuse space from the revision before it.
May 08 08:08:26 <DocScrutinizer05> >> This includes writing through or flushing a disk  cache if present.<<
May 08 08:09:40 <DocScrutinizer05> yeah, there SHOULD be such function call
May 08 08:09:54 <Maxdamantus> That should be what fsync itself does.
May 08 08:10:16 <DocScrutinizer05> no, fsync serves other purpose
May 08 08:10:39 <Maxdamantus> Very little other, except in distributed systems.
May 08 08:11:00 <Maxdamantus> where you want to tell peers that the data has been safely written, as quickly as possible.
May 08 08:11:35 <DocScrutinizer05> right, fsync is a bit... nonsensical for purposes of e.g. safe shutdown etc
May 08 08:11:44 <DocScrutinizer05> sync otoh
May 08 08:12:46 <DocScrutinizer05> generally speaking fsync makes sure your data is "safe"
May 08 08:13:47 <Maxdamantus> I'd say generally speaking it doesn't.
May 08 08:14:00 <Maxdamantus> It provides a way for you to make sure your data is safe.
May 08 08:14:13 <DocScrutinizer05> I guess there might be a option bit in write() to say "no buffering", then you do blocking write() and here you are
May 08 08:14:23 <Maxdamantus> by letting programs know when a future revision of something has been completely written.
May 08 08:15:04 <DocScrutinizer05> ?
May 08 08:16:30 <Maxdamantus> fsync doesn't actually provide a way to know that your data is safe.
May 08 08:16:43 <Maxdamantus> a milisecond after fsync calls, someone else might've overwritten it.
May 08 08:16:44 <DocScrutinizer05> fsync (and fdatasync) says "write this now, I don't want to risk it getting lost on unadvertised brownout"
May 08 08:17:33 <DocScrutinizer05> and with your overwritten data you're really going weird now
May 08 08:17:44 <Maxdamantus> So what do you do after the fsync?
May 08 08:18:13 <DocScrutinizer05> when somebody overwrites my file, well then my system is a pile of bullshot coded by monkeys
May 08 08:18:39 <Maxdamantus> You shouldn't just fsync for the hell of it.
May 08 08:18:41 <DocScrutinizer05> let's see... what does mySQL do after fsync
May 08 08:18:44 <Maxdamantus> It's going to be written eventually
May 08 08:18:55 <DocScrutinizer05> close the transaction maybe?
May 08 08:19:12 <Maxdamantus> Non-distributed databases have a reason to do what I said fsync should do.
May 08 08:19:35 <Maxdamantus> If they want to be able to guarantee database consistency, they need something like fsync.
May 08 08:19:43 <DocScrutinizer05> aha. and what is a commit in your book then?
May 08 08:19:52 <Maxdamantus> but they don't need the "force it to write now" bit.
May 08 08:20:11 <DocScrutinizer05> oh, they don't?
May 08 08:20:24 <Maxdamantus> No. The "force it to write now" doesn't help in ensuring consistency.
May 08 08:20:32 <DocScrutinizer05> aha
May 08 08:20:40 <Maxdamantus> The system could lose power during the fsync or before it.
May 08 08:20:49 <DocScrutinizer05> great
May 08 08:20:52 <DocScrutinizer05> so what?
May 08 08:21:26 <DocScrutinizer05> AFTER the fsync anyway I KNOW my data is on magenitzed bits on a disk
May 08 08:21:42 <DocScrutinizer05> so I return from commit()
May 08 08:21:58 <Maxdamantus> Yes. That's what fsync should ensure.
May 08 08:22:07 <Maxdamantus> It shouldn't try to force anything.
May 08 08:22:13 <DocScrutinizer05> aha
May 08 08:22:20 <Maxdamantus> it should just wait until the data written beforehand is on the disk.
May 08 08:22:28 <DocScrutinizer05> tzz
May 08 08:22:45 <DocScrutinizer05> which may never happen
May 08 08:23:17 <Maxdamantus> It will happen eventually, unless there's a hardware failure.
May 08 08:23:27 <DocScrutinizer05> no it won't
May 08 08:23:42 <DocScrutinizer05> not in any warranted finite timespan
May 08 08:24:18 <Maxdamantus> Do you mean indefinite?
May 08 08:24:36 <Maxdamantus> or infinite?
May 08 08:24:40 <Maxdamantus> It will happen, eventually.
May 08 08:24:45 <Maxdamantus> ie, within a finite amount of time.
May 08 08:24:46 <DocScrutinizer05> I mean  system with echo 5000000000 > /proc/sys/vm/dirty_expire_centisecs
May 08 08:25:35 <Maxdamantus> Then it will have to wait a while.
May 08 08:25:53 <DocScrutinizer05> I'd say THANKYOU to a db that takes 30min to return from a commit()
May 08 08:26:26 <DocScrutinizer05> I suggest you write your own kernel and libs
May 08 08:26:56 <DocScrutinizer05> since on unix or posix fsync won't do what you ask for
May 08 08:27:06 <Maxdamantus> Unless it's part of a distributed system, the database shouldn't wait for the data to be on disk before returning.
May 08 08:27:06 <DocScrutinizer05> maybe some other call does
May 08 08:27:42 <DocScrutinizer05> AHA, you also need to write your own db then, see definition of "commit"
May 08 08:28:09 <Maxdamantus> commit in databases usually has to do with atomicity afaik
May 08 08:28:09 <DocScrutinizer05> good luck with evaluating and certifying that critter 
May 08 08:28:23 <Maxdamantus> ie, you have a bunch of stuff in a commit, which either happens or doesn't.
May 08 08:28:34 <freemangordon_> hmm, isn't commit related to transactions, rather to io?
May 08 08:28:39 <Maxdamantus> Yes.
May 08 08:28:42 <Maxdamantus> (afaik)
May 08 08:28:48 <DocScrutinizer05> commit first and foremost has to do with rolling back atomic sequences of actions
May 08 08:28:55 <Maxdamantus> Yes.
May 08 08:28:57 <freemangordon_> sure
May 08 08:29:02 <Maxdamantus> which is what my use case of fsync is about.
May 08 08:29:19 <freemangordon_> but shouldn't be related to io
May 08 08:29:29 <freemangordon_> what db is that?
May 08 08:29:38 <Maxdamantus> You don't need to wait for a filesystem fsync to return before claiming a commit has finished though.
May 08 08:29:47 <freemangordon_> exactly
May 08 08:30:13 <DocScrutinizer05> depends on your level of consistency you expect from the db
May 08 08:30:28 <Maxdamantus> The point of the filesystem fsync is for there to always be a consistent (not corrupt) version of the DB accessible.
May 08 08:30:48 <DocScrutinizer05> when your commit returns before data got written to disk, it ISN'T committed yet
May 08 08:30:52 <Maxdamantus> So you'll be able to roll back to some good copy after unexpected power loss.
May 08 08:30:58 <freemangordon_> DocScrutinizer05: it is
May 08 08:31:04 <Maxdamantus> To do that, you need to make sure you haven't overwritten all good copies.
May 08 08:31:33 <freemangordon_> as your inserts/updates are in the journal
May 08 08:31:35 <Maxdamantus> So you either need some WORM system, or something based on a passive fsync.
May 08 08:31:53 <DocScrutinizer05> freemangordon_: when system goes down after commit returns but before buffers flushed, you're fsckd
May 08 08:31:54 <Maxdamantus> (with the WORM system, you'd additionally need the guarantee that writes are ordered)
May 08 08:32:04 <antithesis_> Okay, okay, I'll just use umount...
May 08 08:32:05 <freemangordon_> sure, and I've seen that
May 08 08:32:23 <freemangordon_> with oracle on solaris :)
May 08 08:32:27 <DocScrutinizer05> that's why I say "depends"
May 08 08:32:35 <freemangordon_> duplicated primary keys :D
May 08 08:33:00 <freemangordon_> but it is not db job to care about fs 
May 08 08:33:47 <freemangordon_> because begin/end transaction, commit, etc is related to db, not to fs
May 08 08:34:31 <freemangordon_> anyway, back to my job :)
May 08 08:34:43 <DocScrutinizer05> anyway demanding a change of fsync(2) sematics so you don't need to use sth like a non-buffered blocking write() is nonsensical
May 08 08:35:51 <Maxdamantus> in Linux, it's ultimately up to the filesystem implementation to provide the semantics.
May 08 08:36:09 <Maxdamantus> and it seems reasonable to offer different meanings as mount options.
May 08 08:36:23 <Maxdamantus> I'd like to use btrfs without a log.
May 08 08:36:46 <Maxdamantus> So if I lose power, I'll just lose up to 30s of activity.
May 08 08:37:06 <Maxdamantus> I don't need to guarantee to other people that I've saved their data.
May 08 08:37:48 <DocScrutinizer05> whatever you like
May 08 08:38:11 <DocScrutinizer05> toldya, linux is FOSS, go and fork!
May 08 08:39:34 <DocScrutinizer05> since I don't see another way to redefine the clearly specified and fixed sematics of an existing function call when you as well could create a new function call that does what you ask for
May 08 08:40:37 <DocScrutinizer05> man 2 fsync
May 08 08:41:11 <Maxdamantus> Most proper uses of fsync would work with either semantics.
May 08 08:41:13 <DocScrutinizer05> >>fsync()  transfers  ("flushes")  all  modified in-core data of (i.e., modified buffer cache pages for) the file referred to by the file descriptor fd to the disk device<<
May 08 08:41:24 <Maxdamantus> I doubt a database is actually going to wait until the data is on disk before returning from a commit.
May 08 08:41:25 <DocScrutinizer05> not "waits until that happens, eventually"
May 08 08:41:28 <Maxdamantus> That will just slow stuff down.
May 08 08:41:51 <Maxdamantus> Unless you've configured the database to do it.
May 08 08:41:58 <Maxdamantus> which might be useful in distributed systems.
May 08 08:42:02 <DocScrutinizer05> exactly ;)
May 08 08:42:18 <DocScrutinizer05> or in high security systems
May 08 08:42:42 <DocScrutinizer05> where a commit is a commit is a commit
May 08 08:42:51 <Maxdamantus> if the information is contained locally, there's usually the excuse "well, what if it crashed before the fsync? the data's lost anyway"
May 08 08:43:15 <DocScrutinizer05> irrelevant, the transaction gets rolled back
May 08 08:43:29 <Maxdamantus> Rolled back to what?
May 08 08:43:42 <DocScrutinizer05> to "money on account A"
May 08 08:44:00 <Maxdamantus> How does it know where that is?
May 08 08:44:11 <DocScrutinizer05> *sigh*
May 08 08:44:23 <Maxdamantus> What if the "money on account A" hadn't been commited to disk yet?
May 08 08:44:38 <DocScrutinizer05> eh?
May 08 08:45:20 <DocScrutinizer05> it *has* been, otherwise it wasn't on account A so nothing to move from A to B
May 08 08:46:03 <Maxdamantus> If you make two transactions: B → A, A → C, there are three possible places for the money to be.
May 08 08:46:24 <Maxdamantus> You have to roll back to the state you know is not corrupt.
May 08 08:46:32 <DocScrutinizer05> if you make two transactions, then they are atomic each and unentangled
May 08 08:46:41 <Maxdamantus> not necessarily the one before the last.
May 08 08:48:10 <DocScrutinizer05> you can't do A->C before B->A got committed
May 08 08:48:11 <Maxdamantus> You do it by keeping all states accessible, except for ones before the last one you know has been completed.
May 08 08:48:51 <Maxdamantus> So if you know the money-in-A state has been completed, you can forget about the money-in-B state.
May 08 08:49:08 <Maxdamantus> (completed as in: all information about that state is on disk)
May 08 08:49:18 <DocScrutinizer05> that's called "commit"
May 08 08:49:52 <Maxdamantus> No. Commit doesn't have to ensure it's on disk.
May 08 08:50:04 <DocScrutinizer05> maybe in your world
May 08 08:50:15 <Maxdamantus> Commit just has to ensure either none of it or all of it happens.
May 08 08:50:24 <Maxdamantus> rather than half of it.
May 08 08:50:33 <DocScrutinizer05> define 'happens'
May 08 08:50:47 <Maxdamantus> is part of an accessible state.
May 08 08:51:14 <DocScrutinizer05> gibberish
May 08 08:51:43 <Maxdamantus> Not gibberish.
May 08 08:52:01 <Maxdamantus> The accessible states are the one the database is currently portraying and the ones it might roll back to after power loss.
May 08 08:52:36 <DocScrutinizer05> and how's that explaining what you  meant by 'happens'?
May 08 08:52:43 <Maxdamantus> You don't want an in-between state where half of the transaction has taken effect.
May 08 08:53:33 <Maxdamantus> eg, in `A → C`, you don't want to accidentally roll back to a state where both A and C have the money
May 08 08:53:38 <Maxdamantus> or where neither of them have the money.
May 08 08:53:50 <DocScrutinizer05> yes, exactly. Like magnetic record of account A is 5 bucks lower but those 5 bucks are moving somewhere in RAM when machine gone down
May 08 08:54:26 <DocScrutinizer05> instead of got written into magnetic record of B
May 08 08:54:40 <Maxdamantus> What happens if you write that A no longer has the money, then you write that C has the money, then you fsync, but the system crashes in the middle of it?
May 08 08:54:52 <Maxdamantus> so the first write has taken effect, but the second hasn't.
May 08 08:55:10 <DocScrutinizer05> then the commit didn't complete
May 08 08:55:15 <Maxdamantus> There's a magnetic record of A not having the money.
May 08 08:55:34 <Maxdamantus> Obviously "having a magnetic record" isn't useful on its own.
May 08 08:55:40 <DocScrutinizer05> meh
May 08 08:56:01 <DocScrutinizer05> are we going to discuss how transactions and commits work now?
May 08 08:56:31 <Maxdamantus> I'm pretty sure that's what we've been doing.
May 08 08:56:35 <Maxdamantus> at least what I've been doing.
May 08 08:56:43 <Maxdamantus> 20:46:24 < Maxdamantus> You have to roll back to the state you know is not corrupt.
May 08 08:56:46 <Maxdamantus> 20:48:10 < Maxdamantus> You do it by keeping all states accessible, except for ones before the last one you know has been completed.
May 08 08:56:47 <DocScrutinizer05> not on a beginner's level
May 08 08:57:16 <Maxdamantus> So you don't actually overwrite anything about A's or C's money.
May 08 08:57:50 <Maxdamantus> Because you need to make sure at least one consistent state is accessible.
May 08 08:58:23 <DocScrutinizer05> FILE A: ta:345, -5bucks;   FILE B: ta:345, +5bucks;  log: ta:345 committed
May 08 08:58:48 <DocScrutinizer05> rollback from right to left all you like
May 08 08:59:02 <Maxdamantus> If you're just appending to files, you don't need anything like sync.
May 08 08:59:20 <DocScrutinizer05> aha
May 08 08:59:53 <Maxdamantus> You just need a guarantee of ordered writes.
May 08 09:00:11 <DocScrutinizer05> you're aware HDD work with sectors and blocks and such shite? They even spin
May 08 09:00:30 <Maxdamantus> So when you get power back, you read the last complete line of the log file, and truncate everything after that commit on all files.
May 08 09:00:59 <Maxdamantus> A journal can give you ordered writes.
May 08 09:01:34 <Maxdamantus> You only need the metadata to be ordered in this case.
May 08 09:01:38 <DocScrutinizer05> and in-order write for everything will give you a db that's blatantly useless regarding performance. Possibly even runs into deadlocks
May 08 09:02:32 <Maxdamantus> Why would you run into deadlocks?
May 08 09:02:48 <DocScrutinizer05> and it doesn't matter if you fsync your data or your journal
May 08 09:03:49 <DocScrutinizer05> you need to fsync *something* anyway
May 08 09:04:01 <Maxdamantus> You don't need to. You just need ordered metadata writes.
May 08 09:04:11 <Maxdamantus> if you're only appending.
May 08 09:04:18 <Maxdamantus> the fsync is useful for knowing what you can overwrite.
May 08 09:05:30 <DocScrutinizer05> I'm afk
May 08 09:05:46 <DocScrutinizer05> this leads nowhere anyway
May 08 09:06:55 <DocScrutinizer05> particularly since I'm no db developer, I just use them every now and then
May 08 09:07:25 <DocScrutinizer05> e.g to move your money to and from your bank account
May 08 09:08:23 <DocScrutinizer05> and i'd not be surprised if COBOL commit definition actually requires data to get written to HDD
May 08 09:09:09 <DocScrutinizer05> afk now
May 08 09:19:29 <DocScrutinizer05> re your sequential writing and rolling back arbitrary amounts, so you wouldn't need a fsync: alas e.g. a ATM transaction can't get rolled back, the money got released to the customer
May 08 09:22:41 <DocScrutinizer05> so you damn sure wanna release the money same point in time you do the commit to your transaction that books -200$ to the customer's account, and you wanna be sure that's in magnetic storage, not in some buffer
May 08 09:25:11 <DocScrutinizer05> you can't sit on a frankenstein-fsync and wait for buffers to eventually get flushed
May 08 09:25:26 <DocScrutinizer05> in 5 minutes
May 08 09:34:46 <DocScrutinizer05> for a system that has absolutely no dynamic input data to deal with, and doesn't matter when the printout with the result of all your equations and transactions falls off the printer, you may get away with your approach
May 08 09:57:23 <Maxdamantus> Yes. That's an example of a distributed system.
May 08 09:57:51 <Maxdamantus> You have to tell someone else that the commit is permanent, and optimially as quickly as possible.
May 08 09:58:31 <Maxdamantus> (you wouldn't want to wait a minute for the data to be flushed before responding to an ATM request)
May 08 09:58:51 <Maxdamantus> When the ATM server dies, the customer doesn't.
May 08 16:08:14 <DocScrutinizer05> I don't know what to complain about... My GPS seems to work better than ever. After enabling Location Test indoors next to a closed window, I hardly could enable sat view fast enough to see the last 2 of 6 sats turning green. After ~10s I had a 4-sat fix
May 08 16:08:32 <DocScrutinizer05> and GPS had not been used for at least 2 weeks before
May 08 16:10:38 <DocScrutinizer05> AGPS, supl.google.com
May 08 16:11:00 <DocScrutinizer05> SIM activated, WLAN for internet access
May 08 16:11:26 <bencoh> I thought supl.google didnt work anywore
May 08 16:11:27 <DocScrutinizer05> O2-Germany
May 08 16:11:28 <bencoh> anymore*
May 08 16:11:37 <DocScrutinizer05> *shrug*
May 08 16:11:59 <bencoh> (my mobile operator provides me a supl anyway)
May 08 16:12:15 <DocScrutinizer05> possibly it doesn't need any supl, since usually the assistance is via WWAN
May 08 16:12:24 <bencoh> WWAN ?
May 08 16:12:31 <DocScrutinizer05> 2/3G
May 08 16:12:37 <DocScrutinizer05> ~wwan
May 08 16:12:51 <DocScrutinizer05> o.O
May 08 16:12:55 <DocScrutinizer05> anyway
May 08 16:13:04 <DocScrutinizer05> ~gsm-agps
May 08 16:13:05 <infobot> i heard rrlp is the Radio Resource LCS (Location Service) Protocol as specified first in GSM TS 04.31, or http://security.osmocom.org/trac/wiki/RRLP
May 08 16:13:19 <bencoh> hmm, can the n900 use something else than supl for that ?
May 08 16:13:28 <DocScrutinizer05> ^^^
May 08 16:13:55 <DocScrutinizer05> http://en.wikipedia.org/wiki/RRLP
May 08 16:14:33 <bencoh> right but that doesn't give infos needed for gps stuff
May 08 16:14:36 <DocScrutinizer05> prolly 3G helps a lot, via E-OTD
May 08 16:14:37 <bencoh> (ephemerids and all)
May 08 16:14:50 <bencoh> or does it ?
May 08 16:14:52 <DocScrutinizer05> rrlp does
May 08 16:15:11 <DocScrutinizer05> it's basically supl via wwan
May 08 16:15:23 <DocScrutinizer05> well, part of it is
May 08 16:15:23 <bencoh> oh, okay
May 08 16:15:31 <bencoh> interesting
May 08 16:15:36 <DocScrutinizer05> there's a system and a user layer iirc
May 08 16:15:50 <DocScrutinizer05> and on 3G there's E-OTD
May 08 16:16:12 <DocScrutinizer05> which isn't specified as giving feedback to MS
May 08 16:16:15 <bencoh> the MS-assisted GPS part I guess ?
May 08 16:16:22 <DocScrutinizer05> but also nobody says it mustn't
May 08 16:17:40 <DocScrutinizer05> aiui E-OTD has no MS-based mode
May 08 16:18:22 <DocScrutinizer05> the enodeb doesn't share sufficient info to MS to do that on-board
May 08 16:18:54 <DocScrutinizer05> but enodeb could return the result of E-OTD to MS
May 08 16:20:54 <DocScrutinizer05> NB that for GSM/2G there's no such thing like E-OTD
May 08 16:21:25 <bencoh> no E-OTD for me then :)
May 08 16:21:44 <DocScrutinizer05> at least not in specs. Carriers could do passive (from MS POV) OTD triangulation, when they add special equipment to BTS
May 08 16:22:56 <DocScrutinizer05> passive OTD would mean: make MS send any arbitrary thing, check timing difference as seen by receivers of at least 3 BTS
May 08 16:23:40 <DocScrutinizer05> for that the BTS need special equipment to precisely sync to each other and also precisely measure time of arrival of signal from MS
May 08 16:24:09 <bencoh> hmm
May 08 16:24:17 <DocScrutinizer05> it's unclear which providers equipped how many of their BTS with such additional gear
May 08 16:27:20 <DocScrutinizer05> anyway GPS based RRLP is defined also for 2G
May 08 16:27:32 <DocScrutinizer05> afaik
May 08 16:27:48 <DocScrutinizer05> yep, wiki clearly states it
May 08 16:28:00 <DocScrutinizer05> >>Radio resource location services (LCS) protocol (RRLP) applies to GSM and UMTS Cellular Networks<<
May 08 16:29:58 <bencoh> good to know
May 08 16:30:27 <bencoh> doesn't that mean  supl should be useless then ?
May 08 16:38:28 <DocScrutinizer05> well, as long as your carrier provides it via RRLP it actually might be useless
May 08 16:39:08 <DocScrutinizer05> NB the N900 GPS is controlled by modem, not by main CPU
May 08 16:39:09 <bencoh> I should test it some time
May 08 16:39:14 <bencoh> yeah I know
May 08 16:39:25 <DocScrutinizer05> RRLP is the reason for that
May 08 16:40:07 <bencoh> btw how does main cpu feeds the gps with supl results ?
May 08 16:40:19 <DocScrutinizer05> a god question
May 08 16:40:21 <DocScrutinizer05> good
May 08 16:41:06 <bencoh> that goes with all the gps-related secrets ?
May 08 16:41:15 <DocScrutinizer05> there are some (usually proprietary) AT commands (or in case of BB5 modem: ISI messages) to send supl data to modem and from there to GPS system
May 08 16:42:30 <DocScrutinizer05> see the *closed-blob* mini tool Nokia provided for clearing position cache
May 08 16:42:44 <bencoh> you mean ssi-encapsulated AT commands ?
May 08 16:43:00 <bencoh> (ssi/hsi)
May 08 16:43:02 <DocScrutinizer05> for debugging purposes when we had that GPS-doesn't-get-fix issue
May 08 16:43:43 <DocScrutinizer05> I don't think ISI protocol is anything like "AT encapsulated into whatever"
May 08 16:44:15 <DocScrutinizer05> it's more like tcp/ip
May 08 16:44:30 <DocScrutinizer05> with slots/ports for certain services
May 08 16:44:53 <bencoh> yeah I got confused, misread "there are some (usually proprietary) AT commands (or in case of BB5 modem: ISI messages)
May 08 16:45:31 <DocScrutinizer05> we got pnatd to convert AT to ISI
May 08 16:46:46 <DocScrutinizer05> though that critter is so small and so little result from string(1) it, I could even figure they transport the raw ascii to BB5 via ISI, so actually some form of AT-over-HSI
May 08 16:47:33 <DocScrutinizer05> prolly BB5 runs an AT-interpreter service of some sorts, on some slot/port
May 08 16:47:55 <DocScrutinizer05> but that's not the recommended and usual way to communicate with ISI modem
May 08 16:48:11 <DocScrutinizer05> disclaimer: all AIUI/AFAIK
May 08 16:49:12 <DocScrutinizer05> anyway I'm pretty convinced that BB5 does E-OTD on 3G
May 08 16:49:35 <DocScrutinizer05> I could't think of any other explanation for a stable fix after <5s
May 08 16:49:56 <DocScrutinizer05> *indoors* even
May 08 16:51:49 <DocScrutinizer05> oooh, and O2 prolly still runs their "homezone" tariff, which is supposed to knpow about MS position within a circle of iirc 500m around your home
May 08 16:52:15 <DocScrutinizer05> so odds are O2 has a vital interest in running RRLP/E-OTD
May 08 16:53:39 <DocScrutinizer05> I could even figure they do a E-OTD by default, each time a communication with MS happens
May 08 17:38:49 <DocScrutinizer05> hmm, according to http://www.teltarif.de/festnetz-nummer-handy-homezone-funktioniert-technik/news/53020.html?page=2 O2 does NOT use RRLP to define homezone
May 08 17:40:10 <bencoh> I suspect sfr (france) doesn't either but I'm not sure about it
May 08 17:51:38 <DocScrutinizer05> wow, seems that's a nice new virtual provider: https://www.simquadrat.de/produkte/roaming
May 08 17:52:21 <DocScrutinizer05> and they leaked a interesting info there: they call theri own network "sipgate netz" ;-)
May 08 17:53:02 <DocScrutinizer05> sipgate is a great SIP-VoIP provider I'm using since err 14 years?
May 08 17:53:21 <DocScrutinizer05> seems now they go GSM/UMTS
May 08 17:55:58 <DocScrutinizer05> ok, 9 years, not 14
May 08 18:04:00 <DocScrutinizer05> anyway EU-wide free voice roaming, and data roaming that's not take an arm and a leg from you, like other tariffs/providers do
May 08 18:04:33 <DocScrutinizer05> and Germany-wide geo-number/landline-number
May 08 18:05:02 <DocScrutinizer05> that's awesome and pretty much in line with what Sipgate offers for VoIP
May 08 18:08:22 <DocScrutinizer05> bencoh: no RRLP for homezone doesn't mean the carrier doesn't run any RRLP service. Particularly in France I'd bet on it being mandatory for all carriers, to allow for proper law enforcement agencies' target tracking
May 08 18:09:01 <DocScrutinizer05> as well as in GB
May 08 18:09:57 <DocScrutinizer05> dunno about norway - either they hate it or they *want* it
May 08 18:10:34 <DocScrutinizer05> in Germany afaik government can't enforce it
May 08 18:11:12 <DocScrutinizer05> so if O2 or other carriers do RRLP here, I'd guess they do it for location awareness of their customers' iPhone apps
May 08 18:11:53 <DocScrutinizer05> and obviously it works like a charm - I mean 5s TTFF, really?
May 08 18:12:09 <bencoh> DocScrutinizer05: true
May 08 18:13:38 * DocScrutinizer05 switches to 2G ...
May 08 18:16:13 <DocScrutinizer05> AHA! 50s till first feeble 3sat fix
May 08 18:19:30 <DocScrutinizer05> yep, reproducable. though stopping Location Test acquisition and switching to 3G, then resuming LT does _not_ result in fast TTFF. You need to quit LT and restart it, don't ask me why
May 08 18:21:00 <DocScrutinizer05> absolutely obviously only 3G O2 provides data for MS-based GPS assistance
May 08 18:23:53 <DocScrutinizer05> oooh, I just found the term used for what I described as "passive E-OTD alike triangualtion" above: http://en.wikipedia.org/wiki/U-TDOA
May 08 18:26:28 <DocScrutinizer05> >>Today, in the United States, Sprint and Verizon use a form of GPS known as Assisted GPS, and AT&T Mobility and T-Mobile use U-TDOA for their E9-1-1 solutions.<<
May 08 18:26:39 <bencoh> hmm
May 08 18:30:51 <kerio> 8 seconds for me :c
May 08 18:33:17 <DocScrutinizer05> 8s still is great, no?
May 08 18:33:30 <kerio> yeah yeah
May 08 18:33:46 <DocScrutinizer05> I think the theoretical minimum on GPS are 14s
May 08 18:35:15 <DocScrutinizer05> honestly GPS kinda starts becoming a niche technology and obsolete for everyday usage
May 08 18:35:20 <kerio> wait what
May 08 18:35:32 <kerio> you mean "pure" gps, right
May 08 18:36:03 <DocScrutinizer05> yeah, obviously
May 08 18:37:07 <DocScrutinizer05> since A-GPS with rich detailled assistance via RRLP is ibviously better. I mean, Location Test shows me 6 SATs with proper good S/N figures it's using after 5s
May 08 18:38:11 <kerio> agps is great if you have it
May 08 18:38:16 <DocScrutinizer05> while it's augmented and assisted by RRLP, it's still GPS
May 08 18:40:25 <DocScrutinizer05> note that RRLP aiui also sends an ultra-exact timing reference, by telling the MS GPS about phase skew between GSM signal and the SAT signal, so the receiver doesn't need to check correlations for a window of 100ms but maybe only 5ms or less
May 08 18:40:36 <DocScrutinizer05> SUPL never could do this
May 08 18:41:05 <kerio> why is there even a skew?
May 08 18:41:14 <DocScrutinizer05> huh? 
May 08 18:41:34 <DocScrutinizer05> why are two unrelated signals not in sync everywhere on this globe?
May 08 18:41:37 <kerio> yes!
May 08 18:41:43 <kerio> (i see)
May 08 18:41:53 <kerio> (stupid relativity)
May 08 18:42:35 <DocScrutinizer05> rather unrelativity
May 08 18:42:38 <DocScrutinizer05> ;-P
May 08 18:43:54 <DocScrutinizer05> the WWAN signal is not necessarily in sync with GPS signals, and for sure there's a skew caused by realtive distance of MS to both the base station and the satellite
May 08 18:43:59 <bencoh> well, didnt get a fix in a minute from the window (2G/operator supl)
May 08 18:44:20 <bencoh> weather might not help though
May 08 18:44:22 <kerio> raw gps is still useful if you're somewhere with no internets and no clock
May 08 18:44:34 <DocScrutinizer05> yes, sure
May 08 18:44:41 <bencoh> yup, getting a position in 12mn is better than nothing
May 08 18:44:42 <kerio> it's also useful if you never lose the fix
May 08 18:44:43 <kerio> :D
May 08 18:46:10 <DocScrutinizer05> alm and eph stay valid for quize a few hours. So it's sufficient to enable GPS every 20min and you always should get an acceptable TTFF. Not <10s but for sure no 12min
May 08 18:46:29 <kerio> every 20 minutes is 20 minutes too often
May 08 18:46:31 <bencoh> yup
May 08 18:46:40 <bencoh> and yup :)
May 08 18:46:58 <DocScrutinizer05> well, either you need GPS or you don't ;-)
May 08 18:46:59 <kerio> isn't there a way to get an offline supl?
May 08 18:47:12 <kerio> assuming a good clock
May 08 18:47:18 <DocScrutinizer05> how's that supposed to work?
May 08 18:47:28 <bencoh> you mean, computing eph ?
May 08 18:47:47 <kerio> read clock, do calculations to figure out which satellites should be visible
May 08 18:47:49 <DocScrutinizer05> eph is hard to compute, or pretty poor accuracy
May 08 18:47:59 <DocScrutinizer05> that's alm
May 08 18:48:16 <kerio> what's eph?
May 08 18:48:29 <DocScrutinizer05> eph takes into account the local errors in what you would expect according to alm
May 08 18:48:40 <kerio> "local"?
May 08 18:48:41 <bencoh> ephemeris
May 08 18:49:01 <bencoh> and almanacs should stay valid for a day anyway
May 08 18:49:08 <DocScrutinizer05> weeks
May 08 18:50:07 <bencoh> hmm is it all transmitted ?
May 08 18:51:00 <DocScrutinizer05> http://www.colorado.edu/geography/gcraft/notes/gps/gps_f.html
May 08 18:53:30 <DocScrutinizer05> http://www.colorado.edu/geography/gcraft/notes/gps/gps.html#SVData
May 08 18:56:56 <DocScrutinizer05> bencoh: so yes, all is transmitted in 12.5min
May 08 18:57:20 <DocScrutinizer05> and then stored to N900's data cache
May 08 18:58:09 <DocScrutinizer05> so one uninterrupted 13min GPS session per week should suffice
May 08 18:58:25 <DocScrutinizer05> even when you don't have any SUPL or whatever
May 08 18:58:30 <kerio> what about devices that don't have enough space?
May 08 18:58:49 <DocScrutinizer05> those devices don't exist, kerio
May 08 18:58:58 <kerio> how much data is that?
May 08 18:59:21 <DocScrutinizer05> calculate it! the data is there on http://www.colorado.edu/geography/gcraft/notes/gps/gps_f.html
May 08 18:59:26 <kerio> :c
May 08 18:59:44 <DocScrutinizer05> Data frames (1500 bits) are sent every thirty seconds
May 08 19:00:04 <kerio> 30000 bits!
May 08 19:00:18 <kerio> it's 3.66KB
May 08 19:00:37 <DocScrutinizer05> An entire set of twenty-five frames (125 subframes) makes up the complete Navigation Message that is sent over a 12.5 minute period.
May 08 19:01:18 <kerio> anyway, make that 25 minutes
May 08 19:01:32 <kerio> to get the data at least twice
May 08 19:01:39 <DocScrutinizer05> only when you use a particularly stupid algo
May 08 19:01:43 <kerio> i doubt that there's strong error correction
May 08 19:01:51 <DocScrutinizer05> or have dropouts
May 08 19:02:12 <DocScrutinizer05> there are parity bits, a few of them
May 08 19:02:44 <DocScrutinizer05> but yeah, you shouldn't have any significant dropouts
May 08 19:03:07 <DocScrutinizer05> I guess >1s is a sure killer
May 08 19:04:27 <DocScrutinizer05> >>Data bit subframes (300 bits transmitted over six seconds) contain parity bits that allow for data checking and limited error correction.<<
May 08 19:05:08 <DocScrutinizer05> http://www.colorado.edu/geography/gcraft/notes/gps/gif/databits.gif
May 08 19:13:38 <DocScrutinizer05> this is a very nice anim-gif, to understand how GPS receiver determines SAT (aka C/A RNG code) and time delay: http://www.colorado.edu/geography/gcraft/notes/gps/gif/bitsanim.gif
May 08 19:14:57 <DocScrutinizer05> note that you need to use local sliding code pattern to compare, for all SAT in vicinity, and each local pattern needs to get streched according to doppler seen from SAT's velocity relative to you
May 08 19:15:54 <DocScrutinizer05> assistance helps reduce number of patterns to feed to correlator to spot the SAT
May 08 19:16:38 <DocScrutinizer05> modern chips have many of those correlators
May 08 19:19:05 <DocScrutinizer05> ultra-high sensitivity receivers work by extending the time of comparing the patterns, often up to a minute or more
May 08 19:20:57 <kerio> mh, so they actually take longer to get a fix?
May 08 19:23:41 <DocScrutinizer05> sure
May 08 19:24:36 <DocScrutinizer05> they still may get a fix after 1min, when other standard receivers already failed
May 08 19:24:55 <DocScrutinizer05> on a good signal they are no slower than a standard chip
May 08 19:27:10 <kerio> i see
May 08 19:28:45 <DocScrutinizer05> those chips probably need magnitudes more storage and possibly also more computational grunt to accomplish the task
May 08 19:29:03 <DocScrutinizer05> s/storage/memory aka RAM/
May 08 19:29:05 <infobot> DocScrutinizer05 meant: those chips probably need magnitudes more memory aka RAM and possibly also more computational grunt to accomplish the task
May 08 19:32:38 <DocScrutinizer05> afk, cya in 2 days
May 08 19:34:43 <RiD> looks like vacations!
**** ENDING LOGGING AT Fri May 09 03:00:01 2014