Unqualified thoughts

[Hal Murray]

Unqualified thoughts said:
> I think it would be a not-very-good idea to add a bottleneck er mutex to
> threading NTPsec, Linux worked hard to kill off their global lock IIRC. 

The current code is single threaded so adding a global lock is just to 
preserve correctness until we fix the code to use finer grained locking.


> A 24 block byte should suffice for the client-supplied data to the NTPv3/4
> server threads, NTPv2 would probably need the same with perhaps a dozen bytes
> differing.

You need a lock on that block in order to prevent the server from getting half 
the data from before an update and the other half from after the update.  
(Remember, the old code was single threaded.)

If NTPv3 needs anything that isn't in the NTPv3/4 block, we should add it 
rather than creating another block of data.

My expectation is that the client (write) side would collect all the data, 
then grab a (spin?) lock, copy over the data, then release the lock.  
Similarly on the server (read) side, it would grab the lock, copy out the 
data, then release the lock.

> IIRC there was a draft over at IETF to have the client port hop instead of
> sticking to 123/UDP. 

Yes.  I think that will be easier to do after we support threads.  The idea is 
that each client thread would do the packet exchange, then get the global lock 
and call into the existing code.



-- 
These are my opinions.  I hate spam.