accurate timers

[Stephan Steiner]

Hi

I'm using a timer that is triggered each second to perform a countdown. Once
the countdown hits one, I reduce the timer interval by a safety margin, and
the next time the timer callback kicks in, I turn on packet reception in my
program. The next timer interval is one second plus the safety margin, and
is reset once the first packet containing an indicator of the next data
transmission is received. This mechanism works accurately on my client
software running on a pc, it is always in synch with the server, even though
they run on different machines (the client is even connected through a
wlan). However, if I do the same on PocketPC, if I show the counter in the
GUI I can already see that it doesn't match the countdown on the client and
the server PC, and sure enough, the PDA gets out of synch quite often (it
manages to catch up eventually, but the whole point of my data transmission
mechanism is that a client listens at the beginning of the data transfer,
and shuts down as soon as it has all the data it needs). My first thought
was increasing the priority of the underlying thread of my timer
(Threading.Timer), but I didn't find a way to expose that thread and as
there is no other timer class I'm aware off, I'm a bit stuck here. I know I
could increase the leeway period to several seconds and I'd be sure to get
all the data I want, but that would effectively equal to doubling the
listening time and render my whole transmission scheme 50% less effective
(and require twice as much power... wlan uptime is expensive) and that would
just about break my neck.

Any help in that matter would be very welcome.

Regards
Stephan

 

[Dick Grier]

Hi,

I know no details of your underlying design. However, I'd speculate that
you are dealing with a performance issue in the communications code (having
nothing to do with timers or timing). There are several issues that one
needs to understand.

1. The Pocket PC is orders of magnitude less "performant" (not my choice of
phrase, but on that others use) than the average desktop PC (raw data
handling capability).
2. The network connection to the Pocket PC is much slower than the average
network connection that services desktop to desktop (5 to 20 times slower).
3. Threading on the Compact Framework is a subset of that of the standard
desktop framework. Don't ask it to do too much. Use threading
conservatively.

When I faced what may have been a similar issue in one of my designs, I
re-studied the underlying design of the actual socket communications that I
was implementing. I realized that there was SIGNIFICANT overhead in the
communications structure, and that the Pocket PC was slow to handle
individual packets. Therefore, I changed the design to make sure that the
bandwidth to the Pocket PC was more efficiently used (I forced the average
packet to be much larger; while still allowing short packets to handle short
commands and responses). The result was slightly slower performance on
desktop systems, measurable, but not a problem, while enhancing the
performance for my PPC by a huge amount (about 10X).

My suggestion is that you step back and look at the overall design, and
don't concentrate just on the PPC side.

Dick

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 3rd
Edition ISBN 1-890422-27-4 (391 pages) published February 2002.

 

[Stephan Steiner]

Dick

I have a small app running in the taskbar of my PDA showing the CPU usage.
When I made the intitial port, I quickly found that my packet handling was
inefficient, and I'm still finding ways to improve things. I use a very slow
wireless link (not even using 1mbit/s), and incoming packets are no problem
whatsoever, I have eliminated every bottleneck there, and further processing
is done in a low priority thread (it can take a while but that's perfectly
okay as long as they're eventually processed).
Unlike what I think you're thinking, there's no two way communication... I'm
dealing with bulk data broadcasts... they're sent out once and received by
many devices.
Either way, CPU usage is in the 20 - 30% range at all the time since I
started using threads to delay processing of less important tasks, so there
should be ample resources to run the timer, after all checking a timer once
every second and do a few lines of code is not a very demanding task... I
suppose even my trusty HP48 could do that if I don't ask for much more.
The overall communication protocol is designed to be fault tolerant, and it
can easily handle missing the beginning of a broadcast for whatever reason.
However, if that reason is a timer that does not do its job and the
beginning is always missed, the communication will always perform under par.
As I said, CPU usage is in the normal range so I'm not asking too much of my
PDA.. but the darned timer is just not accurate and gets out of synch. Is it
too much to ask that a timer runs accurately for a couple of minutes without
desynchronizing more than half a second? If the clock on my PDA were to
loose more than half a second for every 3 minutes, I couldn't trust its
clock anymore, but since the clock works just fine.

What are the reasons a timer could get off track? Other applications/threads
using up all the CPU time so there's none left for the timer thread seems to
be the most plausible explanation.. but this doesn't seem to be the problem
as my cpu load is just fine. If you have any other ideas, let me know, but
rest assured that I'm not asking too much of my PDA.

Regards
Stephan