John, I will try the sever changes next week... I shot my test system at PI4TUE, and it will not restart, so I have to go there tomorrow... Meanwhile I think I found the error in the client code, and repaired it. I have tested it with some quite big files, on a path with heavy multipath distortion, so it needed lots of repeats. The main problem was that the client generated block numbers outside the scope of the frame and put them into the $Missed variable. Since the change I have not seen that happen again. The sliding window we use is 16 blocks, and the 'missed' blocks should be within that scope. When generating the next frame, the server first sends the missed blocks, and fills the rest of the frame with new blocks, so we are not really missing anything, unless the client generates wrong numbers. But I will try the server changes as soon as I have my test server back... Meanwhile I have put a new server (0.9.20) with some important improvements into the hermes.esrac.ele.tue.tue.nl/pskmail/alpha directory... With that version the server will not get stuck in a deadlock when the client does not respond to connect acks... Today we had some weird conditions on 30, lots of multipath giving the band a 'hollow' sound with even some echo on it.... PSK250 was really struggling, so ideal for testing :) THOR22 always worked... 73, Rein PA0R > -----Ursprüngliche Nachricht----- > Von: "John Douyere" <vk2eta@xxxxxxxxx> > Gesendet: 11.10.09 11:59:29 > An: pskmail@xxxxxxxxxxxxx > Betreff: [pskmail] Re: jpskmail 0.3.8 beta test Rein, > > On the re-send of missing blocks issue, without testing, just by > looking at the server's code, may I suggest the following changes in " > sub handle_rxqueue": > > 1. move the "$cntruns++;" statement in the else part of the test for > good frames. The logic being is that we would stop after having found > 8 missing blocks, not just after checking 8 positions for missing > blocks. The current code is consistent with the behaviour I found: > only the first few missing blocks are requested, not all (or at least > up to 8) of the missing blocks. > > 2. I think we should remove the section below, since it is possible > to have missed 8 blocks, but received the status block OK, or have > accumulated 8 missing blocks. The test in 1 above would in any case > limit the number of missing blocks (there is also a missing string > truncation for that purpose): > > if (length ($MissString) == 8 && $Iamserver) { > $MissString = ""; > $HisLastblock = $Goodblock; > } > > Sorry but I don't have time to test that code. > > Regards, > > john > > On Sun, Oct 11, 2009 at 8:38 PM, Rein Couperus <rein@xxxxxxxxxxxx> > wrote: > I noticed myself yesterday when watching pa0son test with pa0son-4, > I am on it now... > > Rein PA0R > > > -- http://pa0r.blogspirit.com