Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > Interval Timers on Windows

Reply
Thread Tools

Interval Timers on Windows

 
 
Bernard Chan
Guest
Posts: n/a
 
      04-29-2007

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

 
Reply With Quote
 
 
 
 
Brian Wakem
Guest
Posts: n/a
 
      04-29-2007
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
 
Reply With Quote
 
 
 
 
Martijn Lievaart
Guest
Posts: n/a
 
      04-29-2007
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
 
Reply With Quote
 
Bernard Chan
Guest
Posts: n/a
 
      04-29-2007
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

 
Reply With Quote
 
Martijn Lievaart
Guest
Posts: n/a
 
      04-29-2007
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
 
Reply With Quote
 
Bernard Chan
Guest
Posts: n/a
 
      04-30-2007
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

 
Reply With Quote
 
Bernard Chan
Guest
Posts: n/a
 
      05-08-2007
On Thu, 03 May 2007 20:58:44 -0700, sl123 wrote:

> On Tue, 01 May 2007 21:04:26 -0700, http://www.velocityreviews.com/forums/(E-Mail Removed) 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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Timers spf R Siffredi Cisco 1 10-31-2005 05:11 PM
Timer in Windows Service fires eratically when interval elapsed Roland ASP .Net 1 09-08-2004 07:59 PM
timers Girish Pal Singh ASP .Net 2 08-11-2003 01:00 PM
System.Timers.Timer vs. System.Threading.Timer Kelsang Wangchuk ASP .Net 0 07-31-2003 04:28 PM
Timers in application web programming Stephen Inkpen ASP .Net 1 07-16-2003 02:12 AM



Advertisments