[Xorp-hackers] Question of FEA strace

[Bruce M Simpson]

Pavlin Radoslavov wrote:
> Ben Greear <greearb at candelatech.com> wrote:
>
>   
>> Any idea what is causing those writev messages?  It seems they are not
>> passing much information, but doing so very often...  Having a hard
>> time grepping through the code to see the originator...
>>     
>
> Those are from the XRL mechanism.
> I believe there are periodic keepalives between the XRL Finder and
> each process that is controlled by that Finder, but they should be
> on the order of once every few seconds or so.
>
> Regards,
> Pavlin
>
>   
>> 11:32:24.043438 writev(31, [{"Finder 0.2\nMsgType r\nSeqNo 5825\nMsgData 100 / \n", 47}], 1) = 47
>> 11:32:24.043570 rt_sigaction(SIGPIPE, {SIG_DFL}, {SIG_IGN}, 8) = 0
>> 11:32:24.043644 rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0
>> 11:32:24.043705 writev(32, [{"Finder 0.2\nMsgType r\nSeqNo 5828\nMsgData 100 / \n", 47}], 1) = 47
>> 11:32:24.043843 rt_sigaction(SIGPIPE, {SIG_DFL}, {SIG_IGN}, 8) = 0
>> 11:32:24.043910 clock_gettime(CLOCK_MONOTONIC, {768671, 208128378}) = 0
>> 11:32:24.043957 clock_gettime(CLOCK_MONOTONIC, {768671, 208173677}) = 0
>>     


Just to recap: I introduced the change to use CLOCK_MONOTONIC in order 
to address a long-standing problem we had with event callbacks and busy 
xorp_bgp processes, as well as when NTP made changes to the system clock.

Occasionally the BGP process would get very busy, and start to get late 
in dispatching callbacks, to the point of losing track of time. Or NTP 
would update the clock, causing deltas based on gettimeofday() to become 
completely bogus by appearing to go back in time.

CLOCK_MONOTONIC is guaranteed by POSIX to be monotonically increasing, 
independently of wall-clock time, and to increment in SI units. Usually 
it's implemented in terms of a hardware clock, whose origin 0 is the 
time of system boot.

As it's a timer used to calculate deltas in time, rather than display 
the wall-clock time, there is no need for it to correspond directly to 
the wall-clock time, although of course the underlying time base is 
subject to the laws of physics.

[This means it's going to be subject to general relativity, although 
that is *currently* not a XORP design issue until we start installing 
XORP on communications satellites, hopefully well within the next 5 years.]

In FreeBSD, CLOCK_MONOTONIC goes more or less directly to the 
timecounter code in the kernel, although there is a fast path and a 
precise path. XORP just requests the default, which is precise.

The Linux 2.6 timer code looks eerily similar, although the effect is 
the same -- CLOCK_MONOTONIC can be difficult to cache, which is why the 
SystemClock class exists.

Windows uses GetSystemTimeAsFileTime(), as this is the path of least 
resistance. The "right thing" to do there is probably to use 
GetTickCount64(), however this is Vista only -- it's entirely possible, 
though unlikely, that a XORP process timer could be scheduled 50 days in 
advance, or that the delta could span 50 days.

[Having to read the uptime from the registry is the absolute worst case 
scenario -- it will return the correct consistent monotonic result we 
want, at a high API call cost.]

cheers
BMS