switch to room list switch to menu My folders
Go to page: First ... 8 9 10 11 [12] 13 14 15 16 ... Last
[#] Tue Jul 29 2014 11:28:51 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Another awful thing... Valhalla Linux doesn't have a concept of a steady clock within it.

The only clocks I can find for this is a clock that matches the 'real time', and is subject to the usual crap when you adjust the time, and process/thread CPU clocks, which are not exactly steady. There is no way that I can see right now that you can get a kind of clock that simply iterates over a steady rate of time, monotonically.

Did people writing for Valhalla wind up with obscure and weird problems when people changed their time?

[#] Tue Jul 29 2014 11:29:19 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

(Sorry, I wrote 'Valhalla Linux', which is stupid... RedHat Valhalla is what I mean).

[#] Tue Jul 29 2014 12:48:57 EDT from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

you're supposed to run ntpclient in cron or such.

VM-clocs are even less predictable then usual system clocks.

Ticks are supposed to be somewhat predictable..

[#] Tue Jul 29 2014 12:51:23 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

what you're looking for might be /proc/loadavg, which is used by the "uptime" command...

[#] Tue Jul 29 2014 12:52:33 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

/proc/uptime ooks like the the same thing, higher resolution?

[#] Tue Jul 29 2014 13:07:05 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

(I got this by running "strace" on the /usr/bin/uptime. the program queries both /proc/loadavg and /proc/uptime (oops) so the latter is the one that's relevant.

these have been around for a while, so they should work on rh6.2 even.

[#] Tue Jul 29 2014 13:15:37 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Thanks for the information!

Here's something else to add to it:

If I'm reading this correctly, back then, people tried to ensure that time marched forward by relying upon the NTP client to adjust the system clock in monotonic ways. So, you'd never change the system clock yourself... you would let NTP do it for you, and it would always adjust the clock in a fashion that is monotonic in nature.

Obviously, folks must have figured out how bad this idea was, as we now have CLOCK_MONOTONIC available for clocks in current kernels, but I guess we had some relatively naive notions about time back then.

Sooo, at least philosophically, I should be able to use the realtime clock as if it were the steady clock, and avoid adjusting the time/date on the machine, just as I guess they intended back in the day.

I have to figure out how to coerce my code to do this... it *really* wants CLOCK_MONOTONIC or the like. I tried #defining it to CLOCK_REALTIME and now I have a linking error. But I'm sure I can get past that with a little evil.

[#] Tue Jul 29 2014 13:21:11 EDT from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

nm, strings & grep to the hilts!

[#] Tue Jul 29 2014 14:12:54 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Heh... I worked around it by forcing the underlying boost::steady_clock class to use CLOCK_REALTIME instead of CLOCK_MONOTONIC (or variations). It isn't perfect, but it'll have to do since the OS doesn't have a proper monotonic clock.

If I felt plucky, I could maybe build one in some bizarre fashion using the boost::steady_clock interface but writing the underlying code that calls the usual OS APIs to do something with /proc/utime instead... if I can figure out how to make a timer that doesn't busy-wait within this context.

But I think for how I'm doing everything, this may be good enough. I'll know more when we get into testing.

[#] Tue Jul 29 2014 14:12:58 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Well, there is *One* *Simple* *Trick* that you can do to ensure monotonicity in userland ;) ;) ;)

[#] Tue Jul 29 2014 14:17:22 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

(oh, and since this kind of stuff gets picked up by Google now, here's some additional details, in case someone else wants to do this).

If you find yourself in the ridiculous position of having to write code to work on a version of Linux using the 2.14 kernel, after figuring out how to build the GCC 4.83 compiler (not something I'll bother with here... just know that it's doable), you'll need the following in one of your .cpp files:

#if defined(__linux__)
#include <time.h>
#pragma message "This OS doesn't support a steady clock. YMMV."
#include <boost/chrono/detail/inlined/chrono.hpp>

[#] Tue Jul 29 2014 14:19:46 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Oh, god, that is stupid.

There's another guard... #if !defined(CLOCK_MONOTONIC), that I missed.

[#] Tue Jul 29 2014 15:06:25 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Oh, I missed that... 'one simple trick' to ensure monotonicity in userland... RTOS I assume.

[#] Tue Jul 29 2014 15:08:32 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I was thinking of something a little more subtle, but still quite silly.

[#] Tue Jul 29 2014 17:32:42 EDT from zooer @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Things related to Linux that you should probably avoid saying in the

Booting the Colonel now.

It is okay, Don't ask don't tell has been repealed.

[#] Wed Jul 30 2014 06:20:42 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Free greps for everyone!

[#] Wed Jul 30 2014 12:57:19 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Oh, I missed that... 'one simple trick' to ensure monotonicity in
userland... RTOS I assume.

I think I saw that at the bottom of a web page. "Ensure monotonicity in userland with this one weird trick!"

[#] Fri Aug 01 2014 14:47:33 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Heh, my clock trick works, but I don't feel great about it.

Whatever I did to get this compiler built on this machine, though, may not be working so well. I can compile code just fine, and much of it works, but apparently, when I do this One Certain Thing, it segfaults.

I don't think it's the code itself, as this One Certain Thing works everwhere else. I'm not in the habit of blaming compilers for my problems, but I suspect this compiler isn't kosher because of my tamperings.


I'm sorely tempted to tell them that the older version of this product is the only thing that will work on this older OS, and that we won't be able to add new features to it. They need to modernize anyway, maybe this could help give them incentive.

[#] Fri Aug 01 2014 15:24:53 EDT from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

valgrind is your friend.

or... didn't you compile GCC 4.8 anyways? try ASAN.

[#] Fri Aug 01 2014 15:34:40 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I'm not sure I know what 'ASAN' means.

I did compile gcc 4.8, and that's the compiler I'm using, but... I'm not sure it's doing the trick here. I've also tried compiling with a 4.7 compiler, but that also failed to work for me.

I'm not sure valgrind is going to help me much here, when the symbols are so borked that gdb (as newly compiled by 4.8) can't read them. But I can give it a shot... I've been using nm to help me figure out where the weirdness is happening (pthread_create/pthread_wait_for_restart_signal/pthread_handle_sigrestart).

Go to page: First ... 8 9 10 11 [12] 13 14 15 16 ... Last