|
Posted by atcproductions on March 18, 2005, 1:12 pm
Please log in for more thread options
Monks, mongers and perlites,
I have been attempting to use it to provide 20 digit time date stamp
which includes 6 digits for microseconds. In conjunction with
Time::HiRes I have also used Time::Format which calls HiRes.
The issue that I am running into is I am getting duplicate time stamps.
The following is an excerpt of the code:
Situation: MySQL v4.0, perl v5.8, perl DBI/DBD
There is a MySQL prepare statement, then those bind parameters are
inserted in a loop. These inserts can be quite frequent, but as you can
see in the output below, even slow inserts cause dupes.
#!/usr/bin/perl
#
#####
#
# use me, require me..
#
use Time::HiRes;
use Time::Format qw(%time %strftime %manip);
...
...
...
my $ptime;
while(<STDIN>) {
chomp;
my $event = $_;
undef $ptime;
$ptime = $time;
my ($A,$B,$C,$D,$E,$F,$G) = split /<-->/, $event;
EXECUTE: unless ( eval{ $sth->execute($ptime,$A,$B,$C,$D,$E,$F,$G)}) {
# eval ensures no exit!
...
...
...
Here is a sample from the database:
+--------------------------+-------------------------------------+
| timeDateInserted | timeDateInsertedP |
+--------------------------+-------------------------------------+
| 20050318130506 | 20050318130506.304688 |
| 20050318130507 | 20050318130507.304688 |
| 20050318130507 | 20050318130507.355469 |
| 20050318130508 | 20050318130508.304688 |
| 20050318130509 | 20050318130509.304688 |
| 20050318130509 | 20050318130509.304688 |
| 20050318130509 | 20050318130509.414062 |
| 20050318130510 | 20050318130510.414062 |
+--------------------------+-------------------------------------+
8 rows in set (0.00 sec)
It appears that microseconds somehow are not being updated during the
loop. I have also tried using HiRes with out Format and I am getting
the same type of behavior.
Has anyone come across this type of behavior before? I'm just looking
for each row to have a unique, sequential time. The actual accuracy of
the microseconds is irrelevant as long as no 2 rows have the same exact
time. Any suggestions would be greatly appreciated.
TIA!
|
|
Posted by Brian McCauley on March 19, 2005, 7:34 am
Please log in for more thread options
atcproductions@gmail.com wrote:
> Monks, mongers and perlites,
>
> I have been attempting to use it to provide 20 digit time date stamp
> which includes 6 digits for microseconds. In conjunction with
> Time::HiRes I have also used Time::Format which calls HiRes.
> It appears that microseconds somehow are not being updated during the
> loop. I have also tried using HiRes with out Format and I am getting
> the same type of behavior.
>
> Has anyone come across this type of behavior before?
Yes, Time::Hires is only as precise as the underlying hardware / OS.
> I'm just looking
> for each row to have a unique, sequential time. The actual accuracy of
> the microseconds is irrelevant as long as no 2 rows have the same exact
> time. Any suggestions would be greatly appreciated.
If you want a unique monotonically increasing value try a counter.
|
|
Posted by pat.trainor on March 19, 2005, 6:54 am
Please log in for more thread options
Brian,
Thanks for the reply. But this only applies to events that have the
same whole second, as in:
| 20050318130509 | 20050318130509.304688 |
| 20050318130509 | 20050318130509.304688 |
It does not, however, explain when a whole second boundary has been
crossed:
| 20050318130506 | 20050318130506.304688 |
| 20050318130507 | 20050318130507.304688 |
(see previous post for more examples).
Surely the resolution of a 3.0GHz DL320 clock is of a higher precision
than a whole second. So there is something else afoot here, no?
And if the problem can't be corrected, what is the best approach to
apply an extra counter to ensure a unique sequential extension to the
14 digit time/date?
TIA!
|
|
Posted by chris-usenet on March 19, 2005, 6:21 pm
Please log in for more thread options
pat.trainor@gmail.com wrote:
> And if the problem can't be corrected, what is the best approach to
> apply an extra counter to ensure a unique sequential extension to the
> 14 digit time/date?
This sounds like you've been trying to use "arbirtraily accurate"
timestamps to generate unique values to mark some form of event.
Like an OP suggested, you should consider the use of a monotonically
increasing counter. By all means use the date/time as a base, then suffix
the current value of the counter. If possible, reset the counter as
you roll over to another date/time value.
Chris
|
|
Posted by pat on March 21, 2005, 8:23 am
Please log in for more thread options
Chris,
Thanks for the input. Sequential counters are fine, and as the entries
are being stored in a database with an auto_increment column that part
is fine. Unfortunately the solution suggested won't work when entries
in one table/db are compared to another.
Arbitrary is valid if there is only one source of entries, and they are
being compared against other entries in the same table.
When comparing/merging and 'UNION'ing tables together, the
auto_increment fails to allow a chronological sorting of events as
different tables count in the same range at different times.
A true chronological timestamp allows entries from various sources
(tables) to be merged to show precisely what happenned when, and most
importantly in which order. This is all I'm trying to achieve. If a
valid, repeatable usec time could be achieved from this module
(Time::HiRes), life would be good. As is, unfortunately, the module
does not perform consistently or accurately (at lesat in the way that I
am using it).
If the module can't be made to function accurately (see above posts for
cross-second dupes, etc.) then is there a way (perhaps through POSIX?)
to get the system time (sans whole seconds)-regardless of resolution?
Even 1/10 sec resolution is 10 times more accurate than whole seconds.
I hope I'm explaining the symptoms properly; forgive me if not.
There has to be a good solution. Ideas?
TIA!
pat
:)
|
| Similar Threads | Posted | | Does anyone knows how to install the Time::HiRes Module? | February 16, 2005, 6:22 pm |
| large inaccuracies in Time::HiRes on Opteron | February 25, 2005, 5:44 pm |
| error: no suitable installation target found for package Time-HiRes | February 26, 2005, 5:55 am |
| ANNOUNCE: Time::Out 0.01 | January 4, 2005, 11:30 pm |
| Writing row at a time in Excel using OLE | June 14, 2007, 1:43 pm |
| Reduce CPU time while using serialport? | September 6, 2007, 4:18 pm |
| Time::Local - month problem | December 15, 2004, 11:28 am |
| Finding out the time on an FTP server using perl | August 30, 2005, 5:27 am |
| military time with Date::Calc | June 9, 2005, 1:09 am |
| CPAN pause turnaround time | June 29, 2005, 12:45 pm |
|
XML Sitemap