Re: 8.0 network problem
Hi again,
Disabling pf definitely makes samba file transfers move faster (the
speed varies quite a bit, but everything's faster than the single kilobytes
per second I was seeing previously), but I'm perplexed about what's causing
the slowdown. There's certainly some cruft in my pf.conf (below), but I'm
not sure what might be strangling my LAN. Can anyone set me straight?
/etc/pf.conf:
# macros
int_if = "em0"
wifi_if = "wlan0"
ext_if = "nfe0"
nat_opt = "192.168.0.5" # Windows box
nat_cu = "192.168.0.1" # server
tcp_services = "{ 22 }"
icmp_types = "echoreq"
priv_nets = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }"
# options
set block-policy return
set loginterface $ext_if
set skip on lo
# scrub
scrub in
# nat/rdr
nat on $ext_if from !($ext_if) -> ($ext_if:0)
nat on $ext_if from $wifi_if:network to any -> ($ext_if)
rdr on $ext_if proto tcp from any to any port 22 -> $nat_cu
rdr on $ext_if proto tcp from any to any port 6881:6999 -> $nat_opt
rdr on $ext_if proto tcp from any to any port 34567:34575 -> $nat_cu
rdr on $ext_if proto tcp from any to any port 993 -> $nat_opt
# filter rules
block in log
pass out keep state
antispoof quick for { lo $int_if }
pass in on $ext_if inet proto tcp from any to ($ext_if) port $tcp_services
flags S/SA keep state
block drop in quick on $ext_if from $priv_nets to any
block drop out quick on $ext_if from any to $priv_nets
pass in inet proto icmp all icmp-type $icmp_types keep state
#pass in on $int_if from $int_if:network to any keep state
#pass out on $int_if from any to $int_if:network keep state
#pass in on $wifi_if from $wifi_if:network to any keep state
#pass out on $wifi_if from any to $wifi_if:network keep state
pass in on $ext_if inet proto tcp from any to $nat_cu port $tcp_services
flags S/SA synproxy state
pass in on $ext_if inet proto tcp from any to $nat_cu port 34567:34575 flags
S/SA synproxy state
pass in on $ext_if inet proto tcp from any to $nat_opt port 6881:6999 flags
S/SA synproxy state
pass in on $ext_if inet proto tcp from any to $nat_opt port 993 flags S/SA
synproxy state
pass in quick on $int_if
pass in quick on $wifi_if
Many thanks,
Dave
On Mon, Jul 5, 2010 at 5:49 PM, David Warren wrote:
> Hi all,
>
> As several people have noted, I should have been more specific about
> the problem. As far as I can tell, it's limited to the wired portion of my
> network involving the em0 interface. Samba and scp transfers to and from
> computers on the ral0 interface seem unaffected. Even at the relatively
> slow speeds of wireless, those transfers are substantially faster than the
> degraded speeds I'm seeing on the wired network. I should also have noted
> that the main computer on the wired network is a Windows box, while I use
> the wireless with my MacBook. I'm using pf for my firewall on the FreeBSD
> box, and having tried a bunch of the suggested tests I'm thinking that's the
> most likely culprit. I'm going to try a few things out to test that idea.
> However, for completeness, here's are the results of the various tests and
> diagnostics that were requested.
>
> My pciconf output:
>
> > pciconf -lvc
> n...@pci0:0:20:0: class=0x068000 card=0x816a1043 chip=0x026910de
> rev=0xa3 hdr=0x00
> vendor = 'Nvidia Corp'
> device = 'MCP51 Ethernet Controller (2A34103C)'
> class = bridge
> cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0
> e...@pci0:4:8:0: class=0x02 card=0x13768086 chip=0x107c8086 rev=0x05
> hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)'
> class = network
> subclass = ethernet
> cap 01[dc] = powerspec 2 supports D0 D3 current D0
> cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction
> r...@pci0:4:9:0:class=0x028000 card=0x71281432 chip=0x03011814
> rev=0x00 hdr=0x00
> vendor = 'Ralink Technology, Corp'
> device = 'Edimax 54 MBit WLan 802.11g rt 2500 (b8341462)'
> class = network
> cap 01[40] = powerspec 2 supports D0 D3 current D0
>
>
> dmesg isn't reporting anything new when this happens. Disabling
> rxcsum and txcsum doesn't seem to have an effect. Here's a quick overview
> of what I've tried:
>
> pscp works from .13 to .1 (pscp because I'm using key-based
> identification).
> samba fast then slow from .1 to .13
> samba fast then slow from .13 to .1
> netcat fast then slow from .13 to .1
> netcat not working from .1 to .13 (I need to figure out how to get netcat
> input into the Windows box on .13)
>
> While the problem was evident, I collected the following netstat:
>
> > netstat -i
> NameMtu Network Address Ipkts IerrsOpkts Oerrs
> Coll
> em01500 00:0e:0c:b7:71:44 4840841 0 3791658
> 0 0
> em01500 192.168.0.0 192.168.0.15496050 - 3687095
> - -
> ral0 2290 00:1f:1f:3f:76:f30 0 965271
> 1156
Re: Why is NFSv4 so slow?
On Sun, 27 Jun 2010, Rick C. Petty wrote: First off, many thanks to Rick Macklem for making NFSv4 possible in FreeBSD! I recently updated my NFS server and clients to v4, but have since noticed significant performance penalties. For instance, when I try "ls a b c" (if a, b, and c are empty directories) on the client, it takes up to 1.87 seconds (wall time) whereas before it always finished in under 0.1 seconds. If I repeat the test, it takes the same amount of time in v4 (in v3, wall time was always under 0.01 seconds for subsequent requests, as if the directory listing was cached). If I try to play an h264 video file on the filesystem using mplayer, it often jitters and skipping around in time introduces up to a second or so pause. With NFSv3 it behaved more like the file was on local disk (no noticable pauses or jitters). I just came across a case where things get really slow during testing of some experimental caching stuff. (It was caused by the experimental stuff not in head, but...) It turns out that if numvnodes > desiredvnodes, it sleeps for 1sec before allocating a new vnode. This might explain your approx. 1sec delays. When this happens, "ps axlH" will probably show a process sleeping on "vlruwk" and desiredvnodes can be increased by setting a larger value for kern.maxvnodes. (numvnodes can be seen as vfs.numvnodes) I don't think there is actually a vnode leak, but you might find that the experimental nfs subsystem is a vnode hog. rick ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Odd behavior of labels on different filesystem types
> Sender: "J. Hellenthal" > Date: Sun, 04 Jul 2010 13:58:30 -0400 > From: jhell > > On 07/04/2010 12:15, Kevin Oberman wrote: > >> Sender: "J. Hellenthal" > >> Date: Sun, 04 Jul 2010 01:55:20 -0400 > >> From: jhell > >> > >> On 07/03/2010 16:51, Kevin Oberman wrote: > >>> I have run into an odd behavior in 8-stable that I can't see a reason > >>> for. > >>> > >>> If I have a FAT32 formatted removable drive, I get /dev entries for it > >>> as both /dev/msdosfs/LABEL and /dev/ufsid/ID. When I mount the > >>> filesystem, the /dev/ufsid label is removed, but the other two remain. > >>> > >>> If I have a UFS filesystem on the disk, I have similar devices except > >>> that the LABEL is /dev/ufs/LABEL. But, when the UFS device is mounted, > >>> the /dev/ufsid/ID AND the /dev/ufs/LABEL devs are both deleted. > >>> > >>> I'm not sure which is "right", but I can't see the reason for the > >>> different behavior and it has caused a fair bit of trouble when working > >>> with gnome-mount as I can't unmount a ufs device. When the > >>> /dev/ufs/LABEL device is created again on the umount, gnome-mount sees a > >>> new device and immediately re-mounts it. > >>> > >>> Can this inconsistency be corrected? > >> > >> Can you try to zero out that disk first i.e. > >> dd if=/dev/zero of=/dev/DISK bs=4m > >> > >> Then format your msdos fat part and relabel it. You should not see a > >> dev/ufsid/ label for this anymore. I believe that for some reason the > >> ufsid metadata or whatever you want to call it some how has been left > >> behind and is still being read for whatever reason and can be confirmed > >> by this. > >> > >> As for /dev/ufs/LABEL /dev/ufsid/ID /dev/device when you mount one the > >> others should disapear so this is correct behavior. > > > > Thanks for the suggestion. I will try a device which has never had a UFS > > file system and see if the ufsid device is created. Looks like the > > former is an issue with geom tasting and it would be nice to get it > > fixed, but it is not what is causing my problem. It is the latter issue > > that causes the problems with gnome-mount. > > > > The real issue for me is that /dev/ufs/LABEL is removed on a mount while > > /dev/msdosfs/LABEL remains. hald easily works around ufsid by ignoring > > it, but the /dev/FS/LABEL has to be acted upon differently depending on > > which filesystem is involved. > > Do you use those labels for anything ? if not, I worked around this > while I used gnome for a period with devfs.rules(5) example follows. > > rc.conf(5) add devfs_system_ruleset="your_system" > > [your_system=10] > add path 'ufsid' hide > add path 'msdosfs'hide > add path 'ufs'hide > add path 'iso9660'hide > add path 'reiserfs' hide > add path 'ntfs' hide > add path 'ext2fs' hide > add path 'gpt'hide > > And you can do the same for the actual devices that you use a label for, > so mounting devices like daN can just be done from /dev/label/LABEL. > > add path 'da0'hide # Do this only after it is labeled. > add path 'label/DA0LABEL' mode 0600 user jhell group jhell > > With a little toying of the above you should get the desired effect you > want in gnome. I do find it frustrating having to resort to using only > generic labels for situations like this and believe firmly that the > generic label should take precedence over all labels except gpt & ufsid > and result in the other name-brand labels disappearing not causing this > frustration to happen. Having the multiple layers of labels available > IMO is cause for confusion. > > Final note before I stretch this out like the Armstrong figurine ;), > there was a case where I was using the module instead of having > GEOM_LABEL option built into the kernel, this being loaded after the > machine was already booted caused some strange results with the labels > that I know of on 7.2-STABLE. I don't know if this still exists but the > result from that was multiple labels still being available under /dev > while its counterpart label was mounted. That caused Gnome/hald to get > pretty confused. Thanks. It worked...and it didn't help. Something else in Gnome2.30 is triggering this, I guess. The disk now mounts as /dev/da0s1d, just like it should, but it is still re-mounting as soon as I unmount it. This is a problem for ufs disks, but not for FAT. Since most people are probably using this for mounting thumb drives which are almost always FAT, I guess it has not been seen too much. Guess it's time to take this to the gnome list. Thanks again. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-st
Re: 8.1-PRE Throwing Traps Going Multiuser
On 07/05/10 16:29, Tim Daneliuk wrote: Is this a known problem (I've submitted a PR just in case it is not)? I am seeing this consistently when I try to do a build/installworld/kernel with daily sources from the master tree: http://www.mediafire.com/imageview.php?quickkey=qmhizdtnhyo&thumb=4 The system boots fine single-user. Problem is repeatable with both my kernel AND GENERIC. (My config file at end of this msg.) Attempting to enter multi-user causes the problem. This occurs whether or not anything is enabled in /etc/rc.conf. Falling back to my 6-18-2010 system image makes everything right again. MOBO is an Intel D946GZIS with a single SATA drive and one additional 3Com 3c905 NIC in addition to the onboard Intel NIC. My Kernel Config = include GENERIC ident MACHINENAME options IPFIREWALL options IPDIVERT options VESA # System console options options SC_DISABLE_REBOOT # disable reboot key sequence options SC_HISTORY_SIZE=200 # number of history buffer lines options SC_PIXEL_MODE # add support for the raster text mode # The following options will change the default colors of syscons. options SC_NORM_ATTR="(FG_GREEN|BG_BLACK)" options SC_NORM_REV_ATTR="(FG_YELLOW|BG_GREEN)" options SC_KERNEL_CONS_ATTR="(FG_RED|BG_BLACK)" options SC_KERNEL_CONS_REV_ATTR="(FG_BLACK|BG_RED)" By chance do you have any modules being loaded in /boot/loader.conf. I had similar issues and it was VirtualBox needing to be recompiled. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Panic in destroy_dev_sched_cb() for tty
* Jeremie Le Hen wrote: > I've got a panic obviously from the tty layer but I couldn't get the > panic string as no remote system was connected using serial console, and > I don't know how to print it from DDB. Hmmm... This is a tricky one, but I think I do understand what's going on here. If you close and revoke a TTY at the very exact moment, it may call destroy_dev_sched_cb() twice, where the second time it gets called on a null pointer. === --- sys/kern/tty.c (revision 209570) +++ sys/kern/tty.c (working copy) @@ -1040,7 +1040,8 @@ tp->t_dev = NULL; tty_unlock(tp); - destroy_dev_sched_cb(dev, tty_dealloc, tp); + if (dev != NULL) + destroy_dev_sched_cb(dev, tty_dealloc, tp); } void I guess it's very hard to reproduce, right? If so, I'll just commit it to SVN. Thanks for reporting! -- Ed Schouten WWW: http://80386.nl/ pgpVPlQxKBSgQ.pgp Description: PGP signature
Re: 8.0 network problem
Hi all, As several people have noted, I should have been more specific about the problem. As far as I can tell, it's limited to the wired portion of my network involving the em0 interface. Samba and scp transfers to and from computers on the ral0 interface seem unaffected. Even at the relatively slow speeds of wireless, those transfers are substantially faster than the degraded speeds I'm seeing on the wired network. I should also have noted that the main computer on the wired network is a Windows box, while I use the wireless with my MacBook. I'm using pf for my firewall on the FreeBSD box, and having tried a bunch of the suggested tests I'm thinking that's the most likely culprit. I'm going to try a few things out to test that idea. However, for completeness, here's are the results of the various tests and diagnostics that were requested. My pciconf output: > pciconf -lvc n...@pci0:0:20:0: class=0x068000 card=0x816a1043 chip=0x026910de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP51 Ethernet Controller (2A34103C)' class = bridge cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 e...@pci0:4:8:0: class=0x02 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' class = network subclass = ethernet cap 01[dc] = powerspec 2 supports D0 D3 current D0 cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction r...@pci0:4:9:0:class=0x028000 card=0x71281432 chip=0x03011814 rev=0x00 hdr=0x00 vendor = 'Ralink Technology, Corp' device = 'Edimax 54 MBit WLan 802.11g rt 2500 (b8341462)' class = network cap 01[40] = powerspec 2 supports D0 D3 current D0 dmesg isn't reporting anything new when this happens. Disabling rxcsum and txcsum doesn't seem to have an effect. Here's a quick overview of what I've tried: pscp works from .13 to .1 (pscp because I'm using key-based identification). samba fast then slow from .1 to .13 samba fast then slow from .13 to .1 netcat fast then slow from .13 to .1 netcat not working from .1 to .13 (I need to figure out how to get netcat input into the Windows box on .13) While the problem was evident, I collected the following netstat: > netstat -i NameMtu Network Address Ipkts IerrsOpkts Oerrs Coll em01500 00:0e:0c:b7:71:44 4840841 0 3791658 0 0 em01500 192.168.0.0 192.168.0.15496050 - 3687095 - - ral0 2290 00:1f:1f:3f:76:f30 0 965271 1156 0 nfe0 1500 00:01:29:d4:2d:6b 349488 083833 0 0 nfe0 1500 173.19.224.0/ 173-19-224-254.cl 3260 - 7725 - - plip0 15000 00 0 0 lo0 16384 758 0 758 0 0 lo0 16384 fe80:5::1 fe80:5::10 -0 - - lo0 16384 localhost ::1 0 -0 - - lo0 16384 your-net localhost 74 - 758 - - wlan0 1500 00:1f:1f:3f:76:f3 87355264 950672 7 0 wlan0 1500 192.168.1.0 192.168.1.1 142745 - 937938 - - pflog 331520 0 242 0 0 which appears to be free of errors for em0. I also got the following vmstat -i: > vmstat -i interrupt total rate irq1: atkbd0 8 0 irq6: fdc0 7 0 irq15: ata1 144 0 irq16: em0 2456436 52 irq17: ral0 3782116 80 irq20: atapci2217325 4 irq21: hdac0 ohci011 0 irq22: nfe0 ehci0 436597 9 irq23: atapci1206722 4 cpu0: timer 94022466 2000 cpu1: timer 94022098 2000 Total 195143930 4151 And the following netstat: > sudo netstat -I em0 -indb NameMtu Network Address Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll Drop em01500 00:0e:0c:b7:71:44 5023101 0 3770654334 3978181 0 925661555 00 em01500 192.168.0.0/2 192.168.0.15677843 - 4600314279 3873061 - 739695560 -- After starting a netcat transfer from .13 to .1, .13's system monitor indicates that transfer over the local (outbound) interface starts out very fast for a few seconds and then bottoms out. This iostat captures the same pattern. ad4, ad6, ad8, and ad10 are the four disks sharing the base system (geom mirror) and ZFS bulk filesystem. > iostat -n 5 -w 1 -c 30 tty ad4 ad6 ad8 ad10 da0 cpu tin tou
Re: 8.1-PRE Throwing Traps Going Multiuser
On Mon, Jul 05, 2010 at 03:29:29PM -0500, Tim Daneliuk wrote: > Is this a known problem (I've submitted a PR just in case it is not)? > > I am seeing this consistently when I try to do a build/installworld/kernel > with daily sources from the master tree: > > http://www.mediafire.com/imageview.php?quickkey=qmhizdtnhyo&thumb=4 > > The system boots fine single-user. Problem is repeatable with both > my kernel AND GENERIC. (My config file at end of this msg.) > > Attempting to enter multi-user causes the problem. This > occurs whether or not anything is enabled in /etc/rc.conf. > > Falling back to my 6-18-2010 system image makes everything right again. > > MOBO is an Intel D946GZIS with a single SATA drive and one additional > 3Com 3c905 NIC in addition to the onboard Intel NIC. > > > My Kernel Config > = > > include GENERIC > > ident MACHINENAME > > options IPFIREWALL > options IPDIVERT > > options VESA > > # System console options > > options SC_DISABLE_REBOOT # disable reboot key sequence > options SC_HISTORY_SIZE=200 # number of history buffer lines > options SC_PIXEL_MODE # add support for the raster text mode > > # The following options will change the default colors of syscons. > > options SC_NORM_ATTR="(FG_GREEN|BG_BLACK)" > options SC_NORM_REV_ATTR="(FG_YELLOW|BG_GREEN)" > options SC_KERNEL_CONS_ATTR="(FG_RED|BG_BLACK)" > options SC_KERNEL_CONS_REV_ATTR="(FG_BLACK|BG_RED)" Add DDB to your kernel, or specify the dump device. Then obtain a backtrace for the trap. pgpLdZl6vtWEJ.pgp Description: PGP signature
8.1-PRE Throwing Traps Going Multiuser
Is this a known problem (I've submitted a PR just in case it is not)? I am seeing this consistently when I try to do a build/installworld/kernel with daily sources from the master tree: http://www.mediafire.com/imageview.php?quickkey=qmhizdtnhyo&thumb=4 The system boots fine single-user. Problem is repeatable with both my kernel AND GENERIC. (My config file at end of this msg.) Attempting to enter multi-user causes the problem. This occurs whether or not anything is enabled in /etc/rc.conf. Falling back to my 6-18-2010 system image makes everything right again. MOBO is an Intel D946GZIS with a single SATA drive and one additional 3Com 3c905 NIC in addition to the onboard Intel NIC. My Kernel Config = include GENERIC ident MACHINENAME options IPFIREWALL options IPDIVERT options VESA # System console options options SC_DISABLE_REBOOT # disable reboot key sequence options SC_HISTORY_SIZE=200 # number of history buffer lines options SC_PIXEL_MODE # add support for the raster text mode # The following options will change the default colors of syscons. options SC_NORM_ATTR="(FG_GREEN|BG_BLACK)" options SC_NORM_REV_ATTR="(FG_YELLOW|BG_GREEN)" options SC_KERNEL_CONS_ATTR="(FG_RED|BG_BLACK)" options SC_KERNEL_CONS_REV_ATTR="(FG_BLACK|BG_RED)" -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Panic in destroy_dev_sched_cb() for tty
Hi Ed, I've got a panic obviously from the tty layer but I couldn't get the panic string as no remote system was connected using serial console, and I don't know how to print it from DDB. However here is the relevant stuff I could get: db> show pcpu cpuid= 0 dynamic pcpu= 0x5a0600 curthread= 0x87cae240: pid 7701 "screen" curpcb = 0xcb1ebd90 fpcurthread = none idlethread = 0x85544900: pid 11 "idle: cpu0" APIC ID = 0 currentldt = 0x50 db> trace Tracing pid 7701 tid 100302 td 0x87cae240 destroy_dev_sched_cb(0,807137fb,9eff1200,9eff1254) at destroy_dev_sched_cb+0x10 tty_rel_free(9eff1290,0,1,0) at tty_rel_free+0xc7 ttydev_leave(9eff1290,0,0,0,0,...) at ttydev_leave+0x136 ttydev_close(9c756d00,7,2000,87cae240,cb1ebb14,...) at ttydev_close+0xf4 devfs_close(cb1ebb2c,cb1ebb50,80760b10,80a48120,cb1ebb2c,...) at devfs_close+0x3ae VOP_CLOSE_APV(80a48120,cb1ebb2c,809d7133,128,80a84000,...) at VOP_CLOSE_APV+0x44 vn_close(87cee648,7,8a965780,87cae240,80a84300,...) at vn_close+0xd1 vn_closefile(8788f658,87cae240,8788f658,0,cb1ebbe0,...) at vn_closefile+0xfe devfs_close_f(8788f658,87cae240,cb1ebc18,0,1,...) at devfs_close_f+0x27 _fdrop(8788f658,87cae240,8a965780,87cae240,865b7310,...) at _fdrop+0x43 closef(8788f658,87cae240,900fed48,2,876511d0,...) at closef+0x31b kern_close(87cae240,4,cb1ebd2c,8096147c,87cae240,...) at kern_close+0x16d close(87cae240,cb1ebcf8,4,c,c,...) at close+0x1a syscall(cb1ebd38) at syscall+0x320 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (6, FreeBSD ELF32, close), eip = 0x2821b63f, esp = 0x7fbfe1bc, ebp = 0x7fbfe1c8 --- The system is running 8.0-STABLE from around 2009/12/06. Thanks. Regards, -- Jeremie Le Hen Humans are born free and equal. But some are more equal than others. Coluche ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.0 network problem
On 7/4/2010 8:52 PM, David Warren wrote: Hi all, I've got a persistent problem with my LAN. I'm running a FreeBSD 8.0 box as a home server performing the following functions for wired and wireless networks: router; firewall; DHCP server; and file server. For what it's worth, I've got ZFS up and running as the main filesystem. The recurring issue is that file transfers from the FreeBSD box to computers on the wired network (gigabit) start out fast and then become agonizingly slow. I'm sharing home directories over Samba, and those transfers work briefly and then tail off to a few kilobytes per second. The failure is I remember having a simmilar issue, back in the early 7.x days. Try the following tunnables. net.inet.tcp.hostcache.expire=1 net.inet.tcp.inflight.enable=0 Thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
