[Fwd: Re: rigctld performance enhancement]
Nate Bargmann <n0nb <at> n0nb.us>
2011-10-12 17:26:52 GMT
Looks like I was the only one to receive this.
----- Forwarded message from Dave <dave <at> g8kbv.demon.co.uk> -----
Date: Tue, 11 Oct 2011 17:11:20 +0100
From: Dave <dave <at> g8kbv.demon.co.uk>
To: Nate Bargmann <n0nb <at> n0nb.us>
Subject: Re: [Hamlib-developer] rigctld performance enhancement
X-mailer: Pegasus Mail for Windows (4.61)
> * On 2011 10 Oct 20:04 -0500, Charles Suprin wrote:
> > Nate,
> >
> > The caching idea would complicate matters for tracking a satellite station.
> > Some folks want update rates on the order of twenty hertz. That requires a
> > query response change and response to execute quickly and accurately.
>
> I'm not looking to slow the actual response rate. We can't get a query
> faster than the rig's output. In many cases that is 4800 bps!
> Fortunately, newer rigs support faster rates. Also, I'm talking
> srtictly about rigctld, not the library.
>
> > It sounds as though there needs to be a mutex on commands.going out the
> > serial port. It also may suggest a problem with the driver you are using.
>
> That is part of a two-pronged approach I was thinking of--blocking a
> request from another socket while a rig command is in progress and also
> having a cache so the second socket could return *something* even if
> slightly aged.
>
> As rigctld does use pthreads when available, perhaps using a mutex is
> the easiest. Presumably programs won't make a query until a reply is
> received or some timeout value expires. Perhaps this would render a
> cache unecessary?
>
> > I should dig further.
>
> That would be helpful. I am using the K3/Kenwood backend. Tests with
> other backends would be helpful.
>
> 73, de Nate >>
>
Hi Group.
As a developer of instrumentation software (winders based) where often
more then one process needs to monitor and control a "measuring
instrument", I've never had long term success, without some from of
"device proxy" between the app's and the "real" instrument.
That proxy, should be the only process that communicates direct with the
device itself, as most instruments (and all Ham rigs I've meddled with)
are single thread/single user type souls. It (the Proxy) should remember
commands sent, and queries received, so as to minimise the traffic to the
device/radio, while giving the app's the quick response they might want.
Start throwing multiple commands at them, and also asking for status,
often out of sync, only leads to "trouble", to say the least. Having
higher speed remote control links, only makes things worse, for the
radio.
If you do *Realy* need 20Hz update rates (and heaven knows, I can't think
why, even for LEO satellite working, they don't move that fast accross
the sky) Then you need a dedicated radio (SDR?) for the job. Even the
pro's don't use that fast an update rate, except perhaps for tracking
incoming munitions!
73.
Dave G0WBX.
----- End forwarded message -----
--
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Ham radio, Linux, bikes, and more: http://www.n0nb.us
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
RSS Feed