[OpenSIPS-Devel] [ opensips-Patches-3191805 ] Timestamp granularity of seconds is insufficient
Patches item #3191805, was opened at 2011-02-25 03:21 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=3191805group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: core Group: trunk Status: Open Resolution: Invalid Priority: 5 Private: No Submitted By: Dynamic Packet (dpacket) Assigned to: Vladut-Stefan Paiu (vladut-paiu) Summary: Timestamp granularity of seconds is insufficient Initial Comment: Current core options for getting numeric timestamps are limited $Ts (time in seconds) and $Tsm (microseconds of the current second). This leaves no way to calculate more precise time deltas. Even trying to combine the two current variables, being the results of two separate calls, they are not equal, rounding issues non-withstanding. Attached is a patch that creates a new core variable, $Tsms, which represents the current timestamp in MILLISECONDS. This granularity is sufficient for most applications. If more is precision is needed, this could easily be extended to add another var, $Tsus, which would represent current time in MICROSECONDS. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2011-06-20 19:47 Message: let's make a function that returns into 2 vars the secs and usecs. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2011-04-29 19:38 Message: Hi, The approach is invalid as a variable returns numerical vals as integers - 2^32 = 4294967296 . This is the max number of miliseconds you can store. Considering 1000 milliseconds per second, 3600 seconds per hour, 24 hours per day and 365 days per year - you can store only miliseconds covering 0.136 years :Dstarting from 1970 :P... So, the returned value is overflowed big time. I suggest a different approach, having a function that returns (from a single sys call) 2 values, the seconds and microsecs inside the given second. Regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=3191805group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-3191805 ] Timestamp granularity of seconds is insufficient
Patches item #3191805, was opened at 2011-02-25 03:21 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=3191805group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: core Group: None Status: Open Resolution: Invalid Priority: 3 Private: No Submitted By: Dynamic Packet (dpacket) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: Timestamp granularity of seconds is insufficient Initial Comment: Current core options for getting numeric timestamps are limited $Ts (time in seconds) and $Tsm (microseconds of the current second). This leaves no way to calculate more precise time deltas. Even trying to combine the two current variables, being the results of two separate calls, they are not equal, rounding issues non-withstanding. Attached is a patch that creates a new core variable, $Tsms, which represents the current timestamp in MILLISECONDS. This granularity is sufficient for most applications. If more is precision is needed, this could easily be extended to add another var, $Tsus, which would represent current time in MICROSECONDS. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2011-04-29 19:38 Message: Hi, The approach is invalid as a variable returns numerical vals as integers - 2^32 = 4294967296 . This is the max number of miliseconds you can store. Considering 1000 milliseconds per second, 3600 seconds per hour, 24 hours per day and 365 days per year - you can store only miliseconds covering 0.136 years :Dstarting from 1970 :P... So, the returned value is overflowed big time. I suggest a different approach, having a function that returns (from a single sys call) 2 values, the seconds and microsecs inside the given second. Regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=3191805group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-3191805 ] Timestamp granularity of seconds is insufficient
Patches item #3191805, was opened at 2011-02-24 20:21 Message generated for change (Tracker Item Submitted) made by dpacket You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=3191805group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dynamic Packet (dpacket) Assigned to: Nobody/Anonymous (nobody) Summary: Timestamp granularity of seconds is insufficient Initial Comment: Current core options for getting numeric timestamps are limited $Ts (time in seconds) and $Tsm (microseconds of the current second). This leaves no way to calculate more precise time deltas. Even trying to combine the two current variables, being the results of two separate calls, they are not equal, rounding issues non-withstanding. Attached is a patch that creates a new core variable, $Tsms, which represents the current timestamp in MILLISECONDS. This granularity is sufficient for most applications. If more is precision is needed, this could easily be extended to add another var, $Tsus, which would represent current time in MICROSECONDS. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=3191805group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
