I've had several reports from the JTDX group....as I said due to the new power
level calls it is making. And now I'm running into rigs with 50ms
post_write_delay that are too slow and hitting the timeout and I'm loathe to
change that 50ms as most of those were determined by experimentation and I
can't tell which were and which weren't.
I remember seeing quite a few timeouts on the WSJT-X group....I'm not going to
bother to go find them....they weren't horribly common and now I can see why
they were random....all they needed was some delay and WSJT-X would time out
since most everybody uses the default 1 second polling rate..and therefore the
1 second timeout. I seem to recall some decreasing the polling rate. That's
what I've had to tell the Flex users.
There is no logical reason I can think of to have a 1 second timeout when it is
well known that the underlying hardware has longer timeouts than that.
Nobody is going to even know there's a 3 or 4 second timeout. Not that there
is a difference between hamlib's timeout and WSJT-X's timeout. hamlib will
time out based on the rig settings. WSJT-X does not.
It should be possible for WSJT-X to use the rig's "timeout" value plus maybe
200ms. Note that netrigctl has a 2.5 second timeout.
Then I can change rigctld to also use the rig's timeout if it's large than
rigctld's timeout.
Mike
On Friday, April 24, 2020, 09:39:40 AM CDT, Bill Somerville
<g4...@classdesign.com> wrote:
Mike,
the only reports of Hamlib timeouts I have seen are where the connection is
not set up right, e.g. the wrong COM port, baud rate, or handshaking. Can you
point me to a report of a Hamlib timeout that is not caused by similar
misconfiguration?
73
Bill
G4WJS.
On 24/04/2020 15:29, Black Michael via wsjt-devel wrote:
And please give consideration to lengthening the timeout to 3
seconds....we'll get rid of a lot of complaints about timeouts.
Mike
On Friday, April 24, 2020, 09:27:37 AM CDT, Bill Somerville
<g4...@classdesign.com> wrote:
Hi Mike,
OK, hold off from any Hamlib changes to rig_close for now. I will do some
tests when I get some time and work out if WSJT-X is really calling rig_open
twice on the same RIG handle without an intervening rig_close. I'll get back to
you.
73
Bill
G4WJS.
On 24/04/2020 15:03, Black Michael via wsjt-devel wrote:
I have no idea why it's treated differently....been that way since day#1.
I could add a flag to the RIG structure for "close_is_sync" that a client
could set if it wants a synchronous close.
That way we wouldn't break any other apps not expecting it.
Mike
On Friday, April 24, 2020, 08:49:41 AM CDT, Bill Somerville
<g4...@classdesign.com> wrote:
On 24/04/2020 14:39, Black Michael via wsjt-devel wrote:
rig_close being synchronous won't (shouldn't) matter. The problem is that
hamlib recovers from the timeout but when it's done WSJT-X has already timed
out and shuts down rigctld. And it also looks like WSJT-X starts another
connection before closing the first one which then gives the invalid
configuration error....maybe that's where a synchronous close would work
better....but it looks like the idea there was a client just tells rigctld "I'm
done" and that's a 1-way conversation. If we make it synchronous then the
client has to stay around to take the answer or else we start hitting timeouts
in rigctld. I'm a bit reluctant to make it synchronous as I don't know what
all the client programs are expecting. And if we make it synchronous and
rigctld goes away then the client will be timing out trying to close it.
All timeouts are arbitrary but have to be based on what the hardware can do.
.
Making the timeout = pollrate is arbitrary too. If you made the polling 10ms
everything would time out like crazy.
We've got a lot of rigs that just aren't very fast on CAT and 1 second is too
short.
The timeouts aren't hit very often and nobody will even notice it in WSJT-X
if there's a 3-second timeout that almost never gets triggered. What they do
notice is WSJT-X timing out too quickly. And the more data we ask from the
rigs the more likely we are to hit the 1 second timeout.
Mike
Hi Mike,
if WSJT-X is overlapping rig_open/rig_close calls then it should be doing it on
a separate RIG handle, that should not cause a problem.
I thought the Hamlib API was synchronous, why is the rig_close call being
treated differently, that's very confusing to me.
73
Bill
G4WJS.
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
