Vimage globals vs structures measurements.
anyone who has commands and args for their favourite thing the'd like me to test... send it in.. so far using ttcp I have seem no measureable difference. but I have more tests to do of course.. for example throughput with small packets with ttcp (KB/Sec) x VIMAGE_GLOBALS + NO_VIMAGE_GLOBALS +-+ | + xx | | + xxx + | | + xxx x | | x+ x + + xxx + | |x+ ++ xx xxx + xxx x x x + ***x | ||_A__M__|| | |AM| | +-+ N Min Max Median Avg Stddev x 40 48016.01 57361.3256268.06 54915.582 2554.0133 + 40 48999.66 59646.5956261.58 56086.798 3119.1782 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re[2]: kern/123881: [tcp] Turning on TCP blackholing causes slow localhost connections
Here is another demonstration of this bug: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=190401+0+archive/2008/freebsd-net/20080406.freebsd-net Friday, January 30, 2009, 10:48:55 PM, you wrote: vFo> Synopsis: [tcp] Turning on TCP blackholing causes slow localhost connections vFo> State-Changed-From-To: open->closed vFo> State-Changed-By: vwe vFo> State-Changed-When: Fri Jan 30 19:45:46 UTC 2009 vFo> State-Changed-Why: vFo> Tom, vFo> we think this issue either is not related to the tcp stack or not directly vFo> related to blackholing connections. It might be an application issue. vFo> As we do not think there's something we can work on, we're going to close vFo> this PR. vFo> If you think there should be something fixed, please put more information vFo> into the PR so we can check that. Thank you for reporting this problem. vFo> Responsible-Changed-From-To: freebsd-net->vwe vFo> Responsible-Changed-By: vwe vFo> Responsible-Changed-When: Fri Jan 30 19:45:46 UTC 2009 vFo> Responsible-Changed-Why: vFo> track vFo> http://www.freebsd.org/cgi/query-pr.cgi?pr=123881 vFo> ___ vFo> freebsd-net@freebsd.org mailing list vFo> http://lists.freebsd.org/mailman/listinfo/freebsd-net vFo> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" -- Best regards, Anthonymailto:a...@mail.ru ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Vimage globals vs structures measurements.
Julian Elischer wrote: anyone who has commands and args for their favourite thing the'd like me to test... send it in.. so far using ttcp I have seem no measureable difference. but I have more tests to do of course.. for example throughput with small packets with ttcp (KB/Sec) x VIMAGE_GLOBALS + NO_VIMAGE_GLOBALS +-+ | + xx | | + xxx + | | + xxx x | | x+ x + + xxx + | |x+ ++ xx xxx + xxx x x x + ***x | ||_A__M__|| | |AM| | +-+ N Min Max Median Avg Stddev x 40 48016.01 57361.3256268.06 54915.582 2554.0133 + 40 48999.66 59646.5956261.58 56086.798 3119.1782 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" as I said before mst of my tests have shown no real change but this one has the most change I've seen.. it's 160 byte udp packets sent between two identical machines (both using the same kernel each time). x VIMAGE_GLOBALS + NO_VIMAGE_GLOBALS +-+ | + + ++ xx x x | | + + ++ +x++x +xx x x | | + + +++ + +*+**x+ x | | + +++ +++x*++*+**x*x*xx x x x | | + +*+x**+*+**x*x*x*xx x x xx| |*+*+**x*xx xxx| |+ + xx + *++*++***x*x x| |+ +*+++ xx++*+*+*++x***x*xxx*xx x xx x| | |__A__| | | |_A|| +-+ N Min MaxMedianAvgStddev x 150 10175.11 11292.11 10763.8010760.77200.92124 + 150 10075.64 11019.12 10591.6810580.059 172.29227 Difference at 95.0% confidence -180.711 +/- 42.3572 -1.67935% +/- 0.393626% (Student's t, pooled s = 187.155) this one showed a 1.7% slowdown where the one above showed a half percent speedup (but not considered significant). The first one shown above was TCP with 1500 byte packets on bge 1G interfaces.. more test ideas appreciated... ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/126564: [ath] doesn't work with my PCI-E X1 wireless network adaptor
Synopsis: [ath] doesn't work with my PCI-E X1 wireless network adaptor State-Changed-From-To: feedback->closed State-Changed-By: vwe State-Changed-When: Sat Jan 31 10:22:17 UTC 2009 State-Changed-Why: Intron, the latest HAL changes have been committed to 7-STABLE with rev 186910. Please update your source tree. Also please note this PR is a DUP of kern/115226 (we're closing this PR, please file any followups to the other PR). Thank you! Responsible-Changed-From-To: freebsd-net->vwe Responsible-Changed-By: vwe Responsible-Changed-When: Sat Jan 31 10:22:17 UTC 2009 Responsible-Changed-Why: track http://www.freebsd.org/cgi/query-pr.cgi?pr=126564 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: bin/118987: ifconfig(8): ifconfig -l (address_family) does not work correctly on RELENG-7
The following reply was made to PR bin/118987; it has been noted by GNATS. From: Will Andrews To: bug-follo...@freebsd.org Cc: Subject: Re: bin/118987: ifconfig(8): ifconfig -l (address_family) does not work correctly on RELENG-7 Date: Sat, 31 Jan 2009 03:29:52 -0700 --001636c5986450f9c20461c4cdef Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Here is a patch that fixes this problem (it also fixes the problem for address families besides "ether"). I'm not sure if the method used is the best approach for "ether", but it does at least match some other usage within ifconfig. Unfortunately I don't seem to be able to attach patches correctly for GNATS, so here's a link: http://firepipe.net/ifconfig.c.118987-diff2.txt --Will. --001636c5986450f9c20461c4cdef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Here is a patch that fixes this problem (it also fixes the problem for addr= ess families besides "ether"). I'm not sure if the meth= od used is the best approach for "ether", but it does at least ma= tch some other usage within ifconfig. Unfortunately I don't seem = to be able to attach patches correctly for GNATS, so here's a link: http://firepipe.net/ifconfig.c.118987-diff2.txt";>= http://firepipe.net/ifconfig.c.118987-diff2.txt --Will. --001636c5986450f9c20461c4cdef-- ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: bin/118987: ifconfig(8): ifconfig -l (address_family) does not work correctly on RELENG-7
Synopsis: ifconfig(8): ifconfig -l (address_family) does not work correctly on RELENG-7 State-Changed-From-To: open->analyzed State-Changed-By: vwe State-Changed-When: Sat Jan 31 10:31:59 UTC 2009 State-Changed-Why: Will has created a patch for evaluation http://www.freebsd.org/cgi/query-pr.cgi?pr=118987 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/103059: [bce] [patch] "Error mapping mbuf into TX chain!" (tentative patch)
Synopsis: [bce] [patch] "Error mapping mbuf into TX chain!" (tentative patch) State-Changed-From-To: open->closed State-Changed-By: vwe State-Changed-When: Sat Jan 31 11:09:15 UTC 2009 State-Changed-Why: Michael, we think this issue is fixed by r159411 and r164327. If you think this issue is still one, please check your problem with a more recent release as 6.1 has been EOL'd. Responsible-Changed-From-To: freebsd-net->vwe Responsible-Changed-By: vwe Responsible-Changed-When: Sat Jan 31 11:09:15 UTC 2009 Responsible-Changed-Why: track http://www.freebsd.org/cgi/query-pr.cgi?pr=103059 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/118880: [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented for IPv6
The following reply was made to PR kern/118880; it has been noted by GNATS. From: "Bjoern A. Zeeb" To: bug-follo...@freebsd.org, j...@iki.fi Cc: Subject: Re: kern/118880: [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented for IPv6 Date: Sat, 31 Jan 2009 13:25:20 + (UTC) Hi, see kern/122039 which seems to be a ``duplicate'' of this one but has a comment for discussion. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/113842: [ip6] PF_INET6 proto domain state can't be cleared without a reboot
Synopsis: [ip6] PF_INET6 proto domain state can't be cleared without a reboot State-Changed-From-To: open->analyzed State-Changed-By: bz State-Changed-When: Sat Jan 31 13:42:49 UTC 2009 State-Changed-Why: The problem has been analyzed a few months back. A workaround for what I think the submitter has asked for was presented; yet an rc sscript and the kernel has to be fixed. Responsible-Changed-From-To: freebsd-net->bz Responsible-Changed-By: bz Responsible-Changed-When: Sat Jan 31 13:42:49 UTC 2009 Responsible-Changed-Why: I'll take care of this. http://www.freebsd.org/cgi/query-pr.cgi?pr=113842 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/123200: [netgraph] Server failure due to netgraph mpd and dhcpclient
Synopsis: [netgraph] Server failure due to netgraph mpd and dhcpclient State-Changed-From-To: feedback->closed State-Changed-By: mav State-Changed-When: Sat Jan 31 13:52:36 UTC 2009 State-Changed-Why: Patches fixing crashes/freezes on VPN routing loop were merged to 7-STABLE. http://www.freebsd.org/cgi/query-pr.cgi?pr=123200 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/118880: [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented for IPv6
Synopsis: [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented for IPv6 State-Changed-From-To: open->closed State-Changed-By: vwe State-Changed-When: Sat Jan 31 14:23:06 UTC 2009 State-Changed-Why: kern/122039 is a DUP of this PR but we're closing this in favour of kern/122039 as it does contain some more information. Thank you for your report. Responsible-Changed-From-To: freebsd-net->bz Responsible-Changed-By: vwe Responsible-Changed-When: Sat Jan 31 14:23:06 UTC 2009 Responsible-Changed-Why: assign closed PR to bz as it seems to be of interest to him http://www.freebsd.org/cgi/query-pr.cgi?pr=118880 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: lagg failover mode and vlans
On Tue, Jan 27, 2009 at 12:39:26PM -0500, Mike Tancsa wrote: ... > > but if I create some vlan interfaces off lagg0 > > lagg0.100: flags=8843 metric 0 mtu > 1500 > options=3 > ether 00:30:48:90:4c:fe > inet 192.168.100.1 netmask 0xff00 broadcast 192.168.100.255 > media: Ethernet autoselect > status: active > vlan: 100 parent interface: lagg0 > lagg0.102: flags=8843 metric 0 mtu > 1500 > options=3 > ether 00:30:48:90:4c:fe > inet 192.168.102.1 netmask 0xff00 broadcast 192.168.102.255 > media: Ethernet autoselect > status: active > vlan: 102 parent interface: lagg0 > > and do the same pulling of the cable, it does not work. BUT, if I do an > arp -nda on a machine that is part of vlan102 which is doing the pinging > (so an arp-who has gets sent out and a reply answered), it works. The > other option is if I send a packet out on the vlan's broadcast address from > the server Can you verify that em2, em3 and all the lagg* interfaces have the same mac address. Andrew ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/123066: [ipsec] [panic] kernel trap with ipsec
Synopsis: [ipsec] [panic] kernel trap with ipsec Responsible-Changed-From-To: freebsd-net->vanhu Responsible-Changed-By: bz Responsible-Changed-When: Sat Jan 31 22:25:12 UTC 2009 Responsible-Changed-Why: kern/124609 seems linked to this one and you handled that; could you check if both PRs are the same? http://www.freebsd.org/cgi/query-pr.cgi?pr=123066 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
mbuf revision, testers/comments wanted.
http://people.freebsd.org/~jeff/mbuf_ref2.diff Hello, I have been experimenting with different revisions to the mbuf api to improve performance and simplify code. This patch is the first of several proposed steps towards those goals. The aim of this patch is two fold; 1) Revising the reference counting system so that we can eliminate reference uma zones and the significant uma_find_refcnt() costs in some workloads. This is done by making all mbufs reference counted and using the owning mbuf's ref for the ext_ref. In this model we never reference data, we only reference other mbufs owning the data. 2) Improve allocation and free performance by reducing the special cases in the format and using inlines when appropriate. In particular, the simplification of the m_ext structure yields less code and confusion for dealing with external storage on free. The ctor/dtor mbuf routines are no longer used. A zone pointer and length was added to struct mbuf to simplify free and size calculations. A number of routines were made much, much simpler by the addition of a 16bit size field. Previously we dependend on calculating the size by figuring out if it was an ext, pkthdr, or standard mbuf. Ultimately, this patch moves us closer to having a size agnostic mbuf which we can use to experiment with different allocation sizes or even backending to malloc for dynamically sized mbufs. I would appreciate testing feedback from varied workloads to make sure there are no bugs before I go forward with this. I have tested only host oriented networking with a few drivers. It is not anticipated that there will be any significant incompatibilities introduced with this round but there is always that possibility. Thanks, Jeff ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: read() returns ETIMEDOUT
Hi! I have found also: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/108670 http://lists.freebsd.org/mailman/htdig/freebsd-net/2007-February/013095.html I am using FreeBSD 7.0-STABLE. Mitar ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: lagg failover mode and vlans
At 04:33 PM 1/31/2009, Andrew Thompson wrote: > > and do the same pulling of the cable, it does not work. BUT, if I do an > arp -nda on a machine that is part of vlan102 which is doing the pinging > (so an arp-who has gets sent out and a reply answered), it works. The > other option is if I send a packet out on the vlan's broadcast address from > the server Can you verify that em2, em3 and all the lagg* interfaces have the same mac address. Looks to be from the server side. I dont have them hooked up to the switch right now, but will Monday em2: flags=8843 metric 0 mtu 1500 options=19b ether 00:30:48:90:4c:fe inet 1.1.1.1 netmask 0xff00 broadcast 1.1.1.255 media: Ethernet autoselect status: no carrier lagg: laggdev lagg0 em3: flags=8843 metric 0 mtu 1500 options=19b ether 00:30:48:90:4c:fe inet 10.10.1.1 netmask 0xff00 broadcast 10.10.1.255 media: Ethernet autoselect status: no carrier lagg: laggdev lagg0 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 lagg0: flags=8843 metric 0 mtu 1500 options=19b ether 00:30:48:90:4c:fe inet 192.168.44.99 netmask 0xff00 broadcast 192.168.44.255 media: Ethernet autoselect status: no carrier laggproto failover laggport: em3 flags=0<> laggport: em2 flags=1 lagg0.100: flags=8843 metric 0 mtu 1500 options=3 ether 00:30:48:90:4c:fe inet 192.168.100.1 netmask 0xff00 broadcast 192.168.100.255 media: Ethernet autoselect status: no carrier vlan: 100 parent interface: lagg0 lagg0.102: flags=8843 metric 0 mtu 1500 options=3 ether 00:30:48:90:4c:fe inet 192.168.102.1 netmask 0xff00 broadcast 192.168.102.255 media: Ethernet autoselect status: no carrier vlan: 102 parent interface: lagg0 Andrew ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
read() returns ETIMEDOUT
Hi! Is there any progress on this error reported: http://freebsd.monkey.org/freebsd-net/200805/msg00026.html I have the same or very similar issue. On my server large HTTP uploads are failing because there are only one direction data transmissions (when reading/receiving a request) and kernel drops connections after some time with ETIMEDOUT returning from read() even if transmissions are doing just fine with steady speed, tested at different speeds. Is there any workaround currently known? Mitar ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/129719: [tcp] [panic] Panic during shutdown, tcp_ctloutput: inp == NULL
Synopsis: [tcp] [panic] Panic during shutdown, tcp_ctloutput: inp == NULL State-Changed-From-To: open->feedback State-Changed-By: linimon State-Changed-When: Sun Feb 1 01:33:56 UTC 2009 State-Changed-Why: Is this easily reproducible? And, if so, do you have a corefile available that can be posted on the web somewhere? http://www.freebsd.org/cgi/query-pr.cgi?pr=129719 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/129719: [tcp] [panic] Panic during shutdown, tcp_ctloutput: inp == NULL
In the last episode (Feb 01), lini...@freebsd.org said: > Is this easily reproducible? And, if so, do you have a corefile > available that can be posted on the web somewhere? I've only had it happen once, but I still have the corefile if it might help. -- Dan Nelson dnel...@allantgroup.com ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
