Gavin Lambert wrote: > Just noticed something that I think is incorrect, but I thought I'd ask for > a sanity check from the group in case I'm missing something. > > In master/master.c's ec_master_init (line 213 in my patched version; line > 211 in stable-1.5) there's the following line: > > ec_master_set_send_interval(master, 1000000 / HZ); > > According to the definition further down and the docs, that second parameter > is supposed to be the time between master application cycles in > microseconds, which is used to calculate a few queue sizes and also to > control the master thread sleep time if EC_USE_HRTIMER is defined (via > configure --enable-hrtimer). > > Doesn't the use of HZ above mean that this is actually calculating "how many > seconds is 1000000 jiffies"
Which is the same as "how many microseconds is 1 jiffy". So sleeping for this many microseconds is as close as possible to the non-hrtimer code which sleeps for 1 jiffy. > On a somewhat related note, is there some guidance for when using > --enable-hrtimer is good or bad? Does it relate just to whether the hrtimer > is present/trusted or is there something more subtle? In terms of the code, > it just seems to be the difference between a "sleep for X time" vs. a "sleep > for 1 quantum", so it *seems* like --enable-hrtimer is good for reducing CPU > usage. The hrtimer code is a little clearer (IMHO) as the ugliness is concentrated in one function (ec_master_nanosleep) (which BTW also helped me with my userspace port as I only had to replace this one function rather than the several set_current_state/schedule constructs in the non-hrtimer code). More importantly, you need hrtimers if you want (master) cycle times shorter than 1 jiffy. If you don't need them, I don't think there's a big practical advantage in using hrtimers. Regards, Frank -- Dipl.-Math. Frank Heckenbach <f.heckenb...@fh-soft.de> Stubenlohstr. 6, 91052 Erlangen, Germany, +49-9131-21359 Systems Programming, Software Development, IT Consulting _______________________________________________ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev
