Additional monitoring servers (help wanted)


#1

Hi server folks,

I’m closer to ready to adding more monitoring systems to the Pool. Depending on how many we have an early iteration would be to just have the system choose the closer 1-3 monitoring servers to monitor your server; later operators could “choose their own” and eventually maybe the computer can help pick in a smarter way.

I’m unconvinced how this will improve the quality of the pool service, but I don’t think it will make it worse and it might increase the available capacity. It definitely should help the frustrating experience of the pool server operators when “random internet noise” makes their server appear not working.

So… Most of the servers around the world I have access to are virtual machines or otherwise not clearly great monitoring servers.

Does any of you have a system that’s either or both of:

  • not virtualized (and/or good at keeping time with ntpd or chronyd).
  • close to or itself a high quality time service (next to a stratum 1 NTP or PTP source)

The monitoring daemon is a small Go program sending maybe a dozen NTP queries per second. It can run on a regular user account.


#2

This is great news! I think it will really help out with some locations keeping them scored in the pool. Or maybe we will discover some more widespread networking issues around the world, who knows… lol

I would think you would also want/ require dual-stack networking?


#3

when you say “close” to a stratum 1 server, how close is “close”… I use one at a university about 73 miles away in Manhattan


#4

It’s more about “reliable and consistent”, so ideally on another system right next to it or across the data center / campus.

The local internet connection should be reliable, have symmetric latency, generally symmetric routing and never be congested.


#5

Also, what Os does the monitoring software use?


#6

Any variant of Linux or FreeBSD should work.


#7

What is your program’s memory footprint? I don’t know if my weak 103.226.213.30 would qualify… Poor Celeron 1Ghz with GPS PPS source and 100M/100M FTTH connection. I won’t mind if I have to reduce its pool bandwidth to 384k to save CPU time for monitoring.


#8

I can offer either/or:

  1. e.g. arm64 dedicated physical node (e.g. Pine64, Rock64, Go compiles just fine) with an industrial SD card
  2. amd64 virtual host which can keep good time, and isn’t on an overloaded physical node (e.g. could live on our own NFV cluster, rather than customer VM pool)

…either in a datacentre in Geneva with 1 hop to leontp.g.faelix.net (stratum-1 LeoNTP of ours); or in an Equinix DC in the UK with peering across to LINX who provide stratum-1 sources.


#9

Re: “unconvinced how this will improve the quality of the pool service” I suspect it won’t improve the pool but will improve the feel-good-factor of us server suppliers as we’ll feel our stats are more meaningful. eg. My server (physical, solely does the NTP thing) north of London, UK, is monitored from across an ocean and a continent so, unsurprisingly, the variation in how its timekeeping is monitored can vary quite a bit for reasons unrelated to either the box or the local connection. The most notable proof of that is the comparison between IPv4 and IPv6, where one box with native connections for each protocol gets much greater variation on the former than the latter.


#10

I’m in Australia. I’m keen to help. My servers at ntp.polyfoam.com.au and ntp.icemoonprison.com in Melbourne frequently fall off the pool because the monitoring from Los Angeles is losing packets (for reasons unknown). Beta monitoring from Zurich produces much better scores, which makes me think that it’s not my servers per se, but the monitoring.

My NTP server at ntp.polyfoam.com.au is a Raspberry Pi with a PPS GPS hat. My network connection is 100 Mbit symmetric, native IPv4 and IPv6 dual stack. If the Pi can run the monitoring software directly then I can start any time. Otherwise I will need to install a physical machine in the server rack, which may take some days.


#11

I should be able to assist.

If I read correctly this will initially be for localised monitoring with the aim for broader monitoring?


#12

Hello,

we 23media.com would like to help you out.
We are located in Frankfurt am Main and have direct peerings to most of the biggest upstreamers also a very good latency.

If you are interested - please write me a PM.