Re: [Make-wifi-fast] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood)
On Mon, 16 May 2016, Roman Yeryomin wrote: On 16 May 2016 at 11:12, David Lang <da...@lang.hm> wrote: On Mon, 16 May 2016, Roman Yeryomin wrote: On 6 May 2016 at 22:43, Dave Taht <dave.t...@gmail.com> wrote: On Fri, May 6, 2016 at 11:56 AM, Roman Yeryomin <leroi.li...@gmail.com> wrote: On 6 May 2016 at 21:43, Roman Yeryomin <leroi.li...@gmail.com> wrote: On 6 May 2016 at 15:47, Jesper Dangaard Brouer <bro...@redhat.com> wrote: That is too low a limit, also, for normal use. And: for the purpose of this particular UDP test, flows 16 is ok, but not ideal. I played with different combinations, it doesn't make any (significant) difference: 20-30Mbps, not more. What numbers would you propose? How many different flows did you have going at once? I believe that the reason for higher numbers isn't for throughput, but to allow for more flows to be isolated from each other. If you have too few buckets, different flows will end up being combined into one bucket so that one will affect the other more. I'm testing with one flow, I never saw bigger performance with more flows (e.g. -P8 to iperf3). The issue isn't performance, it's isolating a DNS request from a VoIP flow from a streaming video flow from a DVD image download. The question is how many buckets do you need to have to isolate these in practice? it depends how many flows you have. The default was 1024 buckets, but got changed to 128 for low memory devices, and that lower value got made into the default, even for devices with lots of memory. I'm wondering if instead of trying to size this based on device memory, can it be resizable on the fly and grow if too many flows/collisions are detected? David Lang
Re: [Make-wifi-fast] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood)
On Mon, 16 May 2016, Roman Yeryomin wrote: On 6 May 2016 at 22:43, Dave Taht <dave.t...@gmail.com> wrote: On Fri, May 6, 2016 at 11:56 AM, Roman Yeryomin <leroi.li...@gmail.com> wrote: On 6 May 2016 at 21:43, Roman Yeryomin <leroi.li...@gmail.com> wrote: On 6 May 2016 at 15:47, Jesper Dangaard Brouer <bro...@redhat.com> wrote: That is too low a limit, also, for normal use. And: for the purpose of this particular UDP test, flows 16 is ok, but not ideal. I played with different combinations, it doesn't make any (significant) difference: 20-30Mbps, not more. What numbers would you propose? How many different flows did you have going at once? I believe that the reason for higher numbers isn't for throughput, but to allow for more flows to be isolated from each other. If you have too few buckets, different flows will end up being combined into one bucket so that one will affect the other more. David Lang
Re: [Make-wifi-fast] [RFCv2 1/3] mac80211: implement fq_codel for software queuing
On Wed, 16 Mar 2016, Michal Kazior wrote:
Since 11n aggregation become important to get the
best out of txops. However aggregation inherently
requires buffering and queuing. Once variable
medium conditions to different associated stations
is considered it became apparent that bufferbloat
can't be simply fought with qdiscs for wireless
drivers.
If the network is quiet enough, don't do any buffering, but in almost all
situations you are going to need to buffer starting no later than the second
packet you try to send.
Don't try to make queueing occur, just deal with the queues that form naturally
because you can't transmit data any faster (and work to keep them under some
semblence of control)
It's a tempting trap to fall into to try and fill the aggregates to transmit as
efficiently as possible, but don't skip transmitting because you don't have a
full aggregate, transmit what you have and if there is more, you'll catch it on
the next pass.
This is slightly less friendly on the network than waiting to see if you can
fill the aggregate in a quick fashion, but if uces the lowest latency possible,
and deteriorates into the same state that you end up with if you try to fill the
aggregates as the load/congestion builds.
David Lang
This bases on codel5 and sch_fq_codel.c. It may
not be the Right Thing yet but it should at least
provide a framework for more improvements.
Signed-off-by: Michal Kazior <michal.kaz...@tieto.com>
---
include/net/mac80211.h | 96 ++-
net/mac80211/agg-tx.c | 8 +-
net/mac80211/cfg.c | 2 +-
net/mac80211/codel.h | 264 ++
net/mac80211/codel_i.h | 89 ++
net/mac80211/debugfs.c | 267 ++
net/mac80211/ieee80211_i.h | 45 +++-
net/mac80211/iface.c | 25 +-
net/mac80211/main.c| 9 +-
net/mac80211/rx.c | 2 +-
net/mac80211/sta_info.c| 10 +-
net/mac80211/sta_info.h| 27 ++
net/mac80211/status.c | 64 +
net/mac80211/tx.c | 658 ++---
net/mac80211/util.c| 21 +-
15 files changed, 1503 insertions(+), 84 deletions(-)
create mode 100644 net/mac80211/codel.h
create mode 100644 net/mac80211/codel_i.h
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index a5cb1528..947d827f254b 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -565,6 +565,16 @@ struct ieee80211_bss_conf {
struct ieee80211_p2p_noa_attr p2p_noa_attr;
};
+/*
+ * struct codel_params - contains codel parameters
+ * @interval: initial drop rate
+ * @target: maximum persistent sojourn time
+ */
+struct codel_params {
+ u64 interval;
+ u64 target;
+};
+
/**
* enum mac80211_tx_info_flags - flags to describe transmission
information/status
*
@@ -853,6 +863,8 @@ ieee80211_rate_get_vht_nss(const struct ieee80211_tx_rate
*rate)
* @band: the band to transmit on (use for checking for races)
* @hw_queue: HW queue to put the frame on, skb_get_queue_mapping() gives the AC
* @ack_frame_id: internal frame ID for TX status, used internally
+ * @expected_duration: number of microseconds the stack expects this frame to
+ * take to tx. Used for fair queuing.
* @control: union for control data
* @status: union for status data
* @driver_data: array of driver_data pointers
@@ -865,11 +877,10 @@ ieee80211_rate_get_vht_nss(const struct ieee80211_tx_rate
*rate)
struct ieee80211_tx_info {
/* common information */
u32 flags;
- u8 band;
-
- u8 hw_queue;
-
- u16 ack_frame_id;
+ u32 band:2,
+ hw_queue:5,
+ ack_frame_id:15,
+ expected_duration:10;
union {
struct {
@@ -888,8 +899,18 @@ struct ieee80211_tx_info {
/* only needed before rate control */
unsigned long jiffies;
};
- /* NB: vif can be NULL for injected frames */
- struct ieee80211_vif *vif;
+ union {
+ /* NB: vif can be NULL for injected frames */
+ struct ieee80211_vif *vif;
+
+ /* When packets are enqueued on txq it's easy
+* to re-construct the vif pointer. There's no
+* more space in tx_info so it can be used to
+* store the necessary enqueue time for packet
+* sojourn time computation.
+*/
+ u64 enqueue_time;
+ };
struct ieee80211_key_conf *hw_key;
u32 flags;
/* 4 bytes free */
@@ -2114,8 +2135,8 @@ enum ieee80211_hw_flags {
* @cipher_schemes: a pointer to an array of cipher scheme definitions
* supported
Re: Network performance degradation from 2.6.11.12 to 2.6.16.20
On Tue, 19 Sep 2006, Alexey Kuznetsov wrote: Hello! Please think about it this way: suppose you haave a heavily loaded router and some network problem is to be diagnosed. You run tcpdump and suddenly router becomes overloaded (by switching to timestamp-it-all mode I am sorry. I cannot think that way. :-) Instead of attempts to scare, better resend original report, where you said how much performance degraded, I cannot find it. * I do see get_offset_pmtmr() in top lines of profile. That's scary enough. * I do not undestand what the hell dhcp needs timestamps for. * I do not listen any suggestions to screw up tcpdump with a sysctl. Kernel already implements much better thing then a sysctl. Do not want timestamps? Fix tcpdump, add an options, submit the patch to tcpdump maintainers. Not a big deal. if fireing up one program (however minor) can cause network performance to drop by 50% (based on the numbers reported earlier in this thread) that is a significant problem for sysadmins. yes tcpdump may be wrong in requesting timestamps (in most cases it probably is, but in some cases it's doing exactly what the sysadmin wants it to do), but I don't think that many sysadmins would expect this much of a performance hit. there should be some way to tell the system to ignore requests for timestamps so that a badly behaved program cannot cripple the system this way (and preferably something that doesn't require a full SELinux/capabilities implementation) David Lang - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Updated sysctl documentation take #2
On Thu, 8 Jun 2006, Johannes Stezenbach wrote: On Wed, Jun 07, 2006, Diego Calleja wrote: Since people didn't like the many small files approach, I've moved it to directories containing index.txt files: Documentation/sysctl/vm/index.txt Documentation/sysctl/net/core/index.txt Why not just Documentation/sysctl/vm.txt Documentation/sysctl/net/core.txt etc.? better matching of the proc layout would be my guess. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: network freeze with nforce-A939 integrated rhine card
On Fri, 12 May 2006, David Lang wrote: On Fri, 12 May 2006, Roger Luethi wrote: On Thu, 11 May 2006 22:59:44 -0700, David Lang wrote: I haven't had time to go back and find where is started (my prior kernel was 2.6.15-rc7), but with 2.6.17-rc1/2/3/4 I've been running into a problem where when transfering large amounts of data (trying to ftp a TB where is started sounds as if it used to work at some point. In your second posting, however, you note that the problem goes back at least to 2.6.13. So are there any kernels known not to exhibit the problem you described? when I posted this origionally I thought it was new in 2.6.17-rc, however since my testing with older kernels hasn't found me a working one yet I suspect that other factors have been involved with makeing it work. these failures have been on multi-gig files ftp'd from the raid array on my machine to the raid array on the replacement machine. In the past I've sucessfully transfered similar sized files to/from my tivo (slow network), my laptop (slow drive), and smaller sets of files to single drives on other systems (7200rpm drives, but not to arrays). as I type this I'm starting a test going from a single drive on this machine to the raid array on the remote machine to transfer ~84G of data. My suspicion is that this is going to work. I just confirmed this, I was able to transfer 84G with no trouble starting from /dev/hdb, but starting from /dev/md0 the nic hung in less then 3G a good boot logs eth0: VIA Rhine II at 0xe8121000, 00:11:5b:f4:14:a3, IRQ 17. eth0: MII PHY found at address 1, status 0x7869 advertising 05e1 Link cde1. [EMAIL PROTECTED]:~# ethtool eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 1 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: d Current message level: 0x0001 (1) Link detected: yes David Lang - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: network freeze with nforce-A939 integrated rhine card
On Sat, 13 May 2006, David Lang wrote: On Fri, 12 May 2006, David Lang wrote: On Fri, 12 May 2006, Roger Luethi wrote: On Thu, 11 May 2006 22:59:44 -0700, David Lang wrote: I just confirmed this, I was able to transfer 84G with no trouble starting from /dev/hdb, but starting from /dev/md0 the nic hung in less then 3G a good boot logs eth0: VIA Rhine II at 0xe8121000, 00:11:5b:f4:14:a3, IRQ 17. eth0: MII PHY found at address 1, status 0x7869 advertising 05e1 Link cde1. [EMAIL PROTECTED]:~# ethtool eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 1 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: d Current message level: 0x0001 (1) Link detected: yes and here's what I get when it's hung from syslog when it hangs May 13 01:58:17 david kernel: attempt to access beyond end of device May 13 01:58:17 david kernel: md0: rw=0, want=8708129352, limit=2188035584 May 13 01:58:17 david kernel: attempt to access beyond end of device May 13 01:58:17 david kernel: md0: rw=0, want=7768925008, limit=2188035584 May 13 02:13:50 david ntpd[2589]: time reset +0.699871 s May 13 02:16:51 david kernel: eth0: link down from ethtool Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Advertised auto-negotiation: Yes Speed: 10Mb/s Duplex: Half Port: MII PHYAD: 1 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: d Current message level: 0x0001 (1) Link detected: no from the boot with it hung. eth0: VIA Rhine II at 0xe8121000, 00:11:5b:f4:14:a3, IRQ 17. eth0: MII PHY found at address 1, status 0x7849 advertising 05e1 Link . David Lang - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
network freeze with nforce-A939 integrated rhine card
I haven't had time to go back and find where is started (my prior kernel was 2.6.15-rc7), but with 2.6.17-rc1/2/3/4 I've been running into a problem where when transfering large amounts of data (trying to ftp a TB or so of data off of the box to my new server it will run for a while (as little as 1G, as much as 45G) and then the network card will shut down. when I say shut down I mean that it looses link and requires powering down the box (hard power down, not just power off from the front panel), disabling the network card in the BIOS, booting (as far as lilo is enough), powering down again, enabling the card and booting again. there is no indication of trouble before the halt (it's transfering at full speed), the only think in the log is May 11 22:23:57 david kernel: eth0: link down May 11 22:24:00 david kernel: eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1 May 11 22:24:22 david kernel: eth0: link down if I don't do the disable/enable in the bios cycle and just power cycle the system the card does not initialize properly (ethtool reports autonegotiation disabled, 10Mb. will generate an 'unsupported' error if I try to enable the card) the system is x86_64 64 bit kernel with 32 bit userspace lspci report [EMAIL PROTECTED]:~$ /sbin/lspci 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0204 00:00.1 Host bridge: VIA Technologies, Inc.: Unknown device 1204 00:00.2 Host bridge: VIA Technologies, Inc.: Unknown device 2204 00:00.3 Host bridge: VIA Technologies, Inc.: Unknown device 3204 00:00.4 Host bridge: VIA Technologies, Inc.: Unknown device 4204 00:00.7 Host bridge: VIA Technologies, Inc.: Unknown device 7204 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800 South] 00:08.0 RAID bus controller: Triones Technologies, Inc. HPT374 (rev 07) 00:08.1 RAID bus controller: Triones Technologies, Inc. HPT374 (rev 07) 00:0a.0 Ethernet controller: Olicom OC-2326 (rev 01) 00:0f.0 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C/VT8235 PIPC Bus Master IDE (rev 06) 00:10.0 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 81) 00:10.1 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 81) 00:10.2 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 81) 00:10.3 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 81) 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [K8T800 South] 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) 00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 78) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (rev 01) config is attached David Lang config.gz Description: Binary data
Re: network freeze with nforce-A939 integrated rhine card
On Fri, 12 May 2006, Roger Luethi wrote: On Thu, 11 May 2006 22:59:44 -0700, David Lang wrote: I haven't had time to go back and find where is started (my prior kernel was 2.6.15-rc7), but with 2.6.17-rc1/2/3/4 I've been running into a problem where when transfering large amounts of data (trying to ftp a TB where is started sounds as if it used to work at some point. In your second posting, however, you note that the problem goes back at least to 2.6.13. So are there any kernels known not to exhibit the problem you described? when I posted this origionally I thought it was new in 2.6.17-rc, however since my testing with older kernels hasn't found me a working one yet I suspect that other factors have been involved with makeing it work. these failures have been on multi-gig files ftp'd from the raid array on my machine to the raid array on the replacement machine. In the past I've sucessfully transfered similar sized files to/from my tivo (slow network), my laptop (slow drive), and smaller sets of files to single drives on other systems (7200rpm drives, but not to arrays). as I type this I'm starting a test going from a single drive on this machine to the raid array on the remote machine to transfer ~84G of data. My suspicion is that this is going to work. when I say shut down I mean that it looses link and requires powering down the box (hard power down, not just power off from the front panel), disabling the network card in the BIOS, booting (as far as lilo is enough), powering down again, enabling the card and booting again. So there are two problem areas: 1) the chip hangs itself without the driver noticing and 2) the BIOS fails to bring the chip back to life afterwards. yes there is no indication of trouble before the halt (it's transfering at full speed), the only think in the log is May 11 22:23:57 david kernel: eth0: link down May 11 22:24:00 david kernel: eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1 May 11 22:24:22 david kernel: eth0: link down if I don't do the disable/enable in the bios cycle and just power cycle the system the card does not initialize properly (ethtool reports autonegotiation disabled, 10Mb. will generate an 'unsupported' error if I try to enable the card) Any difference in the kernel log when booting with (or ethtooling) a comatose chip? I haven't checked the boot logs, I'll do that. ethtool hasn't generated any logs that I've seen. after the current transfer finishes I'll trigger the bug and test this. [EMAIL PROTECTED]:~$ /sbin/lspci 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0204 00:00.1 Host bridge: VIA Technologies, Inc.: Unknown device 1204 00:00.2 Host bridge: VIA Technologies, Inc.: Unknown device 2204 00:00.3 Host bridge: VIA Technologies, Inc.: Unknown device 3204 00:00.4 Host bridge: VIA Technologies, Inc.: Unknown device 4204 00:00.7 Host bridge: VIA Technologies, Inc.: Unknown device 7204 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800 South] 00:08.0 RAID bus controller: Triones Technologies, Inc. HPT374 (rev 07) 00:08.1 RAID bus controller: Triones Technologies, Inc. HPT374 (rev 07) 00:0a.0 Ethernet controller: Olicom OC-2326 (rev 01) 00:0f.0 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C/VT8235 PIPC Bus Master IDE (rev 06) 00:10.0 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 81) 00:10.1 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 81) 00:10.2 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 81) 00:10.3 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 81) 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [K8T800 South] 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) 00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 78) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (rev 01) Odd. This doesn't look at all like the list I'd expect from an nforce-A939. I thought Nvidia devices featured rather prominently in the device lists of nforce-based boards!? you're right, it's the new server that has the nforce board. I'll have to check the motherboard version when I reboot it. David Lang - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bcm43xx-dev] [Fwd: State of the Union: Wireless]
On Fri, 6 Jan 2006, Patrick McHardy wrote: Marcel Holtmann wrote: I just personally liked the idea of having a device node in /dev for every existing hardware wlan card. Like we have device nodes for other real hardware, too. It felt like a bit of a unix way to do this to me. I don't say this is the way to go. If a netlink socket is used (which is possible, for sure), we stay with the old way of having no device node in /dev for networking devices. That is ok. But that is really only an implementation detail (and for sure a matter of taste). At the OLS last year, I think the consensus was to use netlink for all configuration task. However this was mainly driven by Harald Welte and he might be able to talk about the pros and cons of netlink versus a character device. I think the main advantages of netlink over a character device is its flexible format, which is easily extendable, and multicast capability, which can be used to broadcast events and configuration changes. Its also good to have all the net stuff accessible in a uniform way. character devices are far easier to script. this really sounds like the type of configuration stuff that sysfs was designed for. can we avoid yet another configuration tool that's required? David Lang -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
