Qso counter bug?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Qso counter bug?

SP3RXO
Hi,
 Something strange with qso counter.
Story:
I made qso e.g. on 40m band and logged it. Then changing band e.g for
20m and next I wish to delete last qso. QSO is deleted but logger
deducting it from 20m band instead of 40m. If previous qsos on 20m band
was = 0 after deducting -1 is showed and have to use rescore to get
correct  qso counter.
--
73!
Slav, SP3RXO & EI2IDB
FISTS #19019

0xD1A3320970F8F900.asc (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Qso counter bug?

Thomas Beierlein-4
That is normal behavior. Deleting a QSO needs a complete
re-score/reread of the log file to get QSO counter (and also some multi
and point statistics) right.

Doing the complete reread every time you delete a QSO may take a long
time if you have some thousand QSO already logged.

73, de Tom DL1JBE

 Am Tue, 5 Nov 2019 21:08:10 +0000 schrieb
SP3RXO <[hidden email]>:

> Hi,
>  Something strange with qso counter.
> Story:
> I made qso e.g. on 40m band and logged it. Then changing band e.g for
> 20m and next I wish to delete last qso. QSO is deleted but logger
> deducting it from 20m band instead of 40m. If previous qsos on 20m
> band was = 0 after deducting -1 is showed and have to use rescore to
> get correct  qso counter.



--
"Do what is needful!"
Ursula LeGuin: Earthsea
--


Reply | Threaded
Open this post in threaded view
|

Re: Qso counter bug?

Csahok Zoltan
There are in fact two bugs:
- QSO counts per band are not shown when opening a non-empty log
    (it was OK before)
- QSO count of the current band is decremented instead of the count
  of the actually removed one
    (it's an old runner)

Probably both can be "fixed" with re-scoring, but I think it's better
if we do the right thing in the first place.
Will write issues.

73,
Zoli

On Wed, Nov 06, 2019 at 07:38:25AM +0100, Thomas Beierlein wrote:

> That is normal behavior. Deleting a QSO needs a complete
> re-score/reread of the log file to get QSO counter (and also some multi
> and point statistics) right.
>
> Doing the complete reread every time you delete a QSO may take a long
> time if you have some thousand QSO already logged.
>
> 73, de Tom DL1JBE
>
>  Am Tue, 5 Nov 2019 21:08:10 +0000 schrieb
> SP3RXO <[hidden email]>:
>
> > Hi,
> >  Something strange with qso counter.
> > Story:
> > I made qso e.g. on 40m band and logged it. Then changing band e.g for
> > 20m and next I wish to delete last qso. QSO is deleted but logger
> > deducting it from 20m band instead of 40m. If previous qsos on 20m
> > band was = 0 after deducting -1 is showed and have to use rescore to
> > get correct  qso counter.
>
>
>
> --
> "Do what is needful!"
> Ursula LeGuin: Earthsea
> --
>

Reply | Threaded
Open this post in threaded view
|

Re: Qso counter bug?

Thomas Beierlein-4
In reply to this post by Thomas Beierlein-4
Rereading the problem and my own answer it seems I got it total wrong.
Sorry for that (Lessons learned: DO not answer mails if you are not
fully awake).

Zoli is right, there are two bugs to fix which should be done before
release of 1.4.0 version.

Anyway we should test how much time a automatic rescore after delete
takes and if we can use that now, given the actual speed of modern
computers.

73, de Tom


Am Wed, 6 Nov 2019 07:38:25 +0100 schrieb Thomas Beierlein
<[hidden email]>:

> That is normal behavior. Deleting a QSO needs a complete
> re-score/reread of the log file to get QSO counter (and also some
> multi and point statistics) right.
>
> Doing the complete reread every time you delete a QSO may take a long
> time if you have some thousand QSO already logged.
>
> 73, de Tom DL1JBE
>
>  Am Tue, 5 Nov 2019 21:08:10 +0000 schrieb
> SP3RXO <[hidden email]>:
>
> > Hi,
> >  Something strange with qso counter.
> > Story:
> > I made qso e.g. on 40m band and logged it. Then changing band e.g
> > for 20m and next I wish to delete last qso. QSO is deleted but
> > logger deducting it from 20m band instead of 40m. If previous qsos
> > on 20m band was = 0 after deducting -1 is showed and have to use
> > rescore to get correct  qso counter.  
>
>
>



--
"Do what is needful!"
Ursula LeGuin: Earthsea
--


Reply | Threaded
Open this post in threaded view
|

Re: Qso counter bug?

Csahok Zoltan
Hi Tom,

Made a quick test with the slowest machine that I use, a Pentium M 1.7GHz.
Execution of readcalls() took about 150 ms per 1k QSOs (data are below).
The code scales mostly linearly except dupe checking that is using
a slow linear search. Latter makes it O(N^2) but its contribution
is quite small: for 5k removing dupe checking reduced execution time to ~600 ms only.
Probably not worth changing it to a hash lookup at the moment.
Most of the time (~2/3) is spent figuring out DXCC info in getctydata().

Considering that typical Q counts are around or less than 1k we can conclude
that re-reading takes ~100 ms or less. Such a delay is completely bearable
for a deletion or other operations (e.g. log editing).

One thing I noticed is that upper bounds of various arrays are not checked,
the program crashes simply with segfault. It's prio3 but should be addressed later.

73,
Zoli

#
# Intel(R) Pentium(R) M processor 1.70GHz
#
# Q  ms
5000 740
4000 580
3000 410
2000 280
1000 130
800 110
500 70
300 45


On Thu, Nov 07, 2019 at 07:54:32AM +0100, Thomas Beierlein wrote:
> Rereading the problem and my own answer it seems I got it total wrong.
> Sorry for that (Lessons learned: DO not answer mails if you are not
> fully awake).
>
> Zoli is right, there are two bugs to fix which should be done before
> release of 1.4.0 version.

>
> Anyway we should test how much time a automatic rescore after delete
> takes and if we can use that now, given the actual speed of modern
> computers.
>
> 73, de Tom
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Qso counter bug?

Thomas Beierlein-4
Hi Zoli,

thanks for the test results.

Am Thu, 7 Nov 2019 19:03:14 +0100
schrieb Csahok Zoltan <[hidden email]>:

> Hi Tom,
>
> Made a quick test with the slowest machine that I use, a Pentium M
> 1.7GHz. Execution of readcalls() took about 150 ms per 1k QSOs (data
> are below). The code scales mostly linearly except dupe checking that
> is using a slow linear search. Latter makes it O(N^2) but its
> contribution is quite small: for 5k removing dupe checking reduced
> execution time to ~600 ms only. Probably not worth changing it to a
> hash lookup at the moment. Most of the time (~2/3) is spent figuring
> out DXCC info in getctydata().

Ok. That means we can just 'rescore' after each deleted QSO. That
would be good as we can correct the wrong counts of QSO per band
but have no chance to make any changes to multis or similar undone.
That will always need a complete rescore as long as we stay with the
actual data implementation.

> Considering that typical Q counts are around or less than 1k we can
> conclude that re-reading takes ~100 ms or less. Such a delay is
> completely bearable for a deletion or other operations (e.g. log
> editing).
>
Yes. But I think we should delay the switch to always rescoring
after delete to the next TLF revision to get some room for tests. At the
moment I suggest that we just fix the wrong startup counts and make a
note in the ToDo file.
I am sure there will be some more problems with 1.4.0 and we will need
a bugfix version 1.4.1 in next weeks anyway.


> One thing I noticed is that upper bounds of various arrays are not
> checked, the program crashes simply with segfault. It's prio3 but
> should be addressed later.

I tried to move the critical arrays to GLIBs growing array in last
years but it seems there are some missing. Do you have an idea which
ones were the problem?

73, de Tom DL1JBE

> 73,
> Zoli
>
> #
> # Intel(R) Pentium(R) M processor 1.70GHz
> #
> # Q  ms
> 5000 740
> 4000 580
> 3000 410
> 2000 280
> 1000 130
> 800 110
> 500 70
> 300 45
>
>
> On Thu, Nov 07, 2019 at 07:54:32AM +0100, Thomas Beierlein wrote:
> > Rereading the problem and my own answer it seems I got it total
> > wrong. Sorry for that (Lessons learned: DO not answer mails if you
> > are not fully awake).
> >
> > Zoli is right, there are two bugs to fix which should be done before
> > release of 1.4.0 version.  
>
> >
> > Anyway we should test how much time a automatic rescore after delete
> > takes and if we can use that now, given the actual speed of modern
> > computers.
> >
> > 73, de Tom
> >
> >  



--
"Do what is needful!"
Ursula LeGuin: Earthsea
--


Reply | Threaded
Open this post in threaded view
|

Re: Qso counter bug?

Thomas Beierlein-4
Hi all,

I just pushed two commits to fix the problems mentioned in issue #138
on github.

Please test and report back. If the problems are solved I will release
TLf-1.4.0 with that fixes.

73, de Tom


Am Thu, 7 Nov 2019 20:05:39 +0100
schrieb Thomas Beierlein <[hidden email]>:

> Hi Zoli,
>
> thanks for the test results.
>
> Am Thu, 7 Nov 2019 19:03:14 +0100
> schrieb Csahok Zoltan <[hidden email]>:
> > Hi Tom,
> >
> > Made a quick test with the slowest machine that I use, a Pentium M
> > 1.7GHz. Execution of readcalls() took about 150 ms per 1k QSOs (data
> > are below). The code scales mostly linearly except dupe checking
> > that is using a slow linear search. Latter makes it O(N^2) but its
> > contribution is quite small: for 5k removing dupe checking reduced
> > execution time to ~600 ms only. Probably not worth changing it to a
> > hash lookup at the moment. Most of the time (~2/3) is spent figuring
> > out DXCC info in getctydata().  
>
> Ok. That means we can just 'rescore' after each deleted QSO. That
> would be good as we can correct the wrong counts of QSO per band
> but have no chance to make any changes to multis or similar undone.
> That will always need a complete rescore as long as we stay with the
> actual data implementation.
>
> > Considering that typical Q counts are around or less than 1k we can
> > conclude that re-reading takes ~100 ms or less. Such a delay is
> > completely bearable for a deletion or other operations (e.g. log
> > editing).
> >  
> Yes. But I think we should delay the switch to always rescoring
> after delete to the next TLF revision to get some room for tests. At
> the moment I suggest that we just fix the wrong startup counts and
> make a note in the ToDo file.
> I am sure there will be some more problems with 1.4.0 and we will need
> a bugfix version 1.4.1 in next weeks anyway.
>
>
> > One thing I noticed is that upper bounds of various arrays are not
> > checked, the program crashes simply with segfault. It's prio3 but
> > should be addressed later.  
>
> I tried to move the critical arrays to GLIBs growing array in last
> years but it seems there are some missing. Do you have an idea which
> ones were the problem?
>
> 73, de Tom DL1JBE
>
> > 73,
> > Zoli
> >
> > #
> > # Intel(R) Pentium(R) M processor 1.70GHz
> > #
> > # Q  ms
> > 5000 740
> > 4000 580
> > 3000 410
> > 2000 280
> > 1000 130
> > 800 110
> > 500 70
> > 300 45
> >
> >
> > On Thu, Nov 07, 2019 at 07:54:32AM +0100, Thomas Beierlein wrote:  
> > > Rereading the problem and my own answer it seems I got it total
> > > wrong. Sorry for that (Lessons learned: DO not answer mails if you
> > > are not fully awake).
> > >
> > > Zoli is right, there are two bugs to fix which should be done
> > > before release of 1.4.0 version.    
> >  
> > >
> > > Anyway we should test how much time a automatic rescore after
> > > delete takes and if we can use that now, given the actual speed
> > > of modern computers.
> > >
> > > 73, de Tom
> > >
> > >    
>
>
>



--
"Do what is needful!"
Ursula LeGuin: Earthsea
--