| 00:01.47 | *** join/#maemo RES401 (Elite9109@gateway/shell/elitebnc/x-omnjyedtedlswbwf) |
| 00:20.16 | *** join/#maemo Tekk__``` (~user@cpe-071-077-204-016.ec.res.rr.com) |
| 00:50.06 | *** join/#maemo Smily (Smily@BSN-61-5-189.dial-up.dsl.siol.net) |
| 01:35.58 | *** join/#maemo RedM (~redw@89-73-179-171.dynamic.chello.pl) |
| 01:38.18 | *** join/#maemo maybeHere (~cl@p5790F08D.dip0.t-ipconnect.de) |
| 01:40.02 | *** join/#maemo LauRoman (~LauRoman@5-14-195-26.residential.rdsnet.ro) |
| 01:59.33 | *** join/#maemo uen (~uen@p5084058B.dip0.t-ipconnect.de) |
| 02:01.54 | *** join/#maemo silviof1 (~silviof@unaffiliated/silviof) |
| 02:20.22 | *** join/#maemo qwazix (~qwazix@Maemo/community/council/qwazix) |
| 02:47.27 | *** join/#maemo Milhouse (~Milhouse@Maemo/community/contributor/Milhouse) |
| 03:25.39 | *** join/#maemo raijin (~raininja@unaffiliated/raijin) |
| 03:30.49 | *** join/#maemo maybeWTF (~cl@p5790F40B.dip0.t-ipconnect.de) |
| 03:33.04 | *** join/#maemo amizraa (~amizraa@gateway/tor-sasl/amizraa) |
| 03:39.25 | *** join/#maemo erlehmann (~erlehmann@82.113.121.32) |
| 03:41.33 | *** join/#maemo LjL-Laplet2 (~ljl@93-32-49-69.ip32.fastwebnet.it) |
| 03:48.25 | *** join/#maemo FlameReaper-PC (~FR@110.159.111.75) |
| 03:58.16 | *** join/#maemo LjL-Laplet (~ljl@93-32-49-69.ip32.fastwebnet.it) |
| 04:04.22 | *** join/#maemo protem (~protem@ks3100918.kimsufi.com) |
| 04:04.23 | *** join/#maemo protem (~protem@unaffiliated/protem) |
| 04:15.56 | *** join/#maemo erlehmann (~erlehmann@82.113.121.32) |
| 04:18.40 | DocScrutinizer05 | ~cauldron |
| 04:18.52 | DocScrutinizer05 | ~wiki cauldron |
| 04:25.36 | *** join/#maemo pigeon (~pigeon@eth5284.nsw.adsl.internode.on.net) |
| 04:42.42 | *** join/#maemo erlehmann (~erlehmann@82.113.121.32) |
| 05:04.07 | *** join/#maemo valeriusL (~valerius@85.26.180.169) |
| 05:23.49 | *** join/#maemo jormungandr (~xxx@213.23.120.114) |
| 05:54.49 | *** join/#maemo psycho_oreos (~no@unaffiliated/tuxsavvy) |
| 05:57.29 | *** join/#maemo emma (~em@unaffiliated/emma) |
| 06:05.34 | *** join/#maemo ced117 (~ced117@opensuse/member/ced117) |
| 06:23.04 | *** join/#maemo freemangordon_ (~ivo@printec.bg) |
| 06:23.29 | *** join/#maemo freemangordon_ (~ivo@printec.bg) |
| 06:37.48 | Maxdamantus | add thereto a tiger's chaudron for the ingredients of our cauldron. |
| 06:50.58 | DocScrutinizer05 | ~dict chaudron |
| 06:51.19 | *** join/#maemo Luke-Jr (~luke-jr@unaffiliated/luke-jr) |
| 06:58.20 | DocScrutinizer05 | the heck, wikipedia doesn't even know the words used to explain what's chaudron |
| 06:59.25 | DocScrutinizer05 | well, I know guts and intestine |
| 07:00.11 | DocScrutinizer05 | but wtf is kaldaunen, calduna, coluddyn, coludd ? |
| 07:00.33 | Maxdamantus | They're not words in common use. |
| 07:02.19 | DocScrutinizer05 | ooh, Kutteln |
| 07:03.27 | DocScrutinizer05 | seems a tiger doesn't have any those |
| 07:04.16 | DocScrutinizer05 | ruminant has rumen |
| 07:06.49 | Maxdamantus | Apparently that means tripe, which is basically intestines as a dish. |
| 07:07.20 | Maxdamantus | usually lamb/mutton afaik |
| 07:08.03 | *** join/#maemo Luke-Jr (~luke-jr@unaffiliated/luke-jr) |
| 07:09.11 | DocScrutinizer05 | http://en.wikipedia.org/wiki/Tripes yep |
| 07:09.34 | DocScrutinizer05 | http://en.wikipedia.org/wiki/Saure_Kutteln |
| 07:09.46 | Maxdamantus | Oh, no, it's the stomach, not intestines. |
| 07:09.59 | Maxdamantus | Maybe haggis is the intestines. |
| 07:10.07 | Maxdamantus | hasn't eaten either. |
| 07:10.20 | DocScrutinizer05 | well, stomach is intestines as well in my book |
| 07:10.47 | Maxdamantus | intestines are below the stomach. |
| 07:10.50 | DocScrutinizer05 | me neither °°*°D-: |
| 07:12.04 | *** join/#maemo Guest98402 (~sal@195-241-169-88.ip.telfort.nl) |
| 07:12.28 | DocScrutinizer05 | ooh, you're right. My idea of what are intestines been flawed |
| 07:13.36 | DocScrutinizer05 | seems Miriam Webster is also kinda mistaken on Kaldaunen then |
| 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. |
| 07:14.39 | DocScrutinizer05 | http://de.wikipedia.org/wiki/Kutteln |
| 07:14.57 | DocScrutinizer05 | Guest98402: HDD? |
| 07:15.15 | *** join/#maemo bef0rd (~bef0rd@unaffiliated/beford) |
| 07:15.24 | Maxdamantus | Guest98402: mount that. |
| 07:15.48 | kerio | mass storage mode doesn't export a whole device |
| 07:15.49 | kerio | just a partition |
| 07:15.52 | Maxdamantus | Guest98402: it normally provides the single partition. |
| 07:16.06 | DocScrutinizer05 | when your uSD has no partitions then it will show as /dev/sdb and be so called superfloppy format |
| 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. |
| 07:16.28 | DocScrutinizer05 | also what kerio said |
| 07:16.49 | kerio | i wonder if the exported swap partition is actually writeable |
| 07:16.51 | kerio | i never tried |
| 07:16.53 | kerio | for obvious reasons |
| 07:18.22 | Maxdamantus | it doesn't export it. |
| 07:18.36 | kerio | my swap partition is on the uSD |
| 07:18.39 | kerio | it's exported |
| 07:18.42 | Maxdamantus | Ah. |
| 07:18.45 | DocScrutinizer05 | hah! |
| 07:18.50 | Maxdamantus | Then sure, it would be. |
| 07:18.59 | kerio | isn't it locked or something like that? |
| 07:19.12 | kerio | i would expect the kernel to be quite strict with stuff like that |
| 07:19.21 | DocScrutinizer05 | I'd think it's hard to get exported and same time used by system |
| 07:19.31 | kerio | why's that? |
| 07:19.39 | kerio | the swap partition is a readable device file |
| 07:19.45 | kerio | i was wondering if it's writeable |
| 07:19.49 | Maxdamantus | Hm. Linux (maybe POSIX, can't remember) has a mechanism to lock parts of files. |
| 07:19.51 | DocScrutinizer05 | and you had to think what for you want to mount it anyway |
| 07:19.58 | Maxdamantus | dunno if it works on devices. |
| 07:20.00 | DocScrutinizer05 | unless you wanna write to raw device |
| 07:20.59 | Maxdamantus | it shouldn't be hard to export it. |
| 07:21.44 | Maxdamantus | I'd be surprised if the OS refused to export the SD device while part is used as swap. |
| 07:21.52 | DocScrutinizer05 | I'd rather worry if system still can write to swap when it got exported |
| 07:21.59 | Maxdamantus | probably just unmounts /media/mmc* |
| 07:22.20 | DocScrutinizer05 | :nod: |
| 07:22.21 | Maxdamantus | It can. |
| 07:22.48 | Maxdamantus | neither using swap nor exporting with g_file_storage locks anything. |
| 07:23.03 | DocScrutinizer05 | right |
| 07:23.45 | DocScrutinizer05 | kerio: so go ahead write some mp3 or wav data to swap, watch your N900 starting to sing and dance! ;-P |
| 07:23.53 | *** join/#maemo Luke-Jr (~luke-jr@unaffiliated/luke-jr) |
| 07:24.27 | Maxdamantus | phones as mass storage devices is silly anyway. |
| 07:24.28 | DocScrutinizer05 | I'd honestly blacklist any swap partition from export |
| 07:24.52 | DocScrutinizer05 | I mean there's a reason why I pushed that blacklist into CSSU ;) |
| 07:24.53 | Maxdamantus | It's already powerful enough to run a filesystem server. |
| 07:25.24 | Maxdamantus | just loads g_ether on boot. |
| 07:25.40 | DocScrutinizer05 | hey! |
| 07:25.49 | DocScrutinizer05 | H-E-N? |
| 07:25.58 | Maxdamantus | No. |
| 07:26.18 | Maxdamantus | it's the Linux kernel module that acts as an ethernet device. |
| 07:26.29 | DocScrutinizer05 | ooh, so the device pretends to be a NIC |
| 07:26.37 | Maxdamantus | Yes. |
| 07:26.38 | *** join/#maemo zGrr (~G@46.205.100.213.nat.umts.dynamic.t-mobile.pl) |
| 07:27.01 | kerio | phones as network cards is silly anyway. |
| 07:27.24 | Maxdamantus | Yes, but it's better than as block devices. |
| 07:27.24 | kerio | why isn't g_null the default behaviour anyway? |
| 07:27.25 | DocScrutinizer05 | well, unless you use the modem |
| 07:27.53 | DocScrutinizer05 | to actually access "the internet" |
| 07:28.09 | DocScrutinizer05 | which is best served via ethernet |
| 07:28.24 | DocScrutinizer05 | err network |
| 07:28.30 | Maxdamantus | wire |
| 07:29.03 | DocScrutinizer05 | yeah |
| 07:29.15 | DocScrutinizer05 | TCP/IP |
| 07:29.34 | Maxdamantus | uses it for rsync and for Bluetooth. |
| 07:30.00 | DocScrutinizer05 | rsync? that's running via cronjob and WLAN here |
| 07:30.22 | Maxdamantus | rsync over ssh. |
| 07:30.30 | DocScrutinizer05 | real joy to read the cronjob's mails to root |
| 07:30.39 | Maxdamantus | just for one-off things, not periodic syncs/backups. |
| 07:31.10 | DocScrutinizer05 | ~jrtools |
| 07:31.10 | infobot | somebody said jrtools was http://wiki.maemo.org/User:Joerg_rw/tools |
| 07:31.28 | DocScrutinizer05 | actually http://wiki.maemo.org/User:Joerg_rw/tools#backup |
| 07:31.45 | DocScrutinizer05 | extremely convenient |
| 07:33.13 | kerio | offline backups are the one true way |
| 07:33.39 | DocScrutinizer05 | offline? |
| 07:34.53 | DocScrutinizer05 | idly wonders if somebody already pondered to create a striped raid from eMMC and uSD |
| 07:35.25 | Guest98402 | Maxdamantus: DocScrutinizer05 yeah, I mean the regular 28GB partition |
| 07:35.52 | kerio | DocScrutinizer05: after a successful halt |
| 07:36.11 | DocScrutinizer05 | Guest98402: mount /dev/sdb /media -t vfat |
| 07:36.41 | Maxdamantus | I'm going to eventually run btrfs across the eMMC and SD. |
| 07:36.50 | DocScrutinizer05 | :-D |
| 07:37.12 | Maxdamantus | should get around to writing that alternative phone thing so he can stop using Maemo and use a newer kernel. |
| 07:37.30 | Guest98402 | Thanks DocScrutinizer05 that worked |
| 07:37.36 | DocScrutinizer05 | yw :) |
| 07:37.56 | Guest98402 | I just wonder why pcmanfm and other file managers can't mount it themselves anymore, though |
| 07:37.58 | Maxdamantus | wrote most of a 9p implementation in Go with a better interface than the other 9p implementations. |
| 07:38.01 | Guest98402 | That used to work without problems |
| 07:38.15 | DocScrutinizer05 | don't forget to sync and umount before you unplug! |
| 07:38.26 | *** join/#maemo florian (~fuchs@port-217-146-132-69.static.qsc.de) |
| 07:38.27 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 07:38.27 | Guest98402 | Is sync still necessary if you umount? |
| 07:38.50 | Maxdamantus | No. |
| 07:38.53 | DocScrutinizer05 | good question |
| 07:38.59 | DocScrutinizer05 | prolly not |
| 07:39.01 | Maxdamantus | assuming it is fully unmounted. |
| 07:39.15 | Maxdamantus | You can mount the same filesystem in different places. |
| 07:39.26 | Maxdamantus | so if you "unmount" one, it's not actually unmounted. |
| 07:39.39 | antithesis_ | Yeah, well, I won't do that |
| 07:39.57 | antithesis_ | What about the other way around? Can you sync, then unplug without umounting? |
| 07:40.10 | Maxdamantus | Depends on the filesystem. |
| 07:40.16 | *** join/#maemo japa-fi (~jani@dsl-hkibrasgw4-50dc4f-215.dhcp.inet.fi) |
| 07:40.39 | antithesis_ | FAT filesystems |
| 07:40.54 | Maxdamantus | Should be fine. |
| 07:41.04 | Maxdamantus | as long as you don't write anything after the sync. |
| 07:41.18 | DocScrutinizer05 | dd if=image.bin of=/dev/sdc to flash a complete image to a uSD took >60s for sync. |
| 07:41.21 | kerio | answer = NO |
| 07:41.28 | DocScrutinizer05 | after dd finished |
| 07:41.41 | kerio | there's so much shit going on in a modern linux system |
| 07:41.43 | kerio | you can't be sure |
| 07:42.19 | DocScrutinizer05 | mount -o remount,ro /media |
| 07:42.48 | kerio | DocScrutinizer05: i would expect that to not necessarily sync |
| 07:42.51 | Maxdamantus | Yes, you can do that. |
| 07:43.07 | DocScrutinizer05 | sure it doesn't sync, but after sync you can be sure |
| 07:43.18 | Maxdamantus | It does necessarily sync. |
| 07:43.54 | DocScrutinizer05 | the device can't go r/o before all buffers got flushed |
| 07:44.05 | kerio | the mounted partition is going r/o |
| 07:44.07 | Maxdamantus | So the mount call hangs until that happens. |
| 07:44.48 | DocScrutinizer05 | dunno if it forces sync, or just idles and waits |
| 07:45.08 | DocScrutinizer05 | prolly should force |
| 07:45.14 | Maxdamantus | It wouldn't just idle and wait. |
| 07:45.25 | Maxdamantus | but imo, that's what sync should do. |
| 07:45.34 | Maxdamantus | It's not usually :( |
| 07:46.18 | DocScrutinizer05 | no, sync actively flushes the buffers |
| 07:46.23 | zGrr | moin :) |
| 07:46.28 | DocScrutinizer05 | moinmoin |
| 07:47.12 | Maxdamantus | Not really. |
| 07:47.24 | DocScrutinizer05 | sync takes no parameters afaik, and that sucks |
| 07:47.40 | Maxdamantus | The system will continuously be writing dirty stuff as long as there's stuff to write. |
| 07:48.23 | Maxdamantus | so sync/fsync means "wait until the writeback cache has passed the current moment in time" |
| 07:48.37 | Maxdamantus | but they usually additionally send some sort of commit to the filesystem. |
| 07:49.03 | DocScrutinizer05 | wut? there's a dirty-flush-timeout that's up to 1 minute on laptops etc |
| 07:49.07 | Maxdamantus | and fsync might actually prioritise things. |
| 07:49.37 | DocScrutinizer05 | I'd expect sync to "increase the pressure" |
| 07:50.02 | DocScrutinizer05 | sync(1) that is |
| 07:50.05 | Maxdamantus | Ah yeah, when the writeback cache isn't stressed. |
| 07:50.29 | antithesis_ | oshit what did I ignite |
| 07:50.32 | antithesis_ | still about sync |
| 07:51.45 | DocScrutinizer05 | echo 500 > /proc/sys/vm/dirty_expire_centisecs |
| 07:52.14 | DocScrutinizer05 | rcS |
| 07:52.56 | Maxdamantus | I think it should only be up to the computer operator to "increase the pressure". |
| 07:53.17 | Maxdamantus | so calls like fsync should be there for processes to know when the stuff they wrote has been written. |
| 07:53.22 | DocScrutinizer05 | which he did, by issueing a sync command |
| 07:54.28 | DocScrutinizer05 | I'm not talking about fsync(2) |
| 08:01.24 | *** join/#maemo valeriusL (~valerius@85.26.180.169) |
| 08:02.06 | DocScrutinizer05 | anyway all info about sync, fsync and fdatasync seem to suggest that those function calls are kernel and executed immediately |
| 08:02.38 | DocScrutinizer05 | "the kernel flushes all buffers" |
| 08:04.51 | *** join/#maemo qwazix (~qwazix@Maemo/community/council/qwazix) |
| 08:06.41 | Maxdamantus | Wonder if Linux provides a passive version of fsync. |
| 08:07.08 | Maxdamantus | If you only want to know when some data has been written. |
| 08:07.44 | DocScrutinizer05 | doesn't seem so. But I just learned that (f)sync even is supposed to flush drive cache |
| 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. |
| 08:08.26 | DocScrutinizer05 | >> This includes writing through or flushing a disk cache if present.<< |
| 08:09.40 | DocScrutinizer05 | yeah, there SHOULD be such function call |
| 08:09.54 | Maxdamantus | That should be what fsync itself does. |
| 08:10.16 | DocScrutinizer05 | no, fsync serves other purpose |
| 08:10.39 | Maxdamantus | Very little other, except in distributed systems. |
| 08:11.00 | Maxdamantus | where you want to tell peers that the data has been safely written, as quickly as possible. |
| 08:11.35 | DocScrutinizer05 | right, fsync is a bit... nonsensical for purposes of e.g. safe shutdown etc |
| 08:11.44 | DocScrutinizer05 | sync otoh |
| 08:12.47 | DocScrutinizer05 | generally speaking fsync makes sure your data is "safe" |
| 08:13.47 | Maxdamantus | I'd say generally speaking it doesn't. |
| 08:14.00 | Maxdamantus | It provides a way for you to make sure your data is safe. |
| 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 |
| 08:14.23 | Maxdamantus | by letting programs know when a future revision of something has been completely written. |
| 08:15.04 | DocScrutinizer05 | ? |
| 08:16.30 | Maxdamantus | fsync doesn't actually provide a way to know that your data is safe. |
| 08:16.43 | Maxdamantus | a milisecond after fsync calls, someone else might've overwritten it. |
| 08:16.44 | DocScrutinizer05 | fsync (and fdatasync) says "write this now, I don't want to risk it getting lost on unadvertised brownout" |
| 08:17.33 | DocScrutinizer05 | and with your overwritten data you're really going weird now |
| 08:17.44 | Maxdamantus | So what do you do after the fsync? |
| 08:18.13 | DocScrutinizer05 | when somebody overwrites my file, well then my system is a pile of bullshot coded by monkeys |
| 08:18.39 | Maxdamantus | You shouldn't just fsync for the hell of it. |
| 08:18.41 | DocScrutinizer05 | let's see... what does mySQL do after fsync |
| 08:18.44 | Maxdamantus | It's going to be written eventually |
| 08:18.55 | DocScrutinizer05 | close the transaction maybe? |
| 08:19.12 | Maxdamantus | Non-distributed databases have a reason to do what I said fsync should do. |
| 08:19.35 | Maxdamantus | If they want to be able to guarantee database consistency, they need something like fsync. |
| 08:19.43 | DocScrutinizer05 | aha. and what is a commit in your book then? |
| 08:19.52 | Maxdamantus | but they don't need the "force it to write now" bit. |
| 08:20.00 | *** join/#maemo troulouliou_dev (~troulouli@unaffiliated/troulouliou-dev/x-4757952) |
| 08:20.11 | DocScrutinizer05 | oh, they don't? |
| 08:20.24 | Maxdamantus | No. The "force it to write now" doesn't help in ensuring consistency. |
| 08:20.32 | DocScrutinizer05 | aha |
| 08:20.40 | Maxdamantus | The system could lose power during the fsync or before it. |
| 08:20.49 | DocScrutinizer05 | great |
| 08:20.52 | DocScrutinizer05 | so what? |
| 08:21.26 | DocScrutinizer05 | AFTER the fsync anyway I KNOW my data is on magenitzed bits on a disk |
| 08:21.42 | DocScrutinizer05 | so I return from commit() |
| 08:21.58 | Maxdamantus | Yes. That's what fsync should ensure. |
| 08:22.07 | Maxdamantus | It shouldn't try to force anything. |
| 08:22.13 | DocScrutinizer05 | aha |
| 08:22.20 | Maxdamantus | it should just wait until the data written beforehand is on the disk. |
| 08:22.28 | DocScrutinizer05 | tzz |
| 08:22.45 | DocScrutinizer05 | which may never happen |
| 08:23.17 | Maxdamantus | It will happen eventually, unless there's a hardware failure. |
| 08:23.27 | DocScrutinizer05 | no it won't |
| 08:23.42 | DocScrutinizer05 | not in any warranted finite timespan |
| 08:24.18 | Maxdamantus | Do you mean indefinite? |
| 08:24.36 | Maxdamantus | or infinite? |
| 08:24.41 | Maxdamantus | It will happen, eventually. |
| 08:24.45 | Maxdamantus | ie, within a finite amount of time. |
| 08:24.46 | DocScrutinizer05 | I mean system with echo 5000000000 > /proc/sys/vm/dirty_expire_centisecs |
| 08:25.35 | Maxdamantus | Then it will have to wait a while. |
| 08:25.53 | DocScrutinizer05 | I'd say THANKYOU to a db that takes 30min to return from a commit() |
| 08:26.26 | DocScrutinizer05 | I suggest you write your own kernel and libs |
| 08:26.56 | DocScrutinizer05 | since on unix or posix fsync won't do what you ask for |
| 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. |
| 08:27.06 | DocScrutinizer05 | maybe some other call does |
| 08:27.42 | DocScrutinizer05 | AHA, you also need to write your own db then, see definition of "commit" |
| 08:28.09 | Maxdamantus | commit in databases usually has to do with atomicity afaik |
| 08:28.09 | DocScrutinizer05 | good luck with evaluating and certifying that critter |
| 08:28.23 | Maxdamantus | ie, you have a bunch of stuff in a commit, which either happens or doesn't. |
| 08:28.34 | freemangordon_ | hmm, isn't commit related to transactions, rather to io? |
| 08:28.39 | Maxdamantus | Yes. |
| 08:28.42 | Maxdamantus | (afaik) |
| 08:28.48 | DocScrutinizer05 | commit first and foremost has to do with rolling back atomic sequences of actions |
| 08:28.55 | Maxdamantus | Yes. |
| 08:28.57 | freemangordon_ | sure |
| 08:29.02 | Maxdamantus | which is what my use case of fsync is about. |
| 08:29.19 | freemangordon_ | but shouldn't be related to io |
| 08:29.29 | freemangordon_ | what db is that? |
| 08:29.38 | Maxdamantus | You don't need to wait for a filesystem fsync to return before claiming a commit has finished though. |
| 08:29.47 | freemangordon_ | exactly |
| 08:30.13 | DocScrutinizer05 | depends on your level of consistency you expect from the db |
| 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. |
| 08:30.48 | DocScrutinizer05 | when your commit returns before data got written to disk, it ISN'T committed yet |
| 08:30.52 | Maxdamantus | So you'll be able to roll back to some good copy after unexpected power loss. |
| 08:30.58 | freemangordon_ | DocScrutinizer05: it is |
| 08:31.04 | Maxdamantus | To do that, you need to make sure you haven't overwritten all good copies. |
| 08:31.33 | freemangordon_ | as your inserts/updates are in the journal |
| 08:31.35 | Maxdamantus | So you either need some WORM system, or something based on a passive fsync. |
| 08:31.53 | DocScrutinizer05 | freemangordon_: when system goes down after commit returns but before buffers flushed, you're fsckd |
| 08:31.54 | Maxdamantus | (with the WORM system, you'd additionally need the guarantee that writes are ordered) |
| 08:32.04 | antithesis_ | Okay, okay, I'll just use umount... |
| 08:32.05 | freemangordon_ | sure, and I've seen that |
| 08:32.23 | freemangordon_ | with oracle on solaris :) |
| 08:32.27 | DocScrutinizer05 | that's why I say "depends" |
| 08:32.35 | freemangordon_ | duplicated primary keys :D |
| 08:33.00 | freemangordon_ | but it is not db job to care about fs |
| 08:33.47 | freemangordon_ | because begin/end transaction, commit, etc is related to db, not to fs |
| 08:34.31 | freemangordon_ | anyway, back to my job :) |
| 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 |
| 08:35.51 | Maxdamantus | in Linux, it's ultimately up to the filesystem implementation to provide the semantics. |
| 08:36.09 | Maxdamantus | and it seems reasonable to offer different meanings as mount options. |
| 08:36.23 | Maxdamantus | I'd like to use btrfs without a log. |
| 08:36.48 | Maxdamantus | So if I lose power, I'll just lose up to 30s of activity. |
| 08:37.06 | Maxdamantus | I don't need to guarantee to other people that I've saved their data. |
| 08:37.48 | DocScrutinizer05 | whatever you like |
| 08:38.11 | DocScrutinizer05 | toldya, linux is FOSS, go and fork! |
| 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 |
| 08:40.37 | DocScrutinizer05 | man 2 fsync |
| 08:41.11 | Maxdamantus | Most proper uses of fsync would work with either semantics. |
| 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<< |
| 08:41.24 | Maxdamantus | I doubt a database is actually going to wait until the data is on disk before returning from a commit. |
| 08:41.25 | DocScrutinizer05 | not "waits until that happens, eventually" |
| 08:41.28 | Maxdamantus | That will just slow stuff down. |
| 08:41.51 | Maxdamantus | Unless you've configured the database to do it. |
| 08:41.58 | Maxdamantus | which might be useful in distributed systems. |
| 08:42.02 | DocScrutinizer05 | exactly ;) |
| 08:42.18 | DocScrutinizer05 | or in high security systems |
| 08:42.42 | DocScrutinizer05 | where a commit is a commit is a commit |
| 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" |
| 08:43.15 | DocScrutinizer05 | irrelevant, the transaction gets rolled back |
| 08:43.29 | Maxdamantus | Rolled back to what? |
| 08:43.42 | DocScrutinizer05 | to "money on account A" |
| 08:44.00 | Maxdamantus | How does it know where that is? |
| 08:44.11 | DocScrutinizer05 | *sigh* |
| 08:44.23 | Maxdamantus | What if the "money on account A" hadn't been commited to disk yet? |
| 08:44.38 | DocScrutinizer05 | eh? |
| 08:45.20 | DocScrutinizer05 | it *has* been, otherwise it wasn't on account A so nothing to move from A to B |
| 08:46.03 | Maxdamantus | If you make two transactions: B → A, A → C, there are three possible places for the money to be. |
| 08:46.24 | Maxdamantus | You have to roll back to the state you know is not corrupt. |
| 08:46.32 | DocScrutinizer05 | if you make two transactions, then they are atomic each and unentangled |
| 08:46.41 | Maxdamantus | not necessarily the one before the last. |
| 08:48.10 | DocScrutinizer05 | you can't do A->C before B->A got committed |
| 08:48.11 | Maxdamantus | You do it by keeping all states accessible, except for ones before the last one you know has been completed. |
| 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. |
| 08:49.08 | Maxdamantus | (completed as in: all information about that state is on disk) |
| 08:49.18 | DocScrutinizer05 | that's called "commit" |
| 08:49.52 | Maxdamantus | No. Commit doesn't have to ensure it's on disk. |
| 08:50.04 | DocScrutinizer05 | maybe in your world |
| 08:50.15 | Maxdamantus | Commit just has to ensure either none of it or all of it happens. |
| 08:50.24 | Maxdamantus | rather than half of it. |
| 08:50.33 | DocScrutinizer05 | define 'happens' |
| 08:50.47 | Maxdamantus | is part of an accessible state. |
| 08:51.12 | *** join/#maemo valeriusL (~valerius@85.26.180.169) |
| 08:51.14 | DocScrutinizer05 | gibberish |
| 08:51.43 | Maxdamantus | Not gibberish. |
| 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. |
| 08:52.36 | DocScrutinizer05 | and how's that explaining what you meant by 'happens'? |
| 08:52.43 | Maxdamantus | You don't want an in-between state where half of the transaction has taken effect. |
| 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 |
| 08:53.38 | Maxdamantus | or where neither of them have the money. |
| 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 |
| 08:54.27 | DocScrutinizer05 | instead of got written into magnetic record of B |
| 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? |
| 08:54.52 | Maxdamantus | so the first write has taken effect, but the second hasn't. |
| 08:55.10 | DocScrutinizer05 | then the commit didn't complete |
| 08:55.15 | Maxdamantus | There's a magnetic record of A not having the money. |
| 08:55.34 | Maxdamantus | Obviously "having a magnetic record" isn't useful on its own. |
| 08:55.40 | DocScrutinizer05 | meh |
| 08:56.01 | DocScrutinizer05 | are we going to discuss how transactions and commits work now? |
| 08:56.31 | Maxdamantus | I'm pretty sure that's what we've been doing. |
| 08:56.35 | Maxdamantus | at least what I've been doing. |
| 08:56.43 | Maxdamantus | 20:46:24 < Maxdamantus> You have to roll back to the state you know is not corrupt. |
| 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. |
| 08:56.47 | DocScrutinizer05 | not on a beginner's level |
| 08:57.16 | Maxdamantus | So you don't actually overwrite anything about A's or C's money. |
| 08:57.50 | Maxdamantus | Because you need to make sure at least one consistent state is accessible. |
| 08:58.23 | DocScrutinizer05 | FILE A: ta:345, -5bucks; FILE B: ta:345, +5bucks; log: ta:345 committed |
| 08:58.48 | DocScrutinizer05 | rollback from right to left all you like |
| 08:59.02 | *** join/#maemo eMHa__ (~mh@nat.de.netviewer.com) |
| 08:59.02 | Maxdamantus | If you're just appending to files, you don't need anything like sync. |
| 08:59.20 | DocScrutinizer05 | aha |
| 08:59.53 | Maxdamantus | You just need a guarantee of ordered writes. |
| 09:00.11 | DocScrutinizer05 | you're aware HDD work with sectors and blocks and such shite? They even spin |
| 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. |
| 09:00.59 | Maxdamantus | A journal can give you ordered writes. |
| 09:01.34 | Maxdamantus | You only need the metadata to be ordered in this case. |
| 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 |
| 09:02.04 | *** join/#maemo robink (~quassel@unaffilated/robink) |
| 09:02.32 | Maxdamantus | Why would you run into deadlocks? |
| 09:02.49 | DocScrutinizer05 | and it doesn't matter if you fsync your data or your journal |
| 09:03.49 | DocScrutinizer05 | you need to fsync *something* anyway |
| 09:04.01 | Maxdamantus | You don't need to. You just need ordered metadata writes. |
| 09:04.11 | Maxdamantus | if you're only appending. |
| 09:04.18 | Maxdamantus | the fsync is useful for knowing what you can overwrite. |
| 09:05.30 | DocScrutinizer05 | I'm afk |
| 09:05.46 | DocScrutinizer05 | this leads nowhere anyway |
| 09:06.55 | DocScrutinizer05 | particularly since I'm no db developer, I just use them every now and then |
| 09:07.25 | DocScrutinizer05 | e.g to move your money to and from your bank account |
| 09:08.23 | DocScrutinizer05 | and i'd not be surprised if COBOL commit definition actually requires data to get written to HDD |
| 09:09.09 | DocScrutinizer05 | afk now |
| 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 |
| 09:20.14 | *** join/#maemo valeriusL (~valerius@85.26.180.169) |
| 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 |
| 09:25.11 | DocScrutinizer05 | you can't sit on a frankenstein-fsync and wait for buffers to eventually get flushed |
| 09:25.26 | DocScrutinizer05 | in 5 minutes |
| 09:34.47 | 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 |
| 09:57.23 | Maxdamantus | Yes. That's an example of a distributed system. |
| 09:57.51 | Maxdamantus | You have to tell someone else that the commit is permanent, and optimially as quickly as possible. |
| 09:58.31 | Maxdamantus | (you wouldn't want to wait a minute for the data to be flushed before responding to an ATM request) |
| 09:58.51 | Maxdamantus | When the ATM server dies, the customer doesn't. |
| 10:05.49 | *** join/#maemo Psi_ (~Psi@49-50-247-217.a.hd.net.nz) |
| 10:05.50 | *** join/#maemo jormungandr (~xxx@213.23.120.114) |
| 10:48.23 | *** join/#maemo Natch_j (~Natch@85.225.207.235) |
| 10:48.42 | *** join/#maemo otep_ (~quassel@AP-203.167.4.11.sysads.com) |
| 10:50.59 | *** join/#maemo dromer (~henk@melange.soleus.nu) |
| 10:51.07 | *** join/#maemo g3kk3r_ (torrkull@lehtori.cc.tut.fi) |
| 10:51.18 | *** join/#maemo fil_ (~phil@switch.hands.com) |
| 10:56.15 | *** join/#maemo vakko__ (~vakko@84.54.170.6) |
| 10:56.56 | *** join/#maemo warfare (~falk@kilbeggan.fourecks.de) |
| 10:57.13 | *** join/#maemo mickname (mickname@low6.kyla.fi) |
| 11:02.53 | *** join/#maemo auenf (David@171.72.233.220.static.exetel.com.au) |
| 11:04.24 | *** join/#maemo g3kk3r (torrkull@lehtori.cc.tut.fi) |
| 11:04.45 | *** join/#maemo ALoGeNo (~alogeno@unaffiliated/alogeno) |
| 11:07.45 | *** join/#maemo ecc2g (blc@r.jajcs.net) |
| 11:10.38 | *** join/#maemo t3st3r (~t3st3r@gateway/tor-sasl/t3st3r) |
| 11:25.18 | *** join/#maemo hxka (~hxka@128-69-131-147.broadband.corbina.ru) |
| 11:34.50 | *** join/#maemo okias (~okias@berger.cust.centro-net.cz) |
| 11:40.09 | *** join/#maemo ds3 (noinf@rehut.com) |
| 11:42.47 | *** join/#maemo ddark (~ddark@5.102.198.248) |
| 11:45.02 | *** join/#maemo erlehmann (~erlehmann@82.113.121.32) |
| 11:48.00 | *** join/#maemo protem (~protem@unaffiliated/protem) |
| 11:48.01 | *** join/#maemo LjL (~ljl@unaffiliated/ljl) |
| 11:48.01 | *** join/#maemo AndrewX192 (~andrew@unaffiliated/andrewx192) |
| 11:49.20 | *** join/#maemo darkschneider (~gab@93-32-59-224.ip32.fastwebnet.it) |
| 12:18.40 | *** join/#maemo RES401 (Elite9109@gateway/shell/elitebnc/x-omnjyedtedlswbwf) |
| 12:18.40 | *** join/#maemo b-p (~freenode@dwd.hu) |
| 12:18.40 | *** join/#maemo mkaindl (~mkaindl@2a03:4000:2:4cb:5054:83ff:fe51:69ed) |
| 12:18.40 | *** join/#maemo Trizt (~user@2a03:4000:2:4cb:5054:feff:fe43:cbf1) |
| 12:18.40 | *** join/#maemo guerby (~guerby@ip165-ipv6.tetaneutral.net) |
| 12:18.40 | *** join/#maemo HRH_H_Cr1b (~crab@kowloontong.dim-sum.org) |
| 12:18.40 | *** join/#maemo realitygaps (~realityga@unaffiliated/realitygaps) |
| 12:18.40 | *** join/#maemo ketas (ketas@ketas6-sixxs.si.pri.ee) |
| 12:18.40 | *** join/#maemo merlin1991 (~merlin@Maemo/community/cssu/merlin1991) |
| 12:19.34 | *** join/#maemo ketas (ketas@ketas6-sixxs.si.pri.ee) |
| 12:23.58 | *** join/#maemo LjL-Laplet (~ljl@93-32-49-69.ip32.fastwebnet.it) |
| 12:31.12 | *** join/#maemo LauRoman (~LauRoman@5-14-195-26.residential.rdsnet.ro) |
| 12:49.27 | *** join/#maemo kolp (~quassel@55d443df.access.ecotel.net) |
| 12:55.07 | *** join/#maemo ALoGeNo (~alogeno@unaffiliated/alogeno) |
| 13:11.14 | *** join/#maemo lizardo (lizardo@nat/indt/x-anrnsubadjmazxpt) |
| 13:17.38 | *** join/#maemo LauRoman|Laptop (~LauRoman@5-14-195-26.residential.rdsnet.ro) |
| 13:23.13 | *** join/#maemo remarc (~sequantz@194.11.24.44) |
| 13:23.22 | *** join/#maemo remarc (~sequantz@194.11.24.44) |
| 13:40.42 | *** join/#maemo troulouliou_dev (~troulouli@unaffiliated/troulouliou-dev/x-4757952) |
| 14:20.09 | *** join/#maemo LjL-Laplet2 (~ljl@93-32-49-69.ip32.fastwebnet.it) |
| 14:30.17 | *** join/#maemo jormungandr (~xxx@213.23.120.114) |
| 14:57.28 | *** join/#maemo janemba (~101@unaffiliated/janemba) |
| 14:58.23 | *** join/#maemo VDVsx (~VDVsx@a88-114-88-95.elisa-laajakaista.fi) |
| 15:06.29 | *** join/#maemo geaaru (~geaaru@host170-152-static.43-88-b.business.telecomitalia.it) |
| 15:42.13 | *** join/#maemo wotan147 (~max@HSI-KBW-109-193-012-252.hsi7.kabel-badenwuerttemberg.de) |
| 15:42.55 | *** join/#maemo valeriusL (~valerius@85.26.180.176) |
| 15:44.04 | *** join/#maemo okias (~okias@berger.cust.centro-net.cz) |
| 16:01.42 | *** join/#maemo RiD (~RiD@2.83.36.146) |
| 16:03.30 | *** join/#maemo okias (~okias@berger.cust.centro-net.cz) |
| 16:07.42 | *** join/#maemo mp__ (~mp@77-255-251-48.adsl.inetia.pl) |
| 16:07.45 | *** join/#maemo okias (~okias@berger.cust.centro-net.cz) |
| 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 |
| 16:08.32 | DocScrutinizer05 | and GPS had not been used for at least 2 weeks before |
| 16:10.38 | DocScrutinizer05 | AGPS, supl.google.com |
| 16:11.00 | DocScrutinizer05 | SIM activated, WLAN for internet access |
| 16:11.26 | bencoh | I thought supl.google didnt work anywore |
| 16:11.27 | DocScrutinizer05 | O2-Germany |
| 16:11.28 | bencoh | anymore* |
| 16:11.37 | DocScrutinizer05 | *shrug* |
| 16:11.59 | bencoh | (my mobile operator provides me a supl anyway) |
| 16:12.15 | DocScrutinizer05 | possibly it doesn't need any supl, since usually the assistance is via WWAN |
| 16:12.25 | bencoh | WWAN ? |
| 16:12.31 | DocScrutinizer05 | 2/3G |
| 16:12.38 | DocScrutinizer05 | ~wwan |
| 16:12.51 | DocScrutinizer05 | o.O |
| 16:12.55 | DocScrutinizer05 | anyway |
| 16:13.04 | DocScrutinizer05 | ~gsm-agps |
| 16:13.04 | 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 |
| 16:13.19 | bencoh | hmm, can the n900 use something else than supl for that ? |
| 16:13.27 | DocScrutinizer05 | ^^^ |
| 16:13.55 | DocScrutinizer05 | http://en.wikipedia.org/wiki/RRLP |
| 16:14.33 | bencoh | right but that doesn't give infos needed for gps stuff |
| 16:14.36 | DocScrutinizer05 | prolly 3G helps a lot, via E-OTD |
| 16:14.37 | bencoh | (ephemerids and all) |
| 16:14.50 | bencoh | or does it ? |
| 16:14.52 | DocScrutinizer05 | rrlp does |
| 16:15.11 | DocScrutinizer05 | it's basically supl via wwan |
| 16:15.23 | DocScrutinizer05 | well, part of it is |
| 16:15.23 | bencoh | oh, okay |
| 16:15.31 | bencoh | interesting |
| 16:15.36 | DocScrutinizer05 | there's a system and a user layer iirc |
| 16:15.50 | DocScrutinizer05 | and on 3G there's E-OTD |
| 16:16.12 | DocScrutinizer05 | which isn't specified as giving feedback to MS |
| 16:16.15 | bencoh | the MS-assisted GPS part I guess ? |
| 16:16.22 | DocScrutinizer05 | but also nobody says it mustn't |
| 16:17.40 | DocScrutinizer05 | aiui E-OTD has no MS-based mode |
| 16:18.22 | DocScrutinizer05 | the enodeb doesn't share sufficient info to MS to do that on-board |
| 16:18.55 | DocScrutinizer05 | but enodeb could return the result of E-OTD to MS |
| 16:19.48 | *** join/#maemo drathir (~kamiljk8@s51.linuxpl.com) |
| 16:20.54 | DocScrutinizer05 | NB that for GSM/2G there's no such thing like E-OTD |
| 16:21.25 | bencoh | no E-OTD for me then :) |
| 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 |
| 16:22.58 | DocScrutinizer05 | passive OTD would mean: make MS send any arbitrary thing, check timing difference as seen by receivers of at least 3 BTS |
| 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 |
| 16:24.09 | bencoh | hmm |
| 16:24.17 | DocScrutinizer05 | it's unclear which providers equipped how many of their BTS with such additional gear |
| 16:27.20 | DocScrutinizer05 | anyway GPS based RRLP is defined also for 2G |
| 16:27.32 | DocScrutinizer05 | afaik |
| 16:27.48 | DocScrutinizer05 | yep, wiki clearly states it |
| 16:28.00 | DocScrutinizer05 | >>Radio resource location services (LCS) protocol (RRLP) applies to GSM and UMTS Cellular Networks<< |
| 16:29.58 | bencoh | good to know |
| 16:30.27 | bencoh | doesn't that mean supl should be useless then ? |
| 16:31.22 | *** join/#maemo Pilke (~Pilke@85-76-113-54-nat.elisa-mobile.fi) |
| 16:38.28 | DocScrutinizer05 | well, as long as your carrier provides it via RRLP it actually might be useless |
| 16:39.08 | DocScrutinizer05 | NB the N900 GPS is controlled by modem, not by main CPU |
| 16:39.09 | bencoh | I should test it some time |
| 16:39.14 | bencoh | yeah I know |
| 16:39.25 | DocScrutinizer05 | RRLP is the reason for that |
| 16:40.07 | bencoh | btw how does main cpu feeds the gps with supl results ? |
| 16:40.19 | DocScrutinizer05 | a god question |
| 16:40.21 | DocScrutinizer05 | good |
| 16:41.06 | bencoh | that goes with all the gps-related secrets ? |
| 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 |
| 16:42.30 | DocScrutinizer05 | see the *closed-blob* mini tool Nokia provided for clearing position cache |
| 16:42.44 | bencoh | you mean ssi-encapsulated AT commands ? |
| 16:43.00 | bencoh | (ssi/hsi) |
| 16:43.02 | DocScrutinizer05 | for debugging purposes when we had that GPS-doesn't-get-fix issue |
| 16:43.43 | DocScrutinizer05 | I don't think ISI protocol is anything like "AT encapsulated into whatever" |
| 16:44.15 | DocScrutinizer05 | it's more like tcp/ip |
| 16:44.30 | DocScrutinizer05 | with slots/ports for certain services |
| 16:44.53 | bencoh | yeah I got confused, misread "there are some (usually proprietary) AT commands (or in case of BB5 modem: ISI messages) |
| 16:45.31 | DocScrutinizer05 | we got pnatd to convert AT to ISI |
| 16:46.31 | *** join/#maemo dos1 (~dos@unaffiliated/dos1) |
| 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 |
| 16:47.33 | DocScrutinizer05 | prolly BB5 runs an AT-interpreter service of some sorts, on some slot/port |
| 16:47.55 | DocScrutinizer05 | but that's not the recommended and usual way to communicate with ISI modem |
| 16:48.11 | DocScrutinizer05 | disclaimer: all AIUI/AFAIK |
| 16:48.21 | *** join/#maemo Lumocolor (~disposabl@79-69-200-128.dynamic.dsl.as9105.com) |
| 16:49.12 | DocScrutinizer05 | anyway I'm pretty convinced that BB5 does E-OTD on 3G |
| 16:49.34 | DocScrutinizer05 | I could't think of any other explanation for a stable fix after <5s |
| 16:49.56 | DocScrutinizer05 | *indoors* even |
| 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 |
| 16:52.15 | DocScrutinizer05 | so odds are O2 has a vital interest in running RRLP/E-OTD |
| 16:52.55 | *** join/#maemo Gatta_Negra (~SailCat@95.87.201.145) |
| 16:53.39 | DocScrutinizer05 | I could even figure they do a E-OTD by default, each time a communication with MS happens |
| 17:21.01 | *** join/#maemo erlehmann (~erlehmann@82.113.121.32) |
| 17:25.55 | *** join/#maemo HylianSavior (~hyliandes@HYLIANDESKTOP.RES.CMU.EDU) |
| 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 |
| 17:40.10 | bencoh | I suspect sfr (france) doesn't either but I'm not sure about it |
| 17:45.54 | *** join/#maemo maybeHere (~cl@p5790F40B.dip0.t-ipconnect.de) |
| 17:47.08 | *** join/#maemo ZogG_laptop (~ZogG_lapt@bzq-79-180-4-250.red.bezeqint.net) |
| 17:47.08 | *** join/#maemo ZogG_laptop (~ZogG_lapt@funtoo/user/ZogG) |
| 17:51.38 | DocScrutinizer05 | wow, seems that's a nice new virtual provider: https://www.simquadrat.de/produkte/roaming |
| 17:52.21 | DocScrutinizer05 | and they leaked a interesting info there: they call theri own network "sipgate netz" ;-) |
| 17:53.02 | DocScrutinizer05 | sipgate is a great SIP-VoIP provider I'm using since err 14 years? |
| 17:53.21 | DocScrutinizer05 | seems now they go GSM/UMTS |
| 17:55.58 | DocScrutinizer05 | ok, 9 years, not 14 |
| 18:00.25 | *** join/#maemo ccxN (~ccxCZ@37-48-41-163.tmcz.cz) |
| 18:02.01 | *** part/#maemo ccxN (~ccxCZ@37-48-41-163.tmcz.cz) |
| 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 |
| 18:04.33 | DocScrutinizer05 | and Germany-wide geo-number/landline-number |
| 18:05.03 | DocScrutinizer05 | that's awesome and pretty much in line with what Sipgate offers for VoIP |
| 18:07.06 | *** join/#maemo sq-one (~sq-one@p549A9321.dip0.t-ipconnect.de) |
| 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 |
| 18:09.01 | DocScrutinizer05 | as well as in GB |
| 18:09.57 | DocScrutinizer05 | dunno about norway - either they hate it or they *want* it |
| 18:10.34 | DocScrutinizer05 | in Germany afaik government can't enforce it |
| 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 |
| 18:11.19 | *** join/#maemo auenf (David@171.72.233.220.static.exetel.com.au) |
| 18:11.40 | *** join/#maemo jrocha (~JRocha@AAnnecy-651-1-297-163.w90-27.abo.wanadoo.fr) |
| 18:11.53 | DocScrutinizer05 | and obviously it works like a charm - I mean 5s TTFF, really? |
| 18:12.09 | bencoh | DocScrutinizer05: true |
| 18:13.38 | DocScrutinizer05 | switches to 2G ... |
| 18:15.05 | *** join/#maemo eMHa (~mh@nat.de.netviewer.com) |
| 18:15.16 | *** join/#maemo LjL-Laplet (~ljl@93-32-49-69.ip32.fastwebnet.it) |
| 18:15.45 | *** join/#maemo LjL-Laplet (~ljl@unaffiliated/ljl) |
| 18:16.14 | DocScrutinizer05 | AHA! 50s till first feeble 3sat fix |
| 18:17.16 | *** join/#maemo raijin (~raininja@unaffiliated/raijin) |
| 18:17.26 | *** join/#maemo florian (~fuchs@aftr-37-24-146-152.unity-media.net) |
| 18:17.26 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 18:18.18 | *** join/#maemo cpt_nemo (cpt_nemo@rfc1459.de) |
| 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 |
| 18:21.00 | DocScrutinizer05 | absolutely obviously only 3G O2 provides data for MS-based GPS assistance |
| 18:23.54 | 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 |
| 18:25.18 | *** join/#maemo _rd (~rd@p57B48270.dip0.t-ipconnect.de) |
| 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.<< |
| 18:26.34 | *** join/#maemo goldkatze (~nobody@unaffiliated/goldkatze) |
| 18:26.39 | bencoh | hmm |
| 18:27.29 | *** part/#maemo uen (~uen@p5084058B.dip0.t-ipconnect.de) |
| 18:30.51 | kerio | 8 seconds for me :c |
| 18:33.17 | DocScrutinizer05 | 8s still is great, no? |
| 18:33.30 | kerio | yeah yeah |
| 18:33.46 | DocScrutinizer05 | I think the theoretical minimum on GPS are 14s |
| 18:35.16 | DocScrutinizer05 | honestly GPS kinda starts becoming a niche technology and obsolete for everyday usage |
| 18:35.20 | kerio | wait what |
| 18:35.32 | kerio | you mean "pure" gps, right |
| 18:36.03 | DocScrutinizer05 | yeah, obviously |
| 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 |
| 18:38.11 | kerio | agps is great if you have it |
| 18:38.16 | DocScrutinizer05 | while it's augmented and assisted by RRLP, it's still GPS |
| 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 |
| 18:40.36 | DocScrutinizer05 | SUPL never could do this |
| 18:41.05 | kerio | why is there even a skew? |
| 18:41.15 | DocScrutinizer05 | huh? |
| 18:41.34 | DocScrutinizer05 | why are two unrelated signals not in sync everywhere on this globe? |
| 18:41.37 | kerio | yes! |
| 18:41.43 | kerio | (i see) |
| 18:41.53 | kerio | (stupid relativity) |
| 18:42.35 | DocScrutinizer05 | rather unrelativity |
| 18:42.38 | DocScrutinizer05 | ;-P |
| 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 |
| 18:43.59 | bencoh | well, didnt get a fix in a minute from the window (2G/operator supl) |
| 18:44.20 | bencoh | weather might not help though |
| 18:44.22 | kerio | raw gps is still useful if you're somewhere with no internets and no clock |
| 18:44.34 | DocScrutinizer05 | yes, sure |
| 18:44.41 | bencoh | yup, getting a position in 12mn is better than nothing |
| 18:44.42 | kerio | it's also useful if you never lose the fix |
| 18:44.43 | kerio | :D |
| 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 |
| 18:46.29 | kerio | every 20 minutes is 20 minutes too often |
| 18:46.31 | bencoh | yup |
| 18:46.40 | bencoh | and yup :) |
| 18:46.58 | DocScrutinizer05 | well, either you need GPS or you don't ;-) |
| 18:46.59 | kerio | isn't there a way to get an offline supl? |
| 18:47.12 | kerio | assuming a good clock |
| 18:47.18 | DocScrutinizer05 | how's that supposed to work? |
| 18:47.29 | bencoh | you mean, computing eph ? |
| 18:47.46 | kerio | read clock, do calculations to figure out which satellites should be visible |
| 18:47.49 | DocScrutinizer05 | eph is hard to compute, or pretty poor accuracy |
| 18:47.59 | DocScrutinizer05 | that's alm |
| 18:48.16 | kerio | what's eph? |
| 18:48.29 | DocScrutinizer05 | eph takes into account the local errors in what you would expect according to alm |
| 18:48.40 | kerio | "local"? |
| 18:48.41 | bencoh | ephemeris |
| 18:49.01 | bencoh | and almanacs should stay valid for a day anyway |
| 18:49.08 | DocScrutinizer05 | weeks |
| 18:50.07 | bencoh | hmm is it all transmitted ? |
| 18:51.00 | DocScrutinizer05 | http://www.colorado.edu/geography/gcraft/notes/gps/gps_f.html |
| 18:53.30 | DocScrutinizer05 | http://www.colorado.edu/geography/gcraft/notes/gps/gps.html#SVData |
| 18:56.56 | DocScrutinizer05 | bencoh: so yes, all is transmitted in 12.5min |
| 18:57.22 | DocScrutinizer05 | and then stored to N900's data cache |
| 18:58.09 | DocScrutinizer05 | so one uninterrupted 13min GPS session per week should suffice |
| 18:58.25 | DocScrutinizer05 | even when you don't have any SUPL or whatever |
| 18:58.30 | kerio | what about devices that don't have enough space? |
| 18:58.49 | DocScrutinizer05 | those devices don't exist, kerio |
| 18:58.58 | kerio | how much data is that? |
| 18:59.22 | DocScrutinizer05 | calculate it! the data is there on http://www.colorado.edu/geography/gcraft/notes/gps/gps_f.html |
| 18:59.26 | kerio | :c |
| 18:59.44 | DocScrutinizer05 | Data frames (1500 bits) are sent every thirty seconds |
| 19:00.04 | kerio | 30000 bits! |
| 19:00.18 | kerio | it's 3.66KB |
| 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. |
| 19:01.18 | kerio | anyway, make that 25 minutes |
| 19:01.32 | kerio | to get the data at least twice |
| 19:01.39 | DocScrutinizer05 | only when you use a particularly stupid algo |
| 19:01.43 | kerio | i doubt that there's strong error correction |
| 19:01.51 | DocScrutinizer05 | or have dropouts |
| 19:02.12 | DocScrutinizer05 | there are parity bits, a few of them |
| 19:02.44 | DocScrutinizer05 | but yeah, you shouldn't have any significant dropouts |
| 19:03.07 | DocScrutinizer05 | I guess >1s is a sure killer |
| 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.<< |
| 19:05.08 | DocScrutinizer05 | http://www.colorado.edu/geography/gcraft/notes/gps/gif/databits.gif |
| 19:06.51 | *** join/#maemo shentey (~shentey@nrbg-4dbfe1fa.pool.mediaWays.net) |
| 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 |
| 19:13.54 | *** join/#maemo totalizator (~totalizat@89-69-49-198.dynamic.chello.pl) |
| 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 |
| 19:15.54 | DocScrutinizer05 | assistance helps reduce number of patterns to feed to correlator to spot the SAT |
| 19:16.38 | DocScrutinizer05 | modern chips have many of those correlators |
| 19:19.01 | *** join/#maemo shentey (~shentey@nrbg-4dbfe1fa.pool.mediaWays.net) |
| 19:19.05 | DocScrutinizer05 | ultra-high sensitivity receivers work by extending the time of comparing the patterns, often up to a minute or more |
| 19:20.57 | kerio | mh, so they actually take longer to get a fix? |
| 19:21.26 | *** join/#maemo lxp (~lxp@93-82-52-167.adsl.highway.telekom.at) |
| 19:23.41 | DocScrutinizer05 | sure |
| 19:23.41 | *** join/#maemo dhbiker (~dhbiker@95.87.145.172) |
| 19:24.35 | DocScrutinizer05 | they still may get a fix after 1min, when other standard receivers already failed |
| 19:24.55 | DocScrutinizer05 | on a good signal they are no slower than a standard chip |
| 19:27.10 | kerio | i see |
| 19:28.45 | DocScrutinizer05 | those chips probably need magnitudes more storage and possibly also more computational grunt to accomplish the task |
| 19:29.04 | DocScrutinizer05 | s/storage/memory aka RAM/ |
| 19:32.38 | DocScrutinizer05 | afk, cya in 2 days |
| 19:34.43 | RiD | looks like vacations! |
| 19:36.27 | *** join/#maemo _rd (~rd@p57B48270.dip0.t-ipconnect.de) |
| 19:41.16 | *** join/#maemo troulouliou_dev (~troulouli@unaffiliated/troulouliou-dev/x-4757952) |
| 19:49.49 | *** join/#maemo valeriusL (~valerius@85.26.180.176) |
| 19:55.26 | *** join/#maemo Cor-Ai (~cor-ai@212.112.62.30) |
| 20:01.38 | *** join/#maemo shentey_ (~shentey@nrbg-4dbfe1fa.pool.mediaWays.net) |
| 20:05.57 | *** join/#maemo Cor-Ai (~cor-ai@212.112.62.30) |
| 20:10.56 | *** join/#maemo qwazix_ (~qwazix@77-2-93.static.cyta.gr) |
| 20:23.02 | *** join/#maemo wotan147 (~max@HSI-KBW-109-193-012-252.hsi7.kabel-badenwuerttemberg.de) |
| 20:25.41 | *** join/#maemo lxp (~lxp@93-82-52-167.adsl.highway.telekom.at) |
| 20:28.03 | *** join/#maemo valeriusL (~valerius@85.26.180.164) |
| 20:29.44 | *** join/#maemo LjL-Laplet (~ljl@93-32-49-69.ip32.fastwebnet.it) |
| 21:00.37 | *** join/#maemo Ex-Opesa (~Ex-Opesa@unaffiliated/ex-opesa) |
| 21:02.16 | *** join/#maemo okias (~okias@berger.cust.centro-net.cz) |
| 21:03.34 | *** join/#maemo Dynamit (~Mohamed@84-55-71-67.customers.ownit.se) |
| 21:06.49 | *** join/#maemo _rd (~rd@p57B48270.dip0.t-ipconnect.de) |
| 21:14.04 | *** join/#maemo janemba (~101@unaffiliated/janemba) |
| 21:14.54 | *** join/#maemo nox- (noident@freebsd/developer/nox) |
| 21:24.01 | *** join/#maemo Kabouik_ (~quassel@123.22.95.79.rev.sfr.net) |
| 21:29.31 | *** join/#maemo Kabouik (~quassel@123.22.95.79.rev.sfr.net) |
| 21:29.56 | *** join/#maemo shamus (~shmaus@ip-206-192-193-180.marylandheights.ip.cablemo.net) |
| 21:32.06 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 21:42.58 | *** join/#maemo dos11 (~dos@unaffiliated/dos1) |
| 21:45.18 | *** join/#maemo eMHa (~mh@2a02:8071:2e81:c500:d6be:d9ff:fe2b:f21b) |
| 21:46.01 | *** join/#maemo Kabouik_ (~quassel@123.22.95.79.rev.sfr.net) |
| 22:11.03 | *** join/#maemo okias (~okias@berger.cust.centro-net.cz) |
| 22:15.16 | *** join/#maemo bef0rd (~bef0rd@unaffiliated/beford) |
| 22:16.03 | *** join/#maemo erlehmann (~erlehmann@82.113.121.32) |
| 22:22.15 | *** join/#maemo okias (~okias@berger.cust.centro-net.cz) |
| 22:27.03 | *** join/#maemo totalizator (~totalizat@89-69-49-198.dynamic.chello.pl) |
| 22:33.01 | *** join/#maemo florian (~fuchs@sign-4db6bc57.pool.mediaWays.net) |
| 22:33.01 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 22:41.11 | *** join/#maemo emma (~em@unaffiliated/emma) |
| 22:41.52 | *** join/#maemo teotwaki (~teotwaki@Maemo/community/contributor/crashanddie) |
| 22:45.03 | *** join/#maemo totalizator (~totalizat@89-69-49-198.dynamic.chello.pl) |
| 23:02.42 | *** join/#maemo Milhouse (~Milhouse@Maemo/community/contributor/Milhouse) |
| 23:16.07 | *** join/#maemo totalizator (~totalizat@89-69-49-198.dynamic.chello.pl) |
| 23:20.04 | *** join/#maemo dos1 (~dos@unaffiliated/dos1) |
