Ok. Since I have a limited hardware/software set at my finger tips. I can generate an attack on my machine (such as a synflood or something) to see what type of reponses I can get by setting it up and down. I think this may apply to this feature, to help the machine withstand attacks (and possibly have performance related gains/decreases)
I can't really play with gig-e or NFS at this second, so I ask you to play around with the setting and keep track of what does what, and send a email to me with what settings work best in foo enviornment :) > Not knowing but wondering: > With Gigabit Ethernet and NFS in the mix, anything that gets latency > out is a very good thing :-) and would improve performance. > > MJM > > > ----- Original Message ----- > From: "Mike Silbersack" <[EMAIL PROTECTED]> > To: "Storms of Perfection" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Thursday, January 31, 2002 12:33 PM > Subject: Re: Clock Granularity (kernel option HZ) > > >> >> On Thu, 31 Jan 2002, Storms of Perfection wrote: >> >> > I'm going to benchmark different network senarious with different > options >> > to see what I can get, and what works best. If someone wants to help >> > me out, I could maybe write up a article about it? >> >> I don't think you'll end up seeing the performance improvements you're >> looking for. The case where HZ=1000 is really useful is when using >> dummynet; the more accurate scheduling is necessary for it to handle >> high data rate pipes properly. >> >> The TCP stack, on the other hand, is perfectly happy with 10ms >> resolution. Retransmission timeouts are only actually used when loss >> occurs on the network, and 10ms is more than accurate enough for >> retransmission. (I believe that retransmit timeouts are rounded up to >> 1 second, but don't quote me on that.) The other timed events >> (keepalive timeouts, delayed ack timeouts, etc) are also in good shape >> with 10ms accuracy. >> >> So, it's highly unlikely that you'll be able to observe a perceptable >> difference in network performance except in really convoluted cases. >> >> Mike "Silby" Silbersack >> >> >> To Unsubscribe: send mail to [EMAIL PROTECTED] >> with "unsubscribe freebsd-hackers" in the body of the message Gary Stanley Network Security Engineer PRECISIONet/Webjockey, Inc. (877) 595-8570 Tickle us, do we not laugh? Prick us, do we not bleed? Wrong us, shall we not revenge?" (Merchant of Venice II i 56-63, paraphrase) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
