hmmm, looks like we'll have to roughen up and backwards design some of our comms
and such if we ever really to break out into space - you're right the tight sync that servers, datanets etc are used to today are just not going to hack it, going to have to incorporate some (a lot?) of 1950-80s tech to let systems work...
at the moment would play hob with our secure coms, datanets etc cause they all want to be tightly synced. OTOH Even the older systems secure coms relied on having round-trip handshaking going on in fractioins of a second ... trying to set that up for a relatively long haul - seconds - minutes hmmm not old tech, have to be new cause of that.
T
--- On Sat, 7/24/10, <> wrote:
From: <>
Subject: Re: [Traveller_TNE] speed/acceleration/mass/energy/etc
To:
Date: Saturday, July 24, 2010, 6:56 AM
On 23 Jul 2010 at 22:36, wrote:
> >So synch clocks in different places is meaningless
>
> Then why do we do it?
Earth is more or less a single frame of reference. So we can get away
with a lot of stuff that doesn't work over greater distances or large
celocity differences,.
We do it because we have "instant" communication all over earth and
thus "need" to synch things that closely. Max vcomm-lag on Earth is
about half a second if your call gets routed thru a geosynch
satellite or two. It's more like a tenth of a second if it's going
via undersea cables.
In the Imperium, comm lag between planets *in the same system* is
many minutes to many *hours*. 1 AU is 150 million km. That's 500
light seconds.
At closest approach Venus is .3 AU from Earth, Mars is .6.
So the round trip lag (ie time between signal and response is 5
minutes to Venus (at closest approach). and 10 minutes for Mars.
At max seperation, it's 28:20 for Venus, and 43:20 for Mars.
For Pluto, it's over 10 hours.
At 6 g, it'd take a lot longer for the shortest of those distances.
Earth to Venus at closest approach is .3 AU. 45 million km, 4.5e10 m
so it's 2.25 e10 m to turnover for a constant boost course.
d = 0.5*a*t^2
Assume 6 g (call it 60 m/s^2)
2.25e10 = 0.5*60*t^2
2.25e10 = 30*t^2
7.5e8 = t^2
~27386 =t
double it for the deceleration from turnover
15.2 hours.
No need for fraction of a second synchronization for *that*.
Trips between systems (or in-system, but using jump) take a week. Or
more for multi-jump trips.
So synching to within a minute or two in-system and a few hours
between systems is more than adequate. Yes, they'll shoot for higher
precision, but it's not needed much.
Heck, consider this. Earth's radius is about 6400 km. Which makes the
100 diameter limit 4.25 light seconds.
That means that when a ship comes out of jump, it'll be 4.25 seconds
before folks o the ground know about it. And 8.5 seconds before the
ship recieves a request for identification (assuming it's totally
automated and takes no time between seeing the ship and firing off
the request).
> (I'm not talking techno here, just general concepts. Please forgive
> me if to 'sync' a clock actually means something more then just
> calculating what time one person sees vereses another and displaying
> that as a 'sync-ed' clock.)
>
> >What you *can* do is exchange (speed of light) signals and use
> thoseto vompare clocks (after applying relativistic corrections
> forrelative motion
>
> Right, that's what I'm thinking.
>
> >But that doesn't mean that when both places' clocks show a
> givendate/time that it's the "same" time
>
> By default, no it doesn't mean that. But there's no reason we can't
> create a clock that displays the same time as that which our GPS sats
> "see". The servers we have at my work do not work at all if their
> clocks are not sync-ed with each other and with our desktops. This
> does not mean we are displaying that time on our computers, however.
> We have specific software that
Again I get text truncated by your mailer failing to conform to
standard practices.
By default, no it doesn't mean that. But there's no reason we can't
create a clock that displays the same time as that which our GPS sats
"see". The servers we have at my work do not work at all if their
clocks are not sync-ed with each other and with our desktops.
That's because they need time stamps to agree. and because the time
it takes to communicate between each other is less than a
millisecond.
See my comments above about comm lag. You *cannot* synch stuff that
way even between the ground and a geosynch station.
GPS satellites orbit lower and are a *one way* link. So "correcting"
works (and is for something entirely different than why your servers
need their times synched).
A two-way link and the sort of stuff your servers need to be synched
for *won't work* with comm lags on the order of a second.
For lags of a second you could probably kludge something to make
stuff sort of work. But you'd have to watch for race conditions if
folks in orbit and on the ground both wound up doing updates.
For interplanetary, much less interstellar, you'd have to go back to
the old days where data updates between computers were done as batch
processes. And ive with the fact that between updates the two
locations would have databases that didn't match.
> This does not mean we are displaying that time on our computers,
> however. We have specific software that let's us set our computers
> time to whatever we want while keeping them in sync with the main
> server and any client servers.
Which isn't *possible* once distances get big enough. Again, Earth is
a single frame of reference and (on the surface) has ignorable comm
lags. Earth-moon has well over a second lag each way. Call it 2.5
seconds for the round trip.
So you could synch times (by calculation) but you can't synch
*transactions* because it'd take over a second for the "change this"
to get there and you'd get the "OK" or "I can't do that" back 2.5
seconds later. Then check the closest approach time for Venus. Or
Mars.
People actually notice the quarter second lag doing a voice call over
a satellite link. Which is why they don't get routed that way if
there's another choice. (satellite telephones like Motorola's Iridium
use satellites in *much* lower orbits)
> For that mater, many of our clients are in different time zones, but
> our servers are able to talk to them because there is an agreed upon
> way to measure time. When one of our computers gets out of sync
> (whic does happen, though not often) it cannot talk to the network.
That's a software issue, and predicated on the *assumption* that it
takes a fraction of a second for packet & response.
That sort of architecture *can't* be used beyond near planetary
orbit. Because the time synch is used as part of the comm protocol.
And since comm lag will a large fraction of a second, it'll break
even if the clocks *are* synched.
You don't *have* the sort of network you are used to on Earth between
different planets, much less between systems. Instead, you are vack
to batch processing and "store and forward".
The computer equivalent of "telephone tag".
> In the situation where time is passing at a different rate between
> two places, but people at the two places can talk, they would need
> to agree which 'time' to use as the baseline in order for their
> computers to network properly. (But, of course, they don't *have*
> to network their computers in order to comunicate via radio or any
> other method that doesn't require networking.)
That's the point. You *can't* "talk". Not the way you are thinking
of.
You send a message and wait for a reply. You can send more messages,
but only ones regarding matters that don't depend on the answer to
that first message.
You most definitely can't do the sort of networking you are thinking
of.
You can't "talk" between a planet and anything beyond the 100
diameter limit. And between low orbit and the 100 diameter limit, it
gets steadily more annoying as the distance (and comm lag) increases.
Consider that those servers of yours are constantly asking each other
what time it is to be sure that they agree.
If it takes sevceral seconds for a reply, that breaks things rather
badly. If it takes minutes...
>> Why go to all that trouble? All that matters for a "standard"
>> clock is that it be *consistent*, not the rate it runs at
> Yes, but how are you going to get all worlds to agree on the same
> time? And it's not really much trouble at all as any world could
> easily do the calculations without the need to send a physical clock
> to a zero-G environment.
You *aren't* going to get them to agree. Nor is it necessary for them
to do so. The universe, even in Traveller, doesn't work that way.
A system's clocks will be fairly synched because it's useful. But
given comm lag, the only reason for (say) Earth and Mars to clocks
that are (sort of) synched to UTC is so that comm checks occur at
expected times and time (over and above the comm lag) isn't wasted.
Between systems the only reason to keep a clock running on IST
(Imperial Standard Time) is for scheduking purposes. And even being a
few minutes off isn't going to matter. Because comm lage is *years*
if you don't use a ship, and if you do, it's 2 weeks (give or take
quite a few hours).
>> The time difference between zero-g and any gravity humans can
>> stand is a matter of seconds over *years*.
> I'm not completely sure about that as it is substancial enough to
> affect us today, and sats aren't even far enough away from earth to
> be unafected by our gravity.
It is important for the GPS satellites because your position is
calculated based on the lag time for the signals. for 3 meter
accuracy that requires time accuracy of better than one-hundredth of
a *microsecond*.
In a nanosecond light (and radio) travels roughly 11 inches. See why
the fractional time differences in GPS signals are a problem?
A year is roughly 30 million seconds. So the 1 part in 100 million
error that is bad for a GPS signal is 1 second in 3 years. Not
significant for *human* purposes.
>> The velocity differences between systems and ships will be a much
>> larger value
> Hmmmm. If that's the case, there's no real reason to debate this,
> is there? The clocks will be off one way or another, and since I'm
> just thinking in terms of generalizations that works for me.
Thing is, you are not thinking. You are *assuming* that a lot of
stuff that works on Earth can work the same way once you are dealing
with a larger framework.
The only use of synched clocks/calendars once you get to a larger
scale than a planet is for *scheduling*. And that only requires
accuracy on the minutes/seconds range in a system and *hours* between
them.
--
Leonard Erickson (aka shadow)
shadow at shadowgard dot com