[Dxspider-support] Abusive show/heading commands

[Keith Maton]

Well said, Mike.  I’m glad you’re seeing the same as me where I don’t notice any real bandwidth impact.

However, Elwood has confirmed he’s looking at a couple of options that will reduce bandwidth further.  He’s undecided which way to go right now but as I said yesterday, I’ll keep the list updated.

73 Keith





> On 15 Jan 2024, at 01:57, Michael Walker via Dxspider-support <dxspider-support at tobit.co.uk> wrote:
> 
> I know of at least a dozen ham clock users on my note running on a RPI4 and I can honestly say I don’t see any impact since he made the changes. We asked him to make a year ago.
> 
> It doesn’t take much bandwidth to run a full cluster when you consider we used to do 50 users on a 1200 baud packet radio connection. 
> 
> On my PFsense firewall, I have the DX cluster port throttle to one megabit, and it doesn’t break a sweat even during a contest  
> 
> Call the software piece of shit is very narrow minded.  You have the author who is working with us to do the right thing because he’s responsible.  
> 
> 73
> 
> Mike Va3mw
> 
> 
>> On Jan 14, 2024, at 8:49 PM, du3tw via Dxspider-support <dxspider-support at tobit.co.uk> wrote:
>> 
>> Caching  works
>> 
>> Here is an example of Caching in action … This is taken from my development server - running against my development Dx-Spider cluster (so no one apart from me will be upset).
>> 
>> 
>> Cache now has  1824
>> Cached call  "N5NHJ"  items:  1824  Lookups  10029
>> Cached call  "BY4DX"  items:  1824  Lookups  10030
>> Cached call  "JJ2VLY"  items:  1824  Lookups  10031
>> Cached call  "BY4DX"  items:  1824  Lookups  10032
>> Cached call  "DM6EE"  items:  1824  Lookups  10033
>> Adding to cache  "KC8TQP"
>> Cache now has  1825
>> Cached call  "KM3T"  items:  1825  Lookups  10035
>> Cached call  "NA5G"  items:  1825  Lookups  10036
>> Cached call  "W4KAZ"  items:  1825  Lookups  10037
>> Adding to cache  "N9HAL"
>> Cache now has  1826
>> 
>> The time of the extract was approx 01:42z 15th Jan 2024.
>> 
>> I am using a cache depth of 2,000 (I store the last 2,000 calls)  - every call I lookup I first check is it in the cache - if so I return that (sorry /AM, /MM).
>> 
>> Using DM6EE - this call was found - And so no new record was created.
>> But KC8TQP 0 was not found … and the Logger is informing me - it needed to create a new record.
>> 
>> 
>> Ah - I hear you say - memory problems… And yes you are correct. I am trying to work out which algorithm for Cache reduction works best.
>> 
>> Each Call Sign record, has a field of “last_accessed” - which I am using to clear down the cache.
>> 
>> Overall efficiency :
>> 
>>   10,037 calls - were served by 1825 data members => 82% cache efficiency. This is what most decent Https Server try and achieve.
>> 
>> Sorry for the geek overload…
>> 
>> 
>> 73s de Tim
>>   DV3A
>> 
>> 
>> 
>> 
>>> On 15 Jan 2024, at 07:32, du3tw via Dxspider-support <dxspider-support at tobit.co.uk> wrote:
>>> 
>>> Keith Maton’s suggestion of engaging with the developer is the best idea.
>>> 
>>> I recently have been trying to speed up my own contest logger (homebrewed) and by using a hash/map/dictionary I made a significant speed improvement.
>>> 
>>> I use and parse cry.dat; and generally I am pleased with the results.
>>> 
>>> However if you take a Mexican ham xe1aaa who wants to know where k4aaa is
>>> 
>>> 
>>> Cry can only say Mexico to USA - you have no idea where the k4 is (East central or west)
>>> 
>>> For most other countries there is not such a vast “blob” of area sitting close to their borders.
>>> 
>>> Cache the data - life will be much better
>>> 
>>> My thoughts
>>> 
>>>   73s Tim
>>>    Dv3a
>> 
>> 
>> _______________________________________________
>> Dxspider-support mailing list
>> Dxspider-support at tobit.co.uk
>> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
> 
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at tobit.co.uk
> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support