[pskmail] Re: Pskmail TX lock-up with 3.13AE (in fact since 3.10)

  • From: Rein Couperus <rein@xxxxxxxxxxxx>
  • To: fldigi-alpha@xxxxxxxxxxxxxxxx, John Douyere <vk2eta@xxxxxxxxx>
  • Date: Tue, 08 Sep 2009 09:37:30 +0200

Hi all,

actually fldigi sends a 0x06 at the end of each transmission, which is 
recognized by the modem driver.

When msgsnd writes the message to fldigi (BTW, the server still uses the POSIX 
SYS V queue) a flag is set 
in the .pskmail directory. On receipt of the 0x06 this flag (.tx.lck) is 
removed.
So in principle the exchange with fldigi is mutex based.

I think 2 things should happen:
* check what is the reason why fldigi stops the queue, this should not happen
* check if the mutex handling works as required, pskmail should wait before 
sending the next frame.

I will take a look at the second one. As I am only using PSK250 it has not 
happened on PI4TUE.

73,

Rein PA0R

(follow 'pskmail' on twitter...)

> -----Ursprüngliche Nachricht-----
> Von: "John Douyere" <vk2eta@xxxxxxxxx>
> Gesendet: 08.09.09 02:22:28
> An: fldigi-alpha@xxxxxxxxxxxxxxxx
> Betreff: Pskmail TX lock-up with 3.13AE (in fact since 3.10)

Hi All,
> 
> First let me say that the new feature of background RSID is a great 
> addition for the ARQ scene as it allows to connect in (more or less) 
> any mode depending on the conditions. More on the tests below.
> 
> But for the lockup issue: I have done more tests to identify the 
> issue I highlighted some months ago where Fldigi would lockup and 
> stop transmitting at connect or seemingly at random while used with 
> the Server of PSKmail.
> 
> The problem (very repeatable now that I know what to look for) occurs 
> when Fldigi is currently sending a frame and another frame is being 
> submitted by the server before the end of the transmission. 
> 
> This also explains why lockups would be far more common on slow(er) 
> modes like THOR22, uncommon with PSK125 and rare with PSK250 since 
> the chances of frames overlaps is greater as the transmission time 
> extends.
> 
> It also explains why the server would stop responding at seemingly 
> random times. In fact this occurs when there is a timeout condition 
> in the server and a poll frame is sent to Fldigi while a normal 
> status frame is being currently transmitted.
> 
> I believe has been experienced by other PSKMail server operators too (
> in particular VK2ZSZ with whom I did a number of tests).
> 
> Restarting Fldigi clears the issue until another frame overlap occurs.
> Restarting the server only does not resolve the problem.
> 
> This issue appeared at the transition between Fldigi 3.03 to 3.10. In 
> other words, version 3.03 does not exhibit this issue. Please note 
> that this occurs with pre-compiled binaries as well as when 
> recompiling from source.
> 
> Current operating environment: Ubuntu 8.04 (up to date), PSKMail 
> server 0.9.1 (but issue present on older versions too), Fldigi 13AE (
> compiled from source).
> 
> Correcting this problem in the server by adding delays partially 
> solve the problem but it is still unreliable since the server has no 
> knowledge of the transmission status of Fldigi. Therefore the 
> effective behaviour is for Fldigi to queue the frames for transmission.
> 
> 
> Just for information, slower more robust modes are essential as our 
> tests have demonstrated here in VK: large distances, land mobile 
> operations (and therefore compromise antennas and constantly changing 
> earth and orientation of the car means significant and rapid QSB).
> 
> We have had great success with the THOR and MFSK modes on 40 and 80M 
> while mobile, but this issue issue is really a show stopper.
> 
> Please let me know how I can help more. My knowledge would probably 
> extend to setting up a debugging environment and tracing the code in 
> Fldigi. 
> 
> So far I have traced the Perl code on the server side and I can 
> confirm that the frames are being sent to fldigi via the msgsnd 
> function but Fldigi does not respond to what is being received. If 
> required I could setup a small Perl script to emulate the issue.
> 
> Now back on the background RSID: I have successfully tried that new 
> option with the PSKMail server. This allows us to scan different 
> frequencies independently of the mode used for the exchange. 
> Brilliant.
> 
> The only small issue is that even if the option "only provide 
> notification" in the RSID tab is unticked, I still get a notification 
> pop-up window which is redundant since the change of mode and 
> frequency adjustment has already occurred.
> 
> Please keep up the great work.
> 
> Thanks and regards, John (VK2ETA)
> 
> _______________________________________________ fldigi-alpha mailing 
> list fldigi-alpha@xxxxxxxxxxxxxxxx https://lists.berlios.de/mailman/
> 
> listinfo/fldigi-alpha

-- 
http://pa0r.blogspirit.com

Other related posts: