> On Oct 16, 2014, at 11:14 AM, compdoc <[email protected]> wrote: > > > The difference between Olivier's setup and ours (assuming pfsense 2.1.1+), > > is tuning > > The only way to prove what you say is with numbers. Tuning pfSense won't fix > this hardware problem, *if* it exists in your boards.
Your assumption (that there is a hardware problem) is unwarranted. The problem is that FreeBSD (especially FreeBSD 8.3, upon which the current “release” version of pfSense software (v2.1.5) is based), is not well-tuned to multi-core hardware. We took certain steps to fix the problem (as well as it can be fixed on 8.3) and are working to improve the situation for both FreeBSD and pfSense. (FreeBSD 10 is better than 8.3, but, as Olivier also discovered, imperfect.) There is a lot of work to do in this area, including enabling RSS (for forwarding, there is recent work for reception in FreeBSD -HEAD), thread pinning, additional work on a per-core copy of the state table, more work on flow-table, etc. It’s all roughly planned, and the subject of some discussion while I have all the pfSense coreteam in Austin this week to discuss this, and what we’re going to do after the 2.2 release of pfSense. > >> As I said in my original post, I'm know the C2758 is capable according to > >> its specs, however buyer beware... > > > >Again with the insult and denigration. > > Is it an insult that I think Intel's cpu is capable? Or is it that I suggest > a person be cautious when buying these products? Is your position that you are unaware of the meaning of “Caveat emptor”, and it’s history in both English common law and statutory law in all 50 United States? (Apologies to readers outside the US, but OP is based in Denver, CO, so the point stands.) You might wish to perform an Internet search for “buyer beware” and see the type of thing that comes up, and then reconsider my reaction in light of same. You may also wish to review "Laidlaw v. Organ, 15 U.S. 178 (1817)” if you still don’t know what I’m talking about. Your noisy attempts at persuasion of the consumer base actually require the vendor (that’s me) to respond. (Never mind the whole “silence is assent” attitude that many hold.) You gave some results of some tests you performed on an AMD A8-7600 and an i5-2400. I asked for additional details, and you refused to provide any. You asserted that pfSense crashes under load. (You reported that this “was tested by someone else”) I asked for details, and you refused to provide any. You asserted that BSDRP is a “tool to test hardware”. You stated that it “has very little overhead and runs on freebsd.” The reality is that BSDRP is a slightly customized distribution of FreeBSD, it doesn’t “run on FreeBSD”, it *is* FreeBSD, as packaged by Olivier to suit his purposes at Orange. This is a good thing. That you’ve repurposed it to “test your hardware” is also fine, but your assertion that BSDRP is “a tool to test hardware” is still false. Many people use screwdrivers as levers. This doesn’t mean that their usage is correct, nor does it make “a screwdriver is a tool to open paint cans” true. > > Do you own a C2758? > > Have you actually bothered to read anything I've said in this conversation? > > It's time to end this nonsense. Prove what you say, or shut up. Fair warning: Being rude will eventually get you removed from the list. Published numbers are forthcoming, as soon as we’re ready to make the results public. I’ve already exposed the tools we’re using, and some of the improvements we’ve seen. There is a long history in the project of people making-up benchmark numbers to suit their agenda. There is also a long history in the project of people posting ‘fixes’ for various issues, including performance issues, where these ‘fixes’ have nothing to do with the actual issue. The number of times I’ve seen recommendations to "sysctl -w kern.ipc.maxsockbuf=<huge number>” or to set the TCP/UDP default buffer sizes, or set window scaling in an attempt to increase forwarding performance through ‘pf' makes me cringe. (recent reference: https://forum.pfsense.org/index.php?topic=71949.0) There are a number of things currently in pfSense that do not lend to absolute performance. mbuf tags and ALTQ are two examples. ALTQ is about a 10% impact on PPS performance. mbuf tags are the work of the devil. FreeBSD’s penchant for looking up the ARP entry for every single packet (even though it just looked up the ARP entry for the last packet, which was to the same destination) is also a problem. There are some great results from Luigi Rizzo (actual author of the pkt-gen tool) on putting ipfw (the competing packet filter in FreeBSD) over netmap, reaching 7-10Mpps. We will explore pf over netmap (again, after we get pfSense 2.2 released), and hope for similar results. The point is, we’re focused on it (especially after we get pfSense 2.2 released, such that work we do on pfSense can be taken back “upstream” (to FreeBSD)). There is also work to do on some of the drivers. Both igb(4) and igbe(4) have issues. cxgbe(4) is in really good shape, by comparison. I don’t want to bother with cxgb(4). All of the RSS focus in FreeBSD right now is also on igb(4), igbe(4) and cxgbe(4). Even saying this much, someone in the crowd is sure to make the assertion that, “pfSense isn’t going to support (my favorite driver)!”, which isn’t true, but (favorite driver) might be late to the party. Every statement I make has a certain risk of being taken out of context to “prove” someone else’s point. Jim _______________________________________________ List mailing list [email protected] https://lists.pfsense.org/mailman/listinfo/list
