Forum Discussion

Hamish's avatar
Hamish
Icon for Cirrocumulus rankCirrocumulus
May 10, 2010

clock clicks -milliseconds overflow time?

Does anyone know what the overflow time on the F5 implementation of [clock clicks -milliseconds] is? The TCL docs don't say, but there's a posting from 2002 calling for it to be made a 64bit value to hold the number of milliseconds (Or microseconds with -microseconds) since the epoch (Unix epoch that is).

 

 

But I can't find anywhere that explicitly says what the implementation of it is in iRules (Apart from -milliseconds is the highest resolution, and that's from memory... I can't seem to find the posting... NEDs rule is interesting though. That seems to assume that the hi res timer is an offset from the current second... Again I can't find anywhere that actually documents that though.

 

 

(Although there is a good description of hi res timers on sourceforge, and it's unambiguous, but clock clicks is IMPLEMENTATION DEPENDENT, and thus any docs there possibly aren't much use).

 

 

Fa

 

TIA

 

Hamish.

 

 

7 Replies

  • Hamish's avatar
    Hamish
    Icon for Cirrocumulus rankCirrocumulus
    And it doesn't implement the [clock milliseconds] option which is the preferred method and returns the time from epoch..

     

     

     

    I ask because at the moment I'm finding the [clock clicks -milliseconds] apparently jumps backwards... Some hard docs would be useful here...
  • Tsoi,

     

     

    I'm not sure there is an issue to fix. Can you clarify what problem you've encountered? If you have found a potential bug, a support case might be a better way to approach it.

     

     

    Aaron
  • fixed!

     

     

    set ts [clock clicks -milliseconds] overflows

     

     

    fortunately, that is not how you get the unix time, this is:

     

     

    set ts [clock seconds]
  • Greetings!

     

     

    The problem is actual!

     

    I try to generate rfc3339 compliant timestamp with millisecond precision. My TCL script produces expected result, while iRule with same code doesn't work correct.

     

    BEGIN

     

    set ::TIMEZONE "+4:00"

     

     

    proc mstime {} {

     

    set ms_since_epoch [clock milliseconds]; TCL 8.5+, don't supported by BIG-IP

     

    set ms_since_epoch [clock clicks -milliseconds]; obsoleted version of command, which only available on BIG-IP

     

    set msl [string length ${ms_since_epoch}]; calculate amount of ciphers

     

    set seconds [string range ${ms_since_epoch} 0 [expr $msl - 4]]

     

    set ms [string range ${ms_since_epoch} [expr $msl - 3] $msl]

     

    set http_request_timestamp [clock format $seconds -format %Y-%m-%dT%k:%M:%S.${ms}${::TIMEZONE}]

     

    }

     

     

    puts [mstime]

     

    END

     

     

    Some extra examples:

     

    Code: log "seconds after epoch: [clock seconds]"

     

    Generated message: seconds after epoch: 1365594840

     

     

    Code: log "milliseconds after epoch: [clock clicks -milliseconds]"

     

    Generated message: milliseconds after epoch: -204759372

     

     

    My TCL interpreter don't produce negative number by executing command [clock clicks -milliseconds]

     

     

    I expect such behavior while iRule execution.

     

     

    PS: do you know when custom procedures could be defined in iRules?
  • I know this is a four year old thread but was wondering if anyone found solution for the overflow of [clock clicks -milliseconds] . We use 10.2 Version. Any insight is much appreciated

     

  • I worked a case on this back in 2012 and I just dug it up to cut & paste my findings:

     

    ---START---

     

    Furthermore, with everything 64-bit in v11 already it looks like ‘clock clicks –milliseconds’ already does what you want. So if you use v11, you have it now with no wait and no workaround.

     

    And yet more, there is a work around to get a millisecond timestamp:

     

    set secs [expr {wide([clock seconds])}]

     

    set msecs [expr {($secs * 1000) + ([clock clicks -milliseconds] % 1000)}]

     

    That should avoid the rollover issue.

     

    Basically ‘clock clicks –milliseconds’ returns a 64-bit value, but it is being truncated – we’re only returning the rightmost 32-bits. That’s why it doesn’t look anything like 1000 * seconds. But it is the accurate 32-bit ‘tail’. So if we shift seconds to the left ( * 1000) and then add the remainder from the milliseconds (% 1000) then you should be able to recreate the accurate millisecond timestamp.

     

    ‘clock clicks –milliseconds’ is a synonym for ‘clock milliseconds’ – when the whole value is present. It is the truncation on v10 that is munging the results.

     

    For now I’d use that work around in v10 to get milliseconds.

     

    ---END---