| 00:06.12 | *** join/#maemo amizraa (~amizraa@gateway/tor-sasl/amizraa) |
| 00:11.47 | *** join/#maemo louisdk (~louis@static-5-103-130-65.seas-nve.net) |
| 00:13.38 | *** join/#maemo valeriusL (~valerius@185.3.33.223) |
| 00:16.19 | *** join/#maemo valerius (~user@185.3.33.223) |
| 00:18.58 | *** join/#maemo fortytwo (~thomas@who.let.this.bloody.dropbear.in) |
| 00:20.08 | *** join/#maemo amonk (~amonk@unaffiliated/amonk) |
| 00:30.04 | b1101 | there isn't a buy/sell n900 thing in this channel right ? |
| 00:31.34 | ShadowJK | it's probably a bit low volume for that |
| 00:33.01 | b1101 | How much should I pay for a mint n900 with all accessories ? Looking at one on ebay. I've already contributed to the neo900 project, but can't stand using android anymore. I want my rights back :). |
| 00:33.56 | ShadowJK | I would personally pay 150 without accessories |
| 00:34.13 | ShadowJK | maybe 200 |
| 00:36.01 | b1101 | I like that this one is legitimate. Good pics show it's made in finland and all. I purchased a fake months ago, and was really upset. |
| 00:40.21 | *** join/#maemo triggerhappy (~quassel@112.209.21.95) |
| 00:40.25 | bef0rd | they could use legit pics and fake device though |
| 00:40.35 | bef0rd | I guess ebay/paypal protects you from that |
| 00:41.44 | b1101 | ya, ebay is usually on the customers side |
| 00:42.56 | *** join/#maemo amonk (~amonk@unaffiliated/amonk) |
| 00:45.45 | ShadowJK | The main batch were actually made in Korea, iirc |
| 01:14.56 | SpeedEvil | ShadowJK: indeed. |
| 01:16.53 | SpeedEvil | sighs and wishes he had the energy to do stuff that required coherent thought for more than a few minutes a day. |
| 01:18.11 | SpeedEvil | (Hence lack of doing interesting stuff like paying more attention to neo900 or proper involvment with jolla, or...) |
| 01:22.39 | ShadowJK | yes |
| 01:23.20 | ShadowJK | has spent his past 2 or so weeks of time off work mostly in bed silently cursing himself for not getting anything useful done |
| 01:27.20 | b1101 | ^in the same situation |
| 01:52.42 | *** join/#maemo Aggese (~Durand@ghs/durand) |
| 02:09.12 | SpeedEvil | has had his AC for ~2 weeks or so, and been unable to install it. |
| 02:10.27 | SpeedEvil | On a more sort-of-on-topic point - it raises the other issue (which is not strictly required but is made easier) - attacks based on fuzzing responses from the card - not data, but return codes, and packet formats. |
| 02:16.59 | *** join/#maemo mschlens (~mschlens@p5493673C.dip0.t-ipconnect.de) |
| 02:25.31 | DocScrutinizer05 | SpeedEvil: AC? |
| 02:28.01 | SpeedEvil | Air conditioning - for heating. Heat pump - COP 5.7 - to make it so I can actually heat this place to a reasonable level. |
| 02:28.19 | SpeedEvil | (10C in here) |
| 02:29.12 | FIQ | iirc only prototype N900s were made in finland? |
| 02:30.41 | *** join/#maemo qwazix (~qwazix@Maemo/community/council/qwazix) |
| 02:31.51 | DocScrutinizer05 | sounds about right |
| 02:33.43 | DocScrutinizer05 | SpeedEvil: I think a heating should improve your activity |
| 02:33.53 | SpeedEvil | DocScrutinizer05: It doesn't. |
| 02:34.17 | DocScrutinizer05 | at 10°C I also wouldn't be able to concentrate on anything |
| 02:34.30 | SpeedEvil | I'm on the sofa in a nice warm electric blanket. |
| 02:34.56 | DocScrutinizer05 | yeah, but that also automatically immobilzes you |
| 02:35.04 | SpeedEvil | Actually too hot at the moment. The problem is that I wobble when I get up to do anything, and my head is feeling packed by cotton wool. |
| 02:35.24 | DocScrutinizer05 | dang |
| 02:35.44 | *** join/#maemo Defiant (erik@e177194199.adsl.alicedsl.de) |
| 02:55.45 | *** join/#maemo muelli (~muelli@port-14371.pppoe.wtnet.de) |
| 03:46.02 | *** join/#maemo triggerhappy (~quassel@112.209.21.95) |
| 03:52.18 | *** join/#maemo jeverling (~quassel@jeverling.de) |
| 04:05.04 | *** join/#maemo psycho_oreos (~no@unaffiliated/tuxsavvy) |
| 04:06.33 | *** join/#maemo uen| (~uen@p5DCB1F41.dip0.t-ipconnect.de) |
| 04:13.23 | *** join/#maemo jeverling (~quassel@jeverling.de) |
| 04:27.08 | *** join/#maemo jeverling (~quassel@jeverling.de) |
| 04:30.43 | *** join/#maemo maybeHere (~cl@p5B164777.dip0.t-ipconnect.de) |
| 04:44.57 | *** join/#maemo Aggese (~Durand@ghs/durand) |
| 04:45.26 | *** join/#maemo jeverling (~quassel@jeverling.de) |
| 04:45.44 | *** join/#maemo goldkatze (~nobody@unaffiliated/goldkatze) |
| 04:52.41 | *** join/#maemo otep (~quassel@27.126.153.141) |
| 04:59.11 | *** join/#maemo Herbstbert_ (~Herbstber@drms-4d0d6315.pool.mediaWays.net) |
| 05:05.14 | *** join/#maemo triggerhappy_ (~quassel@112.209.21.95) |
| 05:45.19 | *** join/#maemo triggerhappy (~quassel@112.209.21.95) |
| 05:46.40 | *** join/#maemo Neutron3 (~neutron@36.80-202-98.nextgentel.com) |
| 05:52.31 | *** join/#maemo hubutm20 (~hubutm20@79.114.71.64) |
| 06:39.34 | *** join/#maemo RedW (~redw@89-73-179-171.dynamic.chello.pl) |
| 06:55.37 | *** join/#maemo b1101 (~b@66.55.152.53) |
| 07:06.37 | *** join/#maemo b1101 (~b@66.55.152.53) |
| 07:15.40 | *** join/#maemo Timmy (~quassel@unaffiliated/timmyt) |
| 07:37.30 | *** join/#maemo Agge (~Durand@ghs/durand) |
| 07:44.39 | *** join/#maemo jmlich (~jmlich@ip-78-102-111-118.net.upcbroadband.cz) |
| 08:08.28 | *** join/#maemo Smily (Smily@BSN-176-184-184.dial-up.dsl.siol.net) |
| 08:09.28 | *** join/#maemo sunny_s (~sunny_s@business-092-079-020-027.static.arcor-ip.net) |
| 08:38.08 | *** join/#maemo sunny_s (~sunny_s@business-092-079-020-027.static.arcor-ip.net) |
| 08:51.07 | *** join/#maemo OkropNick (kuba@host-n2-75-80.telpol.net.pl) |
| 08:52.58 | *** join/#maemo valeriusL (~valerius@85.26.186.68) |
| 08:53.24 | *** join/#maemo valerius (~user@85.26.186.68) |
| 08:53.37 | *** join/#maemo rcg (~rcg@aftr-37-24-149-205.unity-media.net) |
| 09:03.32 | *** join/#maemo jmlich (~jmlich@ip-78-102-111-118.net.upcbroadband.cz) |
| 09:11.58 | *** join/#maemo dhbiker (~dhbiker@APN-123-176-138-gprs.simobil.net) |
| 09:13.15 | *** join/#maemo zammy (~zammy@ppp-40-207.98-62.inwind.it) |
| 09:30.37 | *** join/#maemo LauRoman (~LauRoman@5-14-90-40.residential.rdsnet.ro) |
| 09:32.05 | *** join/#maemo LauRoman|Alt (~LauRoman@5-14-90-40.residential.rdsnet.ro) |
| 09:41.07 | *** join/#maemo arcean (~tomek@aaep147.neoplus.adsl.tpnet.pl) |
| 09:42.02 | *** join/#maemo LauRoman (~LauRoman@5-14-90-40.residential.rdsnet.ro) |
| 09:43.01 | *** join/#maemo valeriusL (~valerius@185.3.32.2) |
| 09:44.30 | *** join/#maemo valerius (~user@185.3.32.2) |
| 10:00.26 | *** join/#maemo NIN101 (~NIN@n900.quitesimple.org) |
| 10:02.14 | *** join/#maemo Timmy (~quassel@unaffiliated/timmyt) |
| 10:02.14 | *** join/#maemo sequantz (~sequantz@agbq180.neoplus.adsl.tpnet.pl) |
| 10:07.12 | *** join/#maemo valeriusL (~valerius@185.3.33.10) |
| 10:07.34 | *** join/#maemo eijk (~eijk@e178203122.adsl.alicedsl.de) |
| 10:13.00 | *** join/#maemo hubutm20 (~hubutm20@79.114.71.64) |
| 10:14.35 | *** join/#maemo valerius (~user@185.3.33.10) |
| 10:15.12 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 10:24.08 | *** join/#maemo xes (~xes@unaffiliated/xes) |
| 10:34.18 | DocScrutinizer05 | moinmaemoians |
| 10:35.52 | *** join/#maemo zemmy (~zammy@ppp-145-195.98-62.inwind.it) |
| 10:36.02 | *** join/#maemo trx (ns-team@devbin/founder/trx) |
| 10:36.04 | *** join/#maemo zummy (~sammy@ppp-145-195.98-62.inwind.it) |
| 10:42.32 | *** join/#maemo arcean_ (~tomek@aacw224.neoplus.adsl.tpnet.pl) |
| 10:49.17 | *** join/#maemo shentey (~shentey@e176199048.adsl.alicedsl.de) |
| 10:49.55 | *** join/#maemo muelli (~muelli@port-14371.pppoe.wtnet.de) |
| 10:59.16 | *** join/#maemo louisdk (~louis@static-5-103-130-65.seas-nve.net) |
| 11:03.28 | *** join/#maemo amonk (~amonk@unaffiliated/amonk) |
| 11:20.52 | *** join/#maemo at1as (~at1as@kurios.r4780y.com) |
| 11:27.53 | *** join/#maemo dafox (~dafox@ip51cc571d.speed.planet.nl) |
| 11:31.04 | *** join/#maemo valeriusL (~valerius@85.26.186.156) |
| 11:42.21 | *** join/#maemo valerius (~user@85.26.186.156) |
| 11:56.21 | *** join/#maemo eMHa__ (~mh@nat.de.netviewer.com) |
| 11:58.46 | *** join/#maemo torindel (~torindel@83-144-101-198.static.chello.pl) |
| 12:01.50 | *** join/#maemo nslu2-log_ (~nslu2-log@140.211.169.184) |
| 12:03.45 | *** join/#maemo Malinux_ (~quassel@149.174.189.109.customer.cdi.no) |
| 12:04.59 | *** join/#maemo inz_ (inz@idle.ircing.org) |
| 12:05.06 | *** join/#maemo mattaust1n (mattaustin@gateway/shell/blinkenshell.org/x-edpmndzcujjicjka) |
| 12:05.07 | *** join/#maemo torindel_ (~torindel@83-144-101-198.static.chello.pl) |
| 12:05.20 | *** join/#maemo joga_ (SeyRxcE6@rikki.fi) |
| 12:05.21 | *** join/#maemo oniongar1ic (~milang@tori.tal.org) |
| 12:05.24 | *** join/#maemo erstazi_ (~erstazi@static-71-116-30-43.eriepa.dsl-w.verizon.net) |
| 12:05.25 | *** join/#maemo qwazix_nc (~qwazix@78-14-177.static.cyta.gr) |
| 12:05.29 | *** join/#maemo qwazix_nc (~qwazix@Maemo/community/council/qwazix) |
| 12:05.30 | *** join/#maemo erstazi_ (~erstazi@unaffiliated/erstazi) |
| 12:05.31 | *** join/#maemo netkat_ (~me@80.79.126.176) |
| 12:05.34 | *** join/#maemo muellisoft (~muelli@port-14371.pppoe.wtnet.de) |
| 12:05.36 | *** join/#maemo cyborg-o1e (~cyborg-on@188-115-143-181.broadband.tenet.odessa.ua) |
| 12:05.53 | *** join/#maemo dhbiker_ (~dhbiker@APN-123-176-138-gprs.simobil.net) |
| 12:06.04 | *** join/#maemo ot0to (ototo@ec2-54-225-101-41.compute-1.amazonaws.com) |
| 12:06.50 | *** join/#maemo AndrewX192 (~andrew@131.191.110.77) |
| 12:07.25 | *** join/#maemo shamus (~shmaus@ip-206-192-193-180.marylandheights.ip.cablemo.net) |
| 12:07.57 | *** join/#maemo Humpelstilzchen (erik@e177194199.adsl.alicedsl.de) |
| 12:07.58 | *** join/#maemo NIN102 (~NIN@n900.quitesimple.org) |
| 12:08.20 | *** join/#maemo ototo (ototo@linaro/ototo) |
| 12:13.37 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 12:17.29 | *** join/#maemo Milhouse (~Milhouse@Maemo/community/contributor/Milhouse) |
| 12:22.28 | *** join/#maemo valerius (~user@85.26.186.156) |
| 12:25.49 | *** join/#maemo robotanarchy (~robotanar@g227025105.adsl.alicedsl.de) |
| 12:43.03 | *** join/#maemo sequantz (~sequantz@agbq180.neoplus.adsl.tpnet.pl) |
| 13:05.09 | *** join/#maemo GeneralAntilles (~ryan@Maemo/community/contributor/GeneralAntilles) |
| 13:05.34 | *** join/#maemo phlixi (~phlixi@ppp-188-174-167-178.dynamic.mnet-online.de) |
| 13:22.48 | *** join/#maemo valeriusL (~valerius@185.3.32.191) |
| 13:24.16 | *** join/#maemo dos1 (~dos@unaffiliated/dos1) |
| 13:25.19 | *** join/#maemo valerius (~user@185.3.32.191) |
| 14:07.13 | *** join/#maemo Defiant (erik@e177194199.adsl.alicedsl.de) |
| 14:17.42 | *** join/#maemo SmilyOrg (Smily@BSN-182-182-232.dial-up.dsl.siol.net) |
| 14:19.50 | *** join/#maemo iDont (~iDont@ip4da305b4.direct-adsl.nl) |
| 14:39.44 | *** join/#maemo Venemo (~Timur@fedora/Venemo) |
| 14:50.16 | *** join/#maemo netkat (~me@80.79.126.176) |
| 14:50.16 | *** join/#maemo Ninja (~ninja@74.61.222.224) |
| 14:51.42 | *** join/#maemo Gh0sty (~ghosty@213.219.156.171.adsl.dyn.edpnet.net) |
| 15:02.10 | *** join/#maemo dafox (~dafox@ip51cc571d.speed.planet.nl) |
| 15:11.21 | *** join/#maemo Aggese (~Durand@ghs/durand) |
| 15:35.28 | *** join/#maemo Agge (~Durand@ghs/durand) |
| 15:36.19 | *** join/#maemo FlameReaper (~assassin@jiz-211-123.tm.net.my) |
| 15:38.07 | *** join/#maemo goldkatze (~nobody@unaffiliated/goldkatze) |
| 15:41.12 | *** join/#maemo shanttu (~shanttu@dsl-hkibrasgw3-58c15a-136.dhcp.inet.fi) |
| 15:42.44 | *** join/#maemo FReaper (~assassin@jiz-211-123.tm.net.my) |
| 15:43.01 | *** join/#maemo AndrewX192 (~andrew@unaffiliated/andrewx192) |
| 15:50.38 | *** join/#maemo sLumPia (~sLumPia@182.7.204.3) |
| 15:52.41 | *** join/#maemo zemmy (~zammy@ppp-145-195.98-62.inwind.it) |
| 15:56.06 | sLumPia | sixwheeledbeast: Does ereswap support swapfile? |
| 15:56.39 | sLumPia | I only have one swap partition, but I would like to use ereswap |
| 16:00.01 | *** join/#maemo jmlich (~jmlich@ip-78-102-111-118.net.upcbroadband.cz) |
| 16:05.49 | *** join/#maemo fuz_ (nobody@vau75-10-88-164-23-88.fbx.proxad.net) |
| 16:12.11 | DocScrutinizer05 | swapfile isn't working on stock maemo kernel afaik |
| 16:12.41 | sLumPia | I am not using stock kernel |
| 16:12.52 | DocScrutinizer05 | dunno about KP |
| 16:13.20 | freemangordon | even if it works, I don;t think it makes much of a sense |
| 16:14.13 | sLumPia | Yeah I know |
| 16:15.39 | sLumPia | I thought at least ereswap can turn off my swap partition for a minute, use swapfile, then turn on swap partition again |
| 16:15.54 | *** join/#maemo Aggese (~Durand@ghs/durand) |
| 16:16.07 | DocScrutinizer05 | dividing the existing 768MB swap partition into two halves should work great, it seems Nokia just used 768MB for marketing and fragmentation reasons. A system that actually is in a status where it needs 768MB swap isn't usable by any metrics anyway |
| 16:16.10 | *** join/#maemo solofight (kvirc@115.242.172.181) |
| 16:16.25 | DocScrutinizer05 | fragmentation would become irrelevant with reswap |
| 16:17.30 | sLumPia | Well, I guess there is also that option |
| 16:18.37 | sLumPia | So 389 MB enough for Maemo's swap partition? |
| 16:18.55 | sLumPia | We don't really need big swap partition? |
| 16:19.18 | DocScrutinizer05 | well, I personally never needed 768MB |
| 16:19.45 | sLumPia | I thought Maemo need bigger swap, because its lack of ram |
| 16:19.58 | DocScrutinizer05 | actually it's hard to get the printout that shows swap usage >400MB, since the system already came to a grinding halt |
| 16:21.05 | sLumPia | I'm sorry, how do you know how much swap already used by Maemo? |
| 16:21.20 | DocScrutinizer05 | err, e.g. look at htop or top |
| 16:21.21 | freemangordon | free? |
| 16:21.26 | DocScrutinizer05 | or that |
| 16:21.30 | freemangordon | cat /proc/swaps? |
| 16:21.34 | DocScrutinizer05 | or that |
| 16:21.36 | freemangordon | :) |
| 16:22.17 | sLumPia | lol, I don't know free show swap usage. |
| 16:22.18 | sLumPia | Silly me |
| 16:22.51 | sLumPia | I only look at memory usage when use free |
| 16:22.55 | sLumPia | Ok guys |
| 16:22.57 | sLumPia | Thanks |
| 16:23.26 | sLumPia | I will just devide my swap partition |
| 16:28.11 | *** join/#maemo Kabouik (~quassel@171.152.84.79.rev.sfr.net) |
| 16:31.46 | solofight | I opened the application manager and there is a list of apps for which i need to click, open the terms agreement and the click on details, and description to read about the app.... can i see th elist of apps on a web page somewhere to quickly check them ? |
| 16:42.24 | solofight | i have installed recaller which records all calls into a folder.. the problem is those recorded voices are getting played inbetween songs with the music player |
| 16:42.24 | solofight | any ways to avoid that ? |
| 16:43.18 | solofight | 3. My friends view the gallery often, how can i avoid showing private pictures as a part of the gallery ? |
| 16:49.00 | *** join/#maemo sunny_s (~sunny_s@business-092-079-020-027.static.arcor-ip.net) |
| 16:49.52 | Arkenoi | damn. my *THIRD* n950 suffers from screen rot :-( |
| 16:56.54 | SpeedEvil | :( |
| 16:57.39 | ShadowJK | screen rot$ |
| 16:59.39 | *** join/#maemo Agge (~Durand@ghs/durand) |
| 17:00.03 | ShadowJK | ? |
| 17:02.58 | DocScrutinizer05 | Arkenoi: how the heck did you manage to get THREE n950? |
| 17:04.32 | DocScrutinizer05 | Arkenoi: I guess you found out the hard way about why N950 never went to official sales |
| 17:05.11 | ShadowJK | You know how some people create a 2partition on ssd, 10-20% size, and leave it unused, in order to improve ssd perform |
| 17:05.32 | *** join/#maemo fuz_ (nobody@vau75-10-88-164-23-88.fbx.proxad.net) |
| 17:05.32 | DocScrutinizer05 | the hinge pushing hard against LCD's back, ruining it when you're not gentle and careful when opening up the kbd |
| 17:05.35 | ShadowJK | why I have 2g swap on uSD |
| 17:07.30 | *** join/#maemo goldkatze (~nobody@unaffiliated/goldkatze) |
| 17:08.32 | DocScrutinizer05 | ShadowJK: we discussed that recently, no? the controller on SD needs to erase pages that don't have data, so they can take new data written to them. This erasing can happen async on a background task as long as there are sufficient pages already erased so a write can copy&modify the data from one page to an empty new page |
| 17:09.10 | DocScrutinizer05 | obviously that background erasing of empty pages depends on empty pages _existing_ |
| 17:10.05 | DocScrutinizer05 | otherwise worst case (when _all_ pages hold relevant data) the controller needs to read-modify-erase-write the same erasepage on flash |
| 17:10.42 | DocScrutinizer05 | which slows down each write to ~50ms or whatever it takes to erase a page |
| 17:11.07 | DocScrutinizer05 | might also be 100 or even 200ms, I can't recall |
| 17:11.48 | ShadowJK | I would say nothing happens in background on SD/emmc |
| 17:12.49 | DocScrutinizer05 | while in the long run the performance on SD can't get inproved by keeping empty pages, they nevertheless make a convenient stash of instantly writable pages that can get used up by write action, before that throttling for erase kicks in |
| 17:13.21 | DocScrutinizer05 | ShadowJK: I'd say when they don't do that background erasing, they are pretty dull |
| 17:14.26 | DocScrutinizer05 | why wouldn't they implement flash management in eactly this way? |
| 17:14.36 | DocScrutinizer05 | it seems obvious and natural |
| 17:15.42 | ShadowJK | host devices drop voltage and clock when sd is idle, so it pretty much doesn't even run at all if the host isn't actively writing/reading, no opportunity for background tasks |
| 17:16.02 | DocScrutinizer05 | I'm sure you know that it's not the writing of "1" bits that takes time, but the erasing of whole page to all-zeroes |
| 17:16.06 | *** join/#maemo louisdk (~louis@static-5-103-130-65.seas-nve.net) |
| 17:16.41 | ShadowJK | Sure |
| 17:17.08 | DocScrutinizer05 | well, then they can't continue their background task when voltage dropped. That's pretty trivial. It however doesn't defeat the original idea |
| 17:17.32 | ShadowJK | But the read-write-modify cycles are what hurts performance the worst |
| 17:18.03 | DocScrutinizer05 | hm? |
| 17:21.24 | DocScrutinizer05 | the OS may write to several sectors on same erasepage. During that the SD can write to that erasepage without erasing it, and in background can erase "unused" erasepages. The very moment the OS wants to write a 0 to a bit that previously had a 1, the controller on SD will need to do a read-modify-write action and use an erased erasepage as destination for that. Same moment the controller schedules a deferred page-erase on the original, |
| 17:21.25 | DocScrutinizer05 | now unused, erasepage |
| 17:22.06 | ShadowJK | For example, host writes a tiny file to ext3, 4k written for tiny file, 4k to journal, 4k to ext3 metadata. 3 places in different locations. The first 4k gets written to a page in a newly erased block, when the next request comes in, the SD controller has to "close" the current block, so it reads in 4M-4k from the old block, writes it to its new block, and proceeds on with the second of the 3 4k requests |
| 17:22.20 | ShadowJK | this is what happens in practice on most SDs |
| 17:23.09 | ShadowJK | This describes most Kingston cards actually |
| 17:23.29 | DocScrutinizer05 | whatever happens in practice, the controller can always follow the "erase pages in background" policy |
| 17:23.32 | ShadowJK | while high-end cards are able to keep 8-12 open simultaneously |
| 17:24.08 | ShadowJK | sure, but it's the 4M read-modify-write that hurts more than erases.. |
| 17:24.26 | DocScrutinizer05 | I seriously doubt that |
| 17:24.37 | DocScrutinizer05 | it's known that erase takes AGES |
| 17:24.49 | DocScrutinizer05 | while write is relatively fast compared to that |
| 17:25.06 | ShadowJK | Well it's a factor of 2 or 3 |
| 17:25.27 | *** join/#maemo zemmy (~zammy@ppp-145-195.98-62.inwind.it) |
| 17:25.42 | ShadowJK | While read-modify-write write amplification is a factor 1000 speed difference |
| 17:26.11 | DocScrutinizer05 | and actually it doesn't matter how much the erase hurts, since you can not compensate the one with the other. When you can avoid sync erase, you will do it |
| 17:27.13 | DocScrutinizer05 | and what you tell about your read-modify-write is actually exactly the problem that write takes an erased page |
| 17:27.28 | DocScrutinizer05 | otherwise you can't write modified content |
| 17:28.30 | ShadowJK | The amount of "half erased/written" blocks a sd can keep track of is a major influence on speed |
| 17:28.45 | DocScrutinizer05 | and since your unused partition reserves some erase pages for unused, it speeds up exactly those read-modify-([no]erase)-write cycles |
| 17:29.26 | ShadowJK | It helps the kernel more really :) |
| 17:29.31 | DocScrutinizer05 | there's no such thing like a half-erased erasepage |
| 17:29.33 | *** join/#maemo zemmy (~zammy@ppp-145-195.98-62.inwind.it) |
| 17:29.41 | DocScrutinizer05 | erasing a page is a parallel process |
| 17:29.43 | ShadowJK | partially written to |
| 17:30.05 | ShadowJK | Some cards can deal with two sequential write streams, some can't |
| 17:30.18 | DocScrutinizer05 | maybe |
| 17:30.28 | DocScrutinizer05 | I don't see how that contrdict what I said |
| 17:31.04 | ShadowJK | the net effect, however, is that non-sequential writes are horribly slow, and sequential writes are fast |
| 17:32.04 | DocScrutinizer05 | and basically a controller doesn't need at all keep track of write fill of a page. It just needs to check if modify changed a bit from 1 to 0, which qualifies for a copy from old to new empty erasepage |
| 17:33.50 | DocScrutinizer05 | unless you use a layer above that to tak invalid sectors and use a next sector in same hash chain that may or may not be on same erasepage. But even then the basic principle on lowest level still stays unchanged and applies |
| 17:34.05 | DocScrutinizer05 | s/tak /tag / |
| 17:34.46 | ShadowJK | Maemo kernel's swapout tries to write sequentially, it basically checks swap area for free space, sets a pointer to start of biggest continous chunk of free space, and writes sequentially into that chunk until it reaches the end, and then looks for another free chunk. With time the data gets spread out almost uniformly across the swap area, so the free area becomes smaller and smaller. Each time crossing an erase block boundary costs anout the same in terms of |
| 17:34.52 | ShadowJK | <PROTECTED> |
| 17:35.37 | ShadowJK | With a huge swap partition but same 120-180M or so swapped out, the space in between occupied sectors grows larger, and it doesn't cross erase page boundaries as often |
| 17:35.49 | DocScrutinizer05 | yes, sure |
| 17:36.33 | DocScrutinizer05 | but how is that related to flash controller now? |
| 17:37.03 | DocScrutinizer05 | and particularly to keeping an unused partition to speed up stuff |
| 17:37.18 | ShadowJK | If it was as capable as a full SSD, it wouldn't matter in which order host wrote stuff |
| 17:37.48 | DocScrutinizer05 | errr, mhm |
| 17:38.40 | ShadowJK | Proper SSDs like Intel's 3700 reorders everything, constantly. :-) |
| 17:39.19 | DocScrutinizer05 | sorry, can't parse that |
| 17:39.32 | DocScrutinizer05 | aah, yep, can |
| 17:40.02 | *** join/#maemo Aggese (~Durand@ghs/durand) |
| 17:40.13 | ShadowJK | Internally they work almost like maemo swapout, except they gc when stuff gets fragmented. And like maemo kernel swapout, the less actual data, the easier time it has to gc and reorder |
| 17:40.31 | DocScrutinizer05 | maybe they reorder everything, constantly. How would I even know? I however would think it would be silly to do additional writes and page erases just to reorder something |
| 17:41.38 | DocScrutinizer05 | I fail to remember what we're discussing about |
| 17:42.11 | DocScrutinizer05 | I suggested that a user shall split his swap into two equal halves as maemo never uses 768MB anyway |
| 17:42.25 | DocScrutinizer05 | and I think that's been a correct advice |
| 17:42.30 | *** join/#maemo MrPingu (~MrPingute@ip503c83e7.speed.planet.nl) |
| 17:43.18 | ShadowJK | I'm just saying with huge swap partition, swap fragmentation effects become minimal enough there's no noticeable benefit to swapoff/swapon |
| 17:43.38 | DocScrutinizer05 | while the initial statement of this discussion seems [2013-12-30 18:05:11] <ShadowJK> You know how some people create a 2partition on ssd, 10-20% size, and leave it unused, in order to improve ssd perform |
| 17:44.22 | DocScrutinizer05 | which, on a second thought, I seem to have problems to parse correctly |
| 17:44.48 | DocScrutinizer05 | I don't know how they do that |
| 17:45.43 | DocScrutinizer05 | but I guess it's done to give the flash controller some headroom to do page copy and background erase |
| 17:45.58 | ShadowJK | I found it interesting, that people independent of myself use the same method as I do with swap, to help the SSD controller maintain performance |
| 17:46.50 | ShadowJK | But then, the ssd controller and the maemo kernel swapout are operating with similar constraints, so it shouldn't be too surprising that similar tricks help both |
| 17:48.53 | ShadowJK | Most USB3 flash keys illustrate the constraints beautifully. 100 megabytes/sec write speed for sequential writes, 0.01 megabyte/sec for nonsequential writing :-) |
| 17:49.39 | DocScrutinizer05 | watching a defragmentizer with graphical progress display doing its job on a disl fille at 75% and a disk filled at 98% gives you an instant idea why it helps to keep some space unused on storage |
| 17:50.00 | ShadowJK | (Except "Sandisk Extreme", they put an SSD inside it, and it eats 500mA of current) |
| 17:50.36 | DocScrutinizer05 | s/disl fille/disk filled/ |
| 18:00.00 | DocScrutinizer05 | (([2013-12-30 18:43:18] <ShadowJK> I'm just saying with huge swap partition, swap fragmentation effects become minimal enough there's no noticeable benefit to swapoff/swapon)) Wasn't it you who shown impressive diagrams about fragmentation kicking in after all available swap space been written once sequentially? |
| 18:00.48 | DocScrutinizer05 | and those diagrams didn't look like they want to suggest that increasing swap size could fundamentally change that situation |
| 18:01.02 | *** join/#maemo ssvb (~ssvb@212.16.98.80) |
| 18:01.49 | DocScrutinizer05 | it just takes longer until all available swap got used one time and this swap "filled up" with random data fragments cluttered all over the place |
| 18:03.31 | ShadowJK | Imagine 128M swap in use, worst case fragmentation of that 128M divided into 4k pieces and spread uniformly across the swapspace. If the swapspace is 256M big, that would mean worst case fragmentation is 4k free, 4k used, interleaved across entire device. With 1 gig swapspace, the situation improves to 4k pieces interleaved with 16k free |
| 18:03.58 | DocScrutinizer05 | and when the swap daemon want to reuse a freed slot that previously been used for storing some data, this is a modify on the erasepage and thus needs a page erase and page copy |
| 18:04.17 | ShadowJK | yes |
| 18:04.47 | ShadowJK | hm, would be interesting to make the kernel provide statistics on this :-) |
| 18:12.00 | DocScrutinizer05 | btw the "problem" is that SD is a persistent storage. There's basically never a situation of a "virgin" storage section, unless you use those special new commands that tell the controller to simply erase and leave *empty* the rest of the erasepage |
| 18:12.48 | DocScrutinizer05 | otherwise each erased page will inherit all the obsolete garbage of its ancestor, on read-modify-copywrite |
| 18:13.40 | DocScrutinizer05 | since the flash jas no idea which of the data blocks are considered "free" and which contain valid swap data |
| 18:14.05 | DocScrutinizer05 | considered by the swapd for example, that is |
| 18:14.43 | *** join/#maemo SAiF (~SAiF@117.196.133.57) |
| 18:15.04 | DocScrutinizer05 | thus the whole "fragmentation" actually only happens in swapd's RAM based allocation table |
| 18:15.25 | DocScrutinizer05 | while flash/SD always is "fragmented" |
| 18:16.08 | DocScrutinizer05 | afer a certain timespan of usage, with sufficient IO |
| 18:16.59 | DocScrutinizer05 | nd I guess not even a mkfs or other format program usually will fix that flash fragmentation, unless it's a specialized flash formatter |
| 18:17.26 | *** join/#maemo zummy (~zammy@ppp-145-195.98-62.inwind.it) |
| 18:18.38 | ShadowJK | For simplicity, I always consider SD fragmented and having only one block it can erase |
| 18:18.54 | *** join/#maemo sviridova (~sviridova@91.210.101.185) |
| 18:19.43 | DocScrutinizer05 | I honestly wonder if writing all zeroes to flash would help |
| 18:20.19 | DocScrutinizer05 | when controller is smart (and doesn't work erase-to-ones) it might actually help a lot with write speed |
| 18:22.07 | ShadowJK | I have cards where it helps |
| 18:22.22 | ShadowJK | But the speed boost is pretty short lived |
| 18:23.02 | ShadowJK | I also have cards where writing anything at all sequentially gives boost to future random write :-) |
| 18:25.19 | ShadowJK | Those cards typically have a small log-structured SLC cache or "journal" internally, small writes go into its cache, big writes blows away the cache and leaves it free |
| 18:26.14 | ShadowJK | It's obviously empty when new, and its size seems to be carefully sized to match the workload presented by running crystaldiskmark, a popular disk benchmark, with the default settings |
| 18:26.32 | ShadowJK | second run of crystaldiskmark gives entirely different and worse results :D |
| 18:27.04 | *** join/#maemo murova (~murova@91.210.103.201) |
| 18:32.55 | *** join/#maemo bef0rd (~bef0rd@unaffiliated/beford) |
| 18:49.20 | MrPingu | Hi guys, long time no see! |
| 18:49.31 | ShadowJK | hai |
| 18:49.57 | SpeedEvil | hai |
| 18:52.18 | MrPingu | Been a bit busy and were not able to play and use my N900, hope I haven't missed some fun |
| 18:54.34 | MrPingu | Saw that MCE is REed, anymore big news? |
| 18:55.18 | MrPingu | Just the headlines, I can find the rest myself ^^ |
| 19:08.03 | *** join/#maemo eMHa__ (~mh@nat.de.netviewer.com) |
| 19:14.07 | ShadowJK | reads tmo threads from 2012 |
| 19:14.19 | ShadowJK | I guess 2010 or 2011 was last time I read tmo |
| 19:16.17 | sixwheeledbeast | wonders why sLumPia was asking me about ereswap. |
| 19:18.40 | DocScrutinizer05 | MrPingu: hi! |
| 19:19.29 | DocScrutinizer05 | http://talk.maemo.org/showthread.php?t=91142 |
| 19:19.34 | DocScrutinizer05 | MrPingu: ^^^ |
| 19:21.04 | MrPingu | That's some interesting project. |
| 19:24.34 | sixwheeledbeast | also #neo900 :) |
| 19:24.37 | MrPingu | Seems I need to plant another money-tree... |
| 19:24.51 | MrPingu | :P |
| 19:26.09 | *** join/#maemo at1as (~at1as@kurios.r4780y.com) |
| 19:27.38 | *** join/#maemo Timmy (~quassel@unaffiliated/timmyt) |
| 19:27.52 | *** join/#maemo ssvb (~ssvb@212.16.98.80) |
| 19:33.16 | *** join/#maemo nox- (noident@freebsd/developer/nox) |
| 19:36.39 | *** join/#maemo Aggese (~Durand@ghs/durand) |
| 19:38.30 | anYc | does anyone else has two battery icons after the latest cssu update? |
| 19:39.00 | *** join/#maemo Agge (~Durand@ghs/durand) |
| 19:43.17 | MrPingu | anYc, do you have advanced power installed? |
| 19:47.26 | anYc | hm, I think yes |
| 19:51.02 | *** join/#maemo rcg (~rcg@aftr-37-24-149-205.unity-media.net) |
| 19:52.02 | MrPingu | Uninstall that ;) |
| 19:52.22 | MrPingu | The new batteryicon give the same information AFAIK |
| 19:58.24 | anYc | okay, I'll try that, thanks :) |
| 19:59.27 | *** join/#maemo freemangordon (~freemango@46.249.74.23) |
| 20:00.00 | *** join/#maemo messerting (~messertin@cm-84.209.22.230.getinternet.no) |
| 20:00.38 | MrPingu | anYc: You're welcome |
| 20:04.35 | *** join/#maemo eMHa (~mh@HSI-KBW-37-49-78-45.hsi14.kabel-badenwuerttemberg.de) |
| 20:16.20 | *** join/#maemo arcean (~arcean@aacw224.neoplus.adsl.tpnet.pl) |
| 20:24.10 | *** join/#maemo int_ua (~int_ua@ip-602f.proline.net.ua) |
| 20:25.13 | *** join/#maemo NIN101 (~NIN@n900.quitesimple.org) |
| 20:27.16 | *** join/#maemo valeriusL (~valerius@185.3.35.204) |
| 20:29.15 | *** join/#maemo shentey (~shentey@e176199048.adsl.alicedsl.de) |
| 20:29.24 | *** join/#maemo valerius (~user@185.3.35.204) |
| 20:50.28 | *** join/#maemo eijk (~eijk@e178203122.adsl.alicedsl.de) |
| 21:01.34 | *** join/#maemo Guest81604 (~dafox@ip51cc57fc.speed.planet.nl) |
| 21:09.43 | *** join/#maemo amonk (~amonk@unaffiliated/amonk) |
| 21:13.31 | *** join/#maemo Aggese (~Durand@ghs/durand) |
| 21:17.04 | *** join/#maemo mvp_ (~mvp@port463.ds1-abc.adsl.cybercity.dk) |
| 21:30.02 | *** join/#maemo ALoGeNo (~alogeno@unaffiliated/alogeno) |
| 21:39.02 | *** join/#maemo eijk_ (~eijk@e178209230.adsl.alicedsl.de) |
| 21:42.07 | *** join/#maemo sequantz (~sequantz@agbq180.neoplus.adsl.tpnet.pl) |
| 21:50.51 | *** join/#maemo croppa (~stuart@14.14.233.220.static.exetel.com.au) |
| 22:06.44 | *** join/#maemo zemmy (~zammy@ppp-145-195.98-62.inwind.it) |
| 22:07.38 | *** join/#maemo Aggese (~Durand@ghs/durand) |
| 22:14.50 | *** join/#maemo Agge (~Durand@ghs/durand) |
| 22:17.54 | *** join/#maemo MrPingu (~MrPingute@ip503c83e7.speed.planet.nl) |
| 22:19.08 | *** join/#maemo at1as (~at1as@kurios.r4780y.com) |
| 22:23.56 | *** join/#maemo robotanarchy_ (~robotanar@f051038220.adsl.alicedsl.de) |
| 22:28.39 | *** join/#maemo Aggese (~Durand@ghs/durand) |
| 22:29.57 | *** join/#maemo eijk_ (~eijk@e178209230.adsl.alicedsl.de) |
| 22:32.06 | *** join/#maemo valeriusL (~valerius@185.3.35.33) |
| 22:33.58 | *** join/#maemo valerius (~user@185.3.35.33) |
| 22:39.14 | *** join/#maemo zemmy (~zammy@ppp-145-195.98-62.inwind.it) |
| 22:40.00 | *** join/#maemo MrPingu (~MrPingute@ip503c83e7.speed.planet.nl) |
| 22:45.36 | *** join/#maemo Luke-Jr (~luke-jr@unaffiliated/luke-jr) |
| 22:45.44 | *** join/#maemo eijk (~eijk@e178209230.adsl.alicedsl.de) |
| 22:46.14 | *** join/#maemo Luke-Jr (~luke-jr@unaffiliated/luke-jr) |
| 22:47.01 | *** join/#maemo lexik (~user@99.182.broadband9.iol.cz) |
| 22:47.34 | *** join/#maemo arcean (~arcean@aacw224.neoplus.adsl.tpnet.pl) |
| 22:47.43 | *** join/#maemo Luke-Jr (~luke-jr@unaffiliated/luke-jr) |
| 22:48.37 | *** join/#maemo zemmy (~zammy@ppp-145-195.98-62.inwind.it) |
| 22:48.52 | *** join/#maemo Luke-Jr (~luke-jr@unaffiliated/luke-jr) |
| 22:49.34 | *** join/#maemo Luke-Jr (~luke-jr@unaffiliated/luke-jr) |
| 22:49.39 | *** join/#maemo croppa (~stuart@14.14.233.220.static.exetel.com.au) |
| 22:53.45 | *** join/#maemo zummy (~zammy@ppp-145-195.98-62.inwind.it) |
| 22:58.12 | *** join/#maemo zemmy (~zammy@ppp-145-195.98-62.inwind.it) |
| 23:01.23 | *** join/#maemo sunny_s (~sunny_s@business-092-079-020-027.static.arcor-ip.net) |
| 23:03.15 | *** join/#maemo basiaf (~basiaf@2a01:238:433a:c200::1) |