From: Scott Vermillion (scott_ccie_list@it-ag.com)
Date: Sun Mar 02 2008 - 18:05:24 ARST
Well I don't want to get into a totally OT argument here, but clock rate and
data rate are absolutely directly related on synchronous serial interfaces.
Clock slows down, data rate adjusts downward accordingly. Clock speeds up,
data rate adjusts upward accordingly. A clock signal on a serial interface
is not some kind of time of day NTP thing, LOL! The "synchronization" you
refer to is on a bit-by-bit basis. The clock signal is a square wave whose
duty cycle or period drives directly the rate at which data is fed or read
and dictates exactly the time at which the data leads are sampled. I've
looked at more clock signals on an o'scope and troubleshot more circuit
timing issues than I care to recall.
And the duty cycle of that clock signal is dictated by the clock-rate
command configured on the interface, BTW. Break out an o'scope and have
some fun.
As for BITS, yes, as I said, that can be used to time an ONS chassis or the
like. However, it's generally considered an insufficiently accurate clock
source for optical carriers and (at least in my day) was thus used primarily
as a backup (so that SONET nodes wouldn't fall into a timing loop during
failure events in the ring). BITS came into the world to time
plesiochronous digital hierarchy (PDH) devices that predate SONET by quite a
bit (T3 muxes, etc). But due to the proliferation of BITS in the telco
environment, it was only natural that somebody would go asking vendors to
include a BITS input option (again, mainly for backup purposes). The
parallel between BITS and NTP is a very thin one at best. Yes, they both
have to do with timing. But one has to do with exact time of day, whereas
the other does not have anything to do with that at all.
For an interesting read on PDH and synchronous serial timing, check this:
http://www.oreilly.com/catalog/t1survival/chapter/ch05.html
The discussion in this chapter is more broad that the discussion here, so
you can skip to about the halfway point to "Clocking at the Data Port."
While the example is of a T-1 CSU/DSU and an attached DTE, the discussion is
really generic to any DCE/DTE serial circuit. Whenever you see that clock
square wave in a graphic, you're seeing a signal whose period dictates the
speed at which data moves in a given direction. That period is dictated by
the clock-rate command.
From: Fang Gao [mailto:fanggao@gmail.com]
Sent: Sunday, March 02, 2008 12:21 PM
To: Radioactive Frog
Cc: Scott Vermillion; Sadiq Yakasai; Santi; John; ccielab@groupstudy.com
Subject: Re: hdlc clock rate
Hi,
Clock rate has no direct relation with data-rate. (I assume we just talk
about clock rate configuration on the serial port in Cisco routers).
Clock rate is used only on SERIAL port to feed on clock pin in order to
synchronize the data stream between DCE and DTE.
The serial port (V35 or RS232, or high-speed....) has separate pins for data
stream and clock. Clock-rate feeds the signal on Clock pin. The data go
through Tx/Rx data pins. They are not direct related. As long as DCE and
DTE are synched., the data will transmit over the serial connection.
You can choose any available clock rate (by "clock rate ?") to configure DCE
port.
BITS on Cisco 14545 optical switch is different story. BITS is used to sync
SONET or SDH optical devices. BITS uses T1/E1 as a timing source, similar to
NTP in cisco routers.
HTH
On Sat, Mar 1, 2008 at 10:41 PM, Radioactive Frog <pbhatkoti@gmail.com>
wrote:
I have seen 2 megs station clock feed even the link speed was 6 megs using a
HWIC2T cards.
Check the specification of the HSSI port. IT takes 2 megs clock but can
support port speed upto 52 megs.
So ,.. still clock rate vs data-rate is unclear!
Frog
This archive was generated by hypermail 2.1.4 : Tue Apr 01 2008 - 07:53:52 ART