[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.



More information about the time-nuts mailing list