My phone server accidentally switched off and restart after half a month of online with the same IP 121.202.76.220. After restarting, I found my ip has changed to 49.130.73.113(sorry for the change in IP). Meanwhile, I have found ways to make my ntp server offset smaller, thus could you guys measure my ntp server offset continuously to make sure that my ntp is accurate consistently and send the monitoring graph to me
No. I am not going to monitor your NOT-STATIC-AT-ALL server. If you really want to contribute, acquire a real static IP before you start.
3 Likes
This is only an accident which caused my ip to change, if I can prevent the accident, my ip will remain static, next time I will do better maintenance to prevent phone from restarting due to overloading.
I tried to ask for a static ip by dialing the ISP customer service hotline, the person who serve me said that he doesn’t know things related to static IP, but I still want to contribute to the pool, here is the dilamma
That is not an accident. The power design of most modern smartphones (battery undetachable) prevented them to become a stable platform. When under loading, the battery heats up, and to prevent overheating the smartphone shuts down. Please stop waste your time on trying to run NTP pool service on smartphones: it will not be stable.
You should check if the ISP is providing static IP (free or charged) before registering for its service. Now the installation is complete and you cannot find a way to acquire static IP… I don’t know what can you do now. Maybe cancel the current service in cooling off period and find another one which is known to provide static IP service.
1 Like
Then I use a fan to prevent battery from overheating
People on this forum try to be helpful, but some issues are so fundamental that there is little we can do.
You do not have a static IP address. This makes troubleshooting difficult. A true static address is not changed by equipment reboots, power failures, ISP maintenance, and so forth. Truly static IP addresses requires the support of your ISP. [My ISP charges extra for static IPs]. Your server’s IP address likely changes: when your location experiences power failures, when the device reboots, when the ISP does equipment maintenance or experiences failures.
I previously reported the approximate time error of your server. As far as I can tell the server is still a smartphone. Reference ID=LOCL (local)
Claimed stratum = 1. Actual stratum=???
Claimed error (root dispersion) = 0 Actual error = 20-30 msec (estimated)
I thought you were switching to a MS Windows computer using the NTP distribution packaged by Meinberg.
2 Likes
As stated in my response to one of your previous posts, a phone is not a server. The rules say: For joining the pool “Your computer must have a static IP address and a permanent internet connection.” A phone usually does not provide either of those.
And as per definition in RFC 2119:
MUST - This word, or the terms “REQUIRED” or “SHALL”, mean that the definition is an absolute requirement of the specification.
Further the rules for joining say: “Finally, I must emphasize that joining the pool is a long term commitment. We are happy to take you out of the pool again if your circumstances change, but because of how the ntp clients operate it will take weeks, months or even YEARS before the traffic completely goes away.”
If your phone gets accepted into the pool and the IP is served as a reliable time source to numerous clients, they will likely stick with it. For many clients this means until they are rebooted or power cycled. So they then will ask an IP address which no longer provides them the service it once promised.
The users on the receiving end of the pool rely on the servers being stable and being there for a looong time. The quality of the pool relies on stable and long term committed servers.
But changing IP addresses do not only do harm to the pool, but also to unrelated third parties. Because this IP address will receive ntp requests for a really long time, even when your phone has switched IP addresses multiple times in between. This then might fall back on the ntp pool.
So ntp pool users do not get the service they were once promised, unrelated third parties get unsolicited traffic they do not asked for and the pool will be blamed for it. That’s not a win for our ntp clients, that’s not a win for the third parties and that’s definitely not a win for the pool.
Your zeal and enthusiasm is very welcome, but it would be more favourable to make sure that the right tools are used.
How about using your phone as one of several time sources for a server and than this server - with a real static IP - is added to the pool?
1 Like
I have successfully modified the android configuration file so that the ip will NEVER change and will remain 49.130.73.113
This is real and not a joke
You can power cycle your smartphone NOW to see its results.
1 Like
Because I set ip_dynadr to zero
「CS Chen via NTP Pool Project <ntppool@discoursemail.com>」在 2020年6月9日 週二，下午12:05 寫道：
That would probably be helpful but also a huge undertaking. I’m afraid we’d likely have not the available resources to maintain such a list.
Oh… I wasn’t thinking of maintaining a list, just doing a DNS lookup to one (or more) of the existing lists and not allowing the IP to be added if it appeared to be a dynamic IP. (e.g. dul.dnsbl.sorbs.net will return 127.0.0.10 if it’s on Sorbs’ dynamic IP list)
I’ve no idea how many non-static IPs get added, so it may well be a sledgehammer to crack a nut…!
1 Like
FYI: this list lists two of my IPs as dynamic whereas they are fixed (and “sold” as so) !
So I think it’s a bad idea to deny participation to some volunteers in exchange of blocking a single individual.
My 2¢…
3 Likes
Instead of blocking participation by volunteers in such cases, there could be other ways to deal with it.
- One could introduce a workflow that requires manual intervention by an admin, who would act as a clearing house and then release these servers into the pool.
- One could display a message to the user, pointing out that their IP address has been identified as potentially dynamic and pointing to the static IP address rule. The user then has the option to check the message and confirm that it is indeed a static IP address.
- Leave the process as it is currently implemented and trust the community that has found and handled such individual cases relatively reliably in the past.
I mention again this time my ip will always be static
Given we’re designing a workflow that probably isn’t needed given we don’t know how often people add dynamic IPs and @ask’s ToDo list is so long it probably makes no difference what we design 
as one of the volunteer admins it’s worth commenting on a few points:
Manual workflow: yes, automating and handling exceptions manually is good, but I’d speaking personally I’d prefer block and then handle things manually when raised by the end user This happens reasonably frequently when the Geolocation database puts IPs in the wrong country for various reasons.
User override: sounds good, but given people ignore the “only add your own servers” text either through not understanding it or maliciously, I’d vote no!
Current process: Interested in what you mean by “trust the community that has found and handled such individual cases relatively reliably in the past.”. What has the community done when these have been found in the past? @wilsoncheung0719 's dynamic IPs and phone were left in the pool as far as I know…
1 Like
On 2020-06-09 the server was in error by 600 msec for one hour.
1 Like