in reply to NTP Error

Why not take it up a notch by using POE:::Component::Client::NTP. The author of Net::NTP joined forces with Chris Williams, so it's built on top of Net::NTP.

I added some error handling, but the way you're doing time just doesn't work for me. I'm tryimg Time::Stamp at the moment, but I haven't got it working right yet. Here's what I have so far:
#!/usr/bin/perl -l use strict; use warnings; use Data::Dumper::Concise; use POE qw(Component::Client::NTP); #use Time::Stamp -stamps => {format => 'easy'}; my $host = shift @ARGV; POE::Session->create( package_states => [ main => [qw(_start _stop _response)], ], ); $poe_kernel->run(); exit 0; sub _start { POE::Component::Client::NTP->get_ntp_response( host => $host, event => '_response', ) or die "Couldn't connect to server: $!"; return; } sub _stop { print "Refcount was decremented"; return; } sub _response { my $packet = $_[ARG0]; print Dumper( $packet ); }

Replies are listed 'Best First'.
Re^2: NTP Error
by BrowserUk (Patriarch) on May 28, 2012 at 09:11 UTC
    Why not take it up a notch ...

    I have to ask the counter question: Why take it up a notch?

    For the OPs described purpose, what does adding the all that extra infrastructure into the equation buy?

    Apart from pretty much guaranteeing that by the time he finally lays his hands on the timestamp he is after, it is a week out of date.

    Its like using a MAC-truck as a shopping trolley.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

    The start of some sanity?

      Glad to see that you're feeling chipper! I like your MAC analogy; however, I'd choose a MAC over a shopping trolley any time:-).

      I recommended POE::Component::Client::NTP because it's a better fit with my system, and because it doesn't look for Socket6---it fails tests for me. To get around that, I started using POE::Component::Client::NTP.

      As for which one is the closest to spot-on, I ran some simple timing tests. Hmmm...the jury is still out on that one.

      Net::NTP
      #!/usr/bin/perl use strict; use warnings; use Time::AutoRes qw/time/; use Data::Dumper::Concise; use Net::NTP qw/get_ntp_response/; my $host = 'pool.ntp.org'; print Dumper(my $start = time); my %response = get_ntp_response($host); print Dumper( %response ), "\n"; print Dumper(my $end = time); print Dumper(my $elapsed_time = ($end - $start));
      POE::Component::Client::NTP
      #!/usr/bin/perl use strict; use warnings; use Time::AutoRes qw/time/; use Data::Dumper::Concise; use Net::NTP qw/get_ntp_response/; use POE qw/Component::Client::NTP/; my $host = 'pool.ntp.org'; print Dumper(my $start = time); POE::Session->create( package_states => [ main => [qw(_start _stop _response)], ], ); $poe_kernel->run(); print Dumper(my $end = time); print Dumper(my $elapsed_time = ($end - $start)); exit 0; sub _start { POE::Component::Client::NTP->get_ntp_response( host => $host, event => '_response', context => 'word', ) or die "Couldn't connect to server: $!"; return; } sub _stop { print "Refcount was decremented"; } sub _response { my $packet = $_[ARG0]; print Dumper( $packet ); }
      I got mixed results, but if I use my system time, Net::NTP is consistently faster.
        Net::NTP is consistently faster.

        That is kind of a given. If you trace you Net::NTP script, it executes 1176 lines:

        C:\test>perl -d:Trace junk1001.pl >junk1001.log 2>&1 C:\test>wc -l junk1001.log 1176 junk1001.log

        If you run your POE script, it executes 3575 lines:

        C:\test>perl -d:Trace junk1000.pl >junk1000.log 2>&1 C:\test>wc -l junk1000.log 3575 junk1000.log

        Just over 1000 of those lines -- the ones that run in Net::NTP -- are more or less identical between the two scripts.

        The other 2400 in the POE script are the overhead of running POE.

        Of course, those lines enable you to do many other things besides NTP...but there is no circumstance under which you would want to have a script doing any of those other things concurrently with synchronising your system clock; because the overhead would compromise the accuracy of the synchronisation.

        Actually, if you want to synchronise your clock really accurately, even the overhead of Net::NTP is too much. Especially when the whole purpose of using udp is to allow a very low latency turnaround of the request and response; and the simplicity of coding that comes from udp sendto() and recvfrom() calls.


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

        The start of some sanity?