well I changed HZ=1000, recompiled and rebooted, ftp get and put, some nfs write big files and a app that pushes alot of small file reads, writes and rcp.lockd.
No differance in the timings. Thier is a chance that the test client ran out of CPU but nothing that I spotted. MJM ----- Original Message ----- From: "Storms of Perfection" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, January 31, 2002 7:10 PM Subject: Re: Clock Granularity (kernel option HZ) > 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
