Re: [time-nuts] looking for good description/generalized model for time adjustments
Precisely so. And NTP may actually be the best model here. Does
NTP's "corrected output" meet the "must be monotonic and not
discontinuous" criteria (being too lazy to just go read the NTP docs,
which I have, and which I'll take a look at after lunch).
There is a lot of info available about ntp, you may have troubles finding
what you want, especially if you don't already know what you are looking for.
I'm being sloppy when I say "ntp". It's both a protocol spec (RFC-whatever)
and a reference implementation (ntpd) that is widely deployed.
ntp tries to keep the local machine in sync with UTC. The model is that the
world is a forest of trees. Each tree starts with a local source of time
that claims to be UTC. ntp calls them refclocks. Each tree is a collection
of servers. The refclocks are stratum 0. The root of each tree is stratum
- The next layer of servers is stratum 2...
A lot of the code in ntp is figuring out which trees to believe and then
selecting the best one to sync to.
ntpd is both a client and server. It's a server distributing time to clients
at a higher stratum and a client getting time from servers at a lower stratum.
What OS are you using? FreeBSD is very good. Linux is not--so-good.
ntp runs in two modes. Normally, it gets the time over the net. Ballpark
accuracies are 1 ms if you have a good local system to talk to and a lightly
loaded network and 10s to 100 ms if you go out over the big bad internet.
The other mode is using a refclock. ntpd includes support of over 20
different types of clocks, many are no longer interesting. The key to
getting good time is something like a PPS pulse and kernel support to grab a
timestamp in the interrupt routing. There is also a batch of PLL code in the
kernel that I don't understand.
For network traffic, ntp assumes the delays are symmetric. You can confuse
it with something like a big download over a DSL link. Delays are not a
problem. It's jitter and asymmetry. After a packet exchange, you end up
with 4 time stamps.
When the request left the client.
When it arrived at the server.
When the response left the server.
When it arrived back at the client.
(The packet can sit on the server for a while, say if it is busy doing other
things.)
If you subtract off the time the packet sat on the server you have the round
trip time. If you assume symmetry you can get the offset.
---> But it is the master, by fiat. Here's a scenario: A schedule
is published that says: (MT = Master's time)
At 12:00.001MT Box A puts out a pulse
At 12:00.002MT Box B puts out a pulse
At 12:01.001MT Box A puts out a pulse.
Box A and Box B MUST follow Master Time, no matter how crummy it is.
ntp is trying for UTC, the one great time. But that comes from outside ntp.
You can simplify things a lot if you tell it (config file) to only use one
server.
For example, you could setup box A as the master and tell B to sync to it.
It may be better to setup another box in a stable environment and sync both A
and B to it. That gives B a stable target.
A Single board computer with non TCXO clock (on order of 10ppm
variability over short term) is the "system controller" and sets the
time schedules. It sends commands to devices which have TCXO clocks
(on order of 1ppm short term variability) saying "at time X do action
Y". It also periodically sends messages to the devices saying "At the
tone, my time is Z".
How good is your netework connection? You can get better data by sending
several packets and picking the best one. In this context that probably
means the one with the lowest round-trip-time. Lowest time means lowest
queuing delays. That assumes no-queuing would be symmetric.
ntp is trying to minimize network load. You may do better by sending more
packets. (there is a maxpoll and a burst mode in the config file)
If I was working on something like that, I would setup a testbed and collect
some data.
10 ppm short term variability seems huge. The crystals I've looked at (in
PCs) are ballpark of 1 ppm per C. Do you have wide temperature changes short
term or nasty crystals? (or am I lucky?)
It sounds a little backwards to have the machine with the lousy clock be the
one in charge. Can it get the time from any of the devices with better
clocks?
What we would like is a) some algorithms to do this (and NTP type PLLs
are a decent way) and b) some formalism and rigor to choose operating
parameters (e.g. update every 1 second or every day or whatever)
There is a lot of formalism with ntp. I'm not familiar with most of it.
Picking parameters is a black art.
The ntp problem is the same as a GPSDO: you get good long term stability.
Short to medium is where things get interesting.
--
These are my opinions, not necessarily my employer's. I hate spam.
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On Behalf Of Hal Murray
Sent: Wednesday, July 29, 2009 2:51 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] looking for good description/generalized model for time adjustments
Precisely so. And NTP may actually be the best model here. Does
NTP's "corrected output" meet the "must be monotonic and not
discontinuous" criteria (being too lazy to just go read the NTP docs,
which I have, and which I'll take a look at after lunch).
There is a lot of info available about ntp, you may have troubles finding
what you want, especially if you don't already know what you are looking for.
I'm being sloppy when I say "ntp". It's both a protocol spec (RFC-whatever)
and a reference implementation (ntpd) that is widely deployed.
What OS are you using? FreeBSD is very good. Linux is not--so-good.
RTEMS and/or VxWorks (I'm using RTEMS, others with whom we communicate use a variety of other things. And we don't have network connections per se.. That's why I'm looking for more generic descriptions that aren't tied to things like packet definitions or peculiarities of IP routing. Basically, all of these things should be able to be boiled down to two things: a synchronization signal and a synchronization message.
The other mode is using a refclock. ntpd includes support of over 20
different types of clocks, many are no longer interesting. The key to
getting good time is something like a PPS pulse and kernel support to grab a
timestamp in the interrupt routing. There is also a batch of PLL code in the
kernel that I don't understand.
and it is that PLL code that is particularly interesting (Poul-Henning has useful information in kern/time_tc.c, etc.)
For network traffic, ntp assumes the delays are symmetric. <snip>
In my application, we don't need to "probe the network" to figure out the latencies. We know them apriori, and they are also "very small" compared to the required time precision. The part I'm interested in is the automated reconciliation of the always varying clocks/oscillators on the platforms, essentially trying to predict a bad clock with a good one.
---> But it is the master, by fiat. Here's a scenario: A schedule
is published that says: (MT = Master's time)
At 12:00.001MT Box A puts out a pulse
At 12:00.002MT Box B puts out a pulse
At 12:01.001MT Box A puts out a pulse.
Box A and Box B MUST follow Master Time, no matter how crummy it is.
ntp is trying for UTC, the one great time. But that comes from outside ntp.
You can simplify things a lot if you tell it (config file) to only use one
server.
For example, you could setup box A as the master and tell B to sync to it.
It may be better to setup another box in a stable environment and sync both A
and B to it. That gives B a stable target.
--> Can't do that in this environment. The master is the master, and all the slaves are fore-ordained and must follow it as best they can. What I need to do, really, is figure out what "best they can" is.
A Single board computer with non TCXO clock (on order of 10ppm
variability over short term) is the "system controller" and sets the
time schedules. It sends commands to devices which have TCXO clocks
(on order of 1ppm short term variability) saying "at time X do action
Y". It also periodically sends messages to the devices saying "At the
tone, my time is Z".
How good is your netework connection?
Negligible latency (at least in the context of the required time precision). In reality, it has a worst case jitter of about 1 microsecond and a mean latency of 0.5 microsecond (that is, a "tick" on one end of the link appears at the other end of the link with a uniformly distributed delay of 0-1 microsecond)
Think of it as if I had a piece of wire connecting the boxes, to do with whatever I want. And then, on the side, I have a way to transmit messages among boxes (which has greater latency and jitter)
10 ppm short term variability seems huge. The crystals I've looked at (in
PCs) are ballpark of 1 ppm per C. Do you have wide temperature changes short
term or nasty crystals? (or am I lucky?)
wide temperature ranges: The environment where you go from full sunlight (at 1.3kW/square meter) to full darkness, radiating to 3K blackbody (about -400W/sq meter), and back to sun every 90-100 minutes). A cyclical variation of 10-20 degrees wouldn't be unusual, and it's not sinusoidal.. more like a low pass filtered square wave.
It sounds a little backwards to have the machine with the lousy clock be the
one in charge. Can it get the time from any of the devices with better
clocks?
sadly, no.. that's one of the problems to solve.
What we would like is a) some algorithms to do this (and NTP type PLLs
are a decent way) and b) some formalism and rigor to choose operating
parameters (e.g. update every 1 second or every day or whatever)
There is a lot of formalism with ntp. I'm not familiar with most of it.
Picking parameters is a black art.
precisely so.. Lots of papers and presentations by Mills (and heck, he's been out here to JPL, too), but there's a lot of empiricism in those filter tuning parameters, I suspect.
Turns out that there are lots of applications in spaceflight where you need to synchronize things that have different clocks (with relativistic effects, as well as just long and varying propagation delay). For instance, NTP, by itself, doesn't do a very good job synchronizing a clock on something orbiting the moon. That's because the propagation delay properties are very different from what NTP was originally designed for (network traffic through a bunch of routers). You have a large, but systematic and predictable, range and range rate variation on top of a 1 second delay.
James,
Your email posting style makes it very difficult to follow threads where
you have posted replies.
Most mail reader programs follow the convention, that on a reply, they
automatically start with a header that identifies the last poster ("In
reply to message from xxx") and then "quote" the entire replied-to
message by prefixing each line with a chevron ">" in the first column.
If another person replies later the same process is usually used, so
when reading the latest message in the thread, one can determine the
sequence of replies, because the oldest has maximum chevrons preceeding
the lines, and the most recent comments have none. One can usually trace
up the message to find the "in response to"-type headers and figure out
who said what.
Here's a link with a discussion of these conventions:
http://en.wikipedia.org/wiki/Posting_style
You seem to use a simple text method in your replies that doesn't add
the chevron in front of the earlier stuff so your new reply and the last
poster look to be at the same current sequence level. What's more, you
often preceed your new reply lines with some random number of chevrons,
making it appear in most mail reader programs that this new portion
ought to be some much earlier part of the discussion. It also makes it a
difficult detective process to figure out who said what in that message
and any that follow.
I don't want to start a big netiqette discussion, and you certainly have
the right to do as you choose, but I would ask, that at minimum, you
don't put chevrons in front of your new reply lines when you respond to
previous messages.
-Rex
Lux, James P (337C) wrote:
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On Behalf Of Hal Murray
Sent: Wednesday, July 29, 2009 2:51 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] looking for good description/generalized model for time adjustments
Precisely so. And NTP may actually be the best model here. Does
NTP's "corrected output" meet the "must be monotonic and not
discontinuous" criteria (being too lazy to just go read the NTP docs,
which I have, and which I'll take a look at after lunch).
There is a lot of info available about ntp, you may have troubles finding
what you want, especially if you don't already know what you are looking for.
I'm being sloppy when I say "ntp". It's both a protocol spec (RFC-whatever)
and a reference implementation (ntpd) that is widely deployed.
What OS are you using? FreeBSD is very good. Linux is not--so-good.
RTEMS and/or VxWorks (I'm using RTEMS, others with whom we communicate use a variety of other things. And we don't have network connections per se.. That's why I'm looking for more generic descriptions that aren't tied to things like packet definitions or peculiarities of IP routing. Basically, all of these things should be able to be boiled down to two things: a synchronization signal and a synchronization message.
The other mode is using a refclock. ntpd includes support of over 20
different types of clocks, many are no longer interesting. The key to
getting good time is something like a PPS pulse and kernel support to grab a
timestamp in the interrupt routing. There is also a batch of PLL code in the
kernel that I don't understand.
and it is that PLL code that is particularly interesting (Poul-Henning has useful information in kern/time_tc.c, etc.)
For network traffic, ntp assumes the delays are symmetric. <snip>
In my application, we don't need to "probe the network" to figure out the latencies. We know them apriori, and they are also "very small" compared to the required time precision. The part I'm interested in is the automated reconciliation of the always varying clocks/oscillators on the platforms, essentially trying to predict a bad clock with a good one.
---> But it is the master, by fiat. Here's a scenario: A schedule
is published that says: (MT = Master's time)
At 12:00.001MT Box A puts out a pulse
At 12:00.002MT Box B puts out a pulse
At 12:01.001MT Box A puts out a pulse.
Box A and Box B MUST follow Master Time, no matter how crummy it is.
ntp is trying for UTC, the one great time. But that comes from outside ntp.
You can simplify things a lot if you tell it (config file) to only use one
server.
For example, you could setup box A as the master and tell B to sync to it.
It may be better to setup another box in a stable environment and sync both A
and B to it. That gives B a stable target.
--> Can't do that in this environment. The master is the master, and all the slaves are fore-ordained and must follow it as best they can. What I need to do, really, is figure out what "best they can" is.
A Single board computer with non TCXO clock (on order of 10ppm
variability over short term) is the "system controller" and sets the
time schedules. It sends commands to devices which have TCXO clocks
(on order of 1ppm short term variability) saying "at time X do action
Y". It also periodically sends messages to the devices saying "At the
tone, my time is Z".
How good is your netework connection?
Negligible latency (at least in the context of the required time precision). In reality, it has a worst case jitter of about 1 microsecond and a mean latency of 0.5 microsecond (that is, a "tick" on one end of the link appears at the other end of the link with a uniformly distributed delay of 0-1 microsecond)
Think of it as if I had a piece of wire connecting the boxes, to do with whatever I want. And then, on the side, I have a way to transmit messages among boxes (which has greater latency and jitter)
10 ppm short term variability seems huge. The crystals I've looked at (in
PCs) are ballpark of 1 ppm per C. Do you have wide temperature changes short
term or nasty crystals? (or am I lucky?)
wide temperature ranges: The environment where you go from full sunlight (at 1.3kW/square meter) to full darkness, radiating to 3K blackbody (about -400W/sq meter), and back to sun every 90-100 minutes). A cyclical variation of 10-20 degrees wouldn't be unusual, and it's not sinusoidal.. more like a low pass filtered square wave.
It sounds a little backwards to have the machine with the lousy clock be the
one in charge. Can it get the time from any of the devices with better
clocks?
sadly, no.. that's one of the problems to solve.
What we would like is a) some algorithms to do this (and NTP type PLLs
are a decent way) and b) some formalism and rigor to choose operating
parameters (e.g. update every 1 second or every day or whatever)
There is a lot of formalism with ntp. I'm not familiar with most of it.
Picking parameters is a black art.
precisely so.. Lots of papers and presentations by Mills (and heck, he's been out here to JPL, too), but there's a lot of empiricism in those filter tuning parameters, I suspect.
Turns out that there are lots of applications in spaceflight where you need to synchronize things that have different clocks (with relativistic effects, as well as just long and varying propagation delay). For instance, NTP, by itself, doesn't do a very good job synchronizing a clock on something orbiting the moon. That's because the propagation delay properties are very different from what NTP was originally designed for (network traffic through a bunch of routers). You have a large, but systematic and predictable, range and range rate variation on top of a 1 second delay.
Yes.. I know.. We just changed institutional mail servers (now Exchange..) and then mail clients (now Outlook 2007..) I haven't figured out how to get the mail client to properly quote non-html messages. (I've got a call into the help desk as I write this..)
Jim
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On Behalf Of Rex
Sent: Wednesday, July 29, 2009 4:18 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Posting style Was: looking for good description/generalized model for time adjustments
James,
Your email posting style makes it very difficult to follow threads where
you have posted replies.
Most mail reader programs follow the convention, that on a reply, they
automatically start with a header that identifies the last poster ("In
reply to message from xxx") and then "quote" the entire replied-to
message by prefixing each line with a chevron ">" in the first column.
If another person replies later the same process is usually used, so
when reading the latest message in the thread, one can determine the
sequence of replies, because the oldest has maximum chevrons preceeding
the lines, and the most recent comments have none. One can usually trace
up the message to find the "in response to"-type headers and figure out
who said what.
Here's a link with a discussion of these conventions:
http://en.wikipedia.org/wiki/Posting_style
You seem to use a simple text method in your replies that doesn't add
the chevron in front of the earlier stuff so your new reply and the last
poster look to be at the same current sequence level. What's more, you
often preceed your new reply lines with some random number of chevrons,
making it appear in most mail reader programs that this new portion
ought to be some much earlier part of the discussion. It also makes it a
difficult detective process to figure out who said what in that message
and any that follow.
I don't want to start a big netiqette discussion, and you certainly have
the right to do as you choose, but I would ask, that at minimum, you
don't put chevrons in front of your new reply lines when you respond to
previous messages.
-Rex
Lux, James P (337C) wrote:
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On Behalf Of Hal Murray
Sent: Wednesday, July 29, 2009 2:51 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] looking for good description/generalized model for time adjustments
Precisely so. And NTP may actually be the best model here. Does
NTP's "corrected output" meet the "must be monotonic and not
discontinuous" criteria (being too lazy to just go read the NTP docs,
which I have, and which I'll take a look at after lunch).
There is a lot of info available about ntp, you may have troubles finding
what you want, especially if you don't already know what you are looking for.
I'm being sloppy when I say "ntp". It's both a protocol spec (RFC-whatever)
and a reference implementation (ntpd) that is widely deployed.
What OS are you using? FreeBSD is very good. Linux is not--so-good.
RTEMS and/or VxWorks (I'm using RTEMS, others with whom we communicate use a variety of other things. And we don't have network connections per se.. That's why I'm looking for more generic descriptions that aren't tied to things like packet definitions or peculiarities of IP routing. Basically, all of these things should be able to be boiled down to two things: a synchronization signal and a synchronization message.
The other mode is using a refclock. ntpd includes support of over 20
different types of clocks, many are no longer interesting. The key to
getting good time is something like a PPS pulse and kernel support to grab a
timestamp in the interrupt routing. There is also a batch of PLL code in the
kernel that I don't understand.
and it is that PLL code that is particularly interesting (Poul-Henning has useful information in kern/time_tc.c, etc.)
For network traffic, ntp assumes the delays are symmetric. <snip>
In my application, we don't need to "probe the network" to figure out the latencies. We know them apriori, and they are also "very small" compared to the required time precision. The part I'm interested in is the automated reconciliation of the always varying clocks/oscillators on the platforms, essentially trying to predict a bad clock with a good one.
---> But it is the master, by fiat. Here's a scenario: A schedule
is published that says: (MT = Master's time)
At 12:00.001MT Box A puts out a pulse
At 12:00.002MT Box B puts out a pulse
At 12:01.001MT Box A puts out a pulse.
Box A and Box B MUST follow Master Time, no matter how crummy it is.
ntp is trying for UTC, the one great time. But that comes from outside ntp.
You can simplify things a lot if you tell it (config file) to only use one
server.
For example, you could setup box A as the master and tell B to sync to it.
It may be better to setup another box in a stable environment and sync both A
and B to it. That gives B a stable target.
--> Can't do that in this environment. The master is the master, and all the slaves are fore-ordained and must follow it as best they can. What I need to do, really, is figure out what "best they can" is.
A Single board computer with non TCXO clock (on order of 10ppm
variability over short term) is the "system controller" and sets the
time schedules. It sends commands to devices which have TCXO clocks
(on order of 1ppm short term variability) saying "at time X do action
Y". It also periodically sends messages to the devices saying "At the
tone, my time is Z".
How good is your netework connection?
Negligible latency (at least in the context of the required time precision). In reality, it has a worst case jitter of about 1 microsecond and a mean latency of 0.5 microsecond (that is, a "tick" on one end of the link appears at the other end of the link with a uniformly distributed delay of 0-1 microsecond)
Think of it as if I had a piece of wire connecting the boxes, to do with whatever I want. And then, on the side, I have a way to transmit messages among boxes (which has greater latency and jitter)
10 ppm short term variability seems huge. The crystals I've looked at (in
PCs) are ballpark of 1 ppm per C. Do you have wide temperature changes short
term or nasty crystals? (or am I lucky?)
wide temperature ranges: The environment where you go from full sunlight (at 1.3kW/square meter) to full darkness, radiating to 3K blackbody (about -400W/sq meter), and back to sun every 90-100 minutes). A cyclical variation of 10-20 degrees wouldn't be unusual, and it's not sinusoidal.. more like a low pass filtered square wave.
It sounds a little backwards to have the machine with the lousy clock be the
one in charge. Can it get the time from any of the devices with better
clocks?
sadly, no.. that's one of the problems to solve.
What we would like is a) some algorithms to do this (and NTP type PLLs
are a decent way) and b) some formalism and rigor to choose operating
parameters (e.g. update every 1 second or every day or whatever)
There is a lot of formalism with ntp. I'm not familiar with most of it.
Picking parameters is a black art.
precisely so.. Lots of papers and presentations by Mills (and heck, he's been out here to JPL, too), but there's a lot of empiricism in those filter tuning parameters, I suspect.
Turns out that there are lots of applications in spaceflight where you need to synchronize things that have different clocks (with relativistic effects, as well as just long and varying propagation delay). For instance, NTP, by itself, doesn't do a very good job synchronizing a clock on something orbiting the moon. That's because the propagation delay properties are very different from what NTP was originally designed for (network traffic through a bunch of routers). You have a large, but systematic and predictable, range and range rate variation on top of a 1 second delay.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Test of quoting of responses..
This looks better, at least from here..
James Lux, P.E.
Task Manager, SOMD Software Defined Radios
Flight Communications Systems Section
Jet Propulsion Laboratory
4800 Oak Grove Drive, Mail Stop 161-213
Pasadena, CA, 91109
+1(818)354-2075 phone
+1(818)393-6875 fax
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On
Behalf Of Rex
Sent: Wednesday, July 29, 2009 4:18 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Posting style Was: looking for good
description/generalized model for time adjustments
James,
Your email posting style makes it very difficult to follow threads
where
you have posted replies.
Most mail reader programs follow the convention, that on a reply, they
automatically start with a header that identifies the last poster ("In
reply to message from xxx") and then "quote" the entire replied-to
message by prefixing each line with a chevron ">" in the first column.
If another person replies later the same process is usually used, so
when reading the latest message in the thread, one can determine the
sequence of replies, because the oldest has maximum chevrons preceeding
the lines, and the most recent comments have none. One can usually
trace
up the message to find the "in response to"-type headers and figure out
who said what.
And here's a response..
Seems to have quoted properly.
(of course, some centrally managed configuration update pushed out tonight might set it back...arghh)
Jim
At 07:17 PM 7/29/2009, Rex wrote...
Your email posting style makes it very difficult to follow threads
where you have posted replies.
At least he's not top-posting.
Mike,
What, exactly, is the problem with top posting ?
Sure, if you top post then the reader has to swing to the bottom and go backwards
to pick the thread properly. However, the other way around then the writer has
to always go to the bottom to post. Either way someone has to do some rolling.
I don't know about others but I have a reverse gear in my mail client.
I guess, if we were to count numbers, then there is one writer and many readers.
So the writers loose. For me, I am lazy, and I started out with top posting
decades ago.
Bill....WB6BNQ
Mike S wrote:
At 07:17 PM 7/29/2009, Rex wrote...
Your email posting style makes it very difficult to follow threads
where you have posted replies.
At least he's not top-posting.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
At 07:55 PM 7/29/2009, WB6BNQ wrote...
What, exactly, is the problem with top posting ?
Nothing, if you read books starting with the last chapter, working
forward.
Top posters are a result of the lame default of many MUAs, including MS
Outlook, which place the insertion point for a reply at the top. Other
than the illogical flow, most top-posters are lazy (they just hit reply
and start typing), and leave the entire quoted content in place, in
most cases (I'd bet), not even realizing the full content of their
email below their reply. Five levels of replies are not needed for
context, especially on an email reflector, where all messages go to all
participants.
By bottom posting (or better yet, inline), one is forced to go through
the text one is including for context, which encourages trimming it to
a reasonable amount.
Mike S wrote:
At 07:55 PM 7/29/2009, WB6BNQ wrote...
What, exactly, is the problem with top posting ?
Nothing, if you read books starting with the last chapter, working forward.
Top posters are a result of the lame default of many MUAs, including MS
Outlook, which place the insertion point for a reply at the top. Other
than the illogical flow, most top-posters are lazy (they just hit reply
Be sure to inform your physician that he files your
medical chart incorrectly with the most recent
information on top. :)
and start typing), and leave the entire quoted content in place, in most
cases (I'd bet), not even realizing the full content of their email
below their reply. Five levels of replies are not needed for context,
I think that in-line posting is the most inconvenient.
After a few message exchanges, I give up trying to
find my way through the mess.
especially on an email reflector, where all messages go to all
participants.
By bottom posting (or better yet, inline), one is forced to go through
I sincerely hope that we're not in for a massive
discussion of bottom-posting versus top-posting.
the text one is including for context, which encourages trimming it to a
reasonable amount.
At 08:54 PM 7/29/2009, Mike Naruta AA8K wrote...
Be sure to inform your physician that he files your
medical chart incorrectly with the most recent
information on top. :)
So that's why they have such bad handwriting - they're forced to write
backwards starting at the bottom of the page.
Golly,
Top posting has been used since the very first email programs
were written... I was there.
Back in the day, people were using 110 and 300 baud connections,
and it was a real pain to have to download several pages of quoted
message only to see "me to" at the bottom.
Initially, this argument seemed to be a US vs Europe thing, and then
when the first non academic and government users got added to the
internet, the battle lines were drawn big time.
You don't expect the foot notes of a book to come before the text,
do you?
-Chuck Harris
Mike S wrote:
At 07:55 PM 7/29/2009, WB6BNQ wrote...
What, exactly, is the problem with top posting ?
Nothing, if you read books starting with the last chapter, working forward.
Top posters are a result of the lame default of many MUAs, including MS
Outlook, which place the insertion point for a reply at the top. Other
than the illogical flow, most top-posters are lazy (they just hit reply
and start typing), and leave the entire quoted content in place, in most
cases (I'd bet), not even realizing the full content of their email
below their reply. Five levels of replies are not needed for context,
especially on an email reflector, where all messages go to all
participants.
By bottom posting (or better yet, inline), one is forced to go through
the text one is including for context, which encourages trimming it to a
reasonable amount.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
At 09:43 PM 7/29/2009, Chuck Harris wrote...
Top posting has been used since the very first email programs
were written... I was there.
Really? You used READMAIL/SNDMSG, and exchanged emails with Ray
Tomlinson?
Bottom posting has been the preferred method from day 1 for USENET,
which is the medium most comparable to an email reflector.
It's interesting, though, that most top-posting MUAs insist on putting
a new .sig all the way at the bottom. What's the logic behind that?
it was a real pain to have to download several pages of quoted
message only to see "me to" at the bottom.
People who don't trim are even worse than top-posters.
Arrgh!
Mike S wrote:
At 07:17 PM 7/29/2009, Rex wrote...
Your email posting style makes it very difficult to follow threads
where you have posted replies.
At least he's not top-posting.
I did say this:
"I don't want to start a big netiqette discussion..."
Top/bottom is exactly the discussion I was thinking might happen.
(Notice, I did both this time.) I'm happy with both.
Sorry I sparked it.
That would be incorrect.
To use your analogy, bottom posting is like restarting a book at the
beginning each time you put it aside to do something else and close it.
Another reason for top posting, which is much more recent though: on the
Blackberry, long messages are truncated and you have to download the rest of
the message separately (click "more"), which is an even greater pain, so on
the Blackberry, top posting is VASTLY preferred.
Bottom line: some people prefer one way, and others prefer another way. Live
with it, be flexible. It's here to stay :)
Didier
-----Original Message-----
From: time-nuts-bounces@febo.com
[mailto:time-nuts-bounces@febo.com] On Behalf Of Mike S
Sent: Wednesday, July 29, 2009 7:35 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Posting style Was: looking for
gooddescription/generalized model for time adjustments
At 07:55 PM 7/29/2009, WB6BNQ wrote...
What, exactly, is the problem with top posting ?
Nothing, if you read books starting with the last chapter,
working forward.
Another thing, on the Blackberry, it is simply IMPOSSIBLE to bottom post or
in-line post because the handheld does not actually process the message you
are responding to, only the response, and the response is inserted at the
top by the Blackberry server software.
Didier
-----Original Message-----
From: time-nuts-bounces@febo.com
[mailto:time-nuts-bounces@febo.com] On Behalf Of Didier Juges
Sent: Wednesday, July 29, 2009 10:08 PM
To: 'Discussion of precise time and frequency measurement'
Subject: Re: [time-nuts] Posting style Was: looking
forgooddescription/generalized model for time adjustments
That would be incorrect.
To use your analogy, bottom posting is like restarting a book
at the beginning each time you put it aside to do something
else and close it.
Oh CRAP,
Here we go again. Top, Bottom, left and right posting has been
debated on just about every news group since the beginning of time
(maybe diagonal also) ......LET IT GO!!!
Had
K7MLR
At 07:25 PM 7/29/2009, you wrote:
At 09:43 PM 7/29/2009, Chuck Harris wrote...
Top posting has been used since the very first email programs
were written... I was there.
Really? You used READMAIL/SNDMSG, and exchanged emails with Ray Tomlinson?
Bottom posting has been the preferred method from day 1 for USENET,
which is the medium most comparable to an email reflector.
It's interesting, though, that most top-posting MUAs insist on
putting a new .sig all the way at the bottom. What's the logic behind that?
it was a real pain to have to download several pages of quoted
message only to see "me to" at the bottom.
People who don't trim are even worse than top-posters.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Top Posting, Mid Posting or Bottom Posting,
I agree to not discuss it extensively.
But why it is necessary to fill up the archive space with twice, triple or even
more times of:
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
I do not understand it. Can this be solved?
Perhaps it is wrong to just delete at least this part, but it does save some space.
HTML is very good for Internet information pages, but personally I have some
problems having to read through never ending Spaghetty Lines. Ok, when I trim
my mailer prog to show only a quarter of the screen width these lines get wrapped
to be readable.
I do not use the multi featured mailing programs. I want to avoid any hidden
codes to get active. I do only need just ASCII or ANSI characters for typing
text. Perhaps I am alone whith this behaviour...
Why not to use the different ways of posting all together?
When the response does follow more or less immediately I think it is not
necessary to rehash what I lready have on my disk. Perhaps just mentioning the
subject with date/ time may be sufficient. If there are doubts then I think to add the
previous text at the end is sufficient, even if it sounds to be more logic to put it
in front. In most cases I anyway step down immediately to the new text without
having read this known old part...
I find the Center Posting important when the mail is complex containing
lots of different points and statements or questions, but that does not seem to be
read easily either.
Thanks Rex for your mail and pointing to the WIKI I didn't know about.
Excuse me, ecause my answer is not specific to just one previous mail I just
do not repeat them.
Arnold