Hal Murray :
>
> > Good to know. Yeah, NTP at that volume is sure not going to saturate even a
> > smartphone, let alone anything you'd put in a desktop or server case.
>
> I can get 20k pkt/s through a Pi 3.
So, to a reasonable first approximation, a RasPi 3 could handle PTB's
load with 50% h
> Good to know. Yeah, NTP at that volume is sure not going to saturate even a
> smartphone, let alone anything you'd put in a desktop or server case.
I can get 20k pkt/s through a Pi 3.
There is an interesting quirk in this area. Suppose you have a traffic
generator with a knob on it, and y
Achim Gratz via devel :
> Answer from PTB: Current packet rate is still lower than 10k/s peak over
> all three servers. Not sure how well balanced that is, but I guess it's
> safe to say that it's less than 5k/s on each server.
Good to know. Yeah, NTP at that volume is sure not going to saturate
Achim Gratz via devel writes:
> Eric S. Raymond via devel writes:
>> Achim Gratz via devel :
>>> I could try to contact the responsible person for NTP at PTB if you
>>> can't get at information from NIST.
>>
>> Probably a good idea to have PTB figures even if we *can* get some from NIST.
[…]
> By t
Eric S. Raymond via devel writes:
> Sure, I thought of that. But if I were to do that I would (as the old hacker
> joke about regexps goes) have *two* problems. That is, two layers of
> configuration interpretation, both attracting defects. See "complicated
> and ugly", above.
The configuration
> OK, then, say, 2.5K requests per second per server. That means to stay ahead
> of the processing load it has to handle the CPU-limited part in 0.4us.
typo: us => ms
--
All of your numbers seem reasonable.
I think you are on thin ice translating packets/second to users. The only
Gary, Hal,
If you bump up your scale factor in the pool, traffic will ramp up slowly,
over days or weeks.
If you bump down, or leave, traffic will take months, or longer, to stop.
On Sat, 12 Jan 2019, 4:02 am Hal Murray via devel
> Gary said:
> > I have a RasPi in the ntp pool. Typically aro
Achim Gratz via devel :
> > The biggest problem with any attempt to break up ntpd into multiple
> > separate programs is that it would almost necessarily force changes in
> > the way NTP configuration works that would be (a) user-visible, and
> > (b) not backward compatible. The only ways around h
Gary E. Miller via devel :
> "Eric S. Raymond via devel" wrote:
>
> > That doesn't seem to me like it's going to load a modern processor a
> > lot. Even my RasPis could handle that action.
>
> I have a RasPi in the ntp pool. Typically around 200 kbps in and the same
> back out. The 5 min load
> # ntpq iostats
> ntpq: standard-mode lookup of iostats failed, Name or service
> not known
Sorry for the confusion. It needs a -c.
If you didn't recognize "iostats" as a ntpq command, you might find other
useful ones. Try
$ ntpq -c help
--
These are my opinions. I hate spam.
Eric S. Raymond via devel writes:
> I have, unsurprisingly, spent a lot of time thinking about how to partition
> the existing code into smaller pieces. I had a strong incentive; reducing
> global complexity would ipso facto choke off attack vectors.
Well, others have been at the same junction an
Yo Hal!
On Fri, 11 Jan 2019 12:02:24 -0800
Hal Murray via devel wrote:
> Gary said:
> > I have a RasPi in the ntp pool. Typically around 200 kbps in and
> > the same back out. The 5 min load average is around 0.02.
>
> Go to your pool control page and bump up the bandwidth you are signed
>
Gary said:
> I have a RasPi in the ntp pool. Typically around 200 kbps in and the same
> back out. The 5 min load average is around 0.02.
Go to your pool control page and bump up the bandwidth you are signed up for.
It's not real bandwidth, just a scale factor.
> Is there an easy way to ge
Yo Eric!
On Fri, 11 Jan 2019 11:30:58 -0500
"Eric S. Raymond via devel" wrote:
> That doesn't seem to me like it's going to load a modern processor a
> lot. Even my RasPis could handle that action.
I have a RasPi in the ntp pool. Typically around 200 kbps in and the same
back out. The 5 min l
Achim Gratz via devel :
> By the end of 2016 the request rate grew to about 7000 per second (not
> specified which server, so I assume for all three). The paper didn't go
> into any further details of the NTP service.
OK, then, say, 2.5K requests per second per server. That means to stay ahead
o
Eric S. Raymond via devel writes:
> Achim Gratz via devel :
>> I could try to contact the responsible person for NTP at PTB if you
>> can't get at information from NIST.
>
> Probably a good idea to have PTB figures even if we *can* get some from NIST.
I've sent the questions off, let's see how res
Achim Gratz via devel :
> I could try to contact the responsible person for NTP at PTB if you
> can't get at information from NIST.
Probably a good idea to have PTB figures even if we *can* get some from NIST.
--
http://www.catb.org/~esr/";>Eric S. Raymond
My work is funded by th
Eric S. Raymond via devel writes:
> I'm still going to take convincing. Like, with actual load numbers from
> one of those big servers.
I seem to remember that PTB uses specialized dedicated hardware. Here's
one paper that unfortunately doesn't go into the operational details of
the NTP service.
e...@thyrsus.com said:
> I'm still going to take convincing. Like, with actual load numbers from one
> of those big servers.
I don't have any solid numbers. I just have a memory of comments about the
NIST servers being very busy with no comments saying that it wasn't a problem.
I'll see if I
Hal Murray :
>
> Eric said:
> > I concur. I would need to see actual measurements before I've convinced
> > that
> > ntpd with even a thosand client connections is a performance-degrading
> > load.
>
> I think there are two cases: popular public servers like NIST and everybody
> else.
>
> I
Eric said:
> I concur. I would need to see actual measurements before I've convinced that
> ntpd with even a thosand client connections is a performance-degrading load.
I think there are two cases: popular public servers like NIST and everybody
else.
I agree that the load on most servers is
Achim, apologies for the lack of clarity.
500pps is TX. RX is slightly higher.
--
Sanjeev Gupta
+65 98551208 http://www.linkedin.com/in/ghane
On Mon, Jan 7, 2019 at 3:42 AM Achim Gratz via devel
wrote:
> Sanjeev Gupta via devel writes:
> > PPS is about 500/s, RX is 10% more than TX
> >
Sanjeev Gupta via devel :
> Interface is 100Mbps
> ntpsec is the only network service on the machine. gpsd runs locally
> CPU load is under 3%
> Hardware is a dual-core Pentium 4, 2800MHz, from about 2006
> Network traffic is under 100kbps
> PPS is about 500/s, RX is 10% more than TX
>
> Current
Sanjeev Gupta via devel writes:
> PPS is about 500/s, RX is 10% more than TX
>
> Current client count is 18071
If your PPS number includes both the incoming and the outgoing packets,
then the average poll interval is slightly larger than 64 seconds, which
sounds about right for well-behaved client
On Mon, Jan 7, 2019 at 2:23 AM Achim Gratz via devel
wrote:
> Sanjeev Gupta via devel writes:
> > root@ntpmon:~# ntpq -n -c direct -c mrulist | wc -l
> > 17306
> >
> > I am in the sg, in, and asia pools. v4 and v6. Server access is
> available
> > if you wish to poke around.
>
> What's the inte
Sanjeev Gupta via devel writes:
> root@ntpmon:~# ntpq -n -c direct -c mrulist | wc -l
> 17306
>
> I am in the sg, in, and asia pools. v4 and v6. Server access is available
> if you wish to poke around.
What's the interface speed to the outside world, how much of it is used
up by NTP and what's t
On Mon, Jan 7, 2019 at 12:57 AM Eric S. Raymond via devel
wrote:
> Achim Gratz via devel :
> > > Anyway, I think that thinking about them as separate parts will help
> our
> > > discussions.
> > > We should be able to improve performance on busy servers.
> >
> > It's been decades since I looked a
Achim Gratz via devel :
> > Anyway, I think that thinking about them as separate parts will help our
> > discussions.
> > We should be able to improve performance on busy servers.
>
> It's been decades since I looked at an NTP server that has enough
> clients to make me wonder about performance,
Gary E. Miller via devel :
> Yo Hal!
>
> On Sat, 05 Jan 2019 01:25:57 -0800
> Hal Murray via devel wrote:
>
> > The current code is a combined client and server. I think we should
> > split that into separate programs. Maybe not right away, but we
> > should at least start thinking that way.
>
Hal Murray via devel :
>
> The current code is a combined client and server. I think we should split
> that into separate programs. Maybe not right away, but we should at least
> start thinking that way.
>
> The server side is simple. It gets time from the system. There are a few
> other p
Hal Murray via devel writes:
> The current code is a combined client and server. I think we should split
> that into separate programs. Maybe not right away, but we should at least
> start thinking that way.
If you're going to give ntpd the djb treatment (ref. qmail) then that
split is the mos
Yo Hal!
On Sat, 05 Jan 2019 01:25:57 -0800
Hal Murray via devel wrote:
> The current code is a combined client and server. I think we should
> split that into separate programs. Maybe not right away, but we
> should at least start thinking that way.
If/when ntpd moves to Go then it might be b
The current code is a combined client and server. I think we should split
that into separate programs. Maybe not right away, but we should at least
start thinking that way.
The server side is simple. It gets time from the system. There are a few
other parameters that either need to come f
33 matches
Mail list logo
