Chris Albertson wrote:
On Mon, Mar 7, 2011 at 2:11 PM, David Woolley
wrote:
Terje Mathisen wrote:
David Woolley wrote:
Chris Albertson wrote:
If you are on an isolated network a better setup is to put three
SERVER lines in each config file where each of the tree computers has
itself and
On Sun, Mar 06, 2011 at 11:22:34AM +, David Woolley wrote:
> Ralph wrote:
>
> >filtoffset= 67671.8 66534.8 65931.3 65118.0 63317.3 63029.5 62216.4 58156.6,
>
> Your frequency error is way outside any reasonable bounds, which is
> reflecting in a very high jitter, which is probably the ultimat
Ok. The host OS time is fine so I'd have no problem using that
as the source for my linux guest.
What no one has provided yet is an answer to 'how' to get the
linux guest VM to get the proper time from the host?
___
questions mailing list
questions@list
Sorry if the formatting is bad.
I don't have a local newsfeed (ISPs seems to have abonded providing that)
so I have to post via google. I wraps fine on their editor but I can see
where it might not format well in the newsfeed.
___
questions mailing lis
> When are you going to start working on it?
> ... or are you asking others to do free programming
> for you, to work around your unique problem?
Maybe I deserve that flame for having ranted a bit, but
I hardly think the problem of clock time that won't behave
within a linux guest VM is 'un
Well it started out as NTP's problem because apparently the
clock instability makes it so NTP can't run right on the guest.
I understand this isn't so much an NTP problem if the expectation
is that NTP can't run on a guest OS, but since everyone seemed to
state so matter of factly that the guest sh
"Ralph" wrote in message
news:c5b90638-395f-4e77-8761-f99c25343...@glegroupsg2000goo.googlegroups.com...
Ok. The host OS time is fine so I'd have no problem using that
as the source for my linux guest.
What no one has provided yet is an answer to 'how' to get the
linux guest VM to get the prope
Host OS is windows (2008 if we want to get specific)
nose and corkskrew is nessecary because frankly I'm not
accustomed to there being any difference between a guest
OS and a physical OS in most cases and even when there is
it hasn't been relevant what the host OS is.
Sorry if the formatting is bad.
I don't have a local newsfeed (ISPs seems to have abonded providing
that)
so I have to post via google. I wraps fine on their editor but I can
see
where it might not format well in the newsfeed.
Ralph,
You may be able to use one of the free news services inst
"Terje Mathisen" <"terje.mathisen at tmsw.no"> wrote in message
news:54vg48-ttp2@ntp6.tmsw.no...
[]
A RAIG (Redundant Array of Inexpensive GPSs) setup solves that problem
as well. :-)
I.e. as I wrote I have 3 Oncores as well.
Terje
3 GPS for about US $100 and a little soldering:
http:
David J Taylor wrote:
> "Ralph" wrote in message
> news:d695207e-04ec-4664-8580-35bc25806...@glegroupsg2000goo.googlegroups.com...
>> Well it started out as NTP's problem because apparently the
>> clock instability makes it so NTP can't run right on the guest.
>> I understand this isn't so much
"Ralph" wrote in message
news:d695207e-04ec-4664-8580-35bc25806...@glegroupsg2000goo.googlegroups.com...
Well it started out as NTP's problem because apparently the
clock instability makes it so NTP can't run right on the guest.
I understand this isn't so much an NTP problem if the expectation
i
Ralph wrote:
Host OS is windows (2008 if we want to get specific)
nose and corkskrew is nessecary because frankly I'm not
accustomed to there being any difference between a guest
OS and a physical OS in most cases and even when there is
it hasn't been relevant what the host OS is.
Hi Ralph,
Y
"Rob" wrote in message []
VMware advises to run ntpd in the guest.
Thanks, Rob. I wonder whether this is a change from their earlier
suggestions? I see that they now do suggest this as one route (as well as
providing their own time synchronisation program as another option). Are
the reco
On 3/8/2011 4:16 AM, Miroslav Lichvar wrote:
On Sun, Mar 06, 2011 at 11:22:34AM +, David Woolley wrote:
Ralph wrote:
filtoffset= 67671.8 66534.8 65931.3 65118.0 63317.3 63029.5 62216.4 58156.6,
Your frequency error is way outside any reasonable bounds, which is
reflecting in a very high
On Tue, Mar 8, 2011 at 1:16 AM, Miroslav Lichvar wrote:
> On Sun, Mar 06, 2011 at 11:22:34AM +, David Woolley wrote:
> This seems to be a common problem and with virtual machines getting
> everywhere it will probably only get worse. I'm wondering how hard it
> would be for ntpd to detect that
On Mon, Mar 7, 2011 at 10:32 PM, Terje Mathisen <"terje.mathisen at
tmsw.no"@ntp.org> wrote:
>> The problem is that on an isolated island of N servers you want to
>> automatically select the one server that has the "best" clock even
>> when some computers are not running. I think "orphan" handles
Maybe I read this too quickly, but the report published today by the
UK Royal Academy of Engineering (see
http://www.raeng.org.uk/news/publications/list/reports/RAoE_Global_Navigation_Systems_Report.pdf
and also the BBC coverage at
http://www.bbc.co.uk/news/science-environment-12668230)
seems to b
On 2011-03-08, Ralph wrote:
>
>
>> When are you going to start working on it?
>> ... or are you asking others to do free programming
>> for you, to work around your unique problem?
>
> Maybe I deserve that flame for having ranted a bit, but
> I hardly think the problem of clock time that wo
On 2011-03-08, Ralph wrote:
> Host OS is windows (2008 if we want to get specific)
>
> nose and corkskrew is nessecary because frankly I'm not
> accustomed to there being any difference between a guest
> OS and a physical OS in most cases and even when there is
> it hasn't been relevant what the h
I'm going to end this particular line of discussion because
it is clear that this is a fruitless conversation and arguing
back and forth about my personal ability to code a solution for
VM time syncronization doesn't do anything for the problem at
hand.
On 2011-03-08, Richard B. Gilbert wrote:
> On 3/8/2011 4:16 AM, Miroslav Lichvar wrote:
>> On Sun, Mar 06, 2011 at 11:22:34AM +, David Woolley wrote:
>>> Ralph wrote:
>>>
filtoffset= 67671.8 66534.8 65931.3 65118.0 63317.3 63029.5 62216.4
58156.6,
>>>
>>> Your frequency error is way
JohnAllen wrote:
Maybe I read this too quickly, but the report published today by the
UK Royal Academy of Engineering (see
http://www.raeng.org.uk/news/publications/list/reports/RAoE_Global_Navigation_Systems_Report.pdf
and also the BBC coverage at
http://www.bbc.co.uk/news/science-environment-1
Well along those lines, what about creating a driver or deamon (for
lack of something better to call it) that provides time to ntpd that
gets that time from the host machine? Similar to the local clock
setting but somehow trusting the host. Or would that still have the
problems with high jitter w
On Tue, Mar 08, 2011 at 05:00:44PM +, unruh wrote:
> filtoffset= 67671.8 66534.8 65931.3 65118.0 63317.3 63029.5 62216.4
> 58156.6,
> Not at all sure how Mills comes into the picture. On a system where the
> frequency fluctuates wildly, ntpd is not the right answer, nor is any
> sys
On 2011-03-08, Ralph wrote:
> Well along those lines, what about creating a driver or deamon (for
> lack of something better to call it) that provides time to ntpd that
> gets that time from the host machine? Similar to the local clock
> setting but somehow trusting the host. Or would that still
JohnAllen wrote:
> Maybe I read this too quickly, but the report published today by the
> UK Royal Academy of Engineering (see
> http://www.raeng.org.uk/news/publications/list/reports/RAoE_Global_Navigation_Systems_Report.pdf
> and also the BBC coverage at
> http://www.bbc.co.uk/news/science-envi
On 2011-03-08, j...@specsol.spam.sux.com wrote:
> JohnAllen wrote:
>> Maybe I read this too quickly, but the report published today by the
>> UK Royal Academy of Engineering (see
>> http://www.raeng.org.uk/news/publications/list/reports/RAoE_Global_Navigation_Systems_Report.pdf
>> and also the BB
On Tue, Mar 8, 2011 at 9:04 AM, Ralph wrote:
> I'm going to end this particular line of discussion because
> it is clear that this is a fruitless conversation and arguing
> back and forth about my personal ability to code a solution for
> VM time syncronization doesn't do anything for the problem
On Mar 8, 2011, at 9:13 AM, Ralph wrote:
> Well along those lines, what about creating a driver or deamon (for
> lack of something better to call it) that provides time to ntpd that
> gets that time from the host machine?
I still haven't been able to figure out which virtualization system you are
>> There is a big difference between keeping a computer's time of day clock
>> set to the current time (NTP) and maintaining timing or frequency control
>> in a telecom system.
>
> And exactly what is that difference? While ntp is perhaps too slow to
> respond to local frequency changes, how do you
On 2011-03-08, Miroslav Lichvar wrote:
> On Tue, Mar 08, 2011 at 05:00:44PM +, unruh wrote:
>> filtoffset= 67671.8 66534.8 65931.3 65118.0 63317.3 63029.5 62216.4
>> 58156.6,
>
>> Not at all sure how Mills comes into the picture. On a system where the
>> frequency fluctuates wildly,
On 08/03/11 19:39, unruh wrote:
And exactly what is that difference? While ntp is perhaps too slow to
respond to local frequency changes, how do you see the difference
between keeping a computer's idea of local time accurate from keeping a
telecom's idea of local time accurate?
GPS is used not
Jan Ceuleers wrote:
On 08/03/11 19:39, unruh wrote:
And exactly what is that difference? While ntp is perhaps too slow to
respond to local frequency changes, how do you see the difference
between keeping a computer's idea of local time accurate from keeping a
telecom's idea of local time accura
unruh wrote:
> On 2011-03-08, j...@specsol.spam.sux.com wrote:
>> JohnAllen wrote:
>>> Maybe I read this too quickly, but the report published today by the
>>> UK Royal Academy of Engineering (see
>>> http://www.raeng.org.uk/news/publications/list/reports/RAoE_Global_Navigation_Systems_Report.pd
On Mar 8, 2011, at 11:28 AM, Chris Albertson wrote:
>> And exactly what is that difference? While ntp is perhaps too slow to
>> respond to local frequency changes, how do you see the difference
>> between keeping a computer's idea of local time accurate from keeping a
>> telecom's idea of local tim
Uwe wrote:
> No GPS seems to kill any CDMA mobile networks.
> GSM isn't affected at all.
>
> How masochistic must one be to do telco infrastructure in such
> a haphazard way?
That seems more sadistic than masochistic to me...
H
___
questions mailing li
Chris Albertson wrote:
NTP simply is not good enough for use in a tower so it is not used.
And why would they use it when all towers by definition have a clear
view of the sky
IMHO the basic concept of your system is broken when you have
sync to such high requirements and need external infrastr
On 2011-03-08, Chuck Swiger wrote:
> Seriously, each physical machine only has one RTC and crystal
> oscillator. It's useful to run one instance of ntpd in the Dom0 (or
> host ESX) context where it can actually work and keep this real
> hardware clock in sync.
NTP disciplines the system (i.e. ke
On Tue, Mar 8, 2011 at 1:14 PM, Uwe Klein
wrote:
> IMHO the basic concept of your system is broken when you have
> sync to such high requirements and need external infrastructure
> to achieve this.
> this then is an extremely fickle system that lacks robustness.
I can't defend the design of CDMA
Uwe Klein wrote:
> Chris Albertson wrote:
>> NTP simply is not good enough for use in a tower so it is not used.
>> And why would they use it when all towers by definition have a clear
>> view of the sky
>
> IMHO the basic concept of your system is broken when you have
> sync to such high require
On Mar 8, 2011, at 1:18 PM, Steve Kostecke wrote:
On 2011-03-08, Chuck Swiger wrote:
>> Seriously, each physical machine only has one RTC and crystal
>> oscillator. It's useful to run one instance of ntpd in the Dom0 (or
>> host ESX) context where it can actually work and keep this real
>> hardwar
"David J Taylor" wrote in message
news:ijk0a0$ssp$1...@news.eternal-september.org...
>> Ok I'll go back over your past posts re the problem and report it myself
>> to Garmin UK and see what they say - once I get something back I'll let
>> you know.
>>
>> I have 3.60 running anyway with no new
On 2011-03-08, Chuck Swiger wrote:
> On Mar 8, 2011, at 1:18 PM, Steve Kostecke wrote:
>
>> On 2011-03-08, Chuck Swiger wrote:
>>
>>> Seriously, each physical machine only has one RTC and crystal
>>> oscillator. It's useful to run one instance of ntpd in the Dom0 (or
>>> host ESX) context where
"Chris Albertson" wrote in message
news:aanlktimwu-ezzxv9pp-gbg9mft1ylhsf9edrdzlkj...@mail.gmail.com...
> I can't defend the design of CDMA cell technology. But I'm sure a lot
> of it was driven by trying to get as many calls as possible into a
> limited bandwidth. Another requirement for
45 matches
Mail list logo
