ntpq no longer working -

Bob Goodwin bobgoodwin at wildblue.net
Thu May 25 08:20:09 UTC 2006


Tim wrote:
> Tim:
>   
>>> According to that diagram you have two devices with the same IP on the
>>> same network (the router and box 1), that can't work.  Change one of
>>> them.  Not sure which?  A common practice is to have a .254 ending
>>> address for routers (e.g. 192.168.1.254), though it's not a requirement.
>>>       
>
> Bob Goodwin:
>> http://users.wildblue.net/bobgoodwin/RF-Link.png
>>     
>
> Now you have a device with a .255 ending address.  That's a broadcast
> address, which is an entirely different thing than what wireless does,
> it's a networking issue.  e.g. ping 192.168.1.255 should ping everything
> on the LAN, and everything should respond back.  Some things will treat
> a .255 address as a broadcast one, other things won't; it can be a cause
> for strange problems.
>
>  
>   
>> Ntp is working normally since I corrected the spelling error
>> in /etc/hosts.  I am accustomed to seeing  much lower delays, on the
>> order of 160 ms, and better offsets, usually near 1 ms, but it is
>> working and I don't think I need such great accuracy.  I believe
>> I am limited by the system delays through Wildblue.  Transit time to
>> and from the satellite must be on the order of a quarter of a second
>> in addition to various other system delays?
>>     
>
> Satellite internet does introduce bigger delays, there is a large amount
> of travel involved, at the very least.  Shouldn't be a cause for
> concern, though; NTP should take the delays into account.
>   
My only "concern" is that the numbers are a lot different than what I am 
accustomed to seeing!

Google produces a lot of interesting stuff on the subject of satellite 
delays, ntp, etc.,
at least interesting to me.  This guy seems a reasonable source and 
explains where the five or six
hundred milliseconds I have observed are going.  I figure 126 ms transit 
time between earth and
the satellite assuming a 23,500 mile path length.  With acknowledgments, 
that quickly eats up
500 milliseconds.  With the time servers I selected, at less than 200 
miles, the delays via the
dial-up system were typically ~165 ms vs 600 - 700 ms now.

I realize that the actual path lengths can vary and are not known with 
much accuracy.  Also
Direcway/Hughes and Wildblue are different services but probably have 
similar system delays.

--------------------------------

Here in the Lower 48 DirectWay is a pure satellite system, unlike its hybrid
predecessor which required a land line modem for all outbound traffic.

The biggest problem with DirectWay is the speed of light. The minimum one-way
distance to a geosynchronous satellite is still 23,500 miles, which is about 1/8
light-second. That means the absolute minimum time required for a full duplex
character echo from the distant end is at least 1/2 second (up & down outbound
followed by up & down return). To that time you must add in the arctangent
multipliers for each of the two look angles, and the absolute delays along any
terrestrial path segments.

Aside from the human interface difficulties this delay presents, it can have all
sorts of weird effects on protocols which expect ping times in the 100 msec
range. I remember how we had to change the cryptographic resync pattern from
10101010... to 11111111000000001111111100000000... for 50 kbps analog modems on
military satellite links. I can well imagine how HTTP acceleration and FTP might
be very adversely affected by such lengthy absolute delays.

If you are trying to connect to the Internet from someplace so remote that
satellite is your only means available, then I think DirectWay may be a
tolerable solution. As an engineer, however, I believe DirectWay's designers
must have been sitting on their collective brains when they packaged their
product exclusively for USB + Windows.

--Doc Savage
  Fairview Heights,	http://www.redhat.com/archives/psyche-list/2002-October/msg03812.html
IL

----------------------------------

>   
>> I believe both the router and the bridge are set for dhcp.
>>     
>
> That may or may not be a problem, depending on what your bridge's DHCP
> server is doling out addresses to and to where (if it's the other side
> of the network, and IPs aren't being duplicated, you should be okay).  
>
> i.e. If one doles out different IPs than the other, on the same subnet
> range (e.g. 192.168.1.1 to 192.168.1.100 by one of them, and
> 192.168.1.101 to 192.168.1.253 on the other).  Or, if the router's
> passing out the 192.168.1.x addresses and the other one is doling out
> the 10.0.0.x addresses.
>
> The problem is when you have two DHCP servers on the same subnet, or
> doling out the same IPs to interconnected subnets.
>
>   
>> For whatever reason I haven't been able to get to the bridge setup
>> screen.  That's an annoyance and I don't know why but it works
>> as it is, help from Linksys would require moving it back on to a
>> Windows computer and then I would have a language problem.
>>     
>
> Some devices also have a telnet address.  That gives you a simple
> interface to the device, if you find the web interface doesn't get along
> with your browser.  If worst comes to worst, there should be a master
> reset button on it.
>   
Yes, but determining the addresses is my problem.  The user information 
provided
with the equipment specifies little.  The web interface even had trouble 
"getting along"
with WinXP,  a requirement if you're going to deal with the tech support 
people.  My
problem is not that the system does not work, actually it is working 
surprisingly well,
but that I don't fully understand how or why.
>   
>> Some of the addresses on the diagram were gleaned from the etherape
>> display, e.g. the 192.168.1.255 for the router.
>>     
>
> That may not be reading things correct, or if it is, you may strike some
> problems (as I outlined above).
I'm still struggling to understand the addressing scheme.  Dhcp creates 
some unknowns,
how can I see the address assignments it's made?  Applications like 
Etherape provide some
data but you have to be able to interpret it ...
 


Bob Goodwin




More information about the fedora-list mailing list