getnetbyname broken for DNS case?

2002-09-18 Thread Jim Pirzyk

Hi,

I am trying to debug a problem that I have with /etc/exports.  I cannot
put in the symbolic name for my network (10.26.0.0) without putting it
in /etc/networks.  It is currently in DNS, but it looks like the getnetbyname
is not working correctly for the DNS case.  

The functions that are broken is _getnetbydnsname() and getnetanswer().
The _getnetbydnsname() is easily fixed by changing T_PTR to T_A
in res_query(), but getnetanswer() is harder to solve.  It is not parsing the
format of the result correctly.  First I had to put some code in to
test "type" being T_PTR only if "net_i" is set to BYADDR and T_A if "net_i"
is set to BYNAME.  

When I go into the res_hnok() test, it is assumed by the code that
it IP address is in ascii format, which it is not (it is in network binary 
order).  If I remove the res_hnok() test, then it does not load the 
netent.n_net address correctly.

The code is broken for both -CURRENT and -STABLE.

So my question is then, can I rewrite getnetbyname() to use gethostbyname() 
call and massage the result to a netent entry?  This would  solve the DNS 
result parsing problem and would also get us T_AAA (IPv6) network name 
addresses.  I would also implement getnetbyaddr() in terms of gethostbyaddr() 
too.

- JimP

--- @(#) $Id: dot.signature,v 1.10 2001/05/17 23:38:49 Jim.Pirzyk Exp $
__o   [EMAIL PROTECTED] ---
 _'\<,_
(*)/ (*)  


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message



Re: SMP strange behaviour [HELP]

2002-09-18 Thread Christophe Prevotaux

I tries it , but it does not solve the problem however
when doing this I noticed the lge0 interface goes down
because when I do an ifconfig lge0 up I can log in again 
on the lge0 interface.

Any other ideas ? 



On Tue, 17 Sep 2002 13:13:48 -0400
Barney Wolff <[EMAIL PROTECTED]> wrote:

> Do (as root)
> sysctl net.inet.tcp.path_mtu_discovery=0
> on the side sending the big data and see if the problem goes away.
> tcpdump -v should show the DF flag set if pmtud is in use.
> 
> On Tue, Sep 17, 2002 at 06:29:21PM +0200, Christophe Prevotaux wrote:
> > uhmm how can i find out about this ? 
> > When I do a tcpdump I see nothing related to this
> > 
> > I will use ethereal to look at it and I'll let you know
> 
> -- 
> Barney Wolff
> I'm available by contract or FT:  http://www.databus.com/bwresume.pdf
> 


--
--
===
Christophe Prevotaux  Email: [EMAIL PROTECTED]
HEXANET SARLURL: http://www.hexanet.fr/
Z.A.C Les CharmillesTel: +33 (0)3 26 79 30 05 
3 Allée Thierry Sabine   Direct: +33 (0)3 26 61 77 72 
BP202   Fax: +33 (0)3 26 79 30 06
51686 Reims Cedex 2
FRANCE   HEXANET Network Operation Center 
===

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message



socket buffers

2002-09-18 Thread Petri Helenius


I played around adjusting udp socket buffers for a while and noticed
that if the input buffer is set to a value, packets start getting dropped
when npkt*MTU > SO_RCVBUF so if a socket receives 100 byte packets over
an ethernet interface of 1500 byte MTU and receive buffer of 100k the packets
start dropping at less than 10k received data in a buffer.

Is this a feature or a bug? I'm running RELENG_4 from a few weeks ago.

Pete

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message



Re: socket buffers

2002-09-18 Thread Justin C. Walker


On Wednesday, September 18, 2002, at 08:03 AM, Petri Helenius wrote:

>
> I played around adjusting udp socket buffers for a while and noticed
> that if the input buffer is set to a value, packets start getting 
> dropped
> when npkt*MTU > SO_RCVBUF so if a socket receives 100 byte packets over
> an ethernet interface of 1500 byte MTU and receive buffer of 100k the 
> packets
> start dropping at less than 10k received data in a buffer.

This is, I think, normal behavior.  Check Wright/Stevens (TCP/IP 
Illustrated, V2), Ch. 2, where this is discussed (as I recall).  A 
socket buffer counts not only the valid data bytes enqueued, but also 
the size of the mbufs used.  The reasoning is clear: in order to avoid 
having all the mbufs in the system end up on a single queue, because 
very small packets are being received, counting mbuf space limits the 
number of mbufs that can be sucked up by one direction for one socket.

Regards,

Justin

--
Justin C. Walker, Curmudgeon-At-Large  *
Institute for General Semantics| It's not whether you win or 
lose...
|  It's whether *I* win or lose.
*--*---*


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message



MPD as a PPTP server

2002-09-18 Thread Elliott Perrin

I am not currently on freebsd-net so if you could cc me in replies it would be 
appreciated.

I have a FreeBSD 4.6.2-RELEASE running mpd 3.9 serving as a PPTP server.

I have setup PPTP boxes using MPD before but have run into a problem this time. In 
the past I would use

set ipcp ranges 1.2.3.4/32 192.168.1.100/32

where 1.2.3.4 was the external interface of the machine. This worked with multiple 
links under 3.7, but doesn't seem to under 3.9

Do I have to set a different address for every client connection in tehe first part 
of the ipcp ranges like this?

set ipcp ranges 192.168.1.1/32 192.168.1.100/32
set ipcp ranges 192.168.1.2/32 192.168.1.101/32

and if so, do the first addresses have to corespond to an existing interface 
requiring me to alias the interface with more than 1 IP.

TIA
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message



More on MPD PPTP problem

2002-09-18 Thread Elliott Perrin

Please cc me on responses

sorry fo rthe second post, I realised afterwards I should be posting logs and configs 
if i am going to ask people for help with the problem.

It seems as though I can only setup mpd to listen for one inbound connection. No ng 
interfaces are present prior to initializing mpd, which I make sure of using ngctl 
when the links are not shutdown after killing mpd.

In the mpd.conf file I have posted below, I have used both the 172.22.4.1/32 address 
listed and 1.2.3.4/32 as the first number in the ipcp ranges statement. I get the 
same result each time. 172.22.4.1/32 is an actual interface on the machine.

Here is a snip from my log file to show the problem I am having

Sep 18 14:21:34 gw mpd: mpd: pid 37673, version 3.9 (root@localhost 18:08 12-Sep-2002)
Sep 18 14:21:34 gw mpd: [moveable1] ppp node is "mpd37673-moveab"
Sep 18 14:21:34 gw mpd: mpd: local IP address for PPTP is 1.2.3.4
Sep 18 14:21:34 gw mpd: [moveable1] using interface ng0
Sep 18 14:21:34 gw mpd: [moveable2] can't name ppp node: Address already in use
Sep 18 14:21:34 gw mpd: [moveable2] netgraph initialization failed
Sep 18 14:21:34 gw mpd: [moveable3] can't name ppp node: Address already in use
Sep 18 14:21:34 gw mpd: [moveable3] netgraph initialization failed
Sep 18 14:21:34 gw mpd: [moveable4] can't name ppp node: Address already in use
Sep 18 14:21:34 gw mpd: [moveable4] netgraph initialization failed
Sep 18 14:21:34 gw mpd: [moveable5] can't name ppp node: Address already in use
Sep 18 14:21:34 gw mpd: [moveable5] netgraph initialization failed

My mpd.links file

moveable1:
 set link type pptp
 set pptp self 1.2.3.4
 set pptp enable incoming
 set pptp disable originate

moveable2:
 set link type pptp
 set pptp self 1.2.3.4
 set pptp enable incoming
 set pptp disable originate

moveable3:
 set link type pptp
 set pptp self 1.2.3.4
 set pptp enable incoming
 set pptp disable originate

moveable4:
 set link type pptp
 set pptp self 1.2.3.4
 set pptp enable incoming
 set pptp disable originate

moveable5:
 set link type pptp
 set pptp self 1.2.3.4
 set pptp enable incoming
 set pptp disable originatedefault:

and my mpd.conf file

default:
 load moveable1
 load moveable2
 load moveable3
 load moveable4
 load moveable5

moveable1:
 new -i ng0 moveable1 moveable1
 set ipcp ranges 172.22.4.1/32 172.22.4.105/32
 load client_standard

moveable2:
 new -i ng1 moveable2 moveable2
 set ipcp ranges 172.22.4.1/32 172.22.4.106/32
 load client_standard

moveable3:
 new -i ng2 moveable3 moveable3
 set ipcp ranges 172.22.4.1/32 172.22.4.107/32
 load client_standard

moveable4:
 new -i ng3 moveable4 moveable4
 set ipcp ranges 172.22.4.1/32 172.22.4.108/32
 load client_standard

moveable5:
 new -i ng4 moveable5 moveable5
 set ipcp ranges 172.22.4.1/32 172.22.4.109/32
 load client_standard

client_standard:
 set iface disable on-demand
 set iface enable proxy-arp
 set iface route 172.22.16.0/23
 set iface idle 1800
 set bundle enable multilink
 set link yes acfcomp protocomp
 set link no pap chap
 set link enable chap
 set link mtu 1460
 set link keep-alive 10 60
 set ipcp yes vjcomp
 set ipcp dns 172.22.4.51
 set bundle enable compression
 set ccp yes mppc
 set bundle enable crypt-reqd
 set ccp yes mpp-e128
 set ccp yes mpp-stateless


Any hints?

Cheers,
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message



Broken IPv4 in IPv6 on -current?

2002-09-18 Thread Trish Lynch

FreeBSD femme.sapphite.org 5.0-CURRENT FreeBSD 5.0-CURRENT #16: Mon Sep  9
10:23:22 EDT 2002
[EMAIL PROTECTED]:/admins/obj/admins/src/sys/FEMME  i386

foo.c:

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

int
main(int argc, char *argv[])
{
  struct sockaddr_in6 addr;
  struct hostent *hostinfo;
  int sock;

  memset(&addr, 0, sizeof(struct sockaddr_in6));

  addr.sin6_addr = in6addr_any;
  addr.sin6_family = AF_INET6;

  if(argc < 2)
return 0;

  hostinfo = gethostbyname2(argv[1], AF_INET6);
  memcpy((char *)&addr.sin6_addr, hostinfo->h_addr, hostinfo->h_length);
  addr.sin6_family = hostinfo->h_addrtype;

  addr.sin6_port = htons((u_short));

  sock = socket(AF_INET6, SOCK_STREAM, 0);
  bind(sock, (struct sockaddr *)&addr, sizeof(struct sockaddr_in6));
  listen(sock, 5);

  sleep(60);

  return 0;
}

femme:~#strace ./foo :::127.0.0.1

execve(0xbfbff5c0, [0xbfbffaa4], [/* 0 vars */]) = 0
mmap(0, 2664, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0) = 0x2805f000
munmap(0x2805f000, 2664)= 0
__sysctl([...], 0x2805e4c8, 0xbfbff864, NULL, 0) = 0
mmap(0, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0) =
0x2805f000
geteuid(0)  = 0
getuid()= 0 (euid 0)
getegid(0)  = 0
getgid()= 0 (egid 0)
open("/var/run/ld-elf.so.hints", O_RDONLY) = 3
read(3, "ins/src/libexec/rtld-elf/rtld.c:"..., 128) = 128
lseek(3, 549755813888, SEEK_SET)= 128
read(3, "/usr/lib:/usr/lib/compat:/usr/X1"..., 145) = 145
close(3)= 0
access("/usr/lib/libc.so.5", F_OK)  = 0
open("/usr/lib/libc.so.5", O_RDONLY)= 3
fstat(3, {st_mode=0, st_size=0, ...})   = 0
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096)
= 4096
mmap(0, 741376, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x28067000
mmap(0x28103000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x9b000) = 0x28103000
mmap(0x28108000, 81920, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANON, -1, 0) = 0x28108000
close(3)= 0
mmap(0, 184, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0) = 0x2811c000
munmap(0x2811c000, 184) = 0
mprotect(0x28067000, 638976, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
mmap(0, 18856, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0) = 0x2811c000
munmap(0x2811c000, 18856)   = 0
mprotect(0x28067000, 638976, PROT_READ|PROT_EXEC) = 0
sigaction(SIGILL, {SIG_DFL}, {SIG_DFL}) = 0
sigprocmask(SIG_BLOCK, NULL, [])= 0
sigaction(SIGILL, {SIG_DFL}, NULL)  = 0
sigprocmask(SIG_BLOCK, ~[ILL TRAP ABRT EMT FPE BUS SEGV SYS], []) = 0
sigprocmask(SIG_SETMASK, [], NULL)  = 0
stat("/etc/nsswitch.conf", {st_mode=S_IFBLK|S_ISGID|0554,
st_rdev=makedev(40, 2037645344), ...}) = 0
open("/etc/nsswitch.conf", O_RDONLY)= 3
readlink("/etc/malloc.conf", 0xbfbff830, 63) = -1 ENOENT (No such file or
directory)
mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0) =
0x2811c000
break(0x804b000)= 0
break(0x804c000)= 0
break(0x804d000)= 0
break(0x804e000)= 0
break(0x804f000)= 0
ioctl(3, TIOCGETA, 0xbfbff800)  = -1 ENOTTY (Inappropriate ioctl
for device)
fstat(3, {st_mode=0177350, st_size=18446461400436899560, ...}) = 0
break(0x8051000)= 0
read(3, "hosts: files dns \n", 8192)= 18
read(3, "", 8192)   = 0
break(0x8052000)= 0
break(0x8053000)= 0
ioctl(3, TIOCGETA, 0xbfbff7f0)  = -1 ENOTTY (Inappropriate ioctl
for device)
close(3)= 0
open("/etc/hosts", O_RDONLY)= 3
gettimeofday({1869638985, 1651078003}, NULL) = 0
getpid()= 97560 (ppid 97559)
issetugid(0x7ae)= 0
open("/etc/resolv.conf", O_RDONLY)  = 4
fstat(4, {st_mode=S_IFBLK|S_ISGID|0566, st_rdev=makedev(114, 543490165),
...}) = 0
read(4, "search sapphite.org\nnameserver 6"..., 8192) = 86
read(4, "", 8192)   = 0
close(4)= 0
issetugid(0x7ae)= 0
fstat(3, {st_mode=0150320, st_size=15046755950319947984, ...}) = 0
read(3, "# $FreeBSD: src/etc/hosts,v 1.11"..., 8192) = 1360
read(3, "", 8192)   = 0
close(3)= 0
socket(PF_INET6, SOCK_STREAM, 0)= 3
bind(3, {sin_family=0xd0 /* AF_??? */, {sa_family=208,
sa_data="\320\320\320\320\320\320\320\320\320\320\320\320\320\320"...},
28) = -1 EADDRNOTAVAIL (Can't assign requested address)
listen(3, 5)= 0
nanosleep(0xbfbff9f8, 0xbfbff9f0^C 



its pretty bizarre




--
Trish Lynch[EMAIL PROTECTED]
Ecartis Core Team [EMAIL PROTECTED]
Key f

Broken IPv4 in IPv6 on -current (addendum)

2002-09-18 Thread Trish Lynch

THis works fine on DP-1.

So it broke somewhere between then and now.

-Trish

--
Trish Lynch[EMAIL PROTECTED]
Ecartis Core Team [EMAIL PROTECTED]
Key fingerprint = C44E 8E63 6E3C 18BD 608F  E004 9DC7 C2E9 0E24 DFBD



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message



ipv4 in ipv6 issue solved

2002-09-18 Thread Trish Lynch

sysctl net.inet6.ip6.v6only=0

-Trish

--
Trish Lynch[EMAIL PROTECTED]
Ecartis Core Team [EMAIL PROTECTED]
Key fingerprint = C44E 8E63 6E3C 18BD 608F  E004 9DC7 C2E9 0E24 DFBD



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message



Re: ipv4 in ipv6 issue solved

2002-09-18 Thread JINMEI Tatuya / $B?@L@C#:H(B

> On Wed, 18 Sep 2002 21:44:33 -0400 (EDT), 
> Trish Lynch <[EMAIL PROTECTED]> said:

> sysctl net.inet6.ip6.v6only=0

This should also work:

*** foo.c.orig  Thu Sep 19 12:05:04 2002
--- foo.c   Thu Sep 19 12:05:56 2002
***
*** 14,19 
--- 14,20 
struct sockaddr_in6 addr;
struct hostent *hostinfo;
int sock;
+   int off;
  
memset(&addr, 0, sizeof(struct sockaddr_in6));
  
***
*** 30,35 
--- 31,40 
addr.sin6_port = htons((u_short));
  
sock = socket(AF_INET6, SOCK_STREAM, 0);
+ #ifdef IPV6_V6ONLY
+   off = 0;
+   setsockopt(sock, IPPROTO_IPV6, &off, sizeof(off));
+ #endif
bind(sock, (struct sockaddr *)&addr, sizeof(struct sockaddr_in6));
listen(sock, 5);
  
I'd recommend this approach rather than to use sysctl, particularly
for new applications built from the scratch, because we can control
the policy per-socket basis.

You may have to note that draft-ietf-ipngwg-rfc2553bis-06.txt
specifies 0 as the default value of the option while FreeBSD does not
follow the specification.  Even though the clear specification, there
is a certain amount of stack developers who have a different opinion
on this and intentionally reverse the default.  So, the safest way is
to set the value explicitly.

JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message



Re: Network Transfer Speed Issues - Tweaks/Advice?

2002-09-18 Thread Steve Fettig

I really appreciate everyone who offered up a few ideas and answers.  
One of the first things I finally figured out was that the adapter was 
failing... hmmm doesn't make sense - it didn't fail completely, but I 
swapped it out with a different adapter (same thing 2940UW) and the 
performance change was quite remarkable.  That still didn't solve the 
huge discrepancy in speed difference between my other SCSI (internal) 
drives and the ones I am working with, however.  My next test will be to 
build a system from the ground up w/ a 500 MHz processor and a 133 MHz 
FSB.  I am also wondering if I really missed the boat on the drives, 
too.  They are "older" 5400 RPM SCSI drives (HUGE drives physically) but 
I don't see how they would be any slower than an IDE 5400 RPM drive - 
which they are and quite a bit so.
As for all of the other stuff, the CPU load is usually at a steady 15% 
(nfsd).  Since that is the only service running (besides the required 
daemons on a somewhat vanilla system) and the only load that the 
"server" is under, I don't think that is an issue.  I am going to test 
system performance with the suggested programs (that was another thing I 
was looking for in the answer, although I guess I didn't say it...) and 
see what happens.  I am starting to think that this is a combination of 
controller and system not having the performance I was expecting.  
Everything on the net end seems to be functioning without problem - no 
lost packets, broken communication, etc.

Well, the testing goes on.  Please continue to comment if you have any 
ideas (especially with regards to kernel tweaks, etc).

Thanks,
Steve

On Tuesday, September 17, 2002, at 07:55 , David Burns wrote:

> Steve Fettig wrote:
>> I recently set up an NFS server to run daily backups on.  The server 
>> was built using an old P150 w/ 90 MB of ram and a 6GB hard drive.  
>> (All servers in this experiment are set up using FBSD 4.6.2 and the 
>> client is a Mac PowerBook G4 running Mac OS X.)  Attached to it is an 
>> external SCSI hard drive enclosure with 4 47GB SCSI drives running off 
>> an AHA-2490UW SCSI adapter.  I am getting really odd performance when 
>> doing an NFS transfer (I also get odd performance out of scp) from the 
>> machine I am trying to back up.  I will get a burst of 20Mbps for 
>> about 30 seconds, then it will ramp down to 1 Mbps for about 2 
>> minutes, ramp backup to 20 Mbps, then back down to 1 Mbps and so on.
> You need to break the problem down ... Is the system CPU and/or IO 
> bound during the backup? Also try some quick benchmarks to verify basic 
> system performance levels: Network IO - use ttcp (or netperf etc), and 
> Disk IO - use bonnie (or similar).
>
> NB Of course you can't simply take such benchmarks results and put them 
> together - but you will gain a better understanding of where the 
> potential slowdowns may be.
>
> Lastly, performance issues on older Pentiums can also result from poor 
> memory bandwidth and/or PCI chipset problems. I recently replaced a 
> P120 with a Celeron 333 - the performance improvement was surprising.
>
> Regards,
> David
>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message



Re: Network Transfer Speed Issues - Tweaks/Advice?

2002-09-18 Thread Lars Eggert

Steve,

your setup is way to complex. As David suggested, first try to establish 
whether the network connection between the two machines is the problem 
or not. Forget about NFS for now, just benchmark TCP and UDP (which do 
you NFS mount over, by the way?) If network performance is erratic, 
isolate the setup from cross traffic, and swap out NICs, hubs and or 
switches.

Only after you've ruled out the network would I start worrying about 
disks, controllers and NFS settings.

The idea here is to change ONE parameter in the setup at a time, and 
rerun your benchmark of choice.

Steve Fettig wrote:
> I really appreciate everyone who offered up a few ideas and answers.  
> One of the first things I finally figured out was that the adapter was 
> failing... hmmm doesn't make sense - it didn't fail completely, but I 
> swapped it out with a different adapter (same thing 2940UW) and the 
> performance change was quite remarkable.  That still didn't solve the 
> huge discrepancy in speed difference between my other SCSI (internal) 
> drives and the ones I am working with, however.  My next test will be to 
> build a system from the ground up w/ a 500 MHz processor and a 133 MHz 
> FSB.  I am also wondering if I really missed the boat on the drives, 
> too.  They are "older" 5400 RPM SCSI drives (HUGE drives physically) but 
> I don't see how they would be any slower than an IDE 5400 RPM drive - 
> which they are and quite a bit so.
> As for all of the other stuff, the CPU load is usually at a steady 15% 
> (nfsd).  Since that is the only service running (besides the required 
> daemons on a somewhat vanilla system) and the only load that the 
> "server" is under, I don't think that is an issue.  I am going to test 
> system performance with the suggested programs (that was another thing I 
> was looking for in the answer, although I guess I didn't say it...) and 
> see what happens.  I am starting to think that this is a combination of 
> controller and system not having the performance I was expecting.  
> Everything on the net end seems to be functioning without problem - no 
> lost packets, broken communication, etc.
> 
> Well, the testing goes on.  Please continue to comment if you have any 
> ideas (especially with regards to kernel tweaks, etc).
> 
> Thanks,
> Steve
> 
> On Tuesday, September 17, 2002, at 07:55 , David Burns wrote:
> 
>> Steve Fettig wrote:
>>
>>> I recently set up an NFS server to run daily backups on.  The server 
>>> was built using an old P150 w/ 90 MB of ram and a 6GB hard drive.  
>>> (All servers in this experiment are set up using FBSD 4.6.2 and the 
>>> client is a Mac PowerBook G4 running Mac OS X.)  Attached to it is an 
>>> external SCSI hard drive enclosure with 4 47GB SCSI drives running 
>>> off an AHA-2490UW SCSI adapter.  I am getting really odd performance 
>>> when doing an NFS transfer (I also get odd performance out of scp) 
>>> from the machine I am trying to back up.  I will get a burst of 
>>> 20Mbps for about 30 seconds, then it will ramp down to 1 Mbps for 
>>> about 2 minutes, ramp backup to 20 Mbps, then back down to 1 Mbps and 
>>> so on.
>>
>> You need to break the problem down ... Is the system CPU and/or IO 
>> bound during the backup? Also try some quick benchmarks to verify 
>> basic system performance levels: Network IO - use ttcp (or netperf 
>> etc), and Disk IO - use bonnie (or similar).
>>
>> NB Of course you can't simply take such benchmarks results and put 
>> them together - but you will gain a better understanding of where the 
>> potential slowdowns may be.
>>
>> Lastly, performance issues on older Pentiums can also result from poor 
>> memory bandwidth and/or PCI chipset problems. I recently replaced a 
>> P120 with a Celeron 333 - the performance improvement was surprising.
>>
>> Regards,
>> David
>>
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message


-- 
Lars Eggert <[EMAIL PROTECTED]>   USC Information Sciences Institute



smime.p7s
Description: S/MIME Cryptographic Signature