| 00:25.10 | *** join/#qi-hardware cladamw (~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw) |
| 01:07.13 | *** join/#qi-hardware antgreen (~user@CPE0021910f07ac-CM0019477f82fc.cpe.net.cable.rogers.com) |
| 01:12.03 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 01:27.30 | *** join/#qi-hardware Openfree` (~Openfreer@116.228.88.131) |
| 01:45.32 | *** join/#qi-hardware cladamwa (~Adam@host-222.80-43-115.dynamic.totalbb.net.tw) |
| 02:49.46 | *** join/#qi-hardware xiangfu (~xiangfu@123.115.14.226) |
| 02:54.11 | qi-bot | [commit] Werner Almesberger: m1/xbrd/: reduced CB from 25 mm to 22 mm, reducing overall length to 82.08 mm (master) http://qi-hw.com/p/wernermisc/5bf0b30 |
| 03:00.01 | *** join/#qi-hardware xian9fu (~xiangfu@fidelio.qi-hardware.com) |
| 03:02.06 | *** join/#qi-hardware orson_zhai (~orson@1.202.15.210) |
| 04:09.13 | *** join/#qi-hardware AwAyla (~paul@78.173.72.86.rev.sfr.net) |
| 04:59.58 | xian9fu | kristianpaul, Hi I tried milkyminer some days ago. |
| 05:00.15 | xian9fu | this one: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkyminer-firmware-20120401-0837/ |
| 05:00.33 | xian9fu | I flash the soc.fpg by 'm1nor soc.fpg' then |
| 05:01.14 | xian9fu | it's only worked once. spend 5 minutes for get the result. then what even I send to milkyminer. nothing return. |
| 05:01.56 | xian9fu | do you think we should build the 'soc' branch? |
| 05:21.30 | *** join/#qi-hardware jekhor (~jek@leased-line-46-53-195-5.telecom.by) |
| 05:27.14 | *** join/#qi-hardware cladamw (~Adam@host-222.80-43-115.dynamic.totalbb.net.tw) |
| 06:26.10 | kyak | xian9fu: do you have an idea why this error happens from time to time (ERROR: "irq_set_chip_and_handler_name" [drivers/ieee802154/spi_atusb.ko] undefined!)? |
| 06:26.35 | kyak | i mean, during the build, which has failed |
| 06:27.22 | kyak | xian9fu: also, what's the difference between ~xiangfu/build-nanonote/ and ~xiangfu/building/Nanonote/Ben/ ? |
| 06:28.12 | xian9fu | when build was success it will move to ~xiangfu/building/Nanonote/Ben/ |
| 06:28.17 | kyak | it seems like the minimal build always fails |
| 06:28.36 | xian9fu | sorry. all success will move to ~xiangfu/build-nanonote/ |
| 06:28.48 | kyak | perhaps we miss something from config-minimal |
| 06:29.41 | xian9fu | kyak, we should not build atusb.ko under config.minimal. I think I already disable that. |
| 06:30.56 | kyak | ok.. is it building in a loop or you start it manually? |
| 06:32.38 | xian9fu | building in a loop |
| 06:32.56 | xian9fu | http://fidelio.qi-hardware.com/~xiangfu/bin/qi-hardware-build.sh and http://fidelio.qi-hardware.com/~xiangfu/bin/compile.sh |
| 06:33.25 | *** join/#qi-hardware antgreen` (~user@CPE0021910f07ac-CM0019477f82fc.cpe.net.cable.rogers.com) |
| 06:35.11 | kyak | cool, so it started the full build now |
| 06:35.33 | xian9fu | yes. |
| 06:37.45 | xian9fu | I think the at_usb.h miss the irq.h |
| 06:40.08 | xian9fu | s/at_usb.h/at_usb.c |
| 06:40.09 | qi-bot | xian9fu meant: "I think the at_usb.c miss the irq.h" |
| 06:40.15 | xian9fu | spi_atusb.c |
| 06:44.19 | xian9fu | testing the spi_atusb now... (by add irq.h) |
| 06:44.28 | kyak | looks like this.. wonder why it works in full image |
| 06:45.11 | xian9fu | kyak, full image don't build spi_atusb |
| 06:45.38 | xian9fu | disabled under config.full |
| 06:46.02 | kyak | ah! |
| 06:56.07 | *** join/#qi-hardware DocScrutinizer (~halley@openmoko/engineers/joerg) |
| 07:06.08 | *** join/#qi-hardware GeorgeH_ (~George@c-69-141-105-145.hsd1.nj.comcast.net) |
| 07:21.06 | *** join/#qi-hardware cladamw (~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw) |
| 07:28.10 | *** join/#qi-hardware orson_zhai (~orson@1.202.15.210) |
| 07:45.23 | *** join/#qi-hardware cladamw (~Adam@host-222.80-43-115.dynamic.totalbb.net.tw) |
| 07:57.10 | qi-bot | [commit] Xiangfu: nanonote: config.minimal: disable spi_atusb since we don't have usb host (master) http://qi-hw.com/p/openwrt-packages/e702c87 |
| 07:57.42 | xian9fu | kyak, I just disable the atusb under minimal config. I cannot find out the root cause faster. disable it first. when I work on WPAN patches. will try to make it working. |
| 07:58.21 | kyak | xian9fu: atusb doesn't make sense for Ben anyway, right? |
| 07:58.38 | xian9fu | right. we don't ahve usb host. |
| 08:09.50 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 09:55.55 | *** join/#qi-hardware jivs_ (~jivs@nat-sta-slph1.tvu.ac.uk) |
| 09:57.39 | *** part/#qi-hardware orson_zhai (~orson@1.202.15.210) |
| 10:15.39 | wpwrak | kyak: you'd have to implement USB host first :) |
| 10:15.53 | wpwrak | now, that's marketing: (in german, sorry) http://www.heise.de/newsticker/meldung/Raspberry-Pi-erhaelt-CE-Kennzeichnung-1517687.html |
| 10:17.09 | wpwrak | perhaps we should make a press release whenever Milkymist creator and chief architect Sebastien had a good morning dump ? ;-) |
| 10:22.38 | lekernel | chief architect has better plans, like turning the patch editor into something a bit like the first parts of this: http://vimeo.com/36579366 |
| 10:28.37 | wolfspraul | here's hoping that migen gives an upside in several directions |
| 10:30.37 | lekernel | well this will come after migen. migen is about making the SoC more featureful, faster and more portable. |
| 10:33.37 | wpwrak | lekernel: (immediate feedback) sounds nice |
| 10:48.31 | *** join/#qi-hardware zrafa_ (~rafa@190.14.174.29) |
| 11:32.45 | *** join/#qi-hardware wej (~j@95.211.92.234) |
| 12:03.55 | viric | So, there is a working linux on milkymist SoC already? |
| 12:04.01 | lekernel | uclinux |
| 12:04.06 | viric | ah ok, no mmu |
| 12:04.21 | lekernel | Fallenou is working on a MMU |
| 12:04.31 | viric | ok |
| 12:04.36 | lekernel | you can, too. that's the beauty of MM SoC. |
| 12:04.42 | viric | :) clear |
| 12:04.55 | viric | If you want to be well served, make the bed yourself. |
| 12:09.39 | *** join/#qi-hardware jekhor (~jek@mx2.promwad.com) |
| 12:35.21 | wolfspraul | viric: we can get you interested in Milkymist? :-) |
| 12:41.24 | viric | I'm interested in seeing some information about its software performance and power usage. |
| 12:42.02 | wolfspraul | right now it runs an RTEMS realtime/minikernel, and a specific app on top of that for the video synthesis |
| 12:42.09 | viric | aha |
| 12:42.09 | wolfspraul | power consumption is about 5W total |
| 12:42.24 | viric | with how much ram? |
| 12:42.31 | wolfspraul | 128 megabytes ddr1 |
| 12:42.44 | wolfspraul | I don't think the ram's power consumption matters much at all btw |
| 12:42.50 | wolfspraul | but I have no exact number right now |
| 12:42.52 | viric | ok |
| 12:43.23 | viric | Could you publish a run of "openssl speed" in it? |
| 12:43.41 | wolfspraul | sorry don't understand. what exactly do you want to execute? |
| 12:43.48 | viric | "openssl speed" |
| 12:44.03 | viric | I imagine you can run openssl there. :) |
| 12:45.16 | viric | I don't know much about benchmarking... I use 'openssl speed' everywhere, when I want to compare performances. |
| 12:45.23 | wolfspraul | actually I don't think openssl is ported to m1 today |
| 12:45.40 | viric | it should be ansic code |
| 12:46.11 | wolfspraul | sure someone could do it |
| 12:46.20 | viric | ok |
| 12:46.31 | viric | well, I mean it's a benchmark quite broad and easy to build :) |
| 12:47.03 | wolfspraul | it's not very 'meaningful' for m1, but I 100% agree we should first publish any benchmark, so people have a starting point for their thinking |
| 12:47.21 | wolfspraul | you could then proceed to a hardware accelerated openssl speed benchmark :-) |
| 12:51.50 | *** join/#qi-hardware Ayla (~paul@241.45.123.78.rev.sfr.net) |
| 13:00.02 | *** join/#qi-hardware LunaVorax (~LunaVorax@ABordeaux-651-1-155-243.w109-222.abo.wanadoo.fr) |
| 13:03.49 | wolfspraul | I'm trying to build a mobile & rechargeable battery pack for an m1 setup |
| 13:04.07 | wolfspraul | so basically I need 12V and 5V out of it |
| 13:06.30 | wolfspraul | I found nice little battery packs like this one http://www.iphonemili.com/products_detail/&productId=8f5df92b-03a0-441f-91bb-d444f512a769&comp_stats=comp-FrontProducts_list01-1311553918454.html |
| 13:07.02 | wolfspraul | so that works well, but I would like to use standard batteries, something more flexible |
| 13:07.33 | wolfspraul | I was hoping to find teeny tiny dc-dc converters that just allow me to put some wide voltage in, and get a stable 12V or 5V DC out, but cannot find them |
| 13:09.45 | wolfspraul | they have a lot of nice dc-dc chips, someone should make breakout boards for them :-) |
| 13:11.15 | *** join/#qi-hardware woakas (~woakas@186.28.175.169) |
| 13:16.34 | wpwrak | wolfspraul: you may be able to find some development boards. even for such simple things, they often make some. not sure how cost-effective they are, though |
| 13:17.46 | wolfspraul | well there are suppliers of battery packs, like that mili one |
| 13:17.58 | wolfspraul | but it's amazing how expensive they are, and of course no standard batteries |
| 13:18.27 | wolfspraul | they tend to use charging ics from TI like bqxxxx |
| 13:18.38 | wolfspraul | but in general I find the situation a little unflexible |
| 13:20.37 | wpwrak | that pack looks very stylish. maybe that explains the price :) |
| 13:20.50 | roh | what unit is that? 99 foo? |
| 13:20.55 | roh | us$? |
| 13:21.11 | wolfspraul | yes |
| 13:21.42 | roh | well... there are cheaper ones for sure... but will they do what you want and have a case? |
| 13:21.55 | wolfspraul | case not needed |
| 13:22.13 | roh | there is no standard in user serviceable lithium cells without packaging and security circuit, so they get integrated like in that pack |
| 13:22.41 | wolfspraul | how about every normal rechargeable aa battery? |
| 13:22.49 | roh | how many do you need? i think if its only for prototyping, just buy that thing |
| 13:23.00 | wolfspraul | sure, already done |
| 13:23.10 | wolfspraul | but don't tell me I shouldn't dig deeper :-) |
| 13:23.12 | roh | aa etc sucks. doesnt allow for lithium based cells |
| 13:27.45 | wolfspraul | why couldn't you fit a lithium-ion polymer into an aa case? |
| 13:28.26 | roh | wrong voltage, bad ratio of weight/case/power |
| 13:28.27 | wolfspraul | I didn't pay attention to battery chemicals yet indeed |
| 13:28.45 | *** join/#qi-hardware wej (~j@95.211.92.234) |
| 13:29.03 | roh | li based stuff has between 2.9 and 4.4V per cell, depending on chemistry and charge state |
| 13:29.51 | roh | mostly its between 3.9 and 4.2 or 3.0 and 3.4V... the first for li-ion and li-po based stuff, the latter for li-fe and similars |
| 13:31.34 | roh | and you need a balancing circuit for keeping proper care which has one line to every cell when used in series. parallel is doable, but needs low manufacturing tolerances in cell chemistry. so its much easier to just use one of the typical used 'plastic bag' packges and add standard industry charge control and safety chips (or outsource that) |
| 13:32.25 | wolfspraul | that's what those mili guys are doing (and similar vendors) |
| 13:33.16 | roh | sure. they buy cells and package them with some circuit i bet is very similar to the appnotes of the chips used |
| 13:33.21 | roh | or the reference design |
| 13:33.36 | wolfspraul | sure |
| 13:35.03 | roh | sparkfun and similars, some arduino boards and stuff watterott has also uses simple li-chargecontrollers and dc-dc switchers. not that complicated to use/design with. mostly its just some caps, some inductivity and a fast diode in addition to the chip |
| 13:35.48 | roh | but they use 'prepackged' cells, mostly single ones, but also small packs which then include the security and balancing chips |
| 13:36.25 | wolfspraul | interesting, ok. that's helpful! |
| 13:36.27 | roh | very similar (basically identical) to what one gets for cellphones, just with a hard shell there |
| 13:37.26 | roh | i can name you a book if you like to read up on more details on battery chemistry |
| 13:37.38 | wolfspraul | please, always |
| 13:38.16 | roh | 'moderne akkumulatoren richtig einsetzen' von andreas jossen und wolfgang weydanz im reichardt verlag |
| 13:38.37 | wolfspraul | thanks! |
| 13:38.49 | wolfspraul | will take a little time to get it and read, but it's queued :-) |
| 13:39.13 | roh | ;) |
| 13:39.32 | roh | its worth having when one has some detail question.. and rare indeed |
| 13:39.52 | roh | we got a copy in our raumfahrtagentur-library |
| 13:41.21 | *** join/#qi-hardware LunaVorax (~LunaVorax@ABordeaux-651-1-155-243.w109-222.abo.wanadoo.fr) |
| 14:28.50 | *** join/#qi-hardware wej (~j@95.211.92.234) |
| 14:59.30 | *** join/#qi-hardware GNUtoo (~gnutoo@host149-73-dynamic.56-82-r.retail.telecomitalia.it) |
| 14:59.46 | *** join/#qi-hardware wej (~j@95.211.92.234) |
| 15:23.00 | *** join/#qi-hardware GNUtoo-desktop (~GNUtoo@host149-73-dynamic.56-82-r.retail.telecomitalia.it) |
| 15:37.36 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
| 15:54.23 | *** join/#qi-hardware emeb (~ericb@ip72-223-81-94.ph.ph.cox.net) |
| 15:55.42 | *** join/#qi-hardware kilae (~chatzilla@catv-161-018.tbwil.ch) |
| 16:39.17 | kyak | jow_laptop: it just caught my eye that OpenWrt-Toolchain-* doesn't have "for-Linux-x86_64/i686" in its name any more (unlike SDK). What does it mean? |
| 16:41.59 | jow_laptop | nothing, it was just forgotten I suppose |
| 16:42.28 | kyak | ah, so it's a bug then :) |
| 16:43.56 | jow_laptop | likely |
| 16:44.08 | *** join/#qi-hardware dptech (~dptech@can06-1-82-242-223-39.fbx.proxad.net) |
| 16:47.41 | *** join/#qi-hardware dptech (~dptech@can06-1-82-242-223-39.fbx.proxad.net) |
| 16:59.26 | *** join/#qi-hardware GNUtoo-desktop (~GNUtoo@host149-73-dynamic.56-82-r.retail.telecomitalia.it) |
| 17:14.36 | *** join/#qi-hardware jurting (~jommpa90_@ip-196-213-241-92.dialup.ice.net) |
| 17:31.42 | *** join/#qi-hardware jekhor (~jek@leased-line-46-53-195-5.telecom.by) |
| 17:59.03 | mth | kyak: I can reproduce the gmenu2x problem now |
| 18:05.11 | *** join/#qi-hardware LunaVorax (~LunaVorax@ABordeaux-651-1-155-243.w109-222.abo.wanadoo.fr) |
| 18:05.57 | LunaVorax | Hello everyone! |
| 18:06.19 | kyak | mth: using Ben? |
| 18:07.56 | mth | no, using Dingoo |
| 18:09.31 | kyak | so you couldn't reproduce it before? |
| 18:14.56 | viric | Do you think linux 2.4 could run in the ben using less resources than 2.6? |
| 18:15.04 | viric | or 3 |
| 18:15.34 | viric | or the configuration granularity still allows to achieve similar results, in relation to the features provided? |
| 18:17.59 | mth | kyak: no, but I was probably testing a binary from the wrong location then, so an older version instead of the one I just compiled |
| 18:18.13 | kyak | viric: i think you would spend more time porting 2.4 to Ben |
| 18:19.36 | viric | well I agree |
| 18:19.45 | viric | I just thought if in general linux is becoming too big. |
| 18:19.53 | viric | or the compile time configuration puts all in a good place. |
| 18:20.34 | Ayla | viric: it's becoming big because it have more drivers |
| 18:21.48 | kyak | viric: we could measure performance between 2.6 and 3.2.. probably you will not notice any changes, but who knows? |
| 18:22.23 | viric | but drivers can be disabled at build time |
| 18:22.58 | viric | Maybe linux is forgetting a bit the uniprocessor systems nowadays .) |
| 18:22.58 | viric | :) |
| 18:23.14 | viric | I always thought linux 2.2 was the fastest since 2.0 ;) |
| 18:23.22 | viric | and 2.4 the slowest. |
| 18:23.34 | viric | but I can't prove it :) |
| 18:23.54 | kyak | you are old! :) i barely touched 2.4 |
| 18:24.03 | viric | I started at 2.0.34 :) |
| 18:24.13 | kyak | oooold! :) |
| 18:24.16 | viric | haha |
| 18:24.35 | viric | RH 5.2 it was. 5 is a big number. |
| 18:25.23 | *** join/#qi-hardware LunaVorax_ (~LunaVorax@ABordeaux-651-1-155-243.w109-222.abo.wanadoo.fr) |
| 18:33.44 | zrafa_ | kyak: viric is as old like me I guess :) |
| 18:36.00 | viric | :) |
| 18:36.26 | viric | We went to the magazine store to get updates ;) |
| 18:37.31 | viric | "Mama, can you bring me the latest kernel, at the time you buy your yellow press magazines? Thank you" |
| 18:39.31 | qi-bot | [commit] Maarten ter Huurne: Fixed GCC warning about initialization order. (master) http://qi-hw.com/p/gmenu2x/92d221a |
| 18:39.32 | qi-bot | [commit] Maarten ter Huurne: Don't overwrite link action provided to constructor. (master) http://qi-hw.com/p/gmenu2x/ed8b0c3 |
| 18:39.45 | mth | kyak: that second commit should fix it |
| 18:40.52 | mth | viric: compile time configs help a lot, for example a lot of locking ops are reduced to nothing if you have 1 CPU and no kernel preemption |
| 18:41.09 | mth | but I do see the OpenDingux kernel growing over time and we're not writing that much code |
| 18:41.28 | mth | still, it's probably less effort to optimize 3.x than to backport to 2.4 |
| 18:41.46 | *** join/#qi-hardware wej (~j@95.211.92.234) |
| 18:42.11 | viric | mth: that would mean using a non-SMP kernel, right? |
| 18:42.16 | viric | mth: or it's dynamically set? |
| 18:42.16 | mth | yes |
| 18:42.28 | mth | you can make a non-SMP kernel by config |
| 18:42.33 | viric | I know |
| 18:42.49 | viric | but there is the "nosmp" commandline, or "cpu=1", I can't recall... it isn't equivalent enough? |
| 18:43.09 | viric | I remember in 2.2 that preemption never helped me. |
| 18:43.15 | mth | I don't think so: checking that option might be slower than just doing the lock |
| 18:43.20 | jow_laptop | kyak: since a toolchain is not bound to a particular target it might also make sense to replace BOARD with ARCH |
| 18:43.29 | jow_laptop | kyak: so it reads OpenWrt-Toolchain-mipsel-for-Linux-x86_64-gcc-4.6-linaro_uClibc-0.9.33.tar.bz2 |
| 18:43.37 | viric | mth: I should try in my nonsmp systems. |
| 18:43.40 | viric | In fact I don't own any SMP. |
| 18:44.06 | mth | my desktop is a Core 2 quad-core |
| 18:44.15 | mth | it's very using when doing big compiles |
| 18:44.18 | mth | *useful |
| 18:44.20 | viric | :) |
| 18:44.23 | viric | I don't doubt it |
| 18:44.26 | jow_laptop | kyak: and maybe replace -for- with -on- |
| 18:44.39 | viric | the 7h of battery of mine are very useful too ;) |
| 18:45.03 | viric | mth: 'perf' won't show me anything about the locks, right? |
| 18:45.06 | mth | it's connected to the wall socket and power outages are rare here, fortunately |
| 18:45.13 | jow_laptop | kyak: and prepend the -for- before the ARCH (toolchain-for-mipsel-on-linux-x86...) |
| 18:45.18 | viric | :) |
| 18:45.37 | mth | I've got a laptop with an i7 and that battery lasts about 7h as well, but not when doing make -j8 ;) |
| 18:45.47 | *** join/#qi-hardware abushcrafterfor1 (~alexander@85.210.97.75) |
| 18:45.52 | viric | mth: ah very good |
| 18:45.59 | mth | I don't know 'perf' |
| 18:46.03 | viric | I'll try about the preemption and all that... |
| 18:46.29 | mth | kernel preemption will likely make things slower, not faster |
| 18:46.52 | mth | it only helps if drivers are doing too much work in big chunks |
| 18:47.26 | viric | aha |
| 18:47.38 | viric | userspace preemption will still be there, right? |
| 18:47.46 | mth | yes, that's always there |
| 18:48.10 | mth | the kernel preemption is about whether a syscall or kernel thread can be preempted |
| 18:48.29 | viric | clera |
| 18:48.42 | mth | I guess it could protect against a user doing a denial of service attack by calling lots of expensive syscalls in a row |
| 18:48.55 | mth | but that's not very likely on single-user systems |
| 18:49.20 | viric | aha |
| 18:49.28 | viric | and what do you think of NO_HZ? |
| 18:49.44 | mth | it's good, but it's not perfect yet |
| 18:49.57 | mth | it only turns off the timer ticks when the CPU is idle, we recently found out |
| 18:50.09 | viric | and how is it bad? |
| 18:50.25 | viric | as for performance, may it be bad? |
| 18:50.37 | mth | it's not bad, it's just not always good enough |
| 18:50.51 | mth | in the sense that if you're running for example mplayer, the CPU won't be idle much |
| 18:51.02 | mth | but since there is only 1 process that wants to run, you could omit the timer ticks |
| 18:51.08 | viric | mth: PREEMPT_NONE/PREEMPT_VOLUNTARY/PREEMPT |
| 18:51.09 | mth | but the current kernel does not do that |
| 18:51.58 | viric | ah clear. |
| 18:52.08 | mth | someone is working on a patch to change that, but last time I checked it was still very experimental |
| 18:52.14 | viric | I imagine it's some kind of variable rate scheduler |
| 18:52.34 | mth | in OpenDingux we originally switched to HZ=1000 + NO_HZ, but that increased the overhead significantly |
| 18:52.42 | mth | so now we're using HZ=250 + NO_HZ |
| 18:52.57 | mth | the advantage is that sleep accuracy is now 4 ms instead of 10 ms |
| 18:52.59 | viric | ok |
| 18:53.17 | mth | a lot of emulators want 60 Hz output, so 10 ms is over half a frame, not fine grained enough |
| 18:54.04 | viric | hm |
| 18:54.26 | viric | Ok, I'll go 250 for my desktop too |
| 18:54.44 | mth | hmm, we're using PREEMPT_VOLUNTARY at the moment, maybe we should try PREEMPT_NONE instead |
| 18:56.16 | mth | although the description of PREEMPT_VOLUNTARY says it only preempts at selected places, so maybe that's not so often |
| 18:58.12 | Ayla | PREEMPT_NONE means a much higher latency |
| 18:59.32 | viric | but it's the *kernel* preemption, no? |
| 18:59.43 | viric | latency in what? |
| 18:59.59 | *** join/#qi-hardware LunaVorax (~LunaVorax@ABordeaux-651-1-155-243.w109-222.abo.wanadoo.fr) |
| 19:00.41 | mth | yes, but kernel preemption includes syscalls, so it's not fully independent of user space |
| 19:00.51 | mth | Ayla: according to the docs or measured on OD? |
| 19:00.53 | viric | but if the syscalls wait... |
| 19:01.00 | viric | they go away of the scheduler |
| 19:01.26 | viric | I don't know. I'll try PREEMPT_NONE in my desktop. |
| 19:01.27 | Ayla | mth: I did test it on OD, I honestly didn't see the difference |
| 19:01.35 | mth | if a syscall cannot get a semaphore for example, the process will be put in a wait state indeed |
| 19:01.56 | Ayla | but on OD, we rarely have more than one program running |
| 19:02.02 | mth | but with PREEMPT_VOLUNTARY even if the semaphore is available, other processes will get a chance at that point |
| 19:02.30 | mth | Ayla: and was there a different in throughput? (gpmark) |
| 19:03.02 | Ayla | I don't remember the details, that was a long time ago |
| 19:03.15 | Ayla | when we switched to 1000Hz |
| 19:03.16 | viric | what is gpmark? |
| 19:03.32 | Ayla | it's a program we use to benchmark the video driver |
| 19:03.37 | viric | ok |
| 19:04.32 | viric | Do you know any piece that, given a result of 'lsmod', would tell me the kernel options to enable? :) |
| 19:06.39 | viric | localmodconfig |
| 19:06.46 | viric | incredible |
| 19:06.54 | Ayla | make localmodconfig |
| 19:10.05 | viric | and it still keeps them as modules. |
| 19:10.07 | viric | hm interesting |
| 19:10.58 | *** join/#qi-hardware LunaVorax (~LunaVorax@ABordeaux-651-1-155-243.w109-222.abo.wanadoo.fr) |
| 19:10.59 | *** join/#qi-hardware kuribas (~user@d54C43316.access.telenet.be) |
| 19:29.44 | *** join/#qi-hardware LunaVorax (~LunaVorax@ABordeaux-651-1-155-243.w109-222.abo.wanadoo.fr) |
| 19:47.51 | *** join/#qi-hardware GNUtoo (~gnutoo@host149-73-dynamic.56-82-r.retail.telecomitalia.it) |
| 19:49.12 | *** join/#qi-hardware LunaVorax (~LunaVorax@ABordeaux-651-1-155-243.w109-222.abo.wanadoo.fr) |
| 20:58.53 | qi-bot | [commit] Maarten ter Huurne: SettingsDialog: Code layout cleanup. (master) http://qi-hw.com/p/gmenu2x/fd642ff |
| 20:58.54 | qi-bot | [commit] Maarten ter Huurne: Surface cleanup. (master) http://qi-hw.com/p/gmenu2x/b248aaf |
| 20:58.55 | qi-bot | [commit] Maarten ter Huurne: Touchscreen: Avoid constructing an SDL_Rect for is-inside tests. (master) http://qi-hw.com/p/gmenu2x/58d6077 |
| 20:58.56 | qi-bot | [commit] Maarten ter Huurne: BrowseDialog: Code layout cleanup. (master) http://qi-hw.com/p/gmenu2x/46f2edb |
| 20:58.58 | qi-bot | [commit] Maarten ter Huurne: Explicitly convert 32-bit integers to 16-bit. (master) http://qi-hw.com/p/gmenu2x/8f57afc |
| 20:59.13 | Ayla | whohooo! |
| 21:03.03 | mth | we're back at 0 warnings :) |
| 21:05.11 | wpwrak | mth: so how do you know that the mechanism that generates warnings isn't broken ? :) |
| 21:06.14 | mth | I'm hoping GCC has unit tests for that |
| 21:07.11 | wpwrak | heh :) |
| 21:49.38 | whitequark | viric: openssl is in openwrt, isn't? and I'm pretty sure it is a requirement for some pretty basic apps |
| 21:50.42 | Ayla | mth: with binutils 2.20.1, uClibc 0.9.31 (so, old versions) and GCC 4.7.0 *without* LTO, the libdl bug is still present |
| 21:51.34 | mth | ok, interesting |
| 21:53.35 | viric | whitequark: I hoped so, but we talked about the milkymist |
| 21:53.42 | viric | does the milkymist run owrt? |
| 22:05.02 | whitequark | ah. no idea. |
| 22:05.16 | whitequark | I misread your message then |
| 22:14.40 | viric | :) |
| 22:14.51 | viric | hm using flashplayer... makes my cs/s go to 4000... |
| 22:15.17 | viric | ha, 1000 came from firefox. |
| 22:15.53 | viric | vimprobable2 the same |
| 22:16.45 | viric | mth: if a software makes the cpu go to 4000/5000 cs/s.... |
| 22:16.52 | viric | I better blame the sw, no? |
| 22:28.31 | mth | cs/s? |
| 22:29.58 | Ayla | context switch per second, I guess |
| 22:30.31 | viric | yes |
| 22:30.37 | mth | I don't know what a normal amout is, but 4000 does sound very high |
| 22:30.52 | mth | s/amout/amount/ |
| 22:30.52 | qi-bot | mth meant: "I don't know what a normal amount is, but 4000 does sound very high" |
| 22:31.08 | Ayla | it should be equal to HZ, if the program never sleeps |
| 22:31.08 | viric | I've no idea why this happens. maybe some preemption |
| 22:31.25 | mth | flash player is the easiest way to drain your battery in any case |
| 22:31.26 | viric | it's firefox with its multiples threads |
| 22:31.48 | Ayla | a context switch will occur if the thread waits for some I/O to finish, is blocked on a mutex, or calls usleep() |
| 22:31.56 | viric | Ayla: this is HZ_250 + NO_HZ, PREEMPT_NONE |
| 22:31.57 | mth | sometimes I'm not doing anything CPU intensive and notice the laptop getting slightly warn... then it's probably a flash ad in a web page that's still open |
| 22:32.22 | Ayla | so the number of context switches is HZ minimum, but can be much higher |
| 22:32.32 | viric | Ayla: due to NO_HZ? |
| 22:32.37 | mth | with NO_HZ the number of switches can be lower as well |
| 22:32.42 | viric | ok |
| 22:32.53 | Ayla | viric: no, due to the fact that < Ayla> a context switch will occur if the thread waits for some I/O to finish, is blocked on a mutex, or calls usleep() |
| 22:32.59 | viric | yes, clear |
| 22:33.06 | mth | maybe flash uses a lot of threads that block on semaphores or something |
| 22:33.21 | Ayla | that's the case for Firefox at least |
| 22:33.24 | viric | yes |
| 22:33.29 | viric | then you get firefox+flash... |
| 22:33.30 | mth | or is a different thread in the same process the same context? |
| 22:33.33 | viric | which adds up |
| 22:33.43 | viric | mth: no, not the same context |
| 22:34.20 | mth | most browsers just take up a lot of memory, but not CPU if you're not interacting with them |
| 22:34.26 | viric | ha. |
| 22:34.28 | mth | while flash keeps consuming CPU even in the background |
| 22:34.31 | viric | there is javascript, flash, ... |
| 22:34.53 | mth | poorly written javascript can also be a problem, yes |
| 22:35.12 | viric | animated gifs |
| 22:35.50 | viric | in firefox, even downloading files takes a lot of cpu |
| 22:36.04 | Ayla | mth: a "context" is just the state of the CPU registers, so two threads of the same process don't have the same context |
| 22:36.11 | mth | animated gifs don't have to be updated unless the animation is currently visible |
| 22:36.23 | viric | "dont have to"... :) |
| 22:37.00 | mth | yeah, theory and practice are often not the same |
| 22:37.18 | viric | with elinks, my cs/s average goes ~ 100/s :) |
| 22:38.04 | viric | mplayer playing a flash video, 500/s |
| 22:38.38 | viric | all looks like too much for me |
| 22:38.49 | viric | it only gets reasonable when doing nothing nothing. |
| 22:39.23 | Ayla | why should it be "too much"? |
| 22:39.41 | Ayla | getting a lower number of context switches won't make your system faster |
| 22:40.37 | mth | well, a context switch is overhead, so it does help to reduce the count, the question is when it's significant and when not |
| 22:42.33 | mth | speaking of context switches, we should add register saving for MXU |
| 22:42.39 | *** join/#qi-hardware lekernel (~lekernel@g225042114.adsl.alicedsl.de) |
| 22:43.00 | Ayla | good idea |
| 22:44.03 | mth | with a check whether MXU is enabled for the current context: no need to save/restore it if it's not in use |
| 22:44.53 | Ayla | it'd be useful to add the MXU instructions to binutils too |
| 22:54.48 | *** join/#qi-hardware dvdk (~dvdkhlng@g225037134.adsl.alicedsl.de) |
| 22:56.11 | dvdk | could somebody please remove the spambot user "Bailey Helton" who spammed some qi-hw wiki pages last week? can his changes be reverted automatically? |
| 22:59.07 | dvdk | kristianpaul^ wolfspraul^ |
| 23:20.32 | Ayla | mth: do you know a practical way to make the MXU instructions visible? |
| 23:20.37 | Ayla | I mean something like a lib |
| 23:20.57 | mth | visible in what way? |
| 23:22.38 | Ayla | so that they could be used by several apps or libs, like libpng or mplayer |
| 23:23.51 | wolfspraul | dvdk: a spammer went through unnoticed? wait I check |
| 23:24.10 | mth | I don't think we need a lib for that, just inline asm support |
| 23:24.21 | mth | or maybe intrinsics |
| 23:25.06 | dvdk | wolfspraul: ha, good to meet you here. just wanted to drop a mail; sharims.cc/blog has problems with recent iceweasel webbrowser (i.e. debian's firefox) |
| 23:25.15 | mth | MXU will only be used in performance critical code and it's not easy to write code that is both very efficient and generic |
| 23:25.30 | wolfspraul | oops |
| 23:25.34 | wolfspraul | thanks! |
| 23:25.39 | wolfspraul | just blocked helton |
| 23:25.45 | wolfspraul | I think you reverted the edits already, no? |
| 23:26.54 | dvdk | wolfspraul: wrt shop website, see screenshot im mail |
| 23:27.38 | wolfspraul | yes will do, thanks a lot! |
| 23:30.13 | dvdk | wolfspraul: yes found out how to revert. |
| 23:30.26 | dvdk | wolfspraul: just sent mail. hope you remember your GPG password :) |
| 23:30.48 | dvdk | think website problem is certificate-related. CSS is accessed via https://? |
| 23:31.12 | wolfspraul | maybe the cert just expired? :-) I'll check |
| 23:31.53 | dvdk | wolfspraul: riht, on april 1st. ha that was simple |
| 23:32.25 | dvdk | btw typo above it's sharism.cc/shop, not /blog |