Oh, well, I thought you said "10mb/s", not "10MB/s" .. that makes it a bit different. I wonder if it could still be a tcp window size or something.. Try these sysctl's on C: vfs.nfs.gatherdelay=0 vfs.nfs.async=1 vfs.vmiodirenable=1 kern.ipc.maxsockbuf=2097152 kern.ipc.somaxconn=8192 kern.ipc.maxsockets=16424 kern.maxfiles=65536 kern.maxfilesperproc=32768 net.inet.tcp.rfc1323=1 net.inet.tcp.delayed_ack=0 net.inet.tcp.sendspace=65535 net.inet.tcp.recvspace=65535 net.inet.udp.recvspace=65535 net.inet.udp.maxdgram=57344 net.local.stream.recvspace=65535 net.local.stream.sendspace=65535
Just a try.. Danny Braniss wrote: > > > And what happens when you go from A or B to C? Have you been running a top or >systat -vmstat while this is happening? > > I'm thinking it might be a purely IO thing, on the proc box. I have seen similar >slowness with the default FreeBSD > > install on single proc boxes, but a few sysctl's seem to do the trick. > > a reminder: > A -> NetAPP > B -> NetAPP > C -> NetAPP > is fine, im running the same test, and the results are consitant, ~10MGBs > > so that should eliminate network/switch/port/cable problems, right? > > btw, no network errors are reported, neither from the hosts nor the switches. > > danny > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message -- ------------------------------------------------------------- Eric Anderson [EMAIL PROTECTED] Centaur Technology # rm -rf /bin/laden ------------------------------------------------------------- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
