[time-nuts] No Echo
Robert Vassar
rvassar at rob-vassar.com
Sat Feb 23 11:01:08 EST 2008
On Feb 23, 2008, at 8:31 AM, John Ackermann N8UR wrote:
> Sylvain RICHARD said the following on 02/23/2008 08:59 AM:
>
>>
>> Please note that the usual caveat (is your server time set
>> correctly?)
>> does not apply our case.
>
Just to tie off my end, the originating machine for that message runs
NTP, at around stratum 4/5, but never really gets a good lock because
it sleeps when idle. However, the first timestamp on the SMTP
envelope is generated by linode.rob-vassar.com, which is a virtual
server. It is a UML Linux instance that in effect runs as a large
program on a huge shared Linux server in a co-lo facility. It relies
on the host OS to provide time, and is incapable of setting or
adjusting it's own time. The host is supposed to run NTP, but I have
no visibility or insight into their practices/operation. All I can
say is it "appears correct", but that's kind of an amusing statement
given the mailing list we're on. :-)
This is one of my areas of interest... I'm working on getting a Xen
virtualization machine running here at the house, and I'm curious to
see how the hypervisor and each OS instance impacts NTP. I suspect
it will not be pretty.
> There is also some queuing delay at meow.febo.com, also known as
> febo.com or www.febo.com. Normally, messages are processed pretty
> quickly -- I usually see time-nuts postings within 15 or 20 seconds
> after the message hits the list -- but there can be delays if the
> machine is busy, and particularly if there are several list messages
> being processed in a short time span.
Exim does fairly well in that regard. I'm actually employed a mail
server QA professional, I perform a type of testing known as "stress
test". I don't work with it directly, but I do know that Exim is
used at some of the largest mail server complexes in the world.
>
> There's also a retry delay if message delivery from febo.com to the
> next
> hop fails. The delay is something like an exponential backoff that
> can
> extend out to hours between retries; the system keeps trying to
> deliver
> a message for up to 4 days.
This is all highly adjustable. The typical default is 4 days, I'm
not sure if that's an RFC spec or not. You can investigate queue
performance locally using the "exim -bp" command. If you're
unprivileged, it will only display your messages, if any.
Cheers,
Rob
More information about the time-nuts
mailing list