detha de...@foad.co.za wrote:
On Mon, 27 Jan 2014 21:45:22 +, Rob wrote:
[...]
I can ping it as much as I like, no loss: 1571 packets transmitted, 1571
received, 0% packet loss, time 20468ms rtt min/avg/max/mdev =
0.702/0.845/1.168/0.090 ms
But when ntpd is allowed to climb to
On Wed, 29 Jan 2014 08:28:25 +, Rob wrote:
detha de...@foad.co.za wrote:
On Mon, 27 Jan 2014 21:45:22 +, Rob wrote:
[...]
I can ping it as much as I like, no loss: 1571 packets transmitted,
1571 received, 0% packet loss, time 20468ms rtt min/avg/max/mdev =
0.702/0.845/1.168/0.090
Is there any difference using
ntp.keys generated:
a) manually via inserting key-id, type=M, and string with any lengths like:
1 M fjfjfksdflsjflkfj
2 M asdkjweiu.NEEw.RTyfsd
3 M qweddfkfd..-drftGTG
12 M QWERtrtv.444
or
b) via ntp-keygen -M and using some of these keys like:
cat
detha de...@foad.co.za wrote:
It is apparent that the problem does not occur when the link is busy, but
I still don't know the cause.
It may also be some power-saving mechanism, for example.
First step is to prove that the problem goes away when the link is kept
busy with totally unrelated
On Wed, 29 Jan 2014 17:56:04 +, Rob wrote:
detha de...@foad.co.za wrote:
If keeping the link open with a ping helps, second step is to determine
what times out. Run a ping from somewhere else to the server, or from
the client to somewhere else. If running a ping from the client to
detha de...@foad.co.za wrote:
What distribution and kernel are you running on the wired one? I've got a
spare raspberry somewhere, would be interesting to see if I can reproduce
this.
raspbmc (downloaded bootstrap and installed
and updated using its builtin mechanism).
Linux raspbmc 3.10.21
On 2014-01-29, Rob nom...@example.com wrote:
detha de...@foad.co.za wrote:
It is apparent that the problem does not occur when the link is busy, but
I still don't know the cause.
It may also be some power-saving mechanism, for example.
First step is to prove that the problem goes away when
