| *** shentey has joined #maemo | 00:18 | |
| *** shentey has quit IRC | 00:22 | |
| *** rm_work|away is now known as rm_work | 00:24 | |
| *** _rd has quit IRC | 00:25 | |
| *** shentey has joined #maemo | 00:27 | |
| *** lizardo has quit IRC | 00:27 | |
| *** FReaper-PC has quit IRC | 00:30 | |
| *** shentey has quit IRC | 00:31 | |
| *** shentey has joined #maemo | 00:34 | |
| *** ddark has quit IRC | 00:36 | |
| *** okias has quit IRC | 00:37 | |
| *** okias has joined #maemo | 00:38 | |
| *** jrocha has quit IRC | 00:38 | |
| *** eMHa__ has quit IRC | 00:40 | |
| *** remarc has quit IRC | 00:40 | |
| *** remarc has joined #maemo | 00:41 | |
| *** ddark has joined #maemo | 00:42 | |
| *** lbt has quit IRC | 00:42 | |
| *** freemangordon has quit IRC | 00:42 | |
| *** amizraa has quit IRC | 00:43 | |
| *** amizraa has joined #maemo | 00:45 | |
| *** freemangordon has joined #maemo | 00:45 | |
| *** freemangordon has left #maemo | 00:45 | |
| *** freemangordon has joined #maemo | 00:46 | |
| *** ddark has quit IRC | 00:48 | |
| *** lbt has joined #maemo | 00:51 | |
| *** lbt has quit IRC | 00:51 | |
| *** lbt has joined #maemo | 00:51 | |
| *** ddark has joined #maemo | 00:56 | |
| *** louisdk has quit IRC | 01:15 | |
| *** ddark has quit IRC | 01:16 | |
| *** stroh has quit IRC | 01:18 | |
| *** strohalm has joined #maemo | 01:18 | |
| *** strohalm has joined #maemo | 01:18 | |
| *** florian has quit IRC | 01:22 | |
| *** remarc has quit IRC | 01:22 | |
| *** KhertanAtwork has quit IRC | 01:26 | |
| *** Khertan_Atwork has joined #maemo | 01:26 | |
| *** kolp has quit IRC | 01:34 | |
| *** eMHa__ has joined #maemo | 01:35 | |
| *** wotan147 has quit IRC | 01:50 | |
| *** erlehmann has joined #maemo | 01:54 | |
| *** erlehmann has quit IRC | 02:03 | |
| *** Ex-Opesa has quit IRC | 02:11 | |
| *** erlehmann has joined #maemo | 02:16 | |
| *** robbiethe1st has joined #maemo | 02:37 | |
| *** Ex-Opesa has joined #maemo | 02:38 | |
| *** xes has quit IRC | 02:43 | |
| *** bef0rd has joined #maemo | 02:52 | |
| *** lufu has quit IRC | 02:52 | |
| *** SmilyOrg has joined #maemo | 02:54 | |
| *** Smily has quit IRC | 02:57 | |
| *** dos1 has quit IRC | 02:58 | |
| *** RES401 has joined #maemo | 03:01 | |
| *** okias has quit IRC | 03:06 | |
| *** nox- has quit IRC | 03:08 | |
| *** Tekk__``` has joined #maemo | 03:20 | |
| *** Tekk__``` is now known as Tekk_ | 03:20 | |
| *** Smily has joined #maemo | 03:50 | |
| *** SmilyOrg has quit IRC | 03:52 | |
| *** RedM has joined #maemo | 04:35 | |
| *** RedW has quit IRC | 04:36 | |
| *** maybeHere has quit IRC | 04:38 | |
| *** maybeHere has joined #maemo | 04:38 | |
| *** LauRoman has joined #maemo | 04:40 | |
| *** erlehmann has quit IRC | 04:40 | |
| *** uen has quit IRC | 04:57 | |
| *** uen has joined #maemo | 04:59 | |
| *** silviof1 has joined #maemo | 05:01 | |
| *** silviof has quit IRC | 05:04 | |
| *** qwazix has quit IRC | 05:15 | |
| *** LauRoman has quit IRC | 05:16 | |
| *** qwazix has joined #maemo | 05:20 | |
| *** Milhouse has joined #maemo | 05:47 | |
| *** robbiethe1st has quit IRC | 06:23 | |
| *** raininja has quit IRC | 06:23 | |
| *** amizraa has quit IRC | 06:25 | |
| *** raijin has joined #maemo | 06:25 | |
| *** maybeWTF has joined #maemo | 06:30 | |
| *** amizraa has joined #maemo | 06:33 | |
| *** maybeHere has quit IRC | 06:33 | |
| *** LjL-Laplet has quit IRC | 06:38 | |
| *** erlehmann has joined #maemo | 06:39 | |
| *** LjL-Laplet2 has joined #maemo | 06:41 | |
| *** FlameReaper-PC has joined #maemo | 06:48 | |
| *** LjL-Laplet has joined #maemo | 06:58 | |
| *** LjL-Laplet2 has quit IRC | 07:01 | |
| *** LjL-Laplet has quit IRC | 07:02 | |
| *** protem has joined #maemo | 07:04 | |
| *** protem has joined #maemo | 07:04 | |
| *** mp_ has quit IRC | 07:07 | |
| *** pigeon has quit IRC | 07:13 | |
| *** erlehmann has quit IRC | 07:14 | |
| *** hxka has quit IRC | 07:14 | |
| *** erlehmann has joined #maemo | 07:15 | |
| DocScrutinizer05 | ~cauldron | 07:18 |
|---|---|---|
| DocScrutinizer05 | ~wiki cauldron | 07:18 |
| 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, ... | 07:18 |
| *** pigeon has joined #maemo | 07:25 | |
| *** erlehmann has quit IRC | 07:36 | |
| *** erlehmann has joined #maemo | 07:42 | |
| *** valeriusL has joined #maemo | 08:04 | |
| *** erlehmann has quit IRC | 08:17 | |
| *** jormungandr has joined #maemo | 08:23 | |
| *** japa-fi has quit IRC | 08:37 | |
| *** silviof1 is now known as silviof | 08:40 | |
| *** emma has quit IRC | 08:50 | |
| *** psycho_oreos has quit IRC | 08:51 | |
| *** psycho_oreos has joined #maemo | 08:54 | |
| *** emma has joined #maemo | 08:57 | |
| *** ced117 has joined #maemo | 09:05 | |
| *** freemangordon_ has joined #maemo | 09:23 | |
| *** freemangordon_ has quit IRC | 09:23 | |
| *** freemangordon_ has joined #maemo | 09:23 | |
| *** Titilambert has quit IRC | 09:36 | |
| Maxdamantus | add thereto a tiger's chaudron for the ingredients of our cauldron. | 09:37 |
| *** Luke-Jr has quit IRC | 09:48 | |
| DocScrutinizer05 | ~dict chaudron | 09:50 |
| 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]. | 09:51 |
| *** Luke-Jr has joined #maemo | 09:51 | |
| DocScrutinizer05 | the heck, wikipedia doesn't even know the words used to explain what's chaudron | 09:58 |
| DocScrutinizer05 | well, I know guts and intestine | 09:59 |
| DocScrutinizer05 | but wtf is kaldaunen, calduna, coluddyn, coludd ? | 10:00 |
| Maxdamantus | They're not words in common use. | 10:00 |
| DocScrutinizer05 | ooh, Kutteln | 10:02 |
| DocScrutinizer05 | seems a tiger doesn't have any those | 10:03 |
| DocScrutinizer05 | ruminant has rumen | 10:04 |
| Maxdamantus | Apparently that means tripe, which is basically intestines as a dish. | 10:06 |
| *** Luke-Jr has quit IRC | 10:06 | |
| Maxdamantus | usually lamb/mutton afaik | 10:07 |
| *** Luke-Jr has joined #maemo | 10:08 | |
| DocScrutinizer05 | http://en.wikipedia.org/wiki/Tripes yep | 10:09 |
| DocScrutinizer05 | http://en.wikipedia.org/wiki/Saure_Kutteln | 10:09 |
| Maxdamantus | Oh, no, it's the stomach, not intestines. | 10:09 |
| Maxdamantus | Maybe haggis is the intestines. | 10:09 |
| * Maxdamantus hasn't eaten either. | 10:10 | |
| DocScrutinizer05 | well, stomach is intestines as well in my book | 10:10 |
| Maxdamantus | intestines are below the stomach. | 10:10 |
| DocScrutinizer05 | me neither °°*°D-: | 10:10 |
| *** Guest98402 has joined #maemo | 10:12 | |
| DocScrutinizer05 | ooh, you're right. My idea of what are intestines been flawed | 10:12 |
| DocScrutinizer05 | seems Miriam Webster is also kinda mistaken on Kaldaunen then | 10:13 |
| 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. | 10:14 |
| DocScrutinizer05 | http://de.wikipedia.org/wiki/Kutteln | 10:14 |
| *** bef0rd has quit IRC | 10:14 | |
| DocScrutinizer05 | Guest98402: HDD? | 10:14 |
| *** bef0rd has joined #maemo | 10:15 | |
| Maxdamantus | Guest98402: mount that. | 10:15 |
| kerio | mass storage mode doesn't export a whole device | 10:15 |
| kerio | just a partition | 10:15 |
| Maxdamantus | Guest98402: it normally provides the single partition. | 10:15 |
| DocScrutinizer05 | when your uSD has no partitions then it will show as /dev/sdb and be so called superfloppy format | 10:16 |
| Maxdamantus | Guest98402: the whole device would include swap and /home, which is in use by Maemo, so you don't want to mount that. | 10:16 |
| DocScrutinizer05 | also what kerio said | 10:16 |
| kerio | i wonder if the exported swap partition is actually writeable | 10:16 |
| kerio | i never tried | 10:16 |
| kerio | for obvious reasons | 10:16 |
| Maxdamantus | it doesn't export it. | 10:18 |
| kerio | my swap partition is on the uSD | 10:18 |
| kerio | it's exported | 10:18 |
| Maxdamantus | Ah. | 10:18 |
| DocScrutinizer05 | hah! | 10:18 |
| Maxdamantus | Then sure, it would be. | 10:18 |
| kerio | isn't it locked or something like that? | 10:18 |
| kerio | i would expect the kernel to be quite strict with stuff like that | 10:19 |
| DocScrutinizer05 | I'd think it's hard to get exported and same time used by system | 10:19 |
| kerio | why's that? | 10:19 |
| kerio | the swap partition is a readable device file | 10:19 |
| kerio | i was wondering if it's writeable | 10:19 |
| *** bef0rd has quit IRC | 10:19 | |
| Maxdamantus | Hm. Linux (maybe POSIX, can't remember) has a mechanism to lock parts of files. | 10:19 |
| DocScrutinizer05 | and you had to think what for you want to mount it anyway | 10:19 |
| Maxdamantus | dunno if it works on devices. | 10:19 |
| DocScrutinizer05 | unless you wanna write to raw device | 10:20 |
| Maxdamantus | it shouldn't be hard to export it. | 10:20 |
| Maxdamantus | I'd be surprised if the OS refused to export the SD device while part is used as swap. | 10:21 |
| DocScrutinizer05 | I'd rather worry if system still can write to swap when it got exported | 10:21 |
| Maxdamantus | probably just unmounts /media/mmc* | 10:21 |
| DocScrutinizer05 | :nod: | 10:22 |
| Maxdamantus | It can. | 10:22 |
| Maxdamantus | neither using swap nor exporting with g_file_storage locks anything. | 10:22 |
| *** Luke-Jr has quit IRC | 10:23 | |
| DocScrutinizer05 | right | 10:23 |
| DocScrutinizer05 | kerio: so go ahead write some mp3 or wav data to swap, watch your N900 starting to sing and dance! ;-P | 10:23 |
| *** Luke-Jr has joined #maemo | 10:23 | |
| Maxdamantus | phones as mass storage devices is silly anyway. | 10:24 |
| DocScrutinizer05 | I'd honestly blacklist any swap partition from export | 10:24 |
| DocScrutinizer05 | I mean there's a reason why I pushed that blacklist into CSSU ;) | 10:24 |
| Maxdamantus | It's already powerful enough to run a filesystem server. | 10:24 |
| * Maxdamantus just loads g_ether on boot. | 10:25 | |
| DocScrutinizer05 | hey! | 10:25 |
| DocScrutinizer05 | H-E-N? | 10:25 |
| Maxdamantus | No. | 10:25 |
| Maxdamantus | it's the Linux kernel module that acts as an ethernet device. | 10:26 |
| DocScrutinizer05 | ooh, so the device pretends to be a NIC | 10:26 |
| Maxdamantus | Yes. | 10:26 |
| *** zGrr has joined #maemo | 10:26 | |
| kerio | phones as network cards is silly anyway. | 10:27 |
| Maxdamantus | Yes, but it's better than as block devices. | 10:27 |
| kerio | why isn't g_null the default behaviour anyway? | 10:27 |
| DocScrutinizer05 | well, unless you use the modem | 10:27 |
| DocScrutinizer05 | to actually access "the internet" | 10:27 |
| DocScrutinizer05 | which is best served via ethernet | 10:28 |
| DocScrutinizer05 | err network | 10:28 |
| Maxdamantus | wire | 10:28 |
| DocScrutinizer05 | yeah | 10:29 |
| DocScrutinizer05 | TCP/IP | 10:29 |
| * Maxdamantus uses it for rsync and for Bluetooth. | 10:29 | |
| DocScrutinizer05 | rsync? that's running via cronjob and WLAN here | 10:30 |
| Maxdamantus | rsync over ssh. | 10:30 |
| DocScrutinizer05 | real joy to read the cronjob's mails to root | 10:30 |
| Maxdamantus | just for one-off things, not periodic syncs/backups. | 10:30 |
| DocScrutinizer05 | ~jrtools | 10:31 |
| infobot | somebody said jrtools was http://wiki.maemo.org/User:Joerg_rw/tools | 10:31 |
| DocScrutinizer05 | actually http://wiki.maemo.org/User:Joerg_rw/tools#backup | 10:31 |
| DocScrutinizer05 | extremely convenient | 10:31 |
| kerio | offline backups are the one true way | 10:33 |
| DocScrutinizer05 | offline? | 10:33 |
| * DocScrutinizer05 idly wonders if somebody already pondered to create a striped raid from eMMC and uSD | 10:34 | |
| Guest98402 | Maxdamantus: DocScrutinizer05 yeah, I mean the regular 28GB partition | 10:35 |
| kerio | DocScrutinizer05: after a successful halt | 10:35 |
| DocScrutinizer05 | Guest98402: mount /dev/sdb /media -t vfat | 10:36 |
| Maxdamantus | I'm going to eventually run btrfs across the eMMC and SD. | 10:36 |
| DocScrutinizer05 | :-D | 10:36 |
| * Maxdamantus should get around to writing that alternative phone thing so he can stop using Maemo and use a newer kernel. | 10:37 | |
| Guest98402 | Thanks DocScrutinizer05 that worked | 10:37 |
| DocScrutinizer05 | yw :) | 10:37 |
| Guest98402 | I just wonder why pcmanfm and other file managers can't mount it themselves anymore, though | 10:37 |
| * Maxdamantus wrote most of a 9p implementation in Go with a better interface than the other 9p implementations. | 10:37 | |
| Guest98402 | That used to work without problems | 10:38 |
| DocScrutinizer05 | don't forget to sync and umount before you unplug! | 10:38 |
| *** florian has joined #maemo | 10:38 | |
| *** florian has quit IRC | 10:38 | |
| *** florian has joined #maemo | 10:38 | |
| Guest98402 | Is sync still necessary if you umount? | 10:38 |
| Maxdamantus | No. | 10:38 |
| DocScrutinizer05 | good question | 10:38 |
| DocScrutinizer05 | prolly not | 10:38 |
| Maxdamantus | assuming it is fully unmounted. | 10:39 |
| *** Guest98402 is now known as antithesis_ | 10:39 | |
| Maxdamantus | You can mount the same filesystem in different places. | 10:39 |
| Maxdamantus | so if you "unmount" one, it's not actually unmounted. | 10:39 |
| antithesis_ | Yeah, well, I won't do that | 10:39 |
| antithesis_ | What about the other way around? Can you sync, then unplug without umounting? | 10:39 |
| Maxdamantus | Depends on the filesystem. | 10:40 |
| *** japa-fi has joined #maemo | 10:40 | |
| antithesis_ | FAT filesystems | 10:40 |
| Maxdamantus | Should be fine. | 10:40 |
| Maxdamantus | as long as you don't write anything after the sync. | 10:41 |
| DocScrutinizer05 | dd if=image.bin of=/dev/sdc to flash a complete image to a uSD took >60s for sync. | 10:41 |
| kerio | answer = NO | 10:41 |
| DocScrutinizer05 | after dd finished | 10:41 |
| kerio | there's so much shit going on in a modern linux system | 10:41 |
| kerio | you can't be sure | 10:41 |
| DocScrutinizer05 | mount -o remount,ro /media | 10:42 |
| kerio | DocScrutinizer05: i would expect that to not necessarily sync | 10:42 |
| Maxdamantus | Yes, you can do that. | 10:42 |
| DocScrutinizer05 | sure it doesn't sync, but after sync you can be sure | 10:43 |
| Maxdamantus | It does necessarily sync. | 10:43 |
| DocScrutinizer05 | the device can't go r/o before all buffers got flushed | 10:43 |
| kerio | the mounted partition is going r/o | 10:44 |
| Maxdamantus | So the mount call hangs until that happens. | 10:44 |
| DocScrutinizer05 | dunno if it forces sync, or just idles and waits | 10:44 |
| DocScrutinizer05 | prolly should force | 10:45 |
| Maxdamantus | It wouldn't just idle and wait. | 10:45 |
| Maxdamantus | but imo, that's what sync should do. | 10:45 |
| Maxdamantus | It's not usually :( | 10:45 |
| DocScrutinizer05 | no, sync actively flushes the buffers | 10:46 |
| zGrr | moin :) | 10:46 |
| DocScrutinizer05 | moinmoin | 10:46 |
| *** HylianSavior has quit IRC | 10:46 | |
| Maxdamantus | Not really. | 10:47 |
| DocScrutinizer05 | sync takes no parameters afaik, and that sucks | 10:47 |
| Maxdamantus | The system will continuously be writing dirty stuff as long as there's stuff to write. | 10:47 |
| Maxdamantus | so sync/fsync means "wait until the writeback cache has passed the current moment in time" | 10:48 |
| Maxdamantus | but they usually additionally send some sort of commit to the filesystem. | 10:48 |
| DocScrutinizer05 | wut? there's a dirty-flush-timeout that's up to 1 minute on laptops etc | 10:49 |
| Maxdamantus | and fsync might actually prioritise things. | 10:49 |
| DocScrutinizer05 | I'd expect sync to "increase the pressure" | 10:49 |
| DocScrutinizer05 | sync(1) that is | 10:50 |
| Maxdamantus | Ah yeah, when the writeback cache isn't stressed. | 10:50 |
| antithesis_ | oshit what did I ignite | 10:50 |
| antithesis_ | still about sync | 10:50 |
| DocScrutinizer05 | echo 500 > /proc/sys/vm/dirty_expire_centisecs | 10:51 |
| DocScrutinizer05 | rcS | 10:52 |
| Maxdamantus | I think it should only be up to the computer operator to "increase the pressure". | 10:52 |
| Maxdamantus | so calls like fsync should be there for processes to know when the stuff they wrote has been written. | 10:53 |
| DocScrutinizer05 | which he did, by issueing a sync command | 10:53 |
| DocScrutinizer05 | I'm not talking about fsync(2) | 10:54 |
| *** valeriusL has quit IRC | 10:58 | |
| *** qwazix has quit IRC | 10:59 | |
| *** valeriusL has joined #maemo | 11:01 | |
| DocScrutinizer05 | anyway all info about sync, fsync and fdatasync seem to suggest that those function calls are kernel and executed immediately | 11:02 |
| DocScrutinizer05 | "the kernel flushes all buffers" | 11:02 |
| *** qwazix has joined #maemo | 11:04 | |
| Maxdamantus | Wonder if Linux provides a passive version of fsync. | 11:06 |
| Maxdamantus | If you only want to know when some data has been written. | 11:07 |
| DocScrutinizer05 | doesn't seem so. But I just learned that (f)sync even is supposed to flush drive cache | 11:07 |
| 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. | 11:08 |
| DocScrutinizer05 | >> This includes writing through or flushing a disk cache if present.<< | 11:08 |
| DocScrutinizer05 | yeah, there SHOULD be such function call | 11:09 |
| Maxdamantus | That should be what fsync itself does. | 11:09 |
| DocScrutinizer05 | no, fsync serves other purpose | 11:10 |
| Maxdamantus | Very little other, except in distributed systems. | 11:10 |
| Maxdamantus | where you want to tell peers that the data has been safely written, as quickly as possible. | 11:11 |
| DocScrutinizer05 | right, fsync is a bit... nonsensical for purposes of e.g. safe shutdown etc | 11:11 |
| DocScrutinizer05 | sync otoh | 11:11 |
| DocScrutinizer05 | generally speaking fsync makes sure your data is "safe" | 11:12 |
| Maxdamantus | I'd say generally speaking it doesn't. | 11:13 |
| Maxdamantus | It provides a way for you to make sure your data is safe. | 11:14 |
| DocScrutinizer05 | I guess there might be a option bit in write() to say "no buffering", then you do blocking write() and here you are | 11:14 |
| Maxdamantus | by letting programs know when a future revision of something has been completely written. | 11:14 |
| DocScrutinizer05 | ? | 11:15 |
| Maxdamantus | fsync doesn't actually provide a way to know that your data is safe. | 11:16 |
| Maxdamantus | a milisecond after fsync calls, someone else might've overwritten it. | 11:16 |
| DocScrutinizer05 | fsync (and fdatasync) says "write this now, I don't want to risk it getting lost on unadvertised brownout" | 11:16 |
| DocScrutinizer05 | and with your overwritten data you're really going weird now | 11:17 |
| Maxdamantus | So what do you do after the fsync? | 11:17 |
| DocScrutinizer05 | when somebody overwrites my file, well then my system is a pile of bullshot coded by monkeys | 11:18 |
| Maxdamantus | You shouldn't just fsync for the hell of it. | 11:18 |
| DocScrutinizer05 | let's see... what does mySQL do after fsync | 11:18 |
| Maxdamantus | It's going to be written eventually | 11:18 |
| DocScrutinizer05 | close the transaction maybe? | 11:18 |
| Maxdamantus | Non-distributed databases have a reason to do what I said fsync should do. | 11:19 |
| Maxdamantus | If they want to be able to guarantee database consistency, they need something like fsync. | 11:19 |
| DocScrutinizer05 | aha. and what is a commit in your book then? | 11:19 |
| Maxdamantus | but they don't need the "force it to write now" bit. | 11:19 |
| *** troulouliou_dev has joined #maemo | 11:20 | |
| DocScrutinizer05 | oh, they don't? | 11:20 |
| Maxdamantus | No. The "force it to write now" doesn't help in ensuring consistency. | 11:20 |
| DocScrutinizer05 | aha | 11:20 |
| Maxdamantus | The system could lose power during the fsync or before it. | 11:20 |
| DocScrutinizer05 | great | 11:20 |
| DocScrutinizer05 | so what? | 11:20 |
| DocScrutinizer05 | AFTER the fsync anyway I KNOW my data is on magenitzed bits on a disk | 11:21 |
| DocScrutinizer05 | so I return from commit() | 11:21 |
| Maxdamantus | Yes. That's what fsync should ensure. | 11:21 |
| Maxdamantus | It shouldn't try to force anything. | 11:22 |
| DocScrutinizer05 | aha | 11:22 |
| Maxdamantus | it should just wait until the data written beforehand is on the disk. | 11:22 |
| DocScrutinizer05 | tzz | 11:22 |
| DocScrutinizer05 | which may never happen | 11:22 |
| Maxdamantus | It will happen eventually, unless there's a hardware failure. | 11:23 |
| DocScrutinizer05 | no it won't | 11:23 |
| DocScrutinizer05 | not in any warranted finite timespan | 11:23 |
| Maxdamantus | Do you mean indefinite? | 11:24 |
| Maxdamantus | or infinite? | 11:24 |
| Maxdamantus | It will happen, eventually. | 11:24 |
| Maxdamantus | ie, within a finite amount of time. | 11:24 |
| DocScrutinizer05 | I mean system with echo 5000000000 > /proc/sys/vm/dirty_expire_centisecs | 11:24 |
| Maxdamantus | Then it will have to wait a while. | 11:25 |
| DocScrutinizer05 | I'd say THANKYOU to a db that takes 30min to return from a commit() | 11:25 |
| DocScrutinizer05 | I suggest you write your own kernel and libs | 11:26 |
| DocScrutinizer05 | since on unix or posix fsync won't do what you ask for | 11:26 |
| Maxdamantus | Unless it's part of a distributed system, the database shouldn't wait for the data to be on disk before returning. | 11:27 |
| DocScrutinizer05 | maybe some other call does | 11:27 |
| DocScrutinizer05 | AHA, you also need to write your own db then, see definition of "commit" | 11:27 |
| Maxdamantus | commit in databases usually has to do with atomicity afaik | 11:28 |
| DocScrutinizer05 | good luck with evaluating and certifying that critter | 11:28 |
| Maxdamantus | ie, you have a bunch of stuff in a commit, which either happens or doesn't. | 11:28 |
| freemangordon_ | hmm, isn't commit related to transactions, rather to io? | 11:28 |
| Maxdamantus | Yes. | 11:28 |
| Maxdamantus | (afaik) | 11:28 |
| DocScrutinizer05 | commit first and foremost has to do with rolling back atomic sequences of actions | 11:28 |
| Maxdamantus | Yes. | 11:28 |
| freemangordon_ | sure | 11:28 |
| Maxdamantus | which is what my use case of fsync is about. | 11:29 |
| freemangordon_ | but shouldn't be related to io | 11:29 |
| freemangordon_ | what db is that? | 11:29 |
| Maxdamantus | You don't need to wait for a filesystem fsync to return before claiming a commit has finished though. | 11:29 |
| freemangordon_ | exactly | 11:29 |
| DocScrutinizer05 | depends on your level of consistency you expect from the db | 11:30 |
| Maxdamantus | The point of the filesystem fsync is for there to always be a consistent (not corrupt) version of the DB accessible. | 11:30 |
| DocScrutinizer05 | when your commit returns before data got written to disk, it ISN'T committed yet | 11:30 |
| Maxdamantus | So you'll be able to roll back to some good copy after unexpected power loss. | 11:30 |
| freemangordon_ | DocScrutinizer05: it is | 11:30 |
| Maxdamantus | To do that, you need to make sure you haven't overwritten all good copies. | 11:31 |
| freemangordon_ | as your inserts/updates are in the journal | 11:31 |
| Maxdamantus | So you either need some WORM system, or something based on a passive fsync. | 11:31 |
| DocScrutinizer05 | freemangordon_: when system goes down after commit returns but before buffers flushed, you're fsckd | 11:31 |
| Maxdamantus | (with the WORM system, you'd additionally need the guarantee that writes are ordered) | 11:31 |
| antithesis_ | Okay, okay, I'll just use umount... | 11:32 |
| freemangordon_ | sure, and I've seen that | 11:32 |
| freemangordon_ | with oracle on solaris :) | 11:32 |
| DocScrutinizer05 | that's why I say "depends" | 11:32 |
| freemangordon_ | duplicated primary keys :D | 11:32 |
| freemangordon_ | but it is not db job to care about fs | 11:33 |
| freemangordon_ | because begin/end transaction, commit, etc is related to db, not to fs | 11:33 |
| freemangordon_ | anyway, back to my job :) | 11:34 |
| 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 | 11:34 |
| Maxdamantus | in Linux, it's ultimately up to the filesystem implementation to provide the semantics. | 11:35 |
| Maxdamantus | and it seems reasonable to offer different meanings as mount options. | 11:36 |
| Maxdamantus | I'd like to use btrfs without a log. | 11:36 |
| Maxdamantus | So if I lose power, I'll just lose up to 30s of activity. | 11:36 |
| Maxdamantus | I don't need to guarantee to other people that I've saved their data. | 11:37 |
| DocScrutinizer05 | whatever you like | 11:37 |
| DocScrutinizer05 | toldya, linux is FOSS, go and fork! | 11:38 |
| *** tanty_off is now known as tanty | 11:39 | |
| 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 | 11:39 |
| DocScrutinizer05 | man 2 fsync | 11:40 |
| Maxdamantus | Most proper uses of fsync would work with either semantics. | 11:41 |
| 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<< | 11:41 |
| Maxdamantus | I doubt a database is actually going to wait until the data is on disk before returning from a commit. | 11:41 |
| DocScrutinizer05 | not "waits until that happens, eventually" | 11:41 |
| Maxdamantus | That will just slow stuff down. | 11:41 |
| Maxdamantus | Unless you've configured the database to do it. | 11:41 |
| Maxdamantus | which might be useful in distributed systems. | 11:41 |
| DocScrutinizer05 | exactly ;) | 11:42 |
| DocScrutinizer05 | or in high security systems | 11:42 |
| DocScrutinizer05 | where a commit is a commit is a commit | 11:42 |
| 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" | 11:42 |
| DocScrutinizer05 | irrelevant, the transaction gets rolled back | 11:43 |
| Maxdamantus | Rolled back to what? | 11:43 |
| DocScrutinizer05 | to "money on account A" | 11:43 |
| Maxdamantus | How does it know where that is? | 11:44 |
| DocScrutinizer05 | *sigh* | 11:44 |
| Maxdamantus | What if the "money on account A" hadn't been commited to disk yet? | 11:44 |
| DocScrutinizer05 | eh? | 11:44 |
| DocScrutinizer05 | it *has* been, otherwise it wasn't on account A so nothing to move from A to B | 11:45 |
| Maxdamantus | If you make two transactions: B → A, A → C, there are three possible places for the money to be. | 11:46 |
| Maxdamantus | You have to roll back to the state you know is not corrupt. | 11:46 |
| DocScrutinizer05 | if you make two transactions, then they are atomic each and unentangled | 11:46 |
| Maxdamantus | not necessarily the one before the last. | 11:46 |
| DocScrutinizer05 | you can't do A->C before B->A got committed | 11:48 |
| Maxdamantus | You do it by keeping all states accessible, except for ones before the last one you know has been completed. | 11:48 |
| Maxdamantus | So if you know the money-in-A state has been completed, you can forget about the money-in-B state. | 11:48 |
| Maxdamantus | (completed as in: all information about that state is on disk) | 11:49 |
| DocScrutinizer05 | that's called "commit" | 11:49 |
| Maxdamantus | No. Commit doesn't have to ensure it's on disk. | 11:49 |
| DocScrutinizer05 | maybe in your world | 11:50 |
| Maxdamantus | Commit just has to ensure either none of it or all of it happens. | 11:50 |
| Maxdamantus | rather than half of it. | 11:50 |
| *** valeriusL has quit IRC | 11:50 | |
| DocScrutinizer05 | define 'happens' | 11:50 |
| *** eMHa__ has quit IRC | 11:50 | |
| Maxdamantus | is part of an accessible state. | 11:50 |
| *** valeriusL has joined #maemo | 11:51 | |
| DocScrutinizer05 | gibberish | 11:51 |
| Maxdamantus | Not gibberish. | 11:51 |
| Maxdamantus | The accessible states are the one the database is currently portraying and the ones it might roll back to after power loss. | 11:52 |
| DocScrutinizer05 | and how's that explaining what you meant by 'happens'? | 11:52 |
| Maxdamantus | You don't want an in-between state where half of the transaction has taken effect. | 11:52 |
| Maxdamantus | eg, in `A → C`, you don't want to accidentally roll back to a state where both A and C have the money | 11:53 |
| Maxdamantus | or where neither of them have the money. | 11:53 |
| 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 | 11:53 |
| DocScrutinizer05 | instead of got written into magnetic record of B | 11:54 |
| 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? | 11:54 |
| Maxdamantus | so the first write has taken effect, but the second hasn't. | 11:54 |
| DocScrutinizer05 | then the commit didn't complete | 11:55 |
| Maxdamantus | There's a magnetic record of A not having the money. | 11:55 |
| Maxdamantus | Obviously "having a magnetic record" isn't useful on its own. | 11:55 |
| DocScrutinizer05 | meh | 11:55 |
| DocScrutinizer05 | are we going to discuss how transactions and commits work now? | 11:56 |
| Maxdamantus | I'm pretty sure that's what we've been doing. | 11:56 |
| Maxdamantus | at least what I've been doing. | 11:56 |
| Maxdamantus | 20:46:24 < Maxdamantus> You have to roll back to the state you know is not corrupt. | 11:56 |
| 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. | 11:56 |
| DocScrutinizer05 | not on a beginner's level | 11:56 |
| Maxdamantus | So you don't actually overwrite anything about A's or C's money. | 11:57 |
| Maxdamantus | Because you need to make sure at least one consistent state is accessible. | 11:57 |
| DocScrutinizer05 | FILE A: ta:345, -5bucks; FILE B: ta:345, +5bucks; log: ta:345 committed | 11:58 |
| DocScrutinizer05 | rollback from right to left all you like | 11:58 |
| *** eMHa__ has joined #maemo | 11:59 | |
| Maxdamantus | If you're just appending to files, you don't need anything like sync. | 11:59 |
| DocScrutinizer05 | aha | 11:59 |
| *** robink has quit IRC | 11:59 | |
| Maxdamantus | You just need a guarantee of ordered writes. | 11:59 |
| DocScrutinizer05 | you're aware HDD work with sectors and blocks and such shite? They even spin | 12:00 |
| 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. | 12:00 |
| Maxdamantus | A journal can give you ordered writes. | 12:00 |
| Maxdamantus | You only need the metadata to be ordered in this case. | 12:01 |
| DocScrutinizer05 | and in-order write for everything will give you a db that's blatantly useless regarding performance. Possibly even runs into deadlocks | 12:01 |
| *** robink has joined #maemo | 12:02 | |
| Maxdamantus | Why would you run into deadlocks? | 12:02 |
| DocScrutinizer05 | and it doesn't matter if you fsync your data or your journal | 12:02 |
| DocScrutinizer05 | you need to fsync *something* anyway | 12:03 |
| Maxdamantus | You don't need to. You just need ordered metadata writes. | 12:04 |
| Maxdamantus | if you're only appending. | 12:04 |
| Maxdamantus | the fsync is useful for knowing what you can overwrite. | 12:04 |
| DocScrutinizer05 | I'm afk | 12:05 |
| DocScrutinizer05 | this leads nowhere anyway | 12:05 |
| DocScrutinizer05 | particularly since I'm no db developer, I just use them every now and then | 12:06 |
| DocScrutinizer05 | e.g to move your money to and from your bank account | 12:07 |
| DocScrutinizer05 | and i'd not be surprised if COBOL commit definition actually requires data to get written to HDD | 12:08 |
| *** valeriusL has quit IRC | 12:08 | |
| *** antithesis_ has quit IRC | 12:08 | |
| DocScrutinizer05 | afk now | 12:09 |
| 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 | 12:19 |
| *** valeriusL has joined #maemo | 12:20 | |
| 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 | 12:22 |
| DocScrutinizer05 | you can't sit on a frankenstein-fsync and wait for buffers to eventually get flushed | 12:25 |
| DocScrutinizer05 | in 5 minutes | 12:25 |
| 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 | 12:34 |
| *** jormungandr has quit IRC | 12:54 | |
| Maxdamantus | Yes. That's an example of a distributed system. | 12:57 |
| Maxdamantus | You have to tell someone else that the commit is permanent, and optimially as quickly as possible. | 12:57 |
| Maxdamantus | (you wouldn't want to wait a minute for the data to be flushed before responding to an ATM request) | 12:58 |
| Maxdamantus | When the ATM server dies, the customer doesn't. | 12:58 |
| *** Psi_ has joined #maemo | 13:05 | |
| *** jormungandr has joined #maemo | 13:05 | |
| *** Psi has quit IRC | 13:09 | |
| *** Milhouse has quit IRC | 13:28 | |
| *** Natch_j has joined #maemo | 13:48 | |
| *** otep_ has joined #maemo | 13:48 | |
| *** dromer has joined #maemo | 13:51 | |
| *** g3kk3r_ has joined #maemo | 13:51 | |
| *** fil_ has joined #maemo | 13:51 | |
| *** Natch has quit IRC | 13:55 | |
| *** Ex-Opesa has quit IRC | 13:55 | |
| *** vakko__ has quit IRC | 13:55 | |
| *** mickname has quit IRC | 13:55 | |
| *** fil has quit IRC | 13:55 | |
| *** g3kk3r has quit IRC | 13:55 | |
| *** warfare has quit IRC | 13:55 | |
| *** dreamer has quit IRC | 13:55 | |
| *** otep has quit IRC | 13:55 | |
| *** vakko__ has joined #maemo | 13:56 | |
| *** warfare has joined #maemo | 13:56 | |
| *** mickname has joined #maemo | 13:57 | |
| *** auenf has joined #maemo | 14:02 | |
| *** ALoGeNo has quit IRC | 14:04 | |
| *** g3kk3r has joined #maemo | 14:04 | |
| *** ALoGeNo has joined #maemo | 14:04 | |
| *** ecc2g has joined #maemo | 14:07 | |
| *** t3st3r has joined #maemo | 14:10 | |
| *** g3kk3r_ has quit IRC | 14:23 | |
| *** protem has quit IRC | 14:23 | |
| *** auenfx4 has quit IRC | 14:23 | |
| *** ecc3g has quit IRC | 14:23 | |
| *** LjL has quit IRC | 14:23 | |
| *** AndrewX192 has quit IRC | 14:23 | |
| *** ds3 has quit IRC | 14:23 | |
| *** hxka has joined #maemo | 14:25 | |
| *** dromer is now known as dreamer | 14:28 | |
| *** okias has joined #maemo | 14:34 | |
| *** ds3 has joined #maemo | 14:40 | |
| *** ddark has joined #maemo | 14:42 | |
| *** erlehmann has joined #maemo | 14:45 | |
| *** protem has joined #maemo | 14:48 | |
| *** LjL has joined #maemo | 14:48 | |
| *** AndrewX192 has joined #maemo | 14:48 | |
| *** darkschneider has quit IRC | 14:48 | |
| *** darkschneider has joined #maemo | 14:49 | |
| *** emma has quit IRC | 14:54 | |
| *** RES401 has quit IRC | 15:04 | |
| *** b-p has quit IRC | 15:04 | |
| *** mkaindl has quit IRC | 15:04 | |
| *** Trizt has quit IRC | 15:04 | |
| *** guerby has quit IRC | 15:04 | |
| *** HRH_H_Cr1b has quit IRC | 15:04 | |
| *** realitygaps has quit IRC | 15:04 | |
| *** ketas has quit IRC | 15:04 | |
| *** merlin1991 has quit IRC | 15:04 | |
| *** maybeWTF has quit IRC | 15:05 | |
| *** RES401 has joined #maemo | 15:18 | |
| *** b-p has joined #maemo | 15:18 | |
| *** mkaindl has joined #maemo | 15:18 | |
| *** Trizt has joined #maemo | 15:18 | |
| *** guerby has joined #maemo | 15:18 | |
| *** HRH_H_Cr1b has joined #maemo | 15:18 | |
| *** realitygaps has joined #maemo | 15:18 | |
| *** ketas has joined #maemo | 15:18 | |
| *** merlin1991 has joined #maemo | 15:18 | |
| *** ketas has quit IRC | 15:19 | |
| *** ketas has joined #maemo | 15:19 | |
| *** LjL-Laplet has joined #maemo | 15:23 | |
| *** LauRoman has joined #maemo | 15:31 | |
| *** ALoGeNo has quit IRC | 15:41 | |
| *** hxka has quit IRC | 15:42 | |
| *** kolp has joined #maemo | 15:49 | |
| *** ALoGeNo has joined #maemo | 15:55 | |
| *** lizardo has joined #maemo | 16:11 | |
| *** Natch_j is now known as Natch | 16:12 | |
| *** LauRoman|Laptop has joined #maemo | 16:17 | |
| *** goldkatze has quit IRC | 16:20 | |
| *** remarc has joined #maemo | 16:23 | |
| *** remarc has quit IRC | 16:23 | |
| *** remarc has joined #maemo | 16:23 | |
| *** troulouliou_dev has quit IRC | 16:27 | |
| *** LjL-Laplet has quit IRC | 16:37 | |
| *** troulouliou_dev has joined #maemo | 16:40 | |
| *** jormungandr has quit IRC | 17:13 | |
| *** LjL-Laplet2 has joined #maemo | 17:20 | |
| *** LjL-Laplet2 is now known as LjL-Laplet | 17:25 | |
| *** jormungandr has joined #maemo | 17:30 | |
| *** VDVsx has quit IRC | 17:31 | |
| *** jormungandr has quit IRC | 17:34 | |
| *** janemba has quit IRC | 17:57 | |
| *** janemba has joined #maemo | 17:57 | |
| *** okias has quit IRC | 17:57 | |
| *** VDVsx has joined #maemo | 17:58 | |
| *** geaaru has joined #maemo | 18:06 | |
| *** edheldil has quit IRC | 18:23 | |
| *** valeriusL has quit IRC | 18:25 | |
| *** wotan147 has joined #maemo | 18:42 | |
| *** valeriusL has joined #maemo | 18:42 | |
| *** okias has joined #maemo | 18:44 | |
| *** okias has quit IRC | 18:51 | |
| *** zGrr has quit IRC | 18:56 | |
| *** RiD has joined #maemo | 19:01 | |
| *** okias has joined #maemo | 19:03 | |
| *** okias has quit IRC | 19:05 | |
| *** drathir has quit IRC | 19:05 | |
| *** mp__ has joined #maemo | 19:07 | |
| *** okias has joined #maemo | 19:07 | |
| 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 | 19:08 |
| DocScrutinizer05 | and GPS had not been used for at least 2 weeks before | 19:08 |
| DocScrutinizer05 | AGPS, supl.google.com | 19:10 |
| DocScrutinizer05 | SIM activated, WLAN for internet access | 19:11 |
| bencoh | I thought supl.google didnt work anywore | 19:11 |
| DocScrutinizer05 | O2-Germany | 19:11 |
| bencoh | anymore* | 19:11 |
| DocScrutinizer05 | *shrug* | 19:11 |
| bencoh | (my mobile operator provides me a supl anyway) | 19:11 |
| DocScrutinizer05 | possibly it doesn't need any supl, since usually the assistance is via WWAN | 19:12 |
| bencoh | WWAN ? | 19:12 |
| DocScrutinizer05 | 2/3G | 19:12 |
| DocScrutinizer05 | ~wwan | 19:12 |
| DocScrutinizer05 | o.O | 19:12 |
| DocScrutinizer05 | anyway | 19:12 |
| DocScrutinizer05 | ~gsm-agps | 19:13 |
| 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 | 19:13 |
| bencoh | hmm, can the n900 use something else than supl for that ? | 19:13 |
| DocScrutinizer05 | ^^^ | 19:13 |
| DocScrutinizer05 | http://en.wikipedia.org/wiki/RRLP | 19:13 |
| *** okias has quit IRC | 19:14 | |
| bencoh | right but that doesn't give infos needed for gps stuff | 19:14 |
| DocScrutinizer05 | prolly 3G helps a lot, via E-OTD | 19:14 |
| bencoh | (ephemerids and all) | 19:14 |
| bencoh | or does it ? | 19:14 |
| DocScrutinizer05 | rrlp does | 19:14 |
| DocScrutinizer05 | it's basically supl via wwan | 19:15 |
| DocScrutinizer05 | well, part of it is | 19:15 |
| bencoh | oh, okay | 19:15 |
| bencoh | interesting | 19:15 |
| DocScrutinizer05 | there's a system and a user layer iirc | 19:15 |
| DocScrutinizer05 | and on 3G there's E-OTD | 19:15 |
| DocScrutinizer05 | which isn't specified as giving feedback to MS | 19:16 |
| bencoh | the MS-assisted GPS part I guess ? | 19:16 |
| DocScrutinizer05 | but also nobody says it mustn't | 19:16 |
| DocScrutinizer05 | aiui E-OTD has no MS-based mode | 19:17 |
| DocScrutinizer05 | the enodeb doesn't share sufficient info to MS to do that on-board | 19:18 |
| DocScrutinizer05 | but enodeb could return the result of E-OTD to MS | 19:18 |
| *** drathir has joined #maemo | 19:19 | |
| DocScrutinizer05 | NB that for GSM/2G there's no such thing like E-OTD | 19:20 |
| bencoh | no E-OTD for me then :) | 19:21 |
| DocScrutinizer05 | at least not in specs. Carriers could do passive (from MS POV) OTD triangulation, when they add special equipment to BTS | 19:21 |
| DocScrutinizer05 | passive OTD would mean: make MS send any arbitrary thing, check timing difference as seen by receivers of at least 3 BTS | 19:22 |
| 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 | 19:23 |
| bencoh | hmm | 19:24 |
| DocScrutinizer05 | it's unclear which providers equipped how many of their BTS with such additional gear | 19:24 |
| DocScrutinizer05 | anyway GPS based RRLP is defined also for 2G | 19:27 |
| DocScrutinizer05 | afaik | 19:27 |
| DocScrutinizer05 | yep, wiki clearly states it | 19:27 |
| DocScrutinizer05 | >>Radio resource location services (LCS) protocol (RRLP) applies to GSM and UMTS Cellular Networks<< | 19:28 |
| bencoh | good to know | 19:29 |
| bencoh | doesn't that mean supl should be useless then ? | 19:30 |
| *** Pilke has joined #maemo | 19:31 | |
| *** Lumocolor has quit IRC | 19:35 | |
| DocScrutinizer05 | well, as long as your carrier provides it via RRLP it actually might be useless | 19:38 |
| DocScrutinizer05 | NB the N900 GPS is controlled by modem, not by main CPU | 19:39 |
| bencoh | I should test it some time | 19:39 |
| bencoh | yeah I know | 19:39 |
| DocScrutinizer05 | RRLP is the reason for that | 19:39 |
| bencoh | btw how does main cpu feeds the gps with supl results ? | 19:40 |
| DocScrutinizer05 | a god question | 19:40 |
| DocScrutinizer05 | good | 19:40 |
| bencoh | that goes with all the gps-related secrets ? | 19:41 |
| 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 | 19:41 |
| DocScrutinizer05 | see the *closed-blob* mini tool Nokia provided for clearing position cache | 19:42 |
| bencoh | you mean ssi-encapsulated AT commands ? | 19:42 |
| bencoh | (ssi/hsi) | 19:43 |
| DocScrutinizer05 | for debugging purposes when we had that GPS-doesn't-get-fix issue | 19:43 |
| DocScrutinizer05 | I don't think ISI protocol is anything like "AT encapsulated into whatever" | 19:43 |
| *** LjL-Laplet has quit IRC | 19:43 | |
| DocScrutinizer05 | it's more like tcp/ip | 19:44 |
| DocScrutinizer05 | with slots/ports for certain services | 19:44 |
| bencoh | yeah I got confused, misread "there are some (usually proprietary) AT commands (or in case of BB5 modem: ISI messages) | 19:44 |
| DocScrutinizer05 | we got pnatd to convert AT to ISI | 19:45 |
| *** dos1 has joined #maemo | 19: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 | 19:46 |
| DocScrutinizer05 | prolly BB5 runs an AT-interpreter service of some sorts, on some slot/port | 19:47 |
| DocScrutinizer05 | but that's not the recommended and usual way to communicate with ISI modem | 19:47 |
| DocScrutinizer05 | disclaimer: all AIUI/AFAIK | 19:48 |
| *** Lumocolor has joined #maemo | 19:48 | |
| DocScrutinizer05 | anyway I'm pretty convinced that BB5 does E-OTD on 3G | 19:49 |
| DocScrutinizer05 | I could't think of any other explanation for a stable fix after <5s | 19:49 |
| DocScrutinizer05 | *indoors* even | 19: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 | 19:51 |
| DocScrutinizer05 | so odds are O2 has a vital interest in running RRLP/E-OTD | 19:52 |
| *** Gatta_Negra has quit IRC | 19:52 | |
| *** Gatta_Negra has joined #maemo | 19:52 | |
| DocScrutinizer05 | I could even figure they do a E-OTD by default, each time a communication with MS happens | 19:53 |
| *** erlehmann has quit IRC | 20:20 | |
| *** erlehmann has joined #maemo | 20:21 | |
| *** HylianSavior has joined #maemo | 20:25 | |
| *** protem has quit IRC | 20:28 | |
| 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 | 20:38 |
| *** geaaru has quit IRC | 20:40 | |
| bencoh | I suspect sfr (france) doesn't either but I'm not sure about it | 20:40 |
| *** wotan147 has quit IRC | 20:40 | |
| *** troulouliou_dev has quit IRC | 20:40 | |
| *** maybeHere has joined #maemo | 20:45 | |
| *** ZogG_laptop has joined #maemo | 20:47 | |
| *** ZogG_laptop has quit IRC | 20:47 | |
| *** ZogG_laptop has joined #maemo | 20:47 | |
| *** florian has quit IRC | 20:49 | |
| DocScrutinizer05 | wow, seems that's a nice new virtual provider: https://www.simquadrat.de/produkte/roaming | 20:51 |
| DocScrutinizer05 | and they leaked a interesting info there: they call theri own network "sipgate netz" ;-) | 20:52 |
| DocScrutinizer05 | sipgate is a great SIP-VoIP provider I'm using since err 14 years? | 20:53 |
| DocScrutinizer05 | seems now they go GSM/UMTS | 20:53 |
| DocScrutinizer05 | ok, 9 years, not 14 | 20:55 |
| *** Pilke has quit IRC | 20:59 | |
| *** ccxN has joined #maemo | 21:00 | |
| *** ccxN has left #maemo | 21:02 | |
| 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 | 21:04 |
| DocScrutinizer05 | and Germany-wide geo-number/landline-number | 21:04 |
| DocScrutinizer05 | that's awesome and pretty much in line with what Sipgate offers for VoIP | 21:05 |
| *** sq-one has joined #maemo | 21:07 | |
| 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 | 21:08 |
| DocScrutinizer05 | as well as in GB | 21:09 |
| DocScrutinizer05 | dunno about norway - either they hate it or they *want* it | 21:09 |
| DocScrutinizer05 | in Germany afaik government can't enforce it | 21:10 |
| *** auenf has quit IRC | 21:10 | |
| DocScrutinizer05 | so if O2 or other carriers do RRLP here, I'd guess they do it for location awareness of their customers' iPhone apps | 21:11 |
| *** auenf has joined #maemo | 21:11 | |
| *** jrocha has joined #maemo | 21:11 | |
| DocScrutinizer05 | and obviously it works like a charm - I mean 5s TTFF, really? | 21:11 |
| *** cpt_nemo has quit IRC | 21:12 | |
| *** raijin has quit IRC | 21:12 | |
| bencoh | DocScrutinizer05: true | 21:12 |
| * DocScrutinizer05 switches to 2G ... | 21:13 | |
| *** eMHa has joined #maemo | 21:15 | |
| *** eMHa__ has quit IRC | 21:15 | |
| *** LjL-Laplet has joined #maemo | 21:15 | |
| *** valeriusL has quit IRC | 21:15 | |
| *** LjL-Laplet has quit IRC | 21:15 | |
| *** LjL-Laplet has joined #maemo | 21:15 | |
| DocScrutinizer05 | AHA! 50s till first feeble 3sat fix | 21:16 |
| *** raijin has joined #maemo | 21:17 | |
| *** florian has joined #maemo | 21:17 | |
| *** florian has joined #maemo | 21:17 | |
| *** cpt_nemo has joined #maemo | 21:18 | |
| 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 | 21:19 |
| DocScrutinizer05 | absolutely obviously only 3G O2 provides data for MS-based GPS assistance | 21:21 |
| 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 | 21:23 |
| *** _rd has joined #maemo | 21:25 | |
| 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.<< | 21:26 |
| *** goldkatze has joined #maemo | 21:26 | |
| bencoh | hmm | 21:26 |
| *** uen has left #maemo | 21:27 | |
| *** mp__ has quit IRC | 21:30 | |
| kerio | 8 seconds for me :c | 21:30 |
| DocScrutinizer05 | 8s still is great, no? | 21:33 |
| kerio | yeah yeah | 21:33 |
| DocScrutinizer05 | I think the theoretical minimum on GPS are 14s | 21:33 |
| DocScrutinizer05 | honestly GPS kinda starts becoming a niche technology and obsolete for everyday usage | 21:35 |
| kerio | wait what | 21:35 |
| kerio | you mean "pure" gps, right | 21:35 |
| DocScrutinizer05 | yeah, obviously | 21:36 |
| 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 | 21:37 |
| kerio | agps is great if you have it | 21:38 |
| DocScrutinizer05 | while it's augmented and assisted by RRLP, it's still GPS | 21:38 |
| 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 | 21:40 |
| DocScrutinizer05 | SUPL never could do this | 21:40 |
| *** LjL-Laplet has quit IRC | 21:40 | |
| kerio | why is there even a skew? | 21:41 |
| DocScrutinizer05 | huh? | 21:41 |
| DocScrutinizer05 | why are two unrelated signals not in sync everywhere on this globe? | 21:41 |
| kerio | yes! | 21:41 |
| kerio | (i see) | 21:41 |
| kerio | (stupid relativity) | 21:41 |
| DocScrutinizer05 | rather unrelativity | 21:42 |
| DocScrutinizer05 | ;-P | 21:42 |
| 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 | 21:43 |
| bencoh | well, didnt get a fix in a minute from the window (2G/operator supl) | 21:43 |
| bencoh | weather might not help though | 21:44 |
| kerio | raw gps is still useful if you're somewhere with no internets and no clock | 21:44 |
| DocScrutinizer05 | yes, sure | 21:44 |
| bencoh | yup, getting a position in 12mn is better than nothing | 21:44 |
| kerio | it's also useful if you never lose the fix | 21:44 |
| kerio | :D | 21:44 |
| 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 | 21:46 |
| kerio | every 20 minutes is 20 minutes too often | 21:46 |
| bencoh | yup | 21:46 |
| bencoh | and yup :) | 21:46 |
| DocScrutinizer05 | well, either you need GPS or you don't ;-) | 21:46 |
| kerio | isn't there a way to get an offline supl? | 21:46 |
| kerio | assuming a good clock | 21:47 |
| DocScrutinizer05 | how's that supposed to work? | 21:47 |
| bencoh | you mean, computing eph ? | 21:47 |
| kerio | read clock, do calculations to figure out which satellites should be visible | 21:47 |
| DocScrutinizer05 | eph is hard to compute, or pretty poor accuracy | 21:47 |
| DocScrutinizer05 | that's alm | 21:47 |
| kerio | what's eph? | 21:48 |
| DocScrutinizer05 | eph takes into account the local errors in what you would expect according to alm | 21:48 |
| kerio | "local"? | 21:48 |
| bencoh | ephemeris | 21:48 |
| bencoh | and almanacs should stay valid for a day anyway | 21:49 |
| DocScrutinizer05 | weeks | 21:49 |
| bencoh | hmm is it all transmitted ? | 21:50 |
| DocScrutinizer05 | http://www.colorado.edu/geography/gcraft/notes/gps/gps_f.html | 21:51 |
| DocScrutinizer05 | http://www.colorado.edu/geography/gcraft/notes/gps/gps.html#SVData | 21:53 |
| DocScrutinizer05 | bencoh: so yes, all is transmitted in 12.5min | 21:56 |
| DocScrutinizer05 | and then stored to N900's data cache | 21:57 |
| DocScrutinizer05 | so one uninterrupted 13min GPS session per week should suffice | 21:58 |
| DocScrutinizer05 | even when you don't have any SUPL or whatever | 21:58 |
| kerio | what about devices that don't have enough space? | 21:58 |
| DocScrutinizer05 | those devices don't exist, kerio | 21:58 |
| kerio | how much data is that? | 21:58 |
| DocScrutinizer05 | calculate it! the data is there on http://www.colorado.edu/geography/gcraft/notes/gps/gps_f.html | 21:59 |
| kerio | :c | 21:59 |
| DocScrutinizer05 | Data frames (1500 bits) are sent every thirty seconds | 21:59 |
| kerio | 30000 bits! | 22:00 |
| kerio | it's 3.66KB | 22:00 |
| 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. | 22:00 |
| kerio | anyway, make that 25 minutes | 22:01 |
| kerio | to get the data at least twice | 22:01 |
| DocScrutinizer05 | only when you use a particularly stupid algo | 22:01 |
| kerio | i doubt that there's strong error correction | 22:01 |
| DocScrutinizer05 | or have dropouts | 22:01 |
| DocScrutinizer05 | there are parity bits, a few of them | 22:02 |
| DocScrutinizer05 | but yeah, you shouldn't have any significant dropouts | 22:02 |
| DocScrutinizer05 | I guess >1s is a sure killer | 22:03 |
| DocScrutinizer05 | >>Data bit subframes (300 bits transmitted over six seconds) contain parity bits that allow for data checking and limited error correction.<< | 22:04 |
| DocScrutinizer05 | http://www.colorado.edu/geography/gcraft/notes/gps/gif/databits.gif | 22:05 |
| *** shentey has joined #maemo | 22:06 | |
| *** totalizator has quit IRC | 22:08 | |
| *** _rd has quit IRC | 22:09 | |
| 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 | 22:13 |
| *** totalizator has joined #maemo | 22:13 | |
| 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 | 22:14 |
| DocScrutinizer05 | assistance helps reduce number of patterns to feed to correlator to spot the SAT | 22:15 |
| *** shentey has quit IRC | 22:16 | |
| DocScrutinizer05 | modern chips have many of those correlators | 22:16 |
| *** shentey has joined #maemo | 22:19 | |
| DocScrutinizer05 | ultra-high sensitivity receivers work by extending the time of comparing the patterns, often up to a minute or more | 22:19 |
| *** dhbiker has quit IRC | 22:20 | |
| kerio | mh, so they actually take longer to get a fix? | 22:20 |
| *** lxp has joined #maemo | 22:21 | |
| DocScrutinizer05 | sure | 22:23 |
| *** dhbiker has joined #maemo | 22:23 | |
| DocScrutinizer05 | they still may get a fix after 1min, when other standard receivers already failed | 22:24 |
| DocScrutinizer05 | on a good signal they are no slower than a standard chip | 22:24 |
| *** lxp has quit IRC | 22:25 | |
| kerio | i see | 22:27 |
| DocScrutinizer05 | those chips probably need magnitudes more storage and possibly also more computational grunt to accomplish the task | 22:28 |
| DocScrutinizer05 | s/storage/memory aka RAM/ | 22:29 |
| infobot | DocScrutinizer05 meant: those chips probably need magnitudes more memory aka RAM and possibly also more computational grunt to accomplish the task | 22:29 |
| DocScrutinizer05 | afk, cya in 2 days | 22:32 |
| RiD | looks like vacations! | 22:34 |
| *** _rd has joined #maemo | 22:36 | |
| *** troulouliou_dev has joined #maemo | 22:41 | |
| *** troulouliou_dev has quit IRC | 22:45 | |
| *** valeriusL has joined #maemo | 22:49 | |
| *** Cor-Ai has quit IRC | 22:55 | |
| *** Cor-Ai has joined #maemo | 22:55 | |
| *** Cor-Ai has quit IRC | 23:00 | |
| *** shentey has quit IRC | 23:01 | |
| *** shentey_ has joined #maemo | 23:01 | |
| *** Cor-Ai has joined #maemo | 23:05 | |
| *** qwazix_ has joined #maemo | 23:10 | |
| *** valeriusL has quit IRC | 23:14 | |
| *** qwazix_ has quit IRC | 23:16 | |
| *** wotan147 has joined #maemo | 23:23 | |
| *** lxp has joined #maemo | 23:25 | |
| *** valeriusL has joined #maemo | 23:28 | |
| *** LjL-Laplet has joined #maemo | 23:29 | |
| *** jrocha has quit IRC | 23:32 | |
| *** florian has quit IRC | 23:34 | |
| *** till has quit IRC | 23:37 | |
| *** shentey_ has quit IRC | 23:41 | |
| *** _rd has quit IRC | 23:46 | |
| *** sq-one has quit IRC | 23:59 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!
