Tuning HZ for semi-realtime applications

Harti Brandt brandt at fokus.fraunhofer.de
Mon Aug 4 06:50:45 PDT 2003


On Sun, 3 Aug 2003, Sean Hamilton wrote:

SH>Greetings,
SH>
SH>I have an application which has some task it must execute at some interval
SH>(approximately 1000 times per second.) This application calls select(2) in a
SH>loop, and uses its timeout parameter to try to keep the timing consistent.
SH>
SH>At the end of a cycle, it sends out a large amount of network traffic.
SH>During the select loop, it expects to receive replies to all this traffic.
SH>
SH>Should I set HZ to 1000 (the frequency of my application) or should I set it
SH>to a much higher value? The CPU is running at around 2 GHz, and I set it as
SH>high as 50,000 with no problems. However, the granularity of my timeout
SH>appears to be restricted to 1/1000th of a second.

I run almost all of my systems at HZ=10000. 50000 will break TCP as soon
as you try to connect to systems that are a moderate round trip time away.
The problem seems to be that the round trip time calculation is done in
ticks and that overflows the variables at larger hertzes.

You must also keep in mind that even on an otherwise idle system some
processes can take longer than the 100usec when HZ=10000. A typical
problem are the MII status updates of several cards like the xl(4).
The time they require has drastically been reduced but they still need
around 900usec.

harti

SH>
SH>I would like to use poll(2) instead of select, but it appears to take its
SH>timeout parameter in milliseconds, which aren't precise enough to keep my
SH>timing reasonable, especially if I ever need to increase my frequency.
SH>
SH>Another option would be calling poll/select with no timeout, in a loop.
SH>However, this seems like a waste of CPU time.
SH>
SH>Also, as I am doing large amounts of network traffic, which NIC (preferably
SH>gigabit) should I be using, to cause the least interference with my timing?
SH>
SH>I do not require realtime performance. I am just looking to have this run as
SH>smoothly as possible.
SH>
SH>sh
SH>
SH>_______________________________________________
SH>freebsd-hackers at freebsd.org mailing list
SH>http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
SH>To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
SH>

-- 
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
brandt at fokus.fraunhofer.de, harti at freebsd.org


More information about the freebsd-hackers mailing list