Author Topic: Why did our new router start so badly, then improve markedly?  (Read 3123 times)

Gravitino

  • Posts: 34
    • View Profile
Why did our new router start so badly, then improve markedly?
« on: September 17, 2019, 14:49:26 »
Last night we introduced a new, more expensive router. (£44 from Amazon).  We also had a number of new handsets -- all Amazon Fires, bought for £35 each in the recent Bank Holiday offer -- waiting in the wings.

The first third of the evening was terrible, with the scorer being called every minute, literally, to cope with handsets that had lost connection. Even on my own handset I noticed that it was taking a long time to fill the display with content.  But then halfway through, we noticed everything had improved massively, without any grand intervention from the scorer.

We have a practice of activating all our handsets, so that if one needs replacing, we can switch it quickly with a reserve handset. So last night we had 11 handsets working on 11 tables, with a further 20 waiting in the wings.  (Yes, we really do have 31 handsets, which reflects our disillusionment with the Acer Iconias we orginally bought.)  So my first question is this: does the router/computer poll all activated handsets running the BridgePal app, whether or not they are in use at a table?  Could thiitys slow down the performance of the router?

We also have a policy of switching off any failing handset, and putting it on charge, face-down to indicate it is out of use.  So as handsets failed, the total number of activated machines in the room fell.

My other line of enquiry is into channel-hopping by the router, about which I know very little.  This new router is capable of automatically hopping from one channel to another. It seems to default to channel 10, but this morning I tried it when our old router was already switched on to channel 10, and the new router then appeared on channel 2.

I have been back this morning to the Community Centre where we ran the session, and there the council WiFi broadcasts simultaneously on channels 1, 6 and 11. Could it be that initially our router started on one of these council-used channels, and then decided of its own accord after 30 minutes to hop to a less busy channel?

johng

  • Administrator
  • *****
  • Posts: 214
    • View Profile
Re: Why did our new router start so badly, then improve markedly?
« Reply #1 on: September 17, 2019, 17:44:32 »
Hi Gavin,

I can't explain why you should have these problems, or why switching tablets should fix the problem. No, the computer does not poll activated handsets. I don't know whether the router polls the units, but we have successfully run sessions in the past with 26 tables without problems.

When clubs have experienced problems affecting response times for many units it has been because there is some background task running on the PC using system resources, e.g. anti-virus scan, or disk defragmentation.

If you would like to submit the logs for this session I am happy to take a look at them to see if I can shed any light on the problem. There are instructions on how to do this in the forum post at https://mirgo2.co.uk/bridgepal_forum/index.php?topic=5.0

I would need the uploaded BridgePal request logs from at least some of the tablets that were experiencing problems, in addition to the PC logs.



Gravitino

  • Posts: 34
    • View Profile
Re: Why did our new router start so badly, then improve markedly?
« Reply #2 on: September 18, 2019, 09:34:54 »
John

OK, sounds technical, but I'll have a go after our next session, if it goes badly.  Many thanks for the offer. I intend to change the channel our router uses.

Best wishes

Gavin

johng

  • Administrator
  • *****
  • Posts: 214
    • View Profile
Re: Why did our new router start so badly, then improve markedly?
« Reply #3 on: September 18, 2019, 10:40:09 »
Hi Gavin,

It seems that you've been having these problems for some time now. If you don't want to send me the full set of log files would you be prepared to just send me the file C:/nginx/logs/access.log ? I would be able to tell from the profile of response times in access.log whether anything is running in the background on the PC and causing a problem.

John