I have been struggling with Spectrum Internet, formerly Time Warner now for around 9 years. There were simply no other alternatives, and I check about every so often for other providers, never getting anywhere. Also, my goals are to reduce spend and improve both speed and reliability since I am still partly a remote worker and, well, Netflix. So basically, that rules out Starlink right out the gate from the cost angle.
But back to the motivation for this little home project. I've had building cabling issues that are partly out of my control, numerous arguments about my own (I now have two) vs company provided cable modems, upwards of 8 service visits to remediate the cable problem all to no avail. Well, AT&T came out with 5G+ service (as did T Mobile and a few other providers) recently and I decided to give that a trial run. I cooked up a Python script that uses the speedtest-cli on my Ubuntu development machine in my home office and am letting it collect logs for a couple weeks both on the new access device and the old one for comparision.
This repo is to house that code and to serve as a reference for a future blog post.
- Install the
speedtest-cli
package:
sudo apt update
sudo apt install python3-pip
pip install speedtest-cli
- See the speedtest.py file in the repo
chmod +x speedtest.py
To set up a cron job that runs this script every 30 minutes, follow these steps:
-
Open the crontab editor:
crontab -e
-
Add the following line to the crontab file:
*/30 * * * * /usr/bin/python3 /path/to/the/script/speedtest.py
Replace /path/to/the/script/
with the actual path where you saved the script.
- The log file is saved at
/path/to/the/script/log/wifi_speed.log
. You might need to adjust the path depending on the permissions or preferences. - Ensure that the script path is correct in the crontab entry.
- You can check the log file with
cat /path/to/the/script/log/wifi_speed.log
or one of the report scripts in the repo. - This script will now run every 30 minutes, measuring and logging the WiFi connection speeds on the Ubuntu machine.
- The log file indicates that the script is successfully logging the speed test results but occasionally encounters an error when trying to connect to servers to test latency.
- Modify the script to handle intermittent connectivity issues more gracefully. For example, you can retry the speed test after a short delay if it fails initially.
- Retry Mechanism: The script now attempts the speed test up to 3 times with a 10-second delay between attempts if an error occurs. This can help mitigate temporary connectivity issues.
- Break After Success: The loop will break after a successful speed test, preventing unnecessary retries.
- Final Error Log: If the script still fails after the maximum retries, it logs the error and stops.
- Continue to monitor the log file (
wifi_speed.log
) to see if this retry mechanism reduces the occurrence of errors. - The goal is to have more successful test results logged.
- If errors persist frequently, it might be worth investigating the stability of the network connection.
- Regularly encountering "Unable to connect to servers" might indicate an issue with the local network or ISP.
- If the connection is sometimes slow to establish, consider increasing the timeout for the speed test command by adjusting the command used in
subprocess.run()
to include the--timeout
option (e.g.,--timeout=30
).
- If the cron job isn't running as expected, here are some steps to troubleshoot and resolve the issue:
Ensure that the cron job is correctly entered in the crontab. You should have something like this:
*/30 * * * * /usr/bin/python3 /path/to/the/script/speedtest.py
Common mistakes include:
- Incorrect path to the Python interpreter (
/usr/bin/python3
). - Incorrect path to the script (
/path/to/the/script/speedtest.py
). - Missing shebang (
#!/usr/bin/env python3
) at the top of the script (although this is optional if you specify the Python interpreter in the cron job).
Make sure the script has the appropriate executable permissions:
chmod +x /path/to/the/script/speedtest.py
You can check the system logs to see if the cron job is being executed or if it’s running into any errors. View the cron log with:
grep CRON /var/log/syslog
Look for entries that correspond to the cron job. If there’s an issue, the logs might give you a clue.
Redirect errors from the cron job to a log file for easier debugging. Modify the crontab entry like this:
*/30 * * * * /usr/bin/python3 /path/to/the/script/speedtest.py >> /path/to/the/script/cron.log 2>&1
This will redirect both standard output and errors to cron.log
, where you can check for issues.
Cron jobs run in a very minimal environment. If the script depends on certain environment variables (like PATH
), they might not be set correctly in the cron job environment. You can specify the full path to any commands you’re running, or manually set environment variables in the crontab file.
You can add something like this at the top of the crontab to set the PATH
:
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
Run the script manually from the command line using the exact command in the cron job to ensure it works:
/usr/bin/python3 /path/to/the/script/speedtest.py
If it works manually but not in cron, the issue is likely related to environment variables, permissions, or path settings.
If you made changes to the crontab or installed new cron jobs, you might need to restart the cron service:
sudo service cron restart
Ensure the cron daemon is running. You can check its status with:
sudo service cron status