Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
On Wed, Aug 22, 2012 at 08:43:52AM -0400, John Baldwin wrote: On Tuesday, August 21, 2012 7:16:30 pm Slawa Olhovchenkov wrote: On Tue, Aug 21, 2012 at 05:25:23PM -0400, John Baldwin wrote: On Tuesday, August 21, 2012 9:34:31 am John Baldwin wrote: On Tuesday, August 21, 2012 7:53:08 am Lev Serebryakov wrote: Hello, Garrett. You wrote 21 августа 2012 г., 15:40:35: GC Try reverting r239356 -- if that works, then please let jhb@ know. LS I'm confused by this commit, because it seems (from comment alone), LS that dhclient will not work without devd anymore (with synchronous LS dhcp option in rc.conf). LS Am I right? And if I'm right about understanding what this change does, it is POLA violation for sure. Both consequences: unable to use dhcclient without devd (user will need to restart it by hands after each cable unplugging event) and removing IP address from interface on cable unplugging or other interface down event but before lease is expired. If I'm right in understanding this commit, I vote to back it out and find better solution, may be, two new options: one to remove IP and one to exit on interface down. And default behavior should be OLD ONE about IP address in any case and OLD ONE about exit in case when dhclient isn't started by devd, but by rc scripts directly. Humm. devd is the more common case, and we explicitly don't use devd to start dhclient on boot even when devd is enabled (so out of the box dhcp would first be started by rc, but would be restarted by devd). Another option is to rework dhclient to work like it does on OpenBSD where it renews its lease if the link bounces, but to not exit when the link goes down. That case would fix the currently broken case that you unplug your cable, take your laptop over to another network (e.g. take it home if suspend/resume works), then plug it back in and are still stuck with your old IP. Ok, this is what I came up with, somewhat loosely based on OpenBSD's dhclient. I tested that it survives the following: - Unplugging/replugging does not kill an existing ssh session - Using ifconfig down/up does not kill an existing ssh session - Plugging into a different network does cause dhclient to negotiate a new lease on the new network Assign address on interface manualy cause exiting dhcpclient? Hmm, it does. Is that by design? That seems to be the old behavior of the client from my reading of the code as well. I am don't know, but this is comfortable. It is not desirable lost this behavior. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
On Tue, Aug 21, 2012 at 03:45:48PM +0400, Lev Serebryakov wrote: Hello, Lev. You wrote 21 августа 2012 г., 15:40:35: GC Try reverting r239356 -- if that works, then please let jhb@ know. LS I'm confused by this commit, because it seems (from comment alone), LS that dhclient will not work without devd anymore (with synchronous LS dhcp option in rc.conf). LS Am I right? Also, I don't like idea of removing IP address from interface when cable is unplugged. It was very disturbing behavior of Windows machines for years. I've unplug cable to change switch port for only a second and all connections are broken, even if one second later dhcpclient receive SAME lease! I don't like this. FreeBSD was very tolerant to unplugging cable for eons, and I (and not only me) like it. If I understand this change properly, it is no more the case :( Not only cable. Turn on microwave, lost WiFi connection and lost all open ssh session (and other network connection). ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
On Tue, Aug 21, 2012 at 09:40:27PM +0400, Lev Serebryakov wrote: Hello, Ian. You wrote 21 августа 2012 г., 21:36:30: IL Perhaps the right solution is to add a dhclient command line option to IL operate in the historical buggy mode: it doesn't exit on link status IL changes, and fails to work properly if those link status changes are IL happening because the physical connection has moved to another network. Right solution was spoken by jhb@ already: dhclient should re-request lease on interface down/up cycle. There is no need to exit and be started again in any case. It will work ``as expected'' without any options for everybody. Not re-request lease, simple renew. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
On Tue, Aug 21, 2012 at 10:18:15PM +0400, Lev Serebryakov wrote: SO Not re-request lease, simple renew. Sorry, I'm not very strong in exact terms here. dhcp client can sent different requests: DHCPDISCOVER from 0.0.0.0 to 255.255.255.255 DHCPREQUEST from 0.0.0.0 to SERVER_IP (from DHCPOFFER) or DHCPRELEASE DHCPDISCOVER from 0.0.0.0 to 255.255.255.255 DHCPREQUEST from 0.0.0.0 to SERVER_IP or DHCPREQUEST from 0.0.0.0 to 255.255.255.255 or DHCPREQUEST from IP to SERVER_IP and DHCPINFORM for quering additional parametrs after boot, w/o change IP (for example IE request information about proxy auto config) renew address at lease_time/2 usually DHCPREQUEST from IP to SERVER_IP. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
On Tue, Aug 21, 2012 at 01:56:11PM -0600, Warner Losh wrote: On Aug 21, 2012, at 6:46 AM, Slawa Olhovchenkov wrote: On Tue, Aug 21, 2012 at 03:45:48PM +0400, Lev Serebryakov wrote: Hello, Lev. You wrote 21 августа 2012 г., 15:40:35: GC Try reverting r239356 -- if that works, then please let jhb@ know. LS I'm confused by this commit, because it seems (from comment alone), LS that dhclient will not work without devd anymore (with synchronous LS dhcp option in rc.conf). LS Am I right? Also, I don't like idea of removing IP address from interface when cable is unplugged. It was very disturbing behavior of Windows machines for years. I've unplug cable to change switch port for only a second and all connections are broken, even if one second later dhcpclient receive SAME lease! I don't like this. FreeBSD was very tolerant to unplugging cable for eons, and I (and not only me) like it. If I understand this change properly, it is no more the case :( Not only cable. Turn on microwave, lost WiFi connection and lost all open ssh session (and other network connection). mosh helps. No. Not all remote host allow to install mosh. Cisco routers, for example, don't allow to install mosh. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
On Wed, Aug 22, 2012 at 02:36:23AM +0400, Lev Serebryakov wrote: Hello, Ian. You wrote 22 августа 2012 г., 1:38:04: IL For example, this script can replace devd as a daemon that restarts IL dhclient when any link comes back up... IL Of course the right thing to do is invoke the proper rc scripts rather IL than dhclient directly... this is just to illustrate how easy it is to IL replace devd if your needs are specialized. [sigh] Everything worked with 8.x without problems. It worked with 9.x and -CURRENT with adding of ``synchronous_dhclient=YES'' into /etc/rc.conf (And it cost me about 2 hours of investigation, why dhclient stops to start after upgrade). Next I'll need to write some script. Is it Ok to you? Yes, I understand problem with laptops, which change wire and wireless networks and need to re-acquire new address. But it should be soleved other way. And jhb@ already posted proper solution, BTW! And, as side note, ``man rc.cof'' says NOTHING about relation of devd and ``synchronous_dhclient'' setting! It says about ``start dhclient(8) synchronously at startup'' without explaining, that without this option and with devd disabled, dhclient WILL NOT START AT ALL! And relations between devd and dhclient are not documented at all in: rc.conf(5), dhclient(8), devd.conf(5) and devd(8). Time ago synchronous_dhclient is waiting for obtain IP by dhcpclient. w/o synchronous_dhclient and ifconfig_bge0=DHCP dhcpclient run in background and don't paused boot while obtaining IP address. On perinterface basis: ifconfig_bge0=SYNCDHCP or ifconfig_bge0=NOSYNCDHCP Background start of dhcpclient currently by devd, on UP event on ethernet interface. This introduction in 6.2. 2006-08-22. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
On Tue, Aug 21, 2012 at 05:25:23PM -0400, John Baldwin wrote:
On Tuesday, August 21, 2012 9:34:31 am John Baldwin wrote:
On Tuesday, August 21, 2012 7:53:08 am Lev Serebryakov wrote:
Hello, Garrett.
You wrote 21 августа 2012 г., 15:40:35:
GC Try reverting r239356 -- if that works, then please let jhb@ know.
LS I'm confused by this commit, because it seems (from comment alone),
LS that dhclient will not work without devd anymore (with synchronous
LS dhcp option in rc.conf).
LS Am I right?
And if I'm right about understanding what this change does, it is
POLA violation for sure. Both consequences: unable to use dhcclient
without devd (user will need to restart it by hands after each cable
unplugging event) and removing IP address from interface on cable
unplugging or other interface down event but before lease is expired.
If I'm right in understanding this commit, I vote to back it out and
find better solution, may be, two new options: one to remove IP and
one to exit on interface down. And default behavior should be OLD
ONE about IP address in any case and OLD ONE about exit in case when
dhclient isn't started by devd, but by rc scripts directly.
Humm. devd is the more common case, and we explicitly don't use devd to
start
dhclient on boot even when devd is enabled (so out of the box dhcp would
first
be started by rc, but would be restarted by devd).
Another option is to rework dhclient to work like it does on OpenBSD where
it
renews its lease if the link bounces, but to not exit when the link goes
down.
That case would fix the currently broken case that you unplug your cable,
take
your laptop over to another network (e.g. take it home if suspend/resume
works), then plug it back in and are still stuck with your old IP.
Ok, this is what I came up with, somewhat loosely based on OpenBSD's dhclient.
I tested that it survives the following:
- Unplugging/replugging does not kill an existing ssh session
- Using ifconfig down/up does not kill an existing ssh session
- Plugging into a different network does cause dhclient to negotiate
a new lease on the new network
Assign address on interface manualy cause exiting dhcpclient?
I've removed the bits to clear the old configuration if dhclient exits due to
'ifconfig down', and dhclient no longer exits on link down, but instead tracks
the link state and enters the 'reboot' state when the link goes up.
Index: dhcpd.h
===
--- dhcpd.h (revision 239498)
+++ dhcpd.h (working copy)
@@ -208,6 +208,7 @@
int errors;
int dead;
u_int16_tindex;
+ int linkstat;
};
struct timeout {
Index: dhclient.c
===
--- dhclient.c(revision 239498)
+++ dhclient.c(working copy)
@@ -218,6 +218,7 @@
struct sockaddr *sa;
struct iaddr a;
ssize_t n;
+ int linkstat;
n = read(routefd, msg, sizeof(msg));
rtm = (struct rt_msghdr *)msg;
@@ -278,10 +279,14 @@
ifi-name);
goto die;
}
- if (!interface_link_status(ifi-name)) {
- warning(Interface %s is down, dhclient exiting,
- ifi-name);
- goto die;
+ linkstat = interface_link_status(ifi-name);
+ if (linkstat != ifi-linkstat) {
+ debug(%s link state %s - %s, ifi-name,
+ ifi-linkstat ? up : down,
+ linkstat ? up : down);
+ ifi-linkstat = linkstat;
+ if (linkstat)
+ state_reboot(ifi);
}
break;
case RTM_IFANNOUNCE:
@@ -321,8 +326,6 @@
die:
script_init(FAIL, NULL);
- if (ifi-client-active)
- script_write_params(old_, ifi-client-active);
if (ifi-client-alias)
script_write_params(alias_, ifi-client-alias);
script_go();
@@ -437,6 +440,7 @@
}
fprintf(stderr, got link\n);
}
+ ifi-linkstat = 1;
if ((nullfd = open(_PATH_DEVNULL, O_RDWR, 0)) == -1)
error(cannot open %s: %m, _PATH_DEVNULL);
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
ftpd reset restart position (REST) at any command
I try using mirror 2.9 (old, very old perl script) to mirror ftp site
in passive mode and see don't working restart transfer: server ignored
'REST pos' command.
This because in ftpcmd.y cleared restart_point:
cmd_list
: /* empty */
| cmd_list cmd
{
if (fromname)
free(fromname);
fromname = NULL;
restart_point = 0;
}
| cmd_list rcmd
;
(cmd is any command execept RNFR and REST) and mirror in passive mode
used next command sequence:
REST pos
PASV
RETR file
RFC 3659 allow this, but not recomeded:
The server-PI may react to a badly positioned REST command by
save the restart value and apply it to the next data transfer command
...
Why this case (save the restart value) is bad choice?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Some performance measurements on the FreeBSD network stack
On Wed, Apr 25, 2012 at 01:22:06PM +0400, Maxim Konovalov wrote: Hi, On Tue, 24 Apr 2012, 17:40-, Li, Qing wrote: Yup, all good points. In fact we have considered all of these while doing the work. In case you haven't seen it already, we did write about these issues in our paper and how we tried to address those, flow-table was one of the solutions. http://dl.acm.org/citation.cfm?id=1592641 Is this article available for those without ACM subscription? Tip: get citation from abstract to google. 3'th link: http://conferences.sigcomm.org/sigcomm/2009/workshops/presto/papers/p37.pdf ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
pmap and mtx scalability problem
I treid make -j 30 build{world,kernel} (latest -CURRENT) on 24-core machine and
see poor
scalability of pmap/mtx -- more then 50% cpu spend on system time.
pmcstat:
@ CPU_CLK_UNHALTED_CORE [194841 samples]
42.65% [83102]_mtx_lock_sleep @ /boot/kernel/kernel
40.97% [34051] pmap_enter
100.0% [34051] vm_fault_hold
100.0% [34051] trap_pfault
30.40% [25262] vm_page_activate
100.0% [25262] vm_fault_hold
100.0% [25262] trap_pfault
18.41% [15300] vm_pageq_remove
73.63% [11266] vm_page_free_toq
70.69% [7964]vm_object_terminate
29.31% [3302]vm_object_page_remove
26.37% [4034] vm_fault_hold
100.0% [4034]trap_pfault
make -j 8:
15.44% [10740]_mtx_lock_sleep @ /boot/kernel/kernel
38.77% [4164] pmap_enter
99.93% [4161] vm_fault_hold
100.0% [4161]trap_pfault
00.07% [3] kmem_back
100.0% [3] kmem_malloc
27.98% [3005] vm_page_activate
100.0% [3005] vm_fault_hold
100.0% [3005]trap_pfault
20.64% [2217] vm_pageq_remove
64.73% [1435] vm_page_free_toq
63.41% [910] vm_object_terminate
make -j 4
06.86% [4222] pagezero @ /boot/kernel/kernel
98.39% [4154] trap_pfault
100.0% [4154] trap
01.11% [47]vm_fault_hold
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pmap and mtx scalability problem
On Tue, Apr 24, 2012 at 09:27:30PM +0200, K. Macy wrote: Known problem. There is an open disagreement about how to improve the granularity of locking in pmap. split locking to process-specific information and global information? use lock-free lists (i see TAILQ_INSERT_TAIL in pmap_enter)? sorry for stupidity, if any. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pmap and mtx scalability problem
On Tue, Apr 24, 2012 at 10:43:08PM +0200, K. Macy wrote: No. I developed a patch from Jeffr that pushed the vm_page_lock array down in to the machine dependent code, replacing most of the uses of the single vm_page_queue_lock. However, alc doesn't like the design and has not proposed an alternative. can i test this? -Kip On Tue, Apr 24, 2012 at 10:36 PM, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Tue, Apr 24, 2012 at 09:27:30PM +0200, K. Macy wrote: Known problem. There is an open disagreement about how to improve the granularity of locking in pmap. split locking to process-specific information and global information? use lock-free lists (i see TAILQ_INSERT_TAIL in pmap_enter)? sorry for stupidity, if any. -- ?The real damage is done by those millions who want to 'get by.' The ordinary men who just want to be left in peace. Those who don?t want their little lives disturbed by anything bigger than themselves. Those with no sides and no causes. Those who won?t take measure of their own strength, for fear of antagonizing their own weakness. Those who don?t like to make waves?or enemies. Those for whom freedom, honour, truth, and principles are only literature. Those who live small, love small, die small. It?s the reductionist approach to life: if you keep it small, you?ll keep it under control. If you don?t make any noise, the bogeyman won?t find you. But it?s all an illusion, because they die too, those people who roll up their spirits into tiny little balls so as to be safe. Safe?! From what? Life is always on the edge of death; narrow streets lead to the same place as wide avenues, and a little candle burns itself out just like a flaming torch does. I choose my own way to burn.? Sophie Scholl ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Some performance measurements on the FreeBSD network stack
On Thu, Apr 19, 2012 at 03:30:18PM +0200, Luigi Rizzo wrote: I have been running some performance tests on UDP sockets, using the netsend program in tools/tools/netrate/netsend and instrumenting the source code and the kernel do return in various points of the path. Here are some results which I hope you find interesting. I do some test in 2011. May be this test is not actual now. May be actual. Initial message http://lists.freebsd.org/pipermail/freebsd-performance/2011-January/004156.html UDP socket in FreeBSD http://lists.freebsd.org/pipermail/freebsd-performance/2011-February/004176.html About 4BSD/ULE http://lists.freebsd.org/pipermail/freebsd-performance/2011-February/004181.html ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: rctl limit cpu
On Wed, Jul 27, 2011 at 09:32:49PM +0200, Edward Tomasz Napiera?a wrote: Wiadomo?? napisana przez Alexander Pyhalov w dniu 26 lip 2011, o godz. 15:32: Hello. I see in rctl man page, that I can limit cpu time in milliseconds, e.g., for jail. But I can't deny allocation of the resource (according to man page). In Solaris I can assign different amount of cpu shares to different projects. How can I achieve this with rctl? For example, I'd like to give jail:www 40% CPU, jail:db - 50% CPU and leave 10% to the base system... The cputime resource (it got renamed shortly before the code freeze to match resource names in login.conf(5)) defines amount of CPU time used, not the percentage. That's why you cannot deny it - if you could, it would just make the offending process (jail, login class, user) hang indefinitely. The %CPU limit is not implemented yet. I plan to do this before sometime after 9.0 is out. Any progress yet? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [patch] iwi(4) suspend/resume broken
On Wed, Mar 14, 2012 at 09:46:56AM +0900, Mitsuru IWASAKI wrote: Hi, I've noticed that iwi(4) doesn't have ieee80211_new_state(IEEE80211_S_INIT) in iwi_stop_locked() since 8.0-RELEASE (comparing with RELENG_7's). It seems that this prevent if_iwi from working properly after resuming, no data frames were sent. The patches is available at: http://people.freebsd.org/~iwasaki/iwi/iwi-20120314.diff Now that iwi(4) is working well for me :) I'll commit this coming weekend if there are no objections. ath(4) also don't work witch suspend/resume. and ath(4) dpn't work after resume even if kldunload before suspend (kldload don't work). ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] modular kernel config
On Fri, Mar 02, 2012 at 10:09:24AM +0100, Alexander Leidinger wrote: Quoting Slawa Olhovchenkov s...@zxy.spb.ru (from Thu, 1 Mar 2012 18:58:34 +0400): On Tue, Feb 21, 2012 at 02:35:37PM +0100, Alexander Leidinger wrote: You can download from http://www.Leidinger.net/FreeBSD/current-patches/ The files are - i386_SMALL - i386_SMALL_loader.conf - amd64_SMALL - amd64_SMALL_loader.conf Where SCSI disk/etc? CAM and ATA are loaded as modules in the loader.conf (except for two SCSI controllers, which are not available as modules). I may have missed to load a module, or I may not load in the correct order (which would be a bug of missing/wrong dependencies in some modules). I'm investigating a corresponding report with error messages. Not controllers, peripherals: disk/tape/etc device scbus # SCSI bus (required for ATA/SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass# Passthrough device (direct ATA/SCSI access) device ses # SCSI Environmental Services (and SAF-TE) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] modular kernel config
On Tue, Feb 21, 2012 at 02:35:37PM +0100, Alexander Leidinger wrote: You can download from http://www.Leidinger.net/FreeBSD/current-patches/ The files are - i386_SMALL - i386_SMALL_loader.conf - amd64_SMALL - amd64_SMALL_loader.conf Where SCSI disk/etc? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFT] Major snd_hda rewrite
On Wed, Jan 11, 2012 at 09:33:17PM +0200, Alexander Motin wrote: I would like request for testing of my work on further HDA sound driver improvement. Can you add (or document, if exist) functionality of recording audio playing? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: datapoints on 10G throughput with TCP ?
On Mon, Dec 05, 2011 at 08:27:03PM +0100, Luigi Rizzo wrote: Hi, I am trying to establish the baseline performance for 10G throughput over TCP, and would like to collect some data points. As a testing program i am using nuttcp from ports (as good as anything, i guess -- it is reasonably flexible, and if you use it in TCP with relatively large writes, the overhead for syscalls and gettimeofday() shouldn't kill you). I'd be very grateful if you could do the following test: - have two machines connected by a 10G link - on one run nuttcp -S - on the other one run nuttcp -t -T 5 -w 128 -v the.other.ip and send me a dump of the output, such as the one(s) at the end of the message. I am mostly interested in two configurations: - one over loopback, which should tell how fast is the CPU+memory As an example, one of my machines does about 15 Gbit/s, and one of the faster ones does about 44 Gbit/s - one over the wire using 1500 byte mss. Here it really matters how good is the handling of small MTUs. As a data point, on my machines i get 2..3.5 Gbit/s on the slow machine with a 1500 byte mtu and default card setting. Clearing the interrupt mitigation register (so no mitigation) brings the rate to 5-6 Gbit/s. Same hardware with linux does about 8 Gbit/s. HEAD seems 10-20% slower than RELENG_8 though i am not sure who is at fault. The receive side is particularly critical - on FreeBSD the receiver is woken up every two packets (do the math below, between the number of rx calls and throughput and mss), resulting in almost 200K activations per second, and despite the fact that interrupt mitigation is set to a much lower value (so incoming packets should be batched). On linux, i see much fewer reads, presumably the process is woken up only at the end of a burst. About relative performance FreeBSD and Linux I wrote in -performance@ at Jan'11 (Interrupt performance) EXAMPLES OF OUTPUT -- nuttcp -t -T 5 -w 128 -v 10.0.1.2 nuttcp-t: v6.1.2: socket nuttcp-t: buflen=65536, nstream=1, port=5001 tcp - 10.0.1.2 nuttcp-t: time limit = 5.00 seconds nuttcp-t: connect to 10.0.1.2 with mss=1460, RTT=0.103 ms nuttcp-t: send window size = 131400, receive window size = 65700 nuttcp-t: 3095.0982 MB in 5.00 real seconds = 633785.85 KB/sec = 5191.9737 Mbps nuttcp-t: host-retrans = 0 nuttcp-t: 49522 I/O calls, msec/call = 0.10, calls/sec = 9902.99 nuttcp-t: 0.0user 2.7sys 0:05real 54% 100i+2639d 752maxrss 0+3pf 258876+6csw nuttcp-r: v6.1.2: socket nuttcp-r: buflen=65536, nstream=1, port=5001 tcp nuttcp-r: accept from 10.0.1.4 nuttcp-r: send window size = 33580, receive window size = 131400 nuttcp-r: 3095.0982 MB in 5.17 real seconds = 613526.42 KB/sec = 5026.0084 Mbps nuttcp-r: 1114794 I/O calls, msec/call = 0.00, calls/sec = 215801.03 nuttcp-r: 0.1user 3.5sys 0:05real 69% 112i+1104d 626maxrss 0+15pf 507653+188csw nuttcp -t -T 5 -w 128 -v localhost nuttcp-t: v6.1.2: socket nuttcp-t: buflen=65536, nstream=1, port=5001 tcp - localhost nuttcp-t: time limit = 5.00 seconds nuttcp-t: connect to 127.0.0.1 with mss=14336, RTT=0.051 ms nuttcp-t: send window size = 143360, receive window size = 71680 nuttcp-t: 26963.4375 MB in 5.00 real seconds = 5521440.59 KB/sec = 45231.6413 Mbps nuttcp-t: host-retrans = 0 nuttcp-t: 431415 I/O calls, msec/call = 0.01, calls/sec = 86272.51 nuttcp-t: 0.0user 4.6sys 0:05real 93% 102i+2681d 774maxrss 0+3pf 2510+1csw nuttcp-r: v6.1.2: socket nuttcp-r: buflen=65536, nstream=1, port=5001 tcp nuttcp-r: accept from 127.0.0.1 nuttcp-r: send window size = 43008, receive window size = 143360 nuttcp-r: 26963.4375 MB in 5.20 real seconds = 5313135.74 KB/sec = 43525.2080 Mbps nuttcp-r: 767807 I/O calls, msec/call = 0.01, calls/sec = 147750.09 nuttcp-r: 0.1user 3.9sys 0:05real 79% 98i+2570d 772maxrss 0+16pf 311014+8csw on the server, run ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: High Network Perfomance
On Thu, Aug 04, 2011 at 08:39:17PM -0300, Victor Detoni wrote: Hi Guys, I'm trying tunning a FreeBSD 8.2 to high perfomance network with pf. My server configuration is: Dell 1950 CPU: Intel(R) Xeon(R) CPU5130 @ 2.00GHz (1995.03-MHz K8-class CPU) 4 x CPU 2 NIC (Broadcom NetXtreme II BCM5708 1000Base-T) 1 NIC (em0: Intel(R) PRO/1000 Network Connection 7.1.9) I want to reach the high processing of packets per second and use pf as synproxy and we still processor to handle others packets or flows. I know that em drivers has MULTI_QUEUE implementation that helps high performance for Intel drivers, but I couldn't see more information about. We can reached 500k pps, but no more traffic was processed by this interface. I've already enabled net.isr.direct but with Intel Drivers does not work and the most processors are in System instead of Interrupts, why? When I enable net.isr.direct the processing is balanced for on CPU in system and another in interrupt and I reached 1M pps, but the total perfomance is down, the load grow up too fast. I've changed some parameter in sysctl for intel drivers, but it doesn't have effect. Someone know what I can do to reach more packets performance? I want to use this FreeBSD as a router/firewall only. FreeBSD (and em) need some tuning for high perfomance. Next links in russian, sorry. http://dadv.livejournal.com/138951.html http://dadv.livejournal.com/139170.html http://dadv.livejournal.com/139366.html -- Slawa Olhovchenkov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: A page fault in subr_turnstile.c:propogate_priority()
On Wed, Dec 03, 2003 at 05:43:13PM +0300, Igor Sysoev wrote:
panic: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address = 0xe5
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc053f197
stack pointer = 0x10:0xe3c21c80
frame pointer = 0x10:0xe3c21ca0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 42 (irq29: ahd0)
trap number = 12
panic: page fault
cpuid = 2;
boot() called on cpu#2
syncing disks, buffers remaining... panic: bremfree: removing a buffer not on a queue
cpuid = 2;
boot() called on cpu#2
Uptime: 1d2h4m15s
Dumping 2047 MB
jmp0xc053f2b2 propagate_priority+578
0xc053f187 propagate_priority+279:cmp(%edi),%ebx
0xc053f189 propagate_priority+281:
je 0xc053f290 propagate_priority+544
0xc053f18f propagate_priority+287:mov0x24(%ebx),%eax
0xc053f192 propagate_priority+290:mov0x4(%eax),%eax
0xc053f195 propagate_priority+293:mov(%eax),%edx
[ FAULT ]
/usr/src/sys/kern/subr_turnstile.c:256
td1 = TAILQ_PREV(td, threadqueue, td_lockq);
if (td1-td_priority = pri) {
mtx_unlock_spin(tc-tc_lock);
continue;
}
0xc053f197 propagate_priority+295:movzbl 0xe5(%edx),%eax
0xc053f19e propagate_priority+302:cmp0xfff0(%ebp),%eax
0xc053f1a1 propagate_priority+305:
jle0xc053f290 propagate_priority+544
0xc053f1a7 propagate_priority+311:call 0xc051e650 critical_enter
0xc053f1ac propagate_priority+316:mov%fs:0x0,%edx
0xc053f1b3 propagate_priority+323:mov$0x4,%eax
0xc053f1b8 propagate_priority+328:lock cmpxchg %edx,0xc06ac7fc
0xc053f1c0 propagate_priority+336:sete %al
0xc053f1c3 propagate_priority+339:movzbl %al,%eax
0xc053f1c6 propagate_priority+342:test %eax,%eax
0xc053f1c8 propagate_priority+344:
jne0xc053f210 propagate_priority+416
0xc053f1ca propagate_priority+346:mov%fs:0x0,%edx
--
Slawa Olhovchenkov
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: psmintr not attached w/ acpi
On Mon, Dec 01, 2003 at 09:48:40AM -0800, Nate Lawson wrote: Your ASL indicates that it returns different values for present (based on PS2F) and current resources (based on KBDI). Please send me the URL to the full ASL so I can see what sets those two variables. http://zxy.spb.ru/acpi.dump Do you need additional information? -- Slawa Olhovchenkov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: psmintr not attached w/ acpi
On Mon, Dec 01, 2003 at 10:59:49AM -0800, Nate Lawson wrote:
On Mon, Dec 01, 2003 at 09:48:40AM -0800, Nate Lawson wrote:
Your ASL indicates that it returns different values for present (based on
PS2F) and current resources (based on KBDI). Please send me the URL to
the full ASL so I can see what sets those two variables.
http://zxy.spb.ru/acpi.dump
Do you need additional information?
Try this workaround, recompile your asl, set dsdt_load in loader.conf.
See acpi(4) if you need info on this process. I think your BIOS needs a
workaround. I wonder if the MS interpreter ignores _STA for some devices.
I try recompile asl and got some errors:
===
iasl acpi.dump
Intel ACPI Component Architecture
ASL Optimizing Compiler / AML Disassembler version 20030619 [Nov 25 2003]
Copyright (C) 2000 - 2003 Intel Corporation
Supports ACPI Specification Revision 2.0b
acpi.dump84: And (SUSF, 0x02, STAT)
Error1037 -^ syntax error
ASL Input: acpi.dump - 3574 lines, 113232 bytes, 12 keywords
Compilation complete. 1 Errors, 0 Warnings, 0 Remarks, 9 Optimizations
===
I commented out this line and try again.
===
iasl acpi.dump
Intel ACPI Component Architecture
ASL Optimizing Compiler / AML Disassembler version 20030619 [Nov 25 2003]
Copyright (C) 2000 - 2003 Intel Corporation
Supports ACPI Specification Revision 2.0b
acpi.dump 352: Method (\_WAK, 1, NotSerialized)
Warning 2026 - ^ Reserved method must return a value (_WAK)
acpi.dump 382: Store (Local0, Local0)
Error1013 - ^ Method local variable is not initialized
(Local0)
acpi.dump 387: Store (Local0, Local0)
Error1013 - ^ Method local variable is not initialized
(Local0)
acpi.dump 1609: ICF0, 2,
Error1051 - ^ Access width of Field Unit extends beyond
region limit
acpi.dump 1610: ICF1, 2,
Error1051 - ^ Access width of Field Unit extends beyond
region limit
acpi.dump 1612: WPPE, 1,
Error1051 - ^ Access width of Field Unit extends beyond
region limit
acpi.dump 1614: FAS0, 2,
Error1051 - ^ Access width of Field Unit extends beyond
region limit
acpi.dump 1615: FAS1, 2
Error1051 - ^ Access width of Field Unit extends beyond
region limit
ASL Input: acpi.dump - 3850 lines, 119353 bytes, 1690 keywords
Compilation complete. 7 Errors, 1 Warnings, 0 Remarks, 345 Optimizations
===
What is wrong?
--- slawa-IntelLaptop.asl.origMon Dec 1 10:54:18 2003
+++ slawa-IntelLaptop.asl Mon Dec 1 10:57:39 2003
@@ -3353,14 +3353,7 @@
Name (_HID, EisaId (PNP0F13))
Method (_STA, 0, NotSerialized)
{
-If (LEqual (PS2F, 0x00))
-{
Return (0x0F)
-}
-Else
-{
-Return (0x00)
-}
}
Method (_CRS, 0, NotSerialized)
-Nate
--
Slawa Olhovchenkov
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
psmintr not attached w/ acpi
If acpi enabled PS/2 mouse failed to work and irq12 cold't attach
to psmintr.
Is this problem reporting PS/2 mouse resource before atkbdc?
psmcpnp0 irq 12 on acpi0
atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0
atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0
atkbd: the current kbd controller command byte 0047
atkbd: keyboard ID 0x41ab (2)
kbd0 at atkbd0
kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d
psm0: current command byte:0047
psm0: PS/2 Mouse irq 12 on atkbdc0
psm0: model IntelliMouse, device ID 3-00, 3 buttons
psm0: config:, flags:, packet size:4
psm0: syncmask:08, syncbits:08
vmstat -i
interrupt total rate
irq0: clk 64245 99
irq1: atkbd0 1 0
irq8: rtc 82235127
irq11: xl0 uhci0+737 1
irq13: npx01 0
irq14: ata0 2411 3
irq15: ata1 52 0
Total 149682232
Device (PS2M)
{
Name (_HID, EisaId (PNP0F13))
Method (_STA, 0, NotSerialized)
{
If (LEqual (PS2F, 0x00))
{
Return (0x0F)
}
Else
{
Return (0x00)
}
}
Method (_CRS, 0, NotSerialized)
{
Name (BUF1, Buffer (0x05)
{
0x22, 0x00, 0x10, 0x79, 0x00
})
Name (BUF2, Buffer (0x15)
{
0x47, 0x01, 0x60, 0x00, 0x60, 0x00, 0x01, 0x01,
0x47, 0x01, 0x64, 0x00, 0x64, 0x00, 0x01, 0x01,
0x22, 0x00, 0x10, 0x79, 0x00
})
If (LEqual (KBDI, 0x01))
{
Return (BUF2)
}
Else
{
Return (BUF1)
}
}
}
Device (PS2K)
{
Name (_HID, EisaId (PNP0303))
Method (_STA, 0, NotSerialized)
{
If (LEqual (KBDI, 0x01))
{
Return (0x00)
}
Else
{
Return (0x0F)
}
}
Name (_CRS, Buffer (0x15)
{
0x47, 0x01, 0x60, 0x00, 0x60, 0x00, 0x01, 0x01,
0x47, 0x01, 0x64, 0x00, 0x64, 0x00, 0x01, 0x01,
0x22, 0x02, 0x00, 0x79, 0x00
})
}
--
Slawa Olhovchenkov
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
If you want access to fetch early on in this way, you could make a local branch and maintain the change for your own site, or you could boot from a FreeBSD live CD, or use sysinstall from the installation CD to install a package. I don't see fetch as a requirement for diskless clients. Wrong. Not diskless. Simple w/o CD, DVD, FDC. Only HDD. -- Slawa Olhovchenkov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LOR kernel trap
I am build freebsd-current w/ cvs snap on 2003.11.11 and have some problem: 2. kernel trap cpuid = 0 acic id = 00 This has been fixed in later snaps. Thanks, I now try 5.1-CURRENT FreeBSD 5.1-CURRENT #8: Fri Nov 21 23:12:09 MSK 2003. This trap seems fixed. And I now see 'kernel: stray irq7' -- Slawa Olhovchenkov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
LOR kernel trap
I am build freebsd-current w/ cvs snap on 2003.11.11
and have some problem:
1. LOR
lock order reversal
1st 0xc1b05690 rtentry (rtentry) @ /usr/src/sys/net/rtsock.c:388
2nd 0xc15e187c radix node head (radix node head) @ /usr/src/sys/net/route.c:1114
Stack backtrace:
backtrace(c06126bc,c15e187c,c061775a,c061775a,c06177b0) at backtrace+0x17
witness_lock(c15e187c,8,c06177b0,45a,1) at witness_lock+0x672
_mtx_lock_flags(c15e187c,0,c06177b0,45a,c1b05690) at _mtx_lock_flags+0xba
rt_setgate(c1b05600,c1ad6440,c1b05b78,185,0) at rt_setgate+0x3b8
route_output(c0e11500,c16fc550,b0,c0e11500,1f50) at route_output+0x6aa
raw_usend(c16fc550,0,c0e11500,0,0) at raw_usend+0x73
rts_send(c16fc550,0,c0e11500,0,0) at rts_send+0x35
sosend(c16fc550,0,c6a8bc7c,c0e11500,0) at sosend+0x44d
soo_write(c1a01c38,c6a8bc7c,c1b74780,0,c1afd000) at soo_write+0x70
dofilewrite(c1afd000,c1a01c38,8,bfbfe870,b0) at dofilewrite+0xf8
write(c1afd000,c6a8bd10,c062c0e1,3ee,3) at write+0x6e
syscall(2f,2f,2f,8,3) at syscall+0x2c0
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (4), eip = 0x28283c2f, esp = 0xbfbfe65c, ebp = 0xbfbfe688 ---
2. kernel trap
cpuid = 0 acic id = 00
ip 0x8:0xc04955ed
sp 0x10:0xc6a8babc
fp 0x10:0xc6a8bac0
code segment base 0 limit f type 0x1b DPL 0 pres 1 def32 1 gran 1
eflags interrupt enabled IOPL = 0
current process 562 (ppp)
kernel: type 30 trap, code = 0
stopet at critical_exit+0x2d: jmp critical_exit+0x36
gdb -k /.1/obj/usr/src/sys/SLW/kernel.debug
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
(kgdb) l *0xc04955ed
0xc04955ed is in critical_exit (machine/cpufunc.h:358).
353 }
354
355 static __inline void
356 write_eflags(u_int ef)
357 {
358 __asm __volatile(pushl %0; popfl : : r (ef));
359 }
360
361 static __inline void
362 wrmsr(u_int msr, u_int64_t newval)
--
Slawa Olhovchenkov
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
