Shmuel (Seymour J.) Metz wrote:
> In <EMAIL REMOVED>, on 05/31/2007
> at 09:03 PM, Jerry Stuckle <EMAIL REMOVED> said:
>
>> I got out of hardware before the desire for higher accuracy clocks
>> was expressed. I understand the 308x/309x series had more accurate
>> clocks.
>
> Yes, although the granularity was still limited to about 1/4
> nanosecond. IBM later doubled the width of the TOD clock and used the
> extra bits to both increase the epoch and reduce the granularity.
>

1/4 nanosecond? That's an awful small granularity. It's about a 4Ghz
clock - and I don't think you'll find even a mainframe which can execute
that fast. The clock may be faster - but most instructions (even
machine code) take more than one clock cycle. I think that's going to
be sufficient for a while :-)

>> But I also understand the TOD clocks were still being set by
>> operators from their watches...
>
> Yes, but not as often. Then came the sysplex timer[1], which could be
> used to synchronize multiple mainframes. That's when IBM started
> dealing with leap seconds[1]. The syplex timer could synchronize
> itself against an external time source.
>

OK, as I said, that's about the time I got out of hardware (and out of
the field and into an office).

> [1] Now obsolete; IBM has a newer facility.
>
> [2] A misnomer.
>


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
EMAIL REMOVED
==================

In <EMAIL REMOVED>, on 06/01/2007
at 06:56 AM, Jerry Stuckle <EMAIL REMOVED> said:

>1/4 nanosecond? That's an awful small granularity.

That's not the granularity on every model, but the architecture
requires adding a fixed value at the necessary interval so that bit 51
increments every microsecond. That's why the smallest possibloe
granularity is 2^-12 micorseconds rather than exactly 1/4 nanosecond.
The 128 bit TOD clock allows even more room for growth.

>and I don't think you'll find even a mainframe which can execute
>that fast.

I can't really address that question. The algorithms for calculating
instruction timings had gotten quite complex before IBM stopped
publishing them.

>but most instructions (even machine code) take more than one clock
>cycle.

Hard to say; in some cases multiple things occur concurrently in a
single cycle, and since it's a CISC I don't know what you would
consider to be a representative instruction. I wouldn't be surprised
to see, e.g., AR, run in less than a nanosecond, but, e.g., an MVCL of
entire pages will run much longer.

--
Shmuel (Seymour J.) Metz, truly insane Spews puppet
<http://patriot.net/~shmuel>

I reserve the right to publicly post or ridicule any abusive
E-mail. Reply to domain Patriot dot net user shmuel+news to contact
me. Do not reply to EMAIL REMOVED

Shmuel (Seymour J.) Metz wrote:
> In <EMAIL REMOVED>, on 06/01/2007
> at 06:56 AM, Jerry Stuckle <EMAIL REMOVED> said:
>
>> 1/4 nanosecond? That's an awful small granularity.
>
> That's not the granularity on every model, but the architecture
> requires adding a fixed value at the necessary interval so that bit 51
> increments every microsecond. That's why the smallest possibloe
> granularity is 2^-12 micorseconds rather than exactly 1/4 nanosecond.
> The 128 bit TOD clock allows even more room for growth.
>
>> and I don't think you'll find even a mainframe which can execute
>> that fast.
>
> I can't really address that question. The algorithms for calculating
> instruction timings had gotten quite complex before IBM stopped
> publishing them.
>

All of the mainframes nowadays have microcode to execute the
instructions, just like most processors. Most machines execute one
(sometimes two) microcode instructions per clock cycle.

>> but most instructions (even machine code) take more than one clock
>> cycle.
>
> Hard to say; in some cases multiple things occur concurrently in a
> single cycle, and since it's a CISC I don't know what you would
> consider to be a representative instruction. I wouldn't be surprised
> to see, e.g., AR, run in less than a nanosecond, but, e.g., an MVCL of
> entire pages will run much longer.
>

The microcode is very interesting. I was a specialist on the 3148, and
had to learn the microcode. A very interesting language. No sequential
instruction execution at all. Rather, each instruction has the address
of the next instruction as part of the code, fed directly to the address
regs. And virtually every instruction has a branch option - even simple
move instructions could branch depending on the contents.

Even an AR took two or three machine cycles, I forget which. And back
then you couldn't do two things at once. But now you can be fetching
from memory and adding registers on the same clock cycle, for instance.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
EMAIL REMOVED
==================