Jittery stepper pulses with mesa 7i76E [SOLVED]

The hal/ini files look OK except I would use a larger DPLL pre-sample time, perhaps 100 usec
plotting the same variables I plotted will help diagnose the issue:

joint.0.vel-cmd
hm2_7i76e.0.dpll.phase-error-us
joint.0.f-error
 

@PCW Brilliant! Big thanks :-)That's got me going with halscope, and the change to the DPLL pre-sample time has made the movements perfectly smooth
I've had a fail with a screen dump, so I've attached halscope data files with before and after traces, I hope that is ok. If not I'll try harder. Anyway, hopefully you will see the hideous following error initially. Significantly reduced after the change. There is a pretty large DPLL error, which I assume means that I need to try for a bit better latency.
I've repeated my histogram, with the parameters as suggested by @tommylight (many thanks) and these reveal more latency than gets shown with no parameters - I'll attach. Also for completeness, @tommylight, the moves were still rough with MDI/gcode moves, and my step pulse times were as you suggested. 
One last thing - is it ok to put the altered setp DPLL line into the custom hal file so it doesn't get overwritten by pnconf? Or is that the wrong way to go about it? 

Also @ arvidb, Thanks for your help. PCW has solved it for me as above, but in answer to your suggestion, it was difficult to demonstrate the jitter on a still image from the oscilloscope because the jitter appeared as a regular pulse train which kept jumping about. I probably needed to do some fancy triggering to show it better. Anyway, thanks again.

A bit of explanation:

If you look at the log, the DPLL error is often less than -50 usec.
(the are some ~-57 usec values)
If the sample time was set to -50 usec, a -57 usec error would mean
that the DPLL would not have sampled the stepgen position before it
was read by LinuxCNC, meaning the position read would be the position
almost a whole servo period earlier. This will cause a large, bogus velocity
correction, resulting in the jittery motion you observed.

Basically what this means is there is considerable statistical
variation in host/Ethernet communication delays, causing a large
"baseline wander" in the average delay. I suspect this may be
BroadCom (driver or hardware) related.

That said, there is no real penalty to increasing the pre-sample period.
It does increase the time between reading the position and writing a new velocity,
(which causes a small error during acceleration) but you can compensate for this
with the PIDs FF2 parameter (by adding the DPLL pre-sample time to the FF2
parameter (in seconds so a  -100 usec sample time means add 0.0001 to FF2)

That's very helpful. I like to understand how it works.
Thanks again for your help.

Thank you for the solutions posted here

I think that I may be experiencing the same problems. I was having periodic "grinding" noise that would show up whether I was Jogging or the machine was following gcode that was independent of travel speed that would eventually fade away. I increased the DPLL pre-sample time to 100 and it seemed to go away. But recently it came back (possibly a system update or something changed the network behavior).

My question is if there is a practical upper limit to the DPLL pre-sample time which you shouldn't exceed as it will just end up making things run rough again or trigger other errors or bad cuts?

I am running a Mesa 7i92 card that is connected to a Gecko g540 control box that is all driven by a Raspberry Pi 400.