Scheduled speed tests report much slower speed results than manually triggered once

[BenS89]

Describe the bug
Scheduled speed tests via cron job produce much slower results (Download, Upload, Ping) than manually triggered ones even though the same Server ID is used

To Reproduce
Steps to reproduce the behavior:

1. Check your connection speed within your router, e.g. 600 Mbit/s down and 300 Mbit/s upload
2. Trigger a speedtest manually via web gui with a certain server id —> Download and Upload are nearly 600 Mbit/s and 300 Mbit/s
3. Schedule a cronjob using the Same server id —> job sometimes fail, sometimes much slower download or upload speed
4. Trigger a manual test directly After the cron test —> speed as expected 600/300

Expected behavior
Cron speed tests and manually triggered tests produce the same results

Environment (please complete the following information):

• Latest docker Image via docker

[svenvg93]

What is the schedule you are using? We have seen before that tests run at the hour might give a lower result due to congestion.

https://docs.speedtest-tracker.dev/help/faqs#cron-schedule-from-a-minute-or-hour

[BenS89]

Currently, once per hour 0 * * * * but I also tried cron every 24h on 8 pm for example 0 20 * * *

In both cases ALL scheduled tests were significantly slower (especially ping and upload) than the manually triggered ones directly afterwooods

[svenvg93]

Can you to set it like 6 minutes past the hour. Like said we have seen that test run at 01:00, 02:00 get lower results then test run at 01:06, 02:06 for example. Due to congestion on the network or server.

From the application point of view there is no difference for scheduled or manual tests they are all run in the same way.

[BenS89]

I will try that, thanks for the fast Feedback!

During the day, I tested 08.10 pm as cron, this one was also slower than a manually triggered one on 08.12 pm. But I will give it a try again. Manually triggered ones are nearly identical and completely stable

[alexjustesen]

Going to transfer this to a discussion as this is a pretty common issue for scheduled tests and is a bottleneck in the target speedtest server not the application.

[BenS89]

Thanks a lot - re-scheduling the tests to a less common slot and especially not to full hour did the trick!