Ntpd / gps need some love part II

pete

Thank-you robi!

Updated PFSense today to 2.1.4 along with adding the NTP stuff.

Works great. Still building box #2.

Dagorlad

It's for a GPS with a uBlox chipset; I mentioned it in my first post about GPS bugs here:
https://forum.pfsense.org/index.php?topic=67189.msg367460#msg367460 I believe JimP later posted that it was added because it was funded by a customer. IMHO it should not be there by default

Yes, apparently a uBlox. And a poor command set at that, probably found on some webpage somewhere. But somebody did pay some cash to have it added to pfSense, which then became the basis to further develop it into something that became far more useful to many others. That is the reason it is the "default", with the caveat that it is not recommended. Far from ideal, but unless the person who originally payed for the feature expresses that the newer uBlox config is just as good or better, the original should remain.

BTW charliem, nice find on the rrd graphs, I never had enough time to time figure out why the DB didn't survive a reboot. :(

@pete: I run off a 16GB SLC CF card, using the standard version but with all the options to run as much as possible in RAM set. It's plenty big enough, but I don't run anything like Squid.

tache

To get the patch to work in 2.1.5, I had to edit one services_ntpd.php hunk in Robi's 2.1.3 patch with change according to the commit:

https://github.com/pfsense/pfsense/commit/88c24958a9625d2daa55adb2bb685c70ec9d6eba

fragged

Don't know if this has been mentioned, but the NTP RRD graphs should scale from negative to positive as offset can have a negative value. Now it's clipped off as the graph is shown from 0 up.

robi

@tache:

To get the patch to work in 2.1.5, I had to edit one services_ntpd.php hunk in Robi's 2.1.3 patch with change according to the commit:

https://github.com/pfsense/pfsense/commit/88c24958a9625d2daa55adb2bb685c70ec9d6eba

Yes indeed. Please find attached the patch.

ntpd_love_patch_215.txt

robi

Now that 2.2-RELEASE is out, which includes all this, a quick note with good news for the people who had to tweak serial ports on their motherboard.

fragged

To make ntp rrd graphs look nicer I did some changes on my system to allow full scaling from negative to positive values and I made the graph scale a bit nicer (in my opinion).

Modify rrd.inc to allow negative values. I'm not sure if all of these can actually go to negative, but this was a lazy initial edit. I'm sure none of the values should ever get anywhere close to 1000 though.


$rrdcreate .= "DS:offset:GAUGE:$ntpdvalid:-1000:1000 ";
$rrdcreate .= "DS:sjit:GAUGE:$ntpdvalid:-1000:1000 ";
$rrdcreate .= "DS:cjit:GAUGE:$ntpdvalid:-1000:1000 ";
$rrdcreate .= "DS:wander:GAUGE:$ntpdvalid:-1000:1000 ";
$rrdcreate .= "DS:freq:GAUGE:$ntpdvalid:-1000:1000 ";
$rrdcreate .= "DS:disp:GAUGE:$ntpdvalid:-1000:1000 ";

Modify the status_rrd_graph_img.php file to scale things better for the actual graph. Another part to touch in this file would be the COMMENT/GPRINT part for ntp graph to tweak the number of decimals etc.


$graphcmd .= "--alt-autoscale ";
$graphcmd .= "--alt-y-grid ";
$graphcmd .= "--units-exponent 0 ";
$graphcmd .= "--rigid ";

I've never touched any of the pfSense code before and I don't have a github account nor have I signed the CLA. I would very much appreciate it if someone could take a look at this, make the actual changes needed and post a pull request.

ntprrd_modified.PNG_thumb

charliem

@fragged:

To make ntp rrd graphs look nicer I did some changes on my system to allow full scaling from negative to positive values and I made the graph scale a bit nicer (in my opinion).

Can you post a diff? Would be easier for others to test.

Modify rrd.inc to allow negative values. I'm not sure if all of these can actually go to negative, but this was a lazy initial edit. I'm sure none of the values should ever get anywhere close to 1000 though.

As far as I know, only offset and frequency could have possible negative values. Jitter and wander are calculated as RMS averages and so should always be positive. Dispersion is related to delay and latency measurements, both of which should be positive (unless you live in a Tardis …)

stephenw10

Plotting negative offset seems like a good idea. What does it show now if it can't go negative? Worst case it shows zero offset unrealistically.

Steve

fragged

Negative values are clipped off completely resulting in gaps in the graph.

robi

@charliem:

As far as I know, only offset and frequency could have possible negative values. Jitter and wander are calculated as RMS averages and so should always be positive. Dispersion is related to delay and latency measurements, both of which should be positive (unless you live in a Tardis …)

I'd say it's still good if the graphs themselves could plot negative values, because that could potentially show if there are some problems with ntpd.

I plan to test next week and post a diff too.