Interval Timers on Windows

Discussion in 'Perl Misc' started by Bernard Chan, Apr 29, 2007.

  1. Bernard Chan

    Bernard Chan Guest

    Hi All,

    I am writing a script to generate some packets for RTP stream simulation. As
    you may know, RTP requires a more-or-less constant packet rate (and hence
    UDP is used), and I will need to generate fixed sized packets at regular
    intervals, say 20ms, so that will be around 50 packets per second.

    On Linux I have tried a version using Time::HiRes ualarm(). On some of my
    Linux systems ualarm() can generate a packet rate that approximates 50Hz
    pretty well, and the interval variance is infinitesimal. However, I also
    have some systems (mostly Fedora) which seem to exhibit increasingly long
    intervals after some seconds for reasons unknown to me.

    I would also like to have the script usable on Windows that my peers who
    have Windows on their systems can perform some tests. There is no ualarm()
    in Time::HiRes on Windows, so I tried another approach. I created a
    thread-enabled version of the script. A separate thread is created which
    does roughly this:

    while ($continue) {
    sendPacket();
    select(undef, undef, undef, 20/1000);
    }

    However, I find that the sleep between each packet tends to be slightly
    higher than 20ms, so after not many packets it is already arriving slower
    than the drain rate at the receiver side.

    So, I would like to know, whether I can do anything to improve this on the
    Windows side? I don't need microseconds or even nanoseconds granularity.
    1ms would be generally good enough, but I would like a cross-platform
    (Win+Linux at least) approach.

    Any insights will be much appreciated.

    --
    Regards,
    Bernard Chan

    --
    Posted via a free Usenet account from http://www.teranews.com
    Bernard Chan, Apr 29, 2007
    #1
    1. Advertising

  2. Bernard Chan

    Brian Wakem Guest

    Bernard Chan wrote:

    >
    > Hi All,
    >
    > I am writing a script to generate some packets for RTP stream simulation.
    > As you may know, RTP requires a more-or-less constant packet rate (and
    > hence UDP is used), and I will need to generate fixed sized packets at
    > regular intervals, say 20ms, so that will be around 50 packets per second.
    >
    > On Linux I have tried a version using Time::HiRes ualarm(). On some of my
    > Linux systems ualarm() can generate a packet rate that approximates 50Hz
    > pretty well, and the interval variance is infinitesimal. However, I also
    > have some systems (mostly Fedora) which seem to exhibit increasingly long
    > intervals after some seconds for reasons unknown to me.
    >
    > I would also like to have the script usable on Windows that my peers who
    > have Windows on their systems can perform some tests. There is no ualarm()
    > in Time::HiRes on Windows, so I tried another approach. I created a
    > thread-enabled version of the script. A separate thread is created which
    > does roughly this:
    >
    > while ($continue) {
    > sendPacket();
    > select(undef, undef, undef, 20/1000);
    > }
    >
    > However, I find that the sleep between each packet tends to be slightly
    > higher than 20ms, so after not many packets it is already arriving slower
    > than the drain rate at the receiver side.
    >



    Surely you would need to time sendPacket() and subtract it from the next
    delay?


    --
    Brian Wakem
    Email: http://homepage.ntlworld.com/b.wakem/myemail.png
    Brian Wakem, Apr 29, 2007
    #2
    1. Advertising

  3. On Sun, 29 Apr 2007 10:47:30 +0100, Brian Wakem wrote:

    > Surely you would need to time sendPacket() and subtract it from the next
    > delay?


    Surely time spend in sendPacket is negligible om modern machines?

    (I don't really know.I/O and syscalls used to be expensive. Nowadays
    machines are so fast that syscalls are fast too and sending a packet
    generally means -- I assume -- copying it to some internal buffer and
    some pointer fiddling, so that should be very fast).

    M4
    Martijn Lievaart, Apr 29, 2007
    #3
  4. Bernard Chan

    Bernard Chan Guest

    Martijn Lievaart wrote:

    > On Sun, 29 Apr 2007 10:47:30 +0100, Brian Wakem wrote:
    >
    >> Surely you would need to time sendPacket() and subtract it from the next
    >> delay?

    >
    > Surely time spend in sendPacket is negligible om modern machines?


    Thanks for your replies.

    Actually I have tried a version making similar adjustments to the delay
    before, but there was no noticeable improvements (the packet rate is still
    highly fluctuating while tending to be slightly < 50Hz in the long term). In
    fact the time lag seems to be even more substantial in this version. This is
    the exact code of what I tried:

    sub sendPacketThread {
    my ($t_s, $t_us);
    while ($continue) {
    ($t_s, $t_us) = (time(), ${[gettimeofday()]}[1]);
    sendPacket();
    my ($t2_s, $t2_us) = (time(), ${[gettimeofday()]}[1]);
    my $workTime = ($t2_s - $t_s)*(10**6) + ($t2_us - $t_us);
    ($t_s, $t_us) = ($t2_s, $t2_us);
    select(undef, undef, undef,
    ($ptime*1000-$workTime)/(10**6));
    }
    }

    This subroutine is what was immediately called from thread->new(). In the
    test, both the sender and receiver are on localhost so there should not be
    any packet transit issue.

    Therefore, I am wondering whether there are any "real" timers accessible on
    Windows Perl that gives a more accurate timer. Some fluctuations of delay
    in between individual packets is acceptable, but the long-term rate should
    be very close to 50Hz or the receiver side will start to drop each packet
    on arrival ...

    --
    Regards,
    Bernard Chan

    --
    Posted via a free Usenet account from http://www.teranews.com
    Bernard Chan, Apr 29, 2007
    #4
  5. On Sun, 29 Apr 2007 19:43:18 +0800, Bernard Chan wrote:

    > This subroutine is what was immediately called from thread->new(). In
    > the test, both the sender and receiver are on localhost so there should
    > not be any packet transit issue.


    Perl threading is reasonably slow, and I don't know about the granularity
    of taskswitches. Maybe you should test this first without threads to see
    if threading itself isn't the issue.

    HTH,
    M4
    Martijn Lievaart, Apr 29, 2007
    #5
  6. Bernard Chan

    Bernard Chan Guest

    Martijn Lievaart wrote:

    > On Sun, 29 Apr 2007 19:43:18 +0800, Bernard Chan wrote:
    >
    >> This subroutine is what was immediately called from thread->new(). In
    >> the test, both the sender and receiver are on localhost so there should
    >> not be any packet transit issue.

    >
    > Perl threading is reasonably slow, and I don't know about the granularity
    > of taskswitches. Maybe you should test this first without threads to see
    > if threading itself isn't the issue.


    The same script with single-threaded ualarm() does not have the same issue
    on Linux. The major problem I have is that Windows cannot use it. So I'm
    trying to look for a solution for Windows machines.

    If I use fork() instead of threading, I cannot share variables between them
    (on Windows). Or are there mechanisms for addressing shared variables issue
    without threads?

    Thanks.

    --
    Regards,
    Bernard Chan

    --
    Posted via a free Usenet account from http://www.teranews.com
    Bernard Chan, Apr 30, 2007
    #6
  7. Bernard Chan

    Bernard Chan Guest

    On Thu, 03 May 2007 20:58:44 -0700, sl123 wrote:

    > On Tue, 01 May 2007 21:04:26 -0700, wrote:
    >
    > I was curious about this so I tried this thread model, sending packets
    > on a time boundry. Virtually no drift, mean stayed on target at %99.98.
    > Actually I was suprised.


    Hello,

    Do you have the exact source code? I'm interested in seeing how you got to
    get it.

    Thanks.

    Regards,
    Bernard Chan.

    --
    Posted via a free Usenet account from http://www.teranews.com
    Bernard Chan, May 8, 2007
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Stephen Inkpen

    Timers in application web programming

    Stephen Inkpen, Jul 16, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    332
    Ken Cox [Microsoft MVP]
    Jul 16, 2003
  2. Kelsang Wangchuk

    System.Timers.Timer vs. System.Threading.Timer

    Kelsang Wangchuk, Jul 31, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    705
    Kelsang Wangchuk
    Jul 31, 2003
  3. Girish Pal Singh

    timers

    Girish Pal Singh, Aug 11, 2003, in forum: ASP .Net
    Replies:
    2
    Views:
    560
    Kevin Spencer
    Aug 11, 2003
  4. Girish Pal Singh

    Web Timers

    Girish Pal Singh, Aug 13, 2003, in forum: ASP .Net
    Replies:
    4
    Views:
    436
    George Ter-Saakov
    Aug 13, 2003
  5. Roland
    Replies:
    1
    Views:
    511
    Rutger Smit
    Sep 8, 2004
Loading...

Share This Page