time-nuts@lists.febo.com

Discussion of precise time and frequency measurement

View all threads

Re: [time-nuts] GPS for Nixie Clock

HM
Hal Murray
Tue, Jul 12, 2016 8:21 PM

In addition, even MCU has not enough resources to handle TCP/IP, DHCP  and
NTP, it is some solutions available to outsource it to dedicated  chips. I
was using WIZ5100 (assembled as a modules) with great success.

NTP is pretty simple.  If you are willing to take a few shortcuts, things get even simpler.  If you have a NTP server on your LAN, you can skip routing and DHCP by broadcasting a request.  It would be interesting to see how small you could make a set-the-time package.

The Xerox Alto had an Ethernet boot loader in microcode.  (and space in the microcode ROM was tight)  When bringing up a new machine, we figured out that it was much simpler and faster to debug the Ethernet before the disk controller.  The debugger worked over the Ethernet.  That gave you a solid place to stand early in the debugging process.

--
These are my opinions.  I hate spam.

time@patoka.org said: > In addition, even MCU has not enough resources to handle TCP/IP, DHCP and > NTP, it is some solutions available to outsource it to dedicated chips. I > was using WIZ5100 (assembled as a modules) with great success. NTP is pretty simple. If you are willing to take a few shortcuts, things get even simpler. If you have a NTP server on your LAN, you can skip routing and DHCP by broadcasting a request. It would be interesting to see how small you could make a set-the-time package. The Xerox Alto had an Ethernet boot loader in microcode. (and space in the microcode ROM was tight) When bringing up a new machine, we figured out that it was much simpler and faster to debug the Ethernet before the disk controller. The debugger worked over the Ethernet. That gave you a solid place to stand early in the debugging process. -- These are my opinions. I hate spam.
V
Vlad
Tue, Jul 12, 2016 8:43 PM

DHCP is handy to provide the IP address and specify which NTP server to
use. Using DHCP I don't need to setup all the network settings for my
project. The NTP packet parser itself is really small and doing its duty
very well. Using such setup, it gives me flexibility to choose the
different NTP servers as a time source. It could be my own NTP or it
could be NTP pool.

On 2016-07-12 16:21, Hal Murray wrote:

In addition, even MCU has not enough resources to handle TCP/IP, DHCP
and
NTP, it is some solutions available to outsource it to dedicated
chips. I
was using WIZ5100 (assembled as a modules) with great success.

NTP is pretty simple.  If you are willing to take a few shortcuts,
things get even simpler.  If you have a NTP server on your LAN, you
can skip routing and DHCP by broadcasting a request.  It would be
interesting to see how small you could make a set-the-time package.

The Xerox Alto had an Ethernet boot loader in microcode.  (and space
in the microcode ROM was tight)  When bringing up a new machine, we
figured out that it was much simpler and faster to debug the Ethernet
before the disk controller.  The debugger worked over the Ethernet.
That gave you a solid place to stand early in the debugging process.

--
WBW,

V.P.

DHCP is handy to provide the IP address and specify which NTP server to use. Using DHCP I don't need to setup all the network settings for my project. The NTP packet parser itself is really small and doing its duty very well. Using such setup, it gives me flexibility to choose the different NTP servers as a time source. It could be my own NTP or it could be NTP pool. On 2016-07-12 16:21, Hal Murray wrote: > time@patoka.org said: >> In addition, even MCU has not enough resources to handle TCP/IP, DHCP >> and >> NTP, it is some solutions available to outsource it to dedicated >> chips. I >> was using WIZ5100 (assembled as a modules) with great success. > > NTP is pretty simple. If you are willing to take a few shortcuts, > things get even simpler. If you have a NTP server on your LAN, you > can skip routing and DHCP by broadcasting a request. It would be > interesting to see how small you could make a set-the-time package. > > The Xerox Alto had an Ethernet boot loader in microcode. (and space > in the microcode ROM was tight) When bringing up a new machine, we > figured out that it was much simpler and faster to debug the Ethernet > before the disk controller. The debugger worked over the Ethernet. > That gave you a solid place to stand early in the debugging process. -- WBW, V.P.
JS
John Swenson
Wed, Jul 13, 2016 1:15 AM

Hi Hal,
I've done NTP before, I wanted to do this with GPS since I have never
done a GPS implementation before.

Xerox Alto, wow that brings back memories! My dad worked at Xerox in
Palo Alto for 20 years in the 70s and 80s. He primarily worked on the D
machines but I did get to use an Alto a few times when I was in high
school. I learned Mesa sitting in front of one.

That must have been 3Mbit Ethernet right?

I remember going to the lab one Saturday, they were working on a machine
that was supposed to have a custom chip, but it was not ready, so they
used 7 ASICs, but those were not ready yet either, so they made a large
board out of TTL for each ASIC with a ribbon cable into the motherboard,
these boards were hung on fishing line from the ceiling so they were
just above the motherboard with a very short cable. That thing really
looked like something out of a movie.

John S.

On 7/12/2016 1:21 PM, Hal Murray wrote:

In addition, even MCU has not enough resources to handle TCP/IP, DHCP  and
NTP, it is some solutions available to outsource it to dedicated  chips. I
was using WIZ5100 (assembled as a modules) with great success.

NTP is pretty simple.  If you are willing to take a few shortcuts, things get even simpler.  If you have a NTP server on your LAN, you can skip routing and DHCP by broadcasting a request.  It would be interesting to see how small you could make a set-the-time package.

The Xerox Alto had an Ethernet boot loader in microcode.  (and space in the microcode ROM was tight)  When bringing up a new machine, we figured out that it was much simpler and faster to debug the Ethernet before the disk controller.  The debugger worked over the Ethernet.  That gave you a solid place to stand early in the debugging process.

Hi Hal, I've done NTP before, I wanted to do this with GPS since I have never done a GPS implementation before. Xerox Alto, wow that brings back memories! My dad worked at Xerox in Palo Alto for 20 years in the 70s and 80s. He primarily worked on the D machines but I did get to use an Alto a few times when I was in high school. I learned Mesa sitting in front of one. That must have been 3Mbit Ethernet right? I remember going to the lab one Saturday, they were working on a machine that was supposed to have a custom chip, but it was not ready, so they used 7 ASICs, but those were not ready yet either, so they made a large board out of TTL for each ASIC with a ribbon cable into the motherboard, these boards were hung on fishing line from the ceiling so they were just above the motherboard with a very short cable. That thing really looked like something out of a movie. John S. On 7/12/2016 1:21 PM, Hal Murray wrote: > > time@patoka.org said: >> In addition, even MCU has not enough resources to handle TCP/IP, DHCP and >> NTP, it is some solutions available to outsource it to dedicated chips. I >> was using WIZ5100 (assembled as a modules) with great success. > > NTP is pretty simple. If you are willing to take a few shortcuts, things get even simpler. If you have a NTP server on your LAN, you can skip routing and DHCP by broadcasting a request. It would be interesting to see how small you could make a set-the-time package. > > The Xerox Alto had an Ethernet boot loader in microcode. (and space in the microcode ROM was tight) When bringing up a new machine, we figured out that it was much simpler and faster to debug the Ethernet before the disk controller. The debugger worked over the Ethernet. That gave you a solid place to stand early in the debugging process. > >