Is this interesting/on topic for the list? Anyways...

In message <[EMAIL PROTECTED]> you write:
>gnu not unix wrote:
>> The 2.6.3 kernel with the "ppskit lite" worked pretty well here.
>> I don't have one running at the moment, but I recall it was routinely
>> in the 10's of microseconds offset. A proud member of the herd (grin).

>I got nowhere near that, even when the GPS was the only process running 
>(single user mode).  Maybe there's a tuning option somewhere I missed.

The linux config for 2.6.3 I used is available on my site:

http://www.wraith.sf.ca.us/ntp

There's an ntpq billboard I took off the 2.6.3 host there, it shows 
in the 30's of microseconds offset for that linux kernel.

>> The fanout box is the Big Win here. I've got to replace the differential
>> driver on the roof, though--its gotten badly corroded after a couple
>> years exposure to the elements. 

>Not sure how that helps though..  you end up with multiple tier 1 
>servers on site I guess but they're all synced to exactly the same 
>source!  Surely that's what NTP is there for...

>Now if you had a couple of different GPS, a Radio source, etc. (and if 
>you can get the budget an atomic clock :P)  you could compare them 
>usefully for accuracy.

I have wwv via soundcard on the smidge host, it gets to within
100 microseconds (the limit of the soundcard et al), and I've run
a Trimble SV6 and gotten to within single digit microseconds chime.
I also have a Spectracom WWVB clock, and it got down to the
100's of microseconds as well.

Short of the trick of flying a portable cesium to Boulder, I'm
pretty satisfied that I'm down in the 1's of microseconds to 
The One True Tick. My differential drivers and cable delays add
up to perhaps another 100 nanoseconds of offset. With my ADSL
line, the best I've gotten with external stratum 1's has been
a few hundred microseconds offset. My ratio here is on the
order of 5:1 down/up though.

See the time-nuts mailing list for Those Others...

>> The network here is 100mb switched ethernet. This speed results in
>> 100 microsecond delays. A 10 megabit half duplex isa card will show

>Hmm... 192 here (crosses a gigabit switch but neither box is gigabit.. 
>OTOH the switch is relatively busy):

>*dax.local.nodom .PPS.            1 u  124  128  377    0.192    0.092 
>  0.340

That looks good, thanks for the data point.

>It'd be interesting to see the latency across a pure gigabit connection 
>ie. how much is OS/Interrupt and how much is transmission.

Except, that PCI 33mhz gets you. So, your motherboard needs a PCIX or
a 64bit/66mhz slot for the gigabit card. 

>> up with 1 millisecond delay when added to this setup. It is interesting
>> to see that the freebsd 4.7 unit (smidge) seems to have 100 extra microsecon
>> of udp stack latency, compared to the other two linux 2.4.20/ppskit
>> udp stacks. This may be due to the freebsd kernel having some kind
>> of kernel packet filtering code compiled in, although all the rules
>> are simply wide open. None of the linux boxen have firewall code.

>Could be.. I put it down to the different processor speed on the boxes.

The smidge host, at 350us, is 400Mhz, and the thrall host, at 400Mhz,
is at 180us. I think its the udp path, myself. 

../Steven
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers

Reply via email to