The correct way to disable the generator is to override it with an empty file. Any rules in /etc/udev/rules.d will take precedence over rules in /lib/udev/rules.d, so simply create an empty file or symlink to /dev/null:
sudo touch /etc/udev/rules.d/75-persistent-net-generator.rules
-OR-
sudo ln -s /dev/null /etc/udev/rules.d/75-persistent-net-generator.rules
This is safe and future-proof.
Don't do this. Seriously. Just don't. People keep coming up with the idea that NTP is designed to allow a bunch of machines all to have the same time. It isn't. It's designed, quite carefully, to allow many machines to all have the closest thing they can to the correct time, which is not the same thing.
If you have access to a window, you can build a half-decent stratum-1 server for about £50, or a good one for £100. You would do much better to build something like that, then point the other clients at it. Correct timestamps are much better than merely self-consistent ones, not least for forensics.
But if you absolutely must do what you're doing, then you need to realise that you're perverting ntpd, and this will mean understanding what you're doing.
On the server
server 127.127.1.0 prefer
fudge 127.127.1.0 stratum 10
means "use the local undisciplined clock as if it were authoritative", which is what you want. I'm not sure why you're forcing it to stratum 10, though; consider dropping the stratum 10, and let the driver supply its default stratum of 0. On the clients
server 192.168.178.24 iburst
fudge 192.168.178.24 stratum 10
makes no sense at all. fudge 127.127.x.y is reserved for forcing the use of various kinds of local clock drivers. It makes no sense to give it any other address. Drop the fudge line from the clients, and just point them at the server. You're also using a closed network, so drop all the security stuff until you get this working:
restrict default
If that still doesn't seem to work, we'll need to see the output of ntpq -c as and ntpq -c pe on both the server, and on a badly-behaving client, after at least ten minutes of uninterrupted running.
Edit: you write in a comment below that "I think the offset/jitter is really high because the failing clients
drift in time".
I think you may be right. This chap's blog suggests he had the same experience: that the client clock was so bad that it fooled the local ntpd into thinking that the server was unreliable. He wrote
the reason for the huge jitter finally seems clear! Our clock drifts
so fast that the offset will go up by several seconds through our few
measurements
Given that it's your clients whose time goes most quickly off which are failing to sync (marking the server as "reject"), I think you're seeing the same effect. His solution was to use adjtimex to manually tune the kernel clock (adjusting the tick value) until the system clock was less wayward, at which point ntpd had a chance to recognise the server as being OK, and sync to it. You should probably give that a try on the worst client first, and see if it helps.
Best Answer
Coming in a couple years late, but hopefully it will help.
This will fix the unexpected interaction between ntpdate & ntp:
Then when you do a "update-rc.d ntp disable", ntp won't start on reboot.