**** BEGIN LOGGING AT Tue Mar 01 02:59:57 2011
Mar 01 03:49:33 <lgentili> Hello
Mar 01 03:49:45 <lgentili> anyone using openwrt with a routerboard rb411AHU?
Mar 01 03:55:46 <builder> build #93 of s3c24xx is complete: Failure [failed shell compile_6]  Build details are at http://tksite.gotdns.org:8010/builders/s3c24xx/builds/93
Mar 01 05:41:18 <CIA-84> nbd * r25800 /trunk/ (package/base-files/Makefile scripts/relink-lib.sh):
Mar 01 05:41:18 <CIA-84> base-files: relink uclibc and libgcc libraries to remove leftovers of the statically linked initial libgcc
Mar 01 05:41:18 <CIA-84> saves a few kb and gets rid of unused not exported functions as well
Mar 01 05:41:18 <CIA-84> should also improve the reliability of mklibs
Mar 01 05:41:30 <CIA-84> nbd * r25801 /trunk/toolchain/gcc/patches/linaro/850-use_shared_libgcc.patch: gcc-linaro: fix the libgcc spec to default to using the shared libgcc
Mar 01 05:41:35 <CIA-84> nbd * r25802 /trunk/package/busybox/patches/150-no_static_libgcc.patch: busybox: remove the -static-libgcc flag, saves a few kb
Mar 01 05:41:40 <CIA-84> nbd * r25803 /trunk/toolchain/uClibc/Makefile: uClibc: set the toolchain info at install time instead of prepare time, fixes staging dir rebuilds
Mar 01 05:42:22 <CIA-84> nbd * r25804 /packages/libs/uclibc++/Makefile: uclibc++: use the shared libgcc instead of forcing the static one
Mar 01 06:24:11 <builder> build #90 of ubicom32 is complete: Failure [failed compile_3]  Build details are at http://tksite.gotdns.org:8010/builders/ubicom32/builds/90
Mar 01 09:37:05 <Acinonyx> g'morning
Mar 01 09:47:36 <tornado_> nbd, hi, are you there?
Mar 01 09:48:43 <PsyMan> he broke it didn't he? :p
Mar 01 09:49:16 <blogic> tornado_: its 11am in germany
Mar 01 09:49:24 <blogic> he will most likely sleep for another 4-5 hours
Mar 01 09:50:19 <tornado_> no he's great always :D
Mar 01 09:50:24 <PsyMan> ahh
Mar 01 09:50:29 <PsyMan> :p
Mar 01 09:51:06 <tornado_> ;)
Mar 01 09:52:08 <blogic> :)
Mar 01 10:27:45 <builder> build #94 of atheros is complete: Failure [failed compile_4]  Build details are at http://tksite.gotdns.org:8010/builders/atheros/builds/94
Mar 01 11:24:48 <CIA-84> kaloz * r25805 /trunk/target/linux/generic/patches-2.6.38/ (17 files): [generic/2.6.38]: refresh patches with -rc6
Mar 01 11:25:20 <CIA-84> kaloz * r25806 /trunk/target/linux/generic/patches-2.6.38/040-arm_update_mach-types.patch: [generic/2.6.38]: update arm mach-types
Mar 01 12:10:37 <loswillios> iptables fails with "mips-openwrt-linux-uclibc-gcc  -shared -rdynamic -static-libgcc -o libxt_CHECKSUM.so libxt_CHECKSUM.oo; staging_dir/toolchain-mips_r2_gcc-linaro_uClibc-0.9.32/lib/gcc/mips-openwrt-linux-uclibc/4.5.2/../../../../mips-openwrt-linux-uclibc/bin/ld: cannot find -lgcc_eh_eh"
Mar 01 12:10:52 <loswillios> that's after a dirclean
Mar 01 12:11:18 <blogic> loswillios: yes
Mar 01 12:11:22 <blogic> loswillios: just spotted it
Mar 01 12:11:59 <blogic> looks liek one of the 5 nbd commits last night broke summin
Mar 01 12:12:28 <loswillios> yup, reckoned the same
Mar 01 12:15:33 <PsyMan> indeed
Mar 01 12:16:18 <PsyMan> compiling base system has some similar fatal errors
Mar 01 14:32:03 <mb__> solca: Yes it basically works. One module issue is remaining. But I'm able to boot into X.
Mar 01 15:21:26 <KanjiMonster> [florian1: ping
Mar 01 15:29:43 <[florian1> KanjiMonster: pong
Mar 01 15:32:50 <KanjiMonster> [florian1: I somehow goofed when updating the .37 patch: http://inuyasha.ath.cx/~jonas/0001-bcm63xx-Fix-2.6.37-support.patch
Mar 01 15:33:47 <[florian1> KanjiMonster: allright, I will fix that
Mar 01 15:39:42 <CIA-84> nbd * r25807 /trunk/toolchain/gcc/patches/linaro/850-use_shared_libgcc.patch: toolchain: remove -lgcc_eh from the default libgcc spec, it breaks packages
Mar 01 15:42:03 <CIA-84> nbd * r25808 /trunk/package/iptables/Makefile: iptables: do not use -static-libgcc
Mar 01 15:42:09 <CIA-84> nbd * r25809 /trunk/package/ipset/Makefile: ipset: do not use -static-libgcc
Mar 01 15:45:01 <PsyMan> hmm
Mar 01 15:45:03 <PsyMan> right
Mar 01 15:45:25 <PsyMan> does anyone know a stable revision with acx working and such? :|
Mar 01 15:46:29 <PsyMan> i mean, without freezing the router when restarting it
Mar 01 15:46:54 <[florian]> PsyMan: when will you contact oliver about these issues so that he has a chance to fix them?
Mar 01 15:47:14 <PsyMan> dunno, really
Mar 01 15:47:20 <[florian]> well, then please do
Mar 01 15:47:27 <PsyMan> i can't confirm it's an issue with the driver
Mar 01 15:48:06 <[florian]> rather with vlynq then?
Mar 01 15:48:21 <PsyMan> so don't expect me to notify the guy while i can't be sure of the cause
Mar 01 15:50:06 <PsyMan> not to mention, updating owrt a couple of days ago turned out to be a bad choice, luci causes a hang somewhere when browsing through its pages
Mar 01 15:50:14 <PsyMan> and the load skyrockets
Mar 01 15:50:42 <PsyMan> no changes, just browsing it xD
Mar 01 15:50:59 <[florian]> ouch
Mar 01 15:51:54 <PsyMan> yeah exactly
Mar 01 15:52:19 <PsyMan> well, i have only 96kb free space, but it should work nevertheless
Mar 01 15:52:32 <PsyMan> even with 0 space
Mar 01 15:52:43 <jow_laptop> it is not about flash space
Mar 01 15:53:03 <jow_laptop> its either load, kernel oops or oom
Mar 01 15:57:04 <PsyMan> load is about 0.10 before i login
Mar 01 15:59:06 <PsyMan> at first i thought i had qos forgotten at the slow speed, i did, but "fixing" it just made everything fast again... but the router still froze and the load was immerse after logging in
Mar 01 16:00:02 <PsyMan> now, what could cause it... only thing enabled is upnpd :\
Mar 01 16:00:16 <jow_laptop> check ps, top
Mar 01 16:02:56 <PsyMan> ?
Mar 01 16:03:18 <CIA-84> florian * r25810 /trunk/target/linux/brcm63xx/patches-2.6.37/ (040-bcm963xx_flashmap.patch 141-led_count.patch): [brcm63xx] fix patches after 2.6.37 update, patch from KanjiMonster
Mar 01 16:25:37 <PsyMan> k, uci works fine
Mar 01 16:26:10 <PsyMan> only navigating through luci results in issues
Mar 01 16:32:00 <wigyori> re
Mar 01 17:29:03 <CIA-84> mb * r25811 /trunk/target/linux/omap24xx/config-2.6.38: omap24xx: Fix missing symbols for mac80211
Mar 01 17:48:52 <CIA-84> mb * r25812 /packages/Xorg/app/pwrtray/Makefile: pwrtray: Fixes for latest kernel changes
Mar 01 18:05:05 <CIA-84> jow * r25813 /trunk/package/firewall/ (Makefile files/lib/core_interface.sh): [package] firewall: fix rule generation for v4 or v6 only zones (#8955)
Mar 01 18:05:44 <CIA-84> jow * r25814 /branches/backfire/package/firewall/ (Makefile files/lib/core_interface.sh): [backfire] merge r25813
Mar 01 18:08:50 <CIA-84> jow * r25815 /trunk/package/busybox/config/util-linux/Config.in: [package] busybox: enable mount helpers by default (#8946)
Mar 01 18:09:31 <CIA-84> jow * r25816 /branches/backfire/package/busybox/config/util-linux/Config.in: [backfire] merge r25815
Mar 01 18:26:50 <FinboySlick> heilterminalcons: Jow pointed me to you conserning vrrp under openwrt.  Any caveats I should be aware of?  I don't have all the hardware available yet but I figured I'd learn as much as I can prior.
Mar 01 18:32:45 <heilterminalcons> FinboySlick: Be aware that multicast is functional and not blocked due to firewall reasons
Mar 01 18:33:06 <heilterminalcons> FinboySlick: which hardware would you like to use?
Mar 01 18:35:13 <FinboySlick> heilterminalcons: x86 atom boards.  They come with 5 onboard nics so they're pretty handy.
Mar 01 18:35:41 <FinboySlick> heilterminalcons: I might also use link aggregation to connect to a switch stack to make sure the stack always have connectivity.
Mar 01 18:35:52 <FinboySlick> So it'd be vrrp on bond interfaces.
Mar 01 18:37:49 <FinboySlick> plus conntrackd if it allows me to synch the conntrack table and avoid resetting connections on failover.
Mar 01 18:39:52 <heilterminalcons> FinboySlick: Ive never tried bonding nor cronntrackd under OpenWrt. But that sound very interesting.
Mar 01 18:40:11 <Epsylon3> about connection reset... ive not tested on another router right now... but i cant keep ssh connections alive
Mar 01 18:40:13 <FinboySlick> heilterminalcons: I'm pretty eager to test the whole thing.
Mar 01 18:40:17 <Epsylon3> (to outside)
Mar 01 18:41:02 <builder> build #92 of brcm47xx is complete: Failure [failed compile_7]  Build details are at http://tksite.gotdns.org:8010/builders/brcm47xx/builds/92
Mar 01 18:45:32 <heilterminalcons> FinboySlick: how about starting with keepalived (vrrp) without bonding and conntrackd ?
Mar 01 18:46:55 <FinboySlick> heilterminalcons: Well, that goes without saying.  I'm just laying out the end goal.  How quickly can vrrp failover in your experience?
Mar 01 18:48:37 <CIA-84> obsy * r25817 /packages/net/vsftpd/Makefile: [packages] vsftpd: update to 2.3.4, fix DoS (CVE-2011-0762)
Mar 01 18:49:15 <heilterminalcons> FinboySlick: to average one to four seconds. Please remind that this case should rarely occour
Mar 01 18:49:33 <heilterminalcons> which kind of service should be on top of vrrp?
Mar 01 18:49:51 <heilterminalcons> im my use cases its HAProxy or Stunnel
Mar 01 18:49:54 <FinboySlick> heilterminalcons: Just the network gateway/firewalling.
Mar 01 18:50:13 <FinboySlick> Basically, connectivity to the outside world.
Mar 01 18:51:21 <heilterminalcons> HAProxy is very often the gateway/firewall too. So crazy setups like SNAT tproxy can be done
Mar 01 18:52:34 <heilterminalcons> There I have to deal with a lot of connection 2000-4000/s average
Mar 01 18:55:45 <CIA-84> mb * r25818 /trunk/ (3 files in 3 dirs): 2.6.38: Let mac80211 select CONFIG_AVERAGE
Mar 01 18:59:11 <FinboySlick> heilterminalcons: Wow.  I don't think I'll have that much traffic on this one, but it has to work and keep working.
Mar 01 19:00:23 <heilterminalcons> The only problem was to take care that the conntrack table wont overflow
Mar 01 19:01:59 <heilterminalcons> So I had to play with "-j NOTRACK" rules
Mar 01 19:04:05 <heilterminalcons> FinboySlick: what kind of atom boards are this? Ive never saw boards with 4 up to 5 nics
Mar 01 19:04:05 <FinboySlick> heilterminalcons: These boxes will do almost exclusively routing and firewall so I can handle pretty large conntrack tables.
Mar 01 19:04:26 <FinboySlick> heilterminalcons: Lemme dig it up.  It has 2 onboard and an expansion module for 3 more.
Mar 01 19:05:32 <FinboySlick> heilterminalcons: Jetway JC9C-455-LF
Mar 01 19:05:47 <FinboySlick> They're very cute little things.
Mar 01 19:06:43 <heilterminalcons> FinboySlick: cool :-)
Mar 01 19:07:32 <FinboySlick> heilterminalcons: I have a feeling I'll be pushing Openwrt's built-in config tools though because, of course, there will be vlans on top of those bonded interfaces.
Mar 01 19:09:05 <lgentili> Hellow
Mar 01 19:09:46 <heilterminalcons> FinboySlick: Why not using a switch with vlan functionality?
Mar 01 19:10:54 <lgentili> anyone has any experience of using OpenWrt on a RouterBoard RB411UAHR?
Mar 01 19:12:47 <FinboySlick> heilterminalcons: The box needs to act as a gateway for several of those vlans.
Mar 01 19:13:15 <FinboySlick> Otherwise, I'd need about 30 NICs in that box and a much larger switch.
Mar 01 19:15:59 <heilterminalcons> FinboySlick: so that may also to reason for the need of link aggregation
Mar 01 19:15:59 <FinboySlick> heilterminalcons: (Basically, the bond interfaces will be connected to trunk LAGs)
Mar 01 19:17:16 <heilterminalcons> FinboySlick: on crazy advice: just use xen dom0 for the bonds and openwrt as xen domu for the rest?
Mar 01 19:17:35 <FinboySlick> heilterminalcons: Link aggregation is used a switch failover mechanism.  It's not yet set if we'll use it or not.  The idea being that we configure one port of each switch in a tag to be part of a link aggregation.  The stack sees the lag as a single port, if one switch fails, traffic still flows to the same 'port'.
Mar 01 19:17:51 <FinboySlick> xen?
Mar 01 19:17:59 <FinboySlick> No virtualization here.
Mar 01 19:19:35 <heilterminalcons> FinboySlick: maybe im the only one person that uses openwrt under xen
Mar 01 19:19:53 <netprince> build of libxslt fails with 'permission denied'.... http://openwrt.pastebin.com/3TFx3cxq
Mar 01 19:20:24 <FinboySlick> heilterminalcons: I'm very curious to use VMs but I don't have any *real* use for them so I never did much more than toy with kvm.
Mar 01 19:23:02 <netprince> trunk r25806, target ar913x
Mar 01 19:23:47 <heilterminalcons> FinboySlick: Iam using xen domu in production for loadbalancing
Mar 01 19:26:48 <heilterminalcons>  FinboySlick: and the next crazy idea is to use OpenWrt as Hypervisor for KVM
Mar 01 19:28:52 <loswillios> nice
Mar 01 19:33:20 <builder> build #82 of ppc44x is complete: Failure [failed compile_4]  Build details are at http://tksite.gotdns.org:8010/builders/ppc44x/builds/82
Mar 01 19:35:02 <FinboySlick> heilterminalcons: Hehe, might be why Jow pointed me to you...  He must think I have crazy ideas and you seem to be an expert in those.
Mar 01 19:35:51 <netprince> ping [florian]: perhaps a problem with c25729?  http://openwrt.pastebin.com/3TFx3cxq
Mar 01 19:36:30 <heilterminalcons> FinboySlick: maybe
Mar 01 19:41:13 <netprince> heilterminalcons: OpenWrt as Hypervisor, I like that idea
Mar 01 19:41:55 <heilterminalcons> Until now Iwas not able to package kvm with uclibc for OpenWrt
Mar 01 20:52:59 <[florian]> netprince: look like yes, I will fix it, thanks for the log
Mar 01 20:57:18 <builder> build #94 of at91 is complete: Failure [failed shell compile_6]  Build details are at http://tksite.gotdns.org:8010/builders/at91/builds/94
Mar 01 21:02:17 <tornado> nbd, hi, how are you?
Mar 01 21:02:26 <nbd> hi
Mar 01 21:02:38 <nbd> busy (as usual) ;)
Mar 01 21:03:07 <tornado> nbd, yeah, you're always busy :)
Mar 01 21:05:37 <tornado> nbd, did you see and remember my problem with ath9k?
Mar 01 21:06:53 <tornado> nbd, I write the problem again
Mar 01 21:07:09 <tornado> nbd, Running wifi at station makes the link almost down.  I see some strange ping times like this: http://pastebin.com/uWkizTcS  and after some seconds link will be down at all. I have to run wifi at AP side to bring it back. And the most strange thing is that restarting the AP doesn't help, I have to run wifi after boot. I repeated this test for at least 30 times :)
Mar 01 21:09:36 <nbd> odd
Mar 01 21:09:38 <nbd> i'll look into it
Mar 01 21:10:54 <tornado> nbd, yeah I think the problem started since compat-wireless-11-02-07 but no sure
Mar 01 21:11:35 <nbd> please verify that by trying a few older revisions of the mac80211 package
Mar 01 21:13:04 <tornado> nbd, ok, I'll test it. But I'm sure that I hadn't this problem about 2 months ago
Mar 01 21:31:37 <nbd> tornado: it would still help to figure out which version introduced the issue
Mar 01 21:34:39 <tornado> nbd, ok I'll try older versions. but it would be nice if you can test the last update and check if you have this problem too with your configs
Mar 01 21:36:44 <tornado> nbd, I thought the problem may be solved with new compat wireless, so updated to last trunk yesterday but it didn't help
Mar 01 22:01:15 <_lore_> ping nbd
Mar 01 22:02:15 <nbd> _lore_: pong
Mar 01 22:02:25 <_lore_> hi how are?
Mar 01 22:02:28 <nbd> hi
Mar 01 22:02:31 <_lore_> *you
Mar 01 22:02:37 <nbd> busy, as usual ;)
Mar 01 22:02:42 <_lore_> :)
Mar 01 22:03:47 <_lore_> you have a lot of stuff to  do..
Mar 01 22:04:56 <_lore_> I am wondering if you have done some delay measurements in ath9k/mac80211
Mar 01 22:05:17 <nbd> what kind of delay measurements?
Mar 01 22:05:17 <_lore_> I mean TX/RX delay
Mar 01 22:05:44 <nbd> what kind of tx/rx delay?
Mar 01 22:06:08 <_lore_> at the moment I am tring to figure out how long it takes to tx a particular kind of pkt and rx the response...
Mar 01 22:06:19 <nbd> well, that depends on the environment
Mar 01 22:06:21 <_lore_> no processing delay
Mar 01 22:06:26 <nbd> or do you want to test this under ideal conditions?
Mar 01 22:06:30 <_lore_> the channel is good
Mar 01 22:06:45 <_lore_> i measure the # of rettries
Mar 01 22:07:12 <_lore_> is almost 0
Mar 01 22:07:42 <_lore_> I tx a particular custom pkt, generated in mac80211
Mar 01 22:07:57 <_lore_> e measure the delay of the response
Mar 01 22:08:03 <_lore_> *and
Mar 01 22:08:27 <_lore_> no pkt processing on the receiver
Mar 01 22:08:49 <_lore_> just generate and tx the resposnse
Mar 01 22:09:23 <_lore_> I obtain 1.5ms of global delay
Mar 01 22:09:40 <_lore_> quite huge
Mar 01 22:09:55 <_lore_> don't you think so??
Mar 01 22:10:47 <nbd> how do you measure the delay?
Mar 01 22:11:07 <nbd> btw. remember that ath9k has rx interrupt mitigation
Mar 01 22:11:26 <_lore_> I wrote a module which uses HRT
Mar 01 22:11:45 <_lore_> oh...interesting...
Mar 01 22:12:43 <nbd> btw. i think that tx->rx turnaround time from a driver perspective is mostly irrelevant
Mar 01 22:13:04 <nbd> since everything that depends strongly on fast tx->rx time is hardware assistend
Mar 01 22:13:08 <nbd> assisted
Mar 01 22:13:54 <_lore_> yes...but I need this tx->rx path to be quite fast
Mar 01 22:14:11 <nbd> for what?
Mar 01 22:14:56 <_lore_> I am trying to coordinate channel access with these pkt
Mar 01 22:15:09 <nbd> you're trying to coordinate channel access in software?
Mar 01 22:15:18 <_lore_> yes
Mar 01 22:15:39 <nbd> why not figure out a way to use hardware assisted means of doing that?
Mar 01 22:15:55 <_lore_> a token based channel access
Mar 01 22:15:57 <nbd> that would put less load on the software
Mar 01 22:16:06 <_lore_> yes..
Mar 01 22:16:42 <_lore_> it's quite common in literature
Mar 01 22:17:06 <nbd> i'm sure you could pull off some tricks with CFP and CTS frames
Mar 01 22:17:19 <_lore_> :)
Mar 01 22:17:43 <_lore_> something like this.. I am doing some research..
Mar 01 22:17:50 <_lore_> on this topic
Mar 01 22:17:53 <nbd> is the result going to be public?
Mar 01 22:17:59 <nbd> or is this for a proprietary product?
Mar 01 22:18:43 <_lore_> it's for a research at university
Mar 01 22:18:59 <nbd> cool
Mar 01 22:19:14 <_lore_> have you ever tried to disable physical carrier sense?
Mar 01 22:19:21 <_lore_> I did
Mar 01 22:19:54 <_lore_> but each frame I receive is corrupted
Mar 01 22:19:58 <nbd> yeah, well, there's strong limits to the usefulness of that
Mar 01 22:20:06 <nbd> depends on how you do it, really
Mar 01 22:20:07 <_lore_> yes
Mar 01 22:20:25 <_lore_> but if I manage the channel access in sw
Mar 01 22:20:32 <_lore_> in don't need csma
Mar 01 22:20:36 <_lore_> +I
Mar 01 22:20:40 <_lore_> *I
Mar 01 22:21:02 <nbd> well, it's not that simple imho
Mar 01 22:21:25 <nbd> i think you can't tell the card to ignore the rx path for considering tx
Mar 01 22:21:55 <nbd> iirc if the MAC state machine is in an rx state, only very specific conditions will allow it to abort that and go into tx mode
Mar 01 22:22:03 <_lore_> I disable CSMA/CA writing in a card register
Mar 01 22:22:36 <nbd> so have you verified that it does exactly what you want it to do?
Mar 01 22:22:36 <_lore_> I can't remember the name
Mar 01 22:22:48 <_lore_> no..I can't
Mar 01 22:23:18 <_lore_> frame are transmitted but on rx side are corrupted
Mar 01 22:23:30 <_lore_> each frame
Mar 01 22:23:40 <nbd> i think disabling CSMA/CA in hardware is a bad idea in general
Mar 01 22:23:47 <_lore_> :)
Mar 01 22:23:50 <nbd> you lose more than you gain
Mar 01 22:24:00 <nbd> no on-chip retransmissions
Mar 01 22:24:09 <nbd> hardware ack processing doesn't work anymore
Mar 01 22:24:15 <_lore_> ahh..
Mar 01 22:24:31 <nbd> so the way to manage channel access times is by carefully controlling the NAV
Mar 01 22:25:17 <nbd> you can override the energy detect based carrier sensing
Mar 01 22:25:23 <nbd> by changing thresh62
Mar 01 22:25:51 <nbd> but you shouldn't mess with things that affect the rx path
Mar 01 22:26:01 <_lore_> :)
Mar 01 22:26:15 <_lore_> ok...
Mar 01 22:26:45 <nbd> i think you might even be able to write to the register that holds the current NAV
Mar 01 22:26:57 <nbd> i've never tried that though
Mar 01 22:27:31 <_lore_> because if i have a central station that manages the channel access I don't need NAV anymore
Mar 01 22:28:39 <nbd> using the NAV is a good thing though
Mar 01 22:28:54 <nbd> and central channel management can be done even in the scope of the 802.11 standard
Mar 01 22:29:00 <nbd> have you looked into using PCF?
Mar 01 22:29:27 <_lore_> yes
Mar 01 22:30:00 <_lore_> but I need some less complex...
Mar 01 22:31:22 <nbd> or just use HCF poll
Mar 01 22:31:30 <nbd> that's fairly straightforware
Mar 01 22:31:34 <nbd> straightforward
Mar 01 22:32:04 <_lore_> ok...I'll take a look..
Mar 01 22:32:07 <_lore_> tnx
Mar 01 22:32:16 <nbd> adjust the IFS on the AP so that it has priority over all clients accessing the medium
Mar 01 22:32:32 <nbd> to make sure that it always has medium priority
Mar 01 22:33:00 <_lore_> I am using VO queue right now :)
Mar 01 22:33:12 <nbd> that's good for *local* priority
Mar 01 22:33:28 <nbd> but reducing the IFS is still better for avoiding contention from other clients that may use their VO queue
Mar 01 22:33:45 <nbd> that way they have no chance to accidentally be the first to grab control of the medium
Mar 01 22:34:14 <_lore_> ok
Mar 01 22:34:37 <_lore_> how can I disable interrupt  mitigation in ath9k? is it possible?
Mar 01 22:36:18 <nbd> there's a config variable for that
Mar 01 22:36:20 <nbd> in the code
Mar 01 22:36:30 <nbd> look for it with grep
Mar 01 22:37:25 <_lore_> ok tnx a lot :)
Mar 01 22:37:48 <_lore_> I have not come to fosdem this year
Mar 01 22:39:08 <nbd> me neither
Mar 01 22:39:20 <nbd> but i'll be back at fosdem next year
Mar 01 22:40:11 <_lore_> sorry I was wrong I mean you
Mar 01 22:40:12 <_lore_> :)
Mar 01 22:40:21 <nbd> :)
Mar 01 22:40:22 <_lore_> I was at fosdem
Mar 01 22:40:26 <nbd> ah
Mar 01 22:40:45 <_lore_> it has been fun
Mar 01 22:40:53 <_lore_> funny
Mar 01 22:42:23 <_lore_> do you think that reducing TX/RX hw queue depth also reduce tx <-> rx delay?
Mar 01 22:43:10 <nbd> no
Mar 01 22:43:22 <nbd> technically it isn't a hw queue depth
Mar 01 22:43:34 <nbd> it's just how many buffers the software will chain together
Mar 01 22:43:46 <_lore_> yes
Mar 01 22:44:12 <_lore_> I mean # of buffers processed
Mar 02 00:19:05 <builder> build #88 of orion is complete: Failure [failed compile_7]  Build details are at http://tksite.gotdns.org:8010/builders/orion/builds/88
Mar 02 00:53:04 <builder> build #88 of cobalt is complete: Failure [failed compile_7]  Build details are at http://tksite.gotdns.org:8010/builders/cobalt/builds/88
Mar 02 01:37:24 <builder> build #18 of lantiq is complete: Failure [failed compile_7]  Build details are at http://tksite.gotdns.org:8010/builders/lantiq/builds/18
Mar 02 01:45:02 <builder> build #66 of mpc52xx is complete: Failure [failed compile_4]  Build details are at http://tksite.gotdns.org:8010/builders/mpc52xx/builds/66
**** ENDING LOGGING AT Wed Mar 02 02:59:57 2011