Eric S. Raymond writes:
> It's a clever idea. A posse of Germans apparently headed by one Frank Kardel
> noticed that a lot of clock-radio drivers are structurally very similar:
> repeatedly read a text packet from the device, parse it into a timestamp,
> feed the timestamp to the sync algorothms,
e...@thyrsus.com said:
> Does anyone on the list understand mode 6 well enough to answer questions?
> My main one is: if I add a field to a mode 6 response, is it going to break
> old ntpqs or will they silently ignore it?
I think they ignore it, but try it to be sure.
> (The response field I i
Yesterday I pushed some erroneous commits that got out because my
smoke-test procedure was throwing false negatives. To deal with this,
I've improved the way I test; everything now gets tried on snark
before being pushed to the public repo so the test farm machines can
see it.
While this did enabl
On Sat, Jun 25, 2016 at 11:00:39AM -0400, Eric S. Raymond wrote:
>
> While this did enable me to recover from my errors, it also turned up
> a serious problem. The combination of the buggy async-DNS code we
> inherited from Classic and use of pool servers causes *very* frequent
> crashes.
Can yo
e...@thyrsus.com said:
> 1. Apply Classic's workaround for the problem, which I don't remember the
> details of but involved some dodgy nonstandard linker hacks done through the
> build system. *However, I did not trust this method when I understood it.*
> It seemed sure to cause porting difficul
Kurt Roeckx :
> On Sat, Jun 25, 2016 at 11:00:39AM -0400, Eric S. Raymond wrote:
> >
> > While this did enable me to recover from my errors, it also turned up
> > a serious problem. The combination of the buggy async-DNS code we
> > inherited from Classic and use of pool servers causes *very* fre
Hal Murray :
>
> e...@thyrsus.com said:
> > 1. Apply Classic's workaround for the problem, which I don't remember the
> > details of but involved some dodgy nonstandard linker hacks done through the
> > build system. *However, I did not trust this method when I understood it.*
> > It seemed sure
On Sat, Jun 25, 2016 at 06:13:56PM -0400, Eric S. Raymond wrote:
> Hal Murray :
> >
> > e...@thyrsus.com said:
> > > 1. Apply Classic's workaround for the problem, which I don't remember the
> > > details of but involved some dodgy nonstandard linker hacks done through
> > > the
> > > build syste
Kurt Roeckx :
> > This matches what I remember, except for "use more memory". There was a
> > third
> > workaround involved weird linker options to force early loading of the
> > library.
>
> Like -WL,-z,now? That's not such a weird option.
No, something related to the message I got when I cam
e...@thyrsus.com said:
> I think the hack is to force libgcc_s to be loaded early. I don't know how
> to do that in waf.
There are two problems in this area. One is the end-of-thread code not
getting locked into memory. I think that is what you are running into.
The other is a tangle of erro
Mark: Heads up! Policy issue. Important but not urgent.
Hal Murray :
>
> e...@thyrsus.com said:
> > I think the hack is to force libgcc_s to be loaded early. I don't know how
> > to do that in waf.
>
> There are two problems in this area. One is the end-of-thread code not
> getting locked i
Today, after a false start yesterday and a correction, I completed a
patch sequence that makes a significant structural change that isn't just
removing cruft.
This is kind of a first. Yes, I've made some pretty dramatic changes to
the code over the last year, but other than the not-yet-successful
e...@thyrsus.com said:
> In this case, we have two possible complexity-reducing fixes. One is to
> drop the memlock feature entirely. The other is to drop the buggy homebrew
> asynchronous-DNS lookup from Classic and use libc's.
Dropping memlock is an interesting idea. I can't think of any pla
> Here's how I think it should look:
> --
> refclock shm unit 0 refid GPS
> refclock shm unit 1 prefer refid PPS
> --
I think you should start a list of that sor
14 matches
Mail list logo
