* [ath9k-devel] Retry control & iwconfig @ 2014-03-27 4:20 Pradeep Reddy 2014-03-28 16:26 ` Olivier Marce 2014-03-29 18:32 ` Pradeep Reddy 0 siblings, 2 replies; 12+ messages in thread From: Pradeep Reddy @ 2014-03-27 4:20 UTC (permalink / raw) To: ath9k-devel Hi Marc, You can set NO_ACK bit in Tx descriptor of each packet to indicate the hardware to not to wait for ACK, which in turn avoids retries for that particular packet. If you set IEEE80211_TX_CTL_NO_ACK flag in tx_ctl information, ath9k layer will take care of setting the Tx descriptor flag ATH9K_TXDESC_NOACK. Regards Pradeep -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140327/68392481/attachment.htm ^ permalink raw reply [flat|nested] 12+ messages in thread
* [ath9k-devel] Retry control & iwconfig 2014-03-27 4:20 [ath9k-devel] Retry control & iwconfig Pradeep Reddy @ 2014-03-28 16:26 ` Olivier Marce 2014-03-29 18:32 ` Pradeep Reddy 1 sibling, 0 replies; 12+ messages in thread From: Olivier Marce @ 2014-03-28 16:26 UTC (permalink / raw) To: ath9k-devel Hi Pradeep, thanks, this helped me a lot. It pointed me out to iw command "set noack_map" that is made to set IEEE80211_TX_CTL_NO_ACK flag, and that I did not consider before. I then used "iw <dev> set noack_map 9" to avoid waiting for ACK and to avoid retries by <dev>. What I expected was to see almost no difference with noack when the link conditions are good (i.e. high RSSI level). But this is not the case, with noack set, the data transfer is almost not possible (I used iperf, and it even does not complete its test, 95 to 98% lost packet with ping). What is the reason for this ? Does the NO_ACK bit has an additional impact on the device behaviour like not respecting the requested delays on the air, or whatever ? Any idea ? Thanks. Olivier. On 27/03/2014 05:20, Pradeep Reddy wrote: > Hi Marc, > > You can set NO_ACK bit in Tx descriptor of each packet to indicate the > hardware to not to wait for ACK, which in turn avoids retries for that > particular packet. > > If you set IEEE80211_TX_CTL_NO_ACK flag in tx_ctl information, ath9k > layer will take care of setting the Tx descriptor flag ATH9K_TXDESC_NOACK. > > Regards > Pradeep > > > _______________________________________________ > ath9k-devel mailing list > ath9k-devel at lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > -- Olivier Marc? Alcatel-Lucent Bell Labs France ^ permalink raw reply [flat|nested] 12+ messages in thread
* [ath9k-devel] Retry control & iwconfig 2014-03-27 4:20 [ath9k-devel] Retry control & iwconfig Pradeep Reddy 2014-03-28 16:26 ` Olivier Marce @ 2014-03-29 18:32 ` Pradeep Reddy 2014-03-31 10:27 ` Paul Fuxjaeger 1 sibling, 1 reply; 12+ messages in thread From: Pradeep Reddy @ 2014-03-29 18:32 UTC (permalink / raw) To: ath9k-devel Hi Olivier, NO_ACK feature is meant for few special cases, like, (i)when you want to inject certain packets (Injector), but doesn't bother whether it is delivered or not, (ii) In QoS/11n case, where per packet ACK is disabled and Block ACK is enabled (iii) For boradcast/multicast packets, for which ACK is not needed, For Ex Beacons As you are aware the purpose of ACK in 802.11 Std is to ensure the data packet is delivered without any errors to intended destination, due to uncertainty nature of Wireless Medium. In your case, NO_ACK is set, but Rate control algorithm is still decides the rate based on Tx stats and sets number of retries. But since NO_ACK bit is set, h/w won't wait for ACK and doesn't ensure the error-free delivery of data packets to target. With NO_ACK set also, still the STA follows the CSMA/CA protocol, doesn't violate any protocol timings. I think, your env might be busy with lot of WLAN traffic, so that even with higher signal strengths the packets might not be making till destination as error-free. Is that Correct ? I think, fixing the data rates to make it behave better. Let me know how it goes. Regards Pradeep Date: Fri, 28 Mar 2014 17:26:06 +0100 From: Olivier Marce<Olivier.Marce@alcatel-lucent.com> Subject: Re: [ath9k-devel] Retry control & iwconfig To:<ath9k-devel@venema.h4ckr.net> Message-ID:<5335A29E.3010209@alcatel-lucent.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Hi Pradeep, thanks, this helped me a lot. It pointed me out to iw command "set noack_map" that is made to set IEEE80211_TX_CTL_NO_ACK flag, and that I did not consider before. I then used "iw <dev> set noack_map 9" to avoid waiting for ACK and to avoid retries by <dev>. What I expected was to see almost no difference with noack when the link conditions are good (i.e. high RSSI level). But this is not the case, with noack set, the data transfer is almost not possible (I used iperf, and it even does not complete its test, 95 to 98% lost packet with ping). What is the reason for this ? Does the NO_ACK bit has an additional impact on the device behaviour like not respecting the requested delays on the air, or whatever ? Any idea ? Thanks. Olivier. On 27/03/2014 05:20, Pradeep Reddy wrote: > Hi Marc, > > You can set NO_ACK bit in Tx descriptor of each packet to indicate the > hardware to not to wait for ACK, which in turn avoids retries for that > particular packet. > > If you set IEEE80211_TX_CTL_NO_ACK flag in tx_ctl information, ath9k > layer will take care of setting the Tx descriptor flag ATH9K_TXDESC_NOACK. > > Regards > Pradeep ^ permalink raw reply [flat|nested] 12+ messages in thread
* [ath9k-devel] Retry control & iwconfig 2014-03-29 18:32 ` Pradeep Reddy @ 2014-03-31 10:27 ` Paul Fuxjaeger 2014-04-02 10:02 ` Olivier Marce 0 siblings, 1 reply; 12+ messages in thread From: Paul Fuxjaeger @ 2014-03-31 10:27 UTC (permalink / raw) To: ath9k-devel On 29.03.14 19:32, Pradeep Reddy wrote: > > I think, fixing the data rates to make it behave better. I think so too, maybe minstrel does something very unclever in context of NO_ACK being set (like sticking to a very high MCS). Or this is simply what we get when turning off (fast!) mac-layer retransmission in a busy environment and using TCP over that very leaky pipe then. -paul ^ permalink raw reply [flat|nested] 12+ messages in thread
* [ath9k-devel] Retry control & iwconfig 2014-03-31 10:27 ` Paul Fuxjaeger @ 2014-04-02 10:02 ` Olivier Marce 2014-04-02 16:15 ` Olivier Marce 0 siblings, 1 reply; 12+ messages in thread From: Olivier Marce @ 2014-04-02 10:02 UTC (permalink / raw) To: ath9k-devel Hi, thanks Pradeep and Paul. I investigated on this. But as this time, I'm unable to make a link working with no_ack, even if I fix the rate. The environment is crowded, but not so much. With ACK (iw <dev> set noack_map 0 to be sure), for a iperf 10 sec long test, I found only 43 retry packets over 19k TCP packets. As soon as I set noack (iw <dev> set noack_map 9), the iperf test does not work at all. I'm able to see only 2 packets coming from the iperf client over 15 seconds of capture. The same when fixing the rate (iwconfig <dev> rate 11M), the same with 1M rate. The capture done at the 2 ends (AP and STA) are consistent. This is the same with ping, it does not work (98% packet loss) Other observations : - the ACK are well transmitted in the 2 directions - same behaviour if RTS/CTS on or off Did someone make a link with no_ack work ? In which condition ? Regards On 31/03/2014 12:27, Paul Fuxjaeger wrote: > On 29.03.14 19:32, Pradeep Reddy wrote: >> >> I think, fixing the data rates to make it behave better. > > I think so too, maybe minstrel does something very unclever in context > of NO_ACK being set (like sticking to a very high MCS). Or this is > simply what we get when turning off (fast!) mac-layer retransmission in > a busy environment and using TCP over that very leaky pipe then. > > -paul > > -- Olivier Marc? Alcatel-Lucent Bell Labs France ^ permalink raw reply [flat|nested] 12+ messages in thread
* [ath9k-devel] Retry control & iwconfig 2014-04-02 10:02 ` Olivier Marce @ 2014-04-02 16:15 ` Olivier Marce 0 siblings, 0 replies; 12+ messages in thread From: Olivier Marce @ 2014-04-02 16:15 UTC (permalink / raw) To: ath9k-devel Hi, I found that it can work but depends on device used as STA. As I used special feature like noack on AP side only, I did not think that STA device would be so important in the setup. Then changing the STA makes it working. Not investigated yet why it did not work, I'll let the list know why mater (looks that some strange Block Ack policy was sent back by the STA toward the AP). Regards On 02/04/2014 12:02, Olivier Marce wrote: > Hi, > thanks Pradeep and Paul. > > I investigated on this. > But as this time, I'm unable to make a link working with no_ack, even if > I fix the rate. > > The environment is crowded, but not so much. With ACK (iw <dev> set > noack_map 0 to be sure), for a iperf 10 sec long test, I found only 43 > retry packets over 19k TCP packets. > > As soon as I set noack (iw <dev> set noack_map 9), the iperf test does > not work at all. I'm able to see only 2 packets coming from the iperf > client over 15 seconds of capture. > The same when fixing the rate (iwconfig <dev> rate 11M), the same with > 1M rate. > The capture done at the 2 ends (AP and STA) are consistent. > This is the same with ping, it does not work (98% packet loss) > > Other observations : > - the ACK are well transmitted in the 2 directions > - same behaviour if RTS/CTS on or off > > Did someone make a link with no_ack work ? In which condition ? > > Regards > > On 31/03/2014 12:27, Paul Fuxjaeger wrote: >> On 29.03.14 19:32, Pradeep Reddy wrote: >>> >>> I think, fixing the data rates to make it behave better. >> >> I think so too, maybe minstrel does something very unclever in context >> of NO_ACK being set (like sticking to a very high MCS). Or this is >> simply what we get when turning off (fast!) mac-layer retransmission in >> a busy environment and using TCP over that very leaky pipe then. >> >> -paul >> >> > -- Olivier Marc? Alcatel-Lucent Bell Labs France ^ permalink raw reply [flat|nested] 12+ messages in thread
* [ath9k-devel] Retry control & iwconfig @ 2014-03-25 14:51 Olivier Marce 2014-03-26 12:10 ` Holger Schurig 0 siblings, 1 reply; 12+ messages in thread From: Olivier Marce @ 2014-03-25 14:51 UTC (permalink / raw) To: ath9k-devel Hi there, I tried to use "retry" command of iwconfig to avoid any retry. I still see retries on the traces, although it is correclty set (Retry limit: 0) Looking at the list archive I understood that retry command of iwconfig does not work or at least it is not possible to avoid all retries (see [https://www.mail-archive.com/ath9k-devel%40lists.ath9k.org/msg09951.html]] Is it correct ? If so, is there another way to suppress retransmit than by patching the firmware ? Thx Regards -- Olivier Marc? Alcatel-Lucent Bell Labs France ^ permalink raw reply [flat|nested] 12+ messages in thread
* [ath9k-devel] Retry control & iwconfig 2014-03-25 14:51 Olivier Marce @ 2014-03-26 12:10 ` Holger Schurig 2014-03-26 13:34 ` abhinav narain 0 siblings, 1 reply; 12+ messages in thread From: Holger Schurig @ 2014-03-26 12:10 UTC (permalink / raw) To: ath9k-devel 1. "iwconfig" is outdated, don't use it. Use "iw" instead 2. As noted in the mail you linked to, the retry is also done by software in the mac80211 layer and in the ath9k driver 3. ath9k based-cards don't have firmware So, what you have basically do is to find out where in drivers/net/wireless/atheros and net/mac80211 or net/wireless the software-retry handling is taking place and make this switchable. LXR tells me that IEEE80211_FCTL_RETRY is used in ath9k, see http://lxr.linux.no/linux+v3.13.5/drivers/net/wireless/ath/ath9k/xmit.c#L357 . It seems that the ath9k has a max number of retries defined: http://lxr.linux.no/linux+v3.13.5/drivers/net/wireless/ath/ath9k/ath9k.h#L653 Hope that puts you into the right direction. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [ath9k-devel] Retry control & iwconfig 2014-03-26 12:10 ` Holger Schurig @ 2014-03-26 13:34 ` abhinav narain 2014-04-17 4:49 ` marcus muffin 0 siblings, 1 reply; 12+ messages in thread From: abhinav narain @ 2014-03-26 13:34 UTC (permalink / raw) To: ath9k-devel Hi, just change value from 10 to 0 for retries to be zero! http://lxr.linux.no/linux+v3.13.5/drivers/net/wireless/ath/ath9k/init.c#L954 mac80211 API does not update this in ath9k for some reason and the default value of retries is 7 in rate minstrel which has also to be changed. Thanks, Abhinav On Wed, Mar 26, 2014 at 5:10 AM, Holger Schurig <holgerschurig@gmail.com>wrote: > 1. "iwconfig" is outdated, don't use it. Use "iw" instead > 2. As noted in the mail you linked to, the retry is also done by > software in the mac80211 layer and in the ath9k driver > 3. ath9k based-cards don't have firmware > > So, what you have basically do is to find out where in > drivers/net/wireless/atheros and net/mac80211 or net/wireless the > software-retry handling is taking place and make this switchable. LXR > tells me that IEEE80211_FCTL_RETRY is used in ath9k, see > > http://lxr.linux.no/linux+v3.13.5/drivers/net/wireless/ath/ath9k/xmit.c#L357 > . It seems that the ath9k has a max number of retries defined: > > http://lxr.linux.no/linux+v3.13.5/drivers/net/wireless/ath/ath9k/ath9k.h#L653 > > Hope that puts you into the right direction. > _______________________________________________ > ath9k-devel mailing list > ath9k-devel at lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140326/b7526b43/attachment.html ^ permalink raw reply [flat|nested] 12+ messages in thread
* [ath9k-devel] Retry control & iwconfig 2014-03-26 13:34 ` abhinav narain @ 2014-04-17 4:49 ` marcus muffin 2014-04-17 5:40 ` abhinav narain 0 siblings, 1 reply; 12+ messages in thread From: marcus muffin @ 2014-04-17 4:49 UTC (permalink / raw) To: ath9k-devel hi all, I found that there is a retry value in net/wireless/core.c 348 rdev->wiphy.retry_short = 7; 349 rdev->wiphy.retry_long = 4; If i set those values to 0. the retry will still exist. Is it correct? Marcus 2014-03-26 21:34 GMT+08:00 abhinav narain <abhinavnarain10@gmail.com>: > Hi, > just change value from 10 to 0 for retries to be zero! > > http://lxr.linux.no/linux+v3.13.5/drivers/net/wireless/ath/ath9k/init.c#L954 > > mac80211 API does not update this in ath9k for some reason and the default > value of retries is 7 in rate minstrel which has also to be changed. > > Thanks, > Abhinav > > > On Wed, Mar 26, 2014 at 5:10 AM, Holger Schurig <holgerschurig@gmail.com>wrote: > >> 1. "iwconfig" is outdated, don't use it. Use "iw" instead >> 2. As noted in the mail you linked to, the retry is also done by >> software in the mac80211 layer and in the ath9k driver >> 3. ath9k based-cards don't have firmware >> >> So, what you have basically do is to find out where in >> drivers/net/wireless/atheros and net/mac80211 or net/wireless the >> software-retry handling is taking place and make this switchable. LXR >> tells me that IEEE80211_FCTL_RETRY is used in ath9k, see >> >> http://lxr.linux.no/linux+v3.13.5/drivers/net/wireless/ath/ath9k/xmit.c#L357 >> . It seems that the ath9k has a max number of retries defined: >> >> http://lxr.linux.no/linux+v3.13.5/drivers/net/wireless/ath/ath9k/ath9k.h#L653 >> >> Hope that puts you into the right direction. >> _______________________________________________ >> ath9k-devel mailing list >> ath9k-devel at lists.ath9k.org >> https://lists.ath9k.org/mailman/listinfo/ath9k-devel >> > > > _______________________________________________ > ath9k-devel mailing list > ath9k-devel at lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140417/72a1ddb6/attachment.htm ^ permalink raw reply [flat|nested] 12+ messages in thread
* [ath9k-devel] Retry control & iwconfig 2014-04-17 4:49 ` marcus muffin @ 2014-04-17 5:40 ` abhinav narain 2014-04-19 9:50 ` marcus muffin 0 siblings, 1 reply; 12+ messages in thread From: abhinav narain @ 2014-04-17 5:40 UTC (permalink / raw) To: ath9k-devel Hi Marcus, Yes, as I suggested before, you should change it in driver code. This value in mac80211 codebase is not reflected in ath9k driver(atleast) where the default is 10 retransmits. And if someone can explain how does minstrel work with default as 7 retransmits while driver does 10 retransmits, that will be awesome! - Abhinav On Wed, Apr 16, 2014 at 9:49 PM, marcus muffin <ath9kmuffin@gmail.com>wrote: > hi all, > > I found that there is a retry value in net/wireless/core.c > > 348 rdev->wiphy.retry_short = 7; > 349 rdev->wiphy.retry_long = 4; > > If i set those values to 0. the retry will still exist. Is it correct? > > Marcus > > > 2014-03-26 21:34 GMT+08:00 abhinav narain <abhinavnarain10@gmail.com>: > > Hi, >> just change value from 10 to 0 for retries to be zero! >> >> http://lxr.linux.no/linux+v3.13.5/drivers/net/wireless/ath/ath9k/init.c#L954 >> >> mac80211 API does not update this in ath9k for some reason and the default >> value of retries is 7 in rate minstrel which has also to be changed. >> >> Thanks, >> Abhinav >> >> >> On Wed, Mar 26, 2014 at 5:10 AM, Holger Schurig <holgerschurig@gmail.com>wrote: >> >>> 1. "iwconfig" is outdated, don't use it. Use "iw" instead >>> 2. As noted in the mail you linked to, the retry is also done by >>> software in the mac80211 layer and in the ath9k driver >>> 3. ath9k based-cards don't have firmware >>> >>> So, what you have basically do is to find out where in >>> drivers/net/wireless/atheros and net/mac80211 or net/wireless the >>> software-retry handling is taking place and make this switchable. LXR >>> tells me that IEEE80211_FCTL_RETRY is used in ath9k, see >>> >>> http://lxr.linux.no/linux+v3.13.5/drivers/net/wireless/ath/ath9k/xmit.c#L357 >>> . It seems that the ath9k has a max number of retries defined: >>> >>> http://lxr.linux.no/linux+v3.13.5/drivers/net/wireless/ath/ath9k/ath9k.h#L653 >>> >>> Hope that puts you into the right direction. >>> _______________________________________________ >>> ath9k-devel mailing list >>> ath9k-devel at lists.ath9k.org >>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel >>> >> >> >> _______________________________________________ >> ath9k-devel mailing list >> ath9k-devel at lists.ath9k.org >> https://lists.ath9k.org/mailman/listinfo/ath9k-devel >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140416/909909bd/attachment.htm ^ permalink raw reply [flat|nested] 12+ messages in thread
* [ath9k-devel] Retry control & iwconfig 2014-04-17 5:40 ` abhinav narain @ 2014-04-19 9:50 ` marcus muffin 0 siblings, 0 replies; 12+ messages in thread From: marcus muffin @ 2014-04-19 9:50 UTC (permalink / raw) To: ath9k-devel Hi all, I would like to investigate more on this retry issue. I did a simple experiment (single link, sender is a computer and receiver is a tp-link router. Both are with ath9k driver). I hack the code in sender side with as above mentioned, minstrel (from 7 to 0), ath9k/init.c (from 10 to 0), net/wireless/core.c (long retry from 4 to 0 and short retry from 7 to 0). After re-compile, the iwconfig still show the value of long retry is 7. I am not so sure where the wireless utilities still be able to get this value. I think there may be some missing part to hack for retry. With this hack of code, I perform iperf test (udp with 65 mbps for few minutes), I don't see any tx ecessive retries in iwconfig but the results of iperf doesn't change. If retry is disabled, we should expect to see more packet loss from iperf test but the value of packet loss after hacking is still 0%. I did a control experiment by disabling ack instead of retry (this one is confirmed to be no retry), the packet loss will increase from 0% to 10% with the same setting. I think there is still some parts going wrong to disable retry completely. Does anyone have idea? Marcus 2014-04-17 13:40 GMT+08:00 abhinav narain <abhinavnarain10@gmail.com>: > Hi Marcus, > Yes, as I suggested before, you should change it in driver code. > This value in mac80211 codebase is not reflected in ath9k driver(atleast) > where the default is 10 retransmits. > And if someone can explain how does minstrel work with default as 7 > retransmits while driver does 10 retransmits, > that will be awesome! > > - > Abhinav > > > > On Wed, Apr 16, 2014 at 9:49 PM, marcus muffin <ath9kmuffin@gmail.com>wrote: > >> hi all, >> >> I found that there is a retry value in net/wireless/core.c >> >> 348 rdev->wiphy.retry_short = 7; >> 349 rdev->wiphy.retry_long = 4; >> >> If i set those values to 0. the retry will still exist. Is it correct? >> >> Marcus >> >> >> 2014-03-26 21:34 GMT+08:00 abhinav narain <abhinavnarain10@gmail.com>: >> >> Hi, >>> just change value from 10 to 0 for retries to be zero! >>> >>> http://lxr.linux.no/linux+v3.13.5/drivers/net/wireless/ath/ath9k/init.c#L954 >>> >>> mac80211 API does not update this in ath9k for some reason and the >>> default >>> value of retries is 7 in rate minstrel which has also to be changed. >>> >>> Thanks, >>> Abhinav >>> >>> >>> On Wed, Mar 26, 2014 at 5:10 AM, Holger Schurig <holgerschurig@gmail.com >>> > wrote: >>> >>>> 1. "iwconfig" is outdated, don't use it. Use "iw" instead >>>> 2. As noted in the mail you linked to, the retry is also done by >>>> software in the mac80211 layer and in the ath9k driver >>>> 3. ath9k based-cards don't have firmware >>>> >>>> So, what you have basically do is to find out where in >>>> drivers/net/wireless/atheros and net/mac80211 or net/wireless the >>>> software-retry handling is taking place and make this switchable. LXR >>>> tells me that IEEE80211_FCTL_RETRY is used in ath9k, see >>>> >>>> http://lxr.linux.no/linux+v3.13.5/drivers/net/wireless/ath/ath9k/xmit.c#L357 >>>> . It seems that the ath9k has a max number of retries defined: >>>> >>>> http://lxr.linux.no/linux+v3.13.5/drivers/net/wireless/ath/ath9k/ath9k.h#L653 >>>> >>>> Hope that puts you into the right direction. >>>> _______________________________________________ >>>> ath9k-devel mailing list >>>> ath9k-devel at lists.ath9k.org >>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel >>>> >>> >>> >>> _______________________________________________ >>> ath9k-devel mailing list >>> ath9k-devel at lists.ath9k.org >>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140419/515978ad/attachment.htm ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2014-04-19 9:50 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-03-27 4:20 [ath9k-devel] Retry control & iwconfig Pradeep Reddy 2014-03-28 16:26 ` Olivier Marce 2014-03-29 18:32 ` Pradeep Reddy 2014-03-31 10:27 ` Paul Fuxjaeger 2014-04-02 10:02 ` Olivier Marce 2014-04-02 16:15 ` Olivier Marce -- strict thread matches above, loose matches on Subject: below -- 2014-03-25 14:51 Olivier Marce 2014-03-26 12:10 ` Holger Schurig 2014-03-26 13:34 ` abhinav narain 2014-04-17 4:49 ` marcus muffin 2014-04-17 5:40 ` abhinav narain 2014-04-19 9:50 ` marcus muffin
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.