Date: Fri, 01 Feb 2002 17:19:55 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: "DOROVSKOY,IGOR (A-Portsmouth,ex1)" <igor_dorovskoy@agilent.com> Cc: 'Giorgos Keramidas' <keramida@ceid.upatras.gr>, Storms of Perfection <gary@outloud.org>, replicator@ngs.ru, hackers@freebsd.org Subject: Re: Clock Granularity (kernel option HZ) Message-ID: <3C5B3EBB.8B532BFE@mindspring.com> References: <0D9185CE635BD511ACA50090277A6FCF1359B4@axcs18.cos.agilent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"DOROVSKOY,IGOR (A-Portsmouth,ex1)" wrote: > I've made HZ=100000 and ran few very simple tests (icmp, udp) > thrue gbe interface (3C985B-SX and GA620) against same system > with HZ=100. To transmit - no big difference. For recieve side > "overclocked" system bet regular in times. In my case wasn't big > difference to bing localhost and overclocked system thrue bge nic! > Systat shows empty mbufs all the time. I want to run some better > perfomance tests for tcp tomorrow. As expected. 8-). One thing you might want to try, if you are burning CPU vs. latency like this, is to reduce the quantum time, so that your application runs more frequently, rather than waiting for a time slice. You should see an increase in speed until you heel over into too small a quantum to complete the test program processing. > p.s. guys, x-windows moves so smoothly on overclocked box ... :-) Actually, you aren't overclocked, you're "overhertzed". 8-). Select timeouts are used for windows processing of alternate inputs. This should end up making this "smoother" at the cost of more CPU time being spent, as the select timeout is rounded up to the next tick (this was discussed before, but it was in a way that was pretty far from application). Again, you have to be willing to make the tradeoff. The way UnixWare guarantees X responsiveness is by using a "fixed" sheduling class, so that, no matter what, the X server gets a certain percentage of the CPU dedicated to it. This was the workaround to the VM/buffer cache conflict from non-unification, where the ld program would mmap a lot of object files, seek all over them to do the link, and cause the X server to (effectively) lock up for lack of its pages being in core. Putting it in a fixed class let it spend CPU paging its pages back in, so that it could run. Both of these fall into the category of "ugly hacks", in my book, and unless you need an increased timining granularity for real work, using a higher granularity only while doing profiling is probably a better idea, and understanding the source of your performance problems, and work *on* instead of *around* them, a better approach. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C5B3EBB.8B532BFE>