Re: [PATCH] Disable TSO for non standard qdiscs
On Thu, 2008-01-31 at 20:34 +0100, Andi Kleen wrote: The philosophical problem I have with this suggestion is that I expect that the large majority of users will be more happy with disabled TSO if they use non standard qdiscs and defaults that do not fit the majority use case are bad. I wouldn't be so fast to assume that all users need an exact playout rate, as people seem to do fine with the 8Kbps playout steps in Cisco IOS. A nerd-knob which expresses user's preference in the accuracy/performance trade-off would be nice. The problem with ethtool is that it's a non-obvious nerd knob. At the least the ethtool documentation should be updated to indicate that activating TSO effects tc accuracy. Best wishes, Glen [a network engineer] -- 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: Packetlost when tc qdisc del dev eth0 root
On Wed, 2008-01-16 at 00:46 +0300, [EMAIL PROTECTED] wrote: But i have above 45 k classes and qdiscs After some time i will need patch to up max qdisc and classes more then 65k ( 0xfffe) =))) Also i have very bad TC commands performance then i have more then 10k rules. In contrast a brand name router will support 4 to 16 queues per (sub-)interface. Your large number of queues exceeds expectations. What are you trying to do? You may be better off inventing a new qdisc to meet your need (eg, to do per-IP traffic shaping or, less complexly, a traffic shaping based on the value of mark which might offend DiffServ purists) or have, say, 1000 output rates based on a marking and use the ipset feature of Netfilter to set the mark. Using 1000 rates gives an error of 0.1% which is unlikely to be noticed by your customers given the larger effects of shaping on TCP performance but is beneath the level where you are noticing performance issues. -- 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: Netconf at conf.au 2008?
On Sun, 2008-01-13 at 18:08 -0800, David Miller wrote: Now, if this were available outside of the conference so that we could play with it remotely from where we work, that's more interesting. Hi David, As I posted to this list last year AARNet is willing to make a 10GE connected server in Perth available to the netdev and PFLDNet communities. There was a matching offer from the University of Manchester in England, which gives an impressive BDP (Perth-Sydney-Seattle-New York-London @ 10Gbps across production networks). Since there was no reply to the offer it went on the back burner and we've done a smaller rollout (Perth-Seattle) to suit our own immediate needs. We really appreciate your work and the work of everyone else on the netdev list, so I'll re-contact Manchester and get this back on track. If you have trouble hosting netconf next year please get in touch. Although AARNet could not sponsor the flights or accommodation we could provide everything else you require. We're not name in bright lights people so there would be plenty of room for other sponsors. [1] Alternatively, AARNet has been pretty successful in the past at attracting sponsorship for events which benefit our users, so if you and the netdev people were willing to hold a one-day training/workshop of interest to academic and research network users (say network host tuning) before/after your meeting then we'd have no trouble getting sponsorship via the training event that would be sufficient to cover the airfares and accommodation for the larger event. Anyway, to cut to the chase, the users of AARNet face large RTTs to get anywhere and we are very appreciative of the huge amount of work that you, John, Stephen and many others on this list have put into improving performance under the conditions we face. If we can help your work then please ask. Best wishes, Glen [1] Witness our sponsorship of linux.conf.au, where our only real request is that people don't place us in a difficult position by misusing the network we provide. -- Glen Turner, Network Engineer (08) 8303 3936 or +61 8 8303 3936 Australia's Academic Research Network www.aarnet.edu.au -- 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: Netconf at conf.au 2008?
On Sat, 2008-01-12 at 08:52 +0200, Andy Johnson wrote: I saw somewhere (maybe in this mailing list a while ago) that there might be a Linux Kernel Developers' Netconf conference at conf.au 2008. Does anyone here know if such a thing is planned ? Hi Andy, I don't know. However this seems a good opportunity to remind people that AARNet will as usual be proving a 1Gbps link from linux.conf.au to universities and national labs in the USA and beyond. Netdev people are welcome to hammer this if they want to test performance on a real-life long fat pipe (minimum RTT 200ms). If you particularly want some feature (IPv6, multicast, whatever), some engineering detail, a real worst case RTT (Perth-Sydney-Seattle-New York-Amsterdam-Tomsk @ 1Gbps) or some office space before/after the conference then drop me a mail. There are two well-educated users of fast long-distance networks in Melbourne doing transfers for physics and astronomy applications. If the application/TCP interaction is of interest then I can arrange an introduction. Best wishes, Glen -- Glen Turner, Network Engineer (08) 8303 3936 or +61 8 8303 3936 Australia's Academic Research Network www.aarnet.edu.au -- 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: After many hours all outbound connections get stuck in SYN_SENT
[speculation by network engineer -- not kernel hacker -- follows] The router could be sooo crappy that it drops all packets from TCP streams that have SACK enabled and the client has opened 200+ SACK connections previously... something like that? As far as any third party is concerned the existing TCP connections continue to have negotiated SACK Permitted. Only new connections will not negotiate this. So router crappiness promptly disappearing doesn't seem too likely (a way I could see this happening is if the Linux box sends a Ack for each connection and this clears out Sack datastructures on the third party). But I'd be very surprised if the router is acting as anything more that a network-layer device. It might perhaps have some soft connection state being used for generating accounting records. Being Cisco it's probably a switch-router, so it might carry some per-port hard state for validating source IP addresses and ARPs on each port. The firewall is much more likely to be carrying per-flow Sack state. The Cisco PIX had a bug with SACK handling (CSCse14419, fixed in 7.0(7), 7.1(2.34), 7.2(2.2), 8.0(0.141) but perhaps it has regressed). A simple trace either side of the firewall will show the inconsistency between the TCP sequence number (which gets randomised) and the Sack sequence number (which didn't). You could disable the TCP Sequence Number Randomisation feature and see if the fault reoccurs. You'd probably should also investigate the Linux kernel, especially the size and locks of the components of the Sack data structures and what happens to those data structures after Sack is disabled (presumably the Sack data structure is in some unhappy circumstance, and disabling Sack allows the data to be discarded, magically unclaging the box). In the absence of the reporter wanting to dump the kernel's core, how about a patch to print the Sack datastructure when the command to disable Sack is received by the kernel? Maybe just print the last 16b of the IP address? Best wishes, Glen -- 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: After many hours all outbound connections get stuck in SYN_SENT
I do have TCP Sequence # Randomization enabled on my router. Huh? Do you mean a PIX blade in a Cisco switch-router chassis? It would be very useful if you could be less vague about the equipment in use. However, if this was causing an issue, wouldn't it always occur and cause connection issues, not just after 38 hours of correct operation? That depends more on your customers' networking attributes then you are sharing or perhaps even know. Perhaps your customer base is very Window-skewed and you simply aren't seeing any Sack Permitted negotiations for the first 37.999 hours. Or perhaps you've had a network glitch, and all of your connections have done a Selective Ack, which the firewall has trashed, leaving all the connections in a wacko state, not just a few which you haven't noticed. The actual failure mode needs a packet trace to determine, but you should be able to do this yourself (or ask your local network engineering staff). If your firewall is trashing the Sack field, then it needs to be fixed. Time to raise a case with the Cisco TAC and ask them directly if your PIX version has bug CSCse14419. You can't expect Sack to work when it's being fed trash, so it is important to make sure that is not happening. Cheers, Glen #include network_engineer.h #undef KERNEL_HACKER -- 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: Packet per Second
[Apologies for off-topic] On Mon, 2007-12-17 at 11:18 +, Flávio Pires wrote: I alread though about something like this. But, isn`t NetFlow just for Cisco IOS ? NetFlow is a trade mark of Cisco Systems Inc (USA). Packets in the identical format used by NetFlow are produced by a wide range of networking equipment, including a number of Linux tools. I've seen the Linux tools used in customer networks but I've never evaluated them myself, which is why I'm didn't make a recommendation of a particular tool for the sampler. Because of the trade mark you'll often find NetFlow traffic samplers under names other than NetFlow (eg, Juniper uses cflowd as a synonym for NetFlow). There is one exception: sFlow is *not* identical to the NetFlow format. If you want more information on ISP accounting tools, the NANOG list is a more suitable forum. The Cisco-NSP and Juniper-NSP lists often host useful discussions too. The archives of all these lists are online. Best wishes, Glen -- Glen Turner http://www.gdt.id.au/~gdt/ Tel: 0416 295 857 or +61 416 295 857 -- 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: Packet per Second
On Fri, 2007-12-14 at 15:34 +, Flávio Pires wrote: Well, I work on an ISP and we have a linux box acting as a bridge+firewall. With this bridge+firewall we control the packet rate per second from each client and from our repeaters. But I can`t measure the packet rate per IP. Is there any tool for this? The usual approach is to generate NetFlow records -- there are a number of Linux tools for this. Collect them with a collector (flow-tools being a common choice). Then have a Perl script which reads the flow records, processes them whichever way you desire, and drops the result into a rrdtool file (there are modules for both reading the flow-tools data and outputing in the rrdtool format). The rrdtool utilities have a limited range of graphs, but there is a huge selection of graphing packages from other authors for rrdtool-stored data (Drraw, etc). Flow-tools also has some third-party analysis tools, some of those have good top talker statistics. This is a lot of work, since you are really putting a complete measurement infrastructure in place to get the one statistic you desire. But I'd encourage you to do that, since knowing one statistic usually leads to further questions of the data. -- Glen Turner, Senior Network Engineer Australia's Academic Research Networkwww.aarnet.edu.au -- 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
