Kitz Forum
Broadband Related => Router Monitoring Software => Topic started by: lloyd on July 29, 2015, 06:48:15 PM
-
Since Sunday I've started getting occasional email warnings about duplicate uploads. Nothing has changed at my end - anything changed on the server? I know I can ignore them, but would be nice to know what is causing them.
Thanks
Lloyd (pianist)
-
Check what time you started recording on DSLstats. If it's close to the turn of the minute, pause it and resume recording between 5 and 45 seconds past the minute. I'll be updating DSLstats to do this automatically shortly.
-
This was answered a short while back for someone else with the same query. You are uploading at about 1 second past the minute and sometimes a bit earlier and this causes the error. Eric will fix the problem in DSLstats but for now just stop it for about 10-15 secs then resume so the upload time is a bit later.
Other post is HERE (http://forum.kitz.co.uk/index.php/topic,15049.msg294633.html#msg294633)
-
Thanks both. I'll stop and restart it.
-
I have same issue. Using v5.5.4.
Restarted several times at 5, 10, 20, 30, 40, 50 seconds past the minute, always same problem.
Any other thing I can try?
Thanks.
-
I have same issue. Using v5.5.4.
Restarted several times at 5, 10, 20, 30, 40, 50 seconds past the minute, always same problem.
Any other thing I can try?
Thanks.
Can you start uploading again please and I can track what's happening. When did it start? 20:59 - did you change anything around then, possibly clock on uploader?
-
sorry for the delay Tony.
Just restarted it: "Recording started: 23:38:21".
No mail yet, after 2 minutes. Hope it's working fine now, I won't stop it. :)
-
Alessandro
Well there haven't been any more as you will know. Everything looks normal from this end both on the upload monitor and in the database during the time when you were getting the mails.
Since it suddenly started during the evening, the only possibility I can think of is that something happened on your upload terminal with the stats process but I can't offer an explanation of what that might be other than a second instance started up. Eric may have an idea?
I'll leave the monitor on and if it happens again, it should be possible to deduce what the reason is.
-
Eric may have an idea?
In no particular order, these things occur as possibilities:
1. A bug in DSLstats. Always possible of course, but as this issue only affects a small proportion of users I don't think it very likely. I've pored over the relevant code many times, and it looks robust.
2. An inaccurate PC clock. If the PC is properly synchronised to an internet time source, this can be discounted.
3. A second instance of DSLstats running on a different machine. This wouldn't happen by accident, so I think we can discount it.
4. Inconsistency in the time taken to collect samples. If the PC is connected by WiFi I would rate this as the highest possibility. But it's still possible with a wired connection, depending on the modem and the PC and how heavily loaded they are.
-
Thanks Eric. Looking at the logs etc, the upload times are very consistent and there was no sign of the clock being adrift in the database while the problem was occurring. He's an hour ahead of us so the logged upload time on the server is -1 hour on his log file time. But that is very consistent to the second.
The second instance was the obvious reason but I have no evidence of that - however, I'll look in the Apache server logs later this morning and see if they show something which they should do if it is a rogue or whatever second instance.
Edit:
I've had a look through the server logs and can't see anything that would explain it. There is only ever one instance running!
The only other thing I can think of is that the server failed to cancel the database flag it uses to say whether it is a real duplicate or not after detecting one at some point. There is nothing though to show that in the database log. If that was the case, stopping the uploads for 4-5 mins and restarting should cure it. You might try that if it happens again please.
-
Eric may have an idea?
In no particular order, these things occur as possibilities:
1. A bug in DSLstats. Always possible of course, but as this issue only affects a small proportion of users I don't think it very likely. I've pored over the relevant code many times, and it looks robust.
2. An inaccurate PC clock. If the PC is properly synchronised to an internet time source, this can be discounted.
3. A second instance of DSLstats running on a different machine. This wouldn't happen by accident, so I think we can discount it.
4. Inconsistency in the time taken to collect samples. If the PC is connected by WiFi I would rate this as the highest possibility. But it's still possible with a wired connection, depending on the modem and the PC and how heavily loaded they are.
2. It's my linux server (a NAS), synchronised via NTP to an internet public time server. It also serves as NTP server for devices in my home. So this can be excluded, also because time was consistent while I was testing to solve the issue.
3. There was only one instance running, always, I can assure you because I was doing tests manually. This started happening when I rebooted the NAS.
I would opt for option 1, maybe a subtle bug that is difficult to catch, but since I don't know the logic behind the upload timings I cannot give any advice.
Thanks a lot for your help, and let me know if you want me to test something. Right now, after the last restart I had no duplicate upload issues.
-
FWIW, I had the same issue - the emails started arriving in the early hours of Saturday 1/8/15. I had occasion to reboot my PC after doing some updates, and they stopped after that.
Definitely only had one instance of DSLstats running.
-
FWIW, I had the same issue - the emails started arriving in the early hours of Saturday 1/8/15. I had occasion to reboot my PC after doing some updates, and they stopped after that.
Definitely only had one instance of DSLstats running.
In your case it was likely due to your clock running a little slow and being close to the minute change. Your reboot put the clock 8 secs fast which is fine.
Accurate clock time is important with MDWS and always has been and can cause all sorts of problems. With MS, you can fiddle with the Windows Registry and set the sync time to every 15mins if you want (the default is or was about 12 days by which time some clocks will be in the next day!) or use a tiny free utility as I do in the UK which is NetTime (http://www.timesynctool.com/). Set that to sync every 15 mins. You might want to change the first two server entries as in the screen grab if you are in the UK.
I believe Eric is going to force DSLstats to upload outside the 'danger' zone to help with this :)
-
Same issue myself yesterday - checked the time sync on my RPI, and rebooted stopped afterwards.
-
I believe Eric is going to force DSLstats to upload outside the 'danger' zone to help with this :)
Yes I am, but of course it will still depend on the accuracy of the PC's clock.
-
Well, it's simple enough to reset the clock, which will be my first move if it should happen again. Annoyingly, although you can tell Windows 8 to synchronise the clock with a time server, but you can't adjust the schedule, so you have to rely on the OS. I wonder if that will change with Windows 10?
-
Well, it's simple enough to reset the clock, which will be my first move if it should happen again. Annoyingly, although you can tell Windows 8 to synchronise the clock with a time server, but you can't adjust the schedule, so you have to rely on the OS. I wonder if that will change with Windows 10?
Yes you can if you dive into the Registry - mine's set to 15 mins rather than 7 days ( :-X ) default. This is from an update to the Help system but not online yet (& it's for newbies ;) ). Usual caution applies:
Press the Windows logo key and R. This will open the Run dialog. Then type regedit and click OK.
Alternatively, open the Start Menu and type "regedit" in the search box. Click the regedit program entry to open
Navigate to HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\W32Time\TimeProviders\NtpClient. Just click the arrows next to the folder icons to navigate to the correct directories. You may have to scroll a bit when you reach the SYSTEM key
Right click on the SpecialPollInterval key, then click Modify.
Click Decimal. Then, enter 900 (seconds) and click OK. This will set the interval to 15 mins which is the smallest Windows will allow.
Close regedit.
-
Thanks - I'm comfortable enough using regedit, just set it to 3600 as I think once an hour's enough. ;D
-
I can now confirm that this setting survived the upgrade to Win 10. :)
-
FWIW, I had the same issue - the emails started arriving in the early hours of Saturday 1/8/15. I had occasion to reboot my PC after doing some updates, and they stopped after that.
Definitely only had one instance of DSLstats running.
... use a tiny free utility as I do in the UK which is NetTime (http://www.timesynctool.com/). ...
Thanks for the heads-up on NetTime, just what I needed.
-
Same issue myself yesterday - checked the time sync on my RPI, and rebooted stopped afterwards.
It's a pity the RPi does not have a CMOS battery for time yet it will pick up the time sync over the net, you can use this command sudo dpkg-reconfigure tzdata to get it to pick up the correct time.