Comments on: Time to know your code My understanding is that it was a bug in some AMD motherboards - fixable by a bios upgrade. We used to get it on a lot of the machines at Krome some years ago now. My understanding is that it was a bug in some AMD motherboards – fixable by a bios upgrade. We used to get it on a lot of the machines at Krome some years ago now.

]]>
By: elmindreda/2011/03/22/time-to-know-your-code/#comment-1900 elmindreda Wed, 23 Mar 2011 11:02:33 +0000

]]>
By: Bjoern Knafla/2011/03/22/time-to-know-your-code/#comment-1897 Bjoern Knafla Wed, 23 Mar 2011 10:23:46 +0000 True that I haven't seen it in a while, but I'm not sure it's old enough to warrant not having the checks in there. Anyway, I've updated the code in the repository to make the fallback path optional (through a compile-time flag). True that I haven’t seen it in a while, but I’m not sure it’s old enough to warrant not having the checks in there. Anyway, I’ve updated the code in the repository to make the fallback path optional (through a compile-time flag).

]]>
By: Mattias Jansson /2011/03/22/time-to-know-your-code/#comment-1879 Mattias Jansson  Tue, 22 Mar 2011 22:40:17 +0000 Nooo - don't end the article that early ;-) Can't wait to read your next posts! I like your philosophy of moving memory management out of the library and to the users. A few questions: - Wouldn't it make sense to have a "difference" function so I could just take timestamps inside of number crunching code and calculate the time diffs later on so that I don't skew the timing by the measurements (at least a bit less)? - Are calls to the realtime clock functions kernel calls or do they stay in user-land (or: what's the price to pay per timestamp query)? - What data-type (bit-size) hides behind tick_t - is it big enough to prevent overflows (mainly looking at the POSIX section)? I'm mainly asking because of the non-standardized size of POSIX time_t - which makes it quite hard to be truly platform agnostic. - There is an error-check in the POSIX section but a return-value is missing - would you merely return a zero value to signal that a realtime clock isn't supported? Nooo – don’t end the article that early ;-)
Can’t wait to read your next posts! I like your philosophy of moving memory management out of the library and to the users.

A few questions:
- Wouldn’t it make sense to have a “difference” function so I could just take timestamps inside of number crunching code and calculate the time diffs later on so that I don’t skew the timing by the measurements (at least a bit less)?

- Are calls to the realtime clock functions kernel calls or do they stay in user-land (or: what’s the price to pay per timestamp query)?

- What data-type (bit-size) hides behind tick_t – is it big enough to prevent overflows (mainly looking at the POSIX section)? I’m mainly asking because of the non-standardized size of POSIX time_t – which makes it quite hard to be truly platform agnostic.

- There is an error-check in the POSIX section but a return-value is missing – would you merely return a zero value to signal that a realtime clock isn’t supported?

]]>
By: Pavel Tumik/2011/03/22/time-to-know-your-code/#comment-1875 Pavel Tumik Tue, 22 Mar 2011 17:29:49 +0000 Well, I actually want to measure total time spent for a block to complete, including preemption. I think will become clear when I draw up the idea for the actual profiling code and visualizer. Well, I actually want to measure total time spent for a block to complete, including preemption. I think will become clear when I draw up the idea for the actual profiling code and visualizer.

]]>
By: Mattias Jansson /2011/03/22/time-to-know-your-code/#comment-1870 Mattias Jansson  Tue, 22 Mar 2011 13:44:00 +0000 Have you thought of any tricks to overcome the problem of thread preemption? It seems your algorithm works with global clock, not making any difference on thread sleep! Have you thought of any tricks to overcome the problem of thread preemption? It seems your algorithm works with global clock, not making any difference on thread sleep!

]]>
By: MartinsM/2011/03/22/time-to-know-your-code/#comment-1868 MartinsM Tue, 22 Mar 2011 13:29:27 +0000 Linux FAQ for clock_gettime(CLOCK_REALTIME):

CLOCK_REALTIME is affected by settime()/settimeofday() calls… CLOCK_MONOTONIC is not affected by settime()/settimeofday()

Also if you declare tick_t as unsigned type, then what’s the point of using if (refdiff < 0) when refdiff is variable of tick_t type?

]]>