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 _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
