Correction to the data transfer protocol
parent
6f0a7b0261
commit
ffefec9d45
|
@ -38,7 +38,7 @@ Of course, these chips are not designed as hypercubes. We can't route our own ne
|
||||||
0. Idle - the processor at the receiving end is idle and can accept work;
|
0. Idle - the processor at the receiving end is idle and can accept work;
|
||||||
1. Busy writing - the processor at the sending end is writing data to the buffer, which is not yet complete;
|
1. Busy writing - the processor at the sending end is writing data to the buffer, which is not yet complete;
|
||||||
2. Ready to read - the processor at the sending end has written data to the buffer, and it is complete;
|
2. Ready to read - the processor at the sending end has written data to the buffer, and it is complete;
|
||||||
3. Read - the processor at the receiving end has read the current contents of the buffer.
|
3. Busy reading - the processor at the receiving end is reading the current contents of the buffer.
|
||||||
|
|
||||||
Thus I think it takes at least six clock ticks to write the buffer (set busy-writing, copy four 64 bit words into the buffer, set ready-to-read) and five to read it out - again, more if the messages are cryptographically signed - for an eleven clock tick transfer (the buffers may be allocated in main memory, but in practice they will always live in L2 cache). That's probably cheaper than making a stack frame. All communications channels within the 'crystal' cost exactly the same.
|
Thus I think it takes at least six clock ticks to write the buffer (set busy-writing, copy four 64 bit words into the buffer, set ready-to-read) and five to read it out - again, more if the messages are cryptographically signed - for an eleven clock tick transfer (the buffers may be allocated in main memory, but in practice they will always live in L2 cache). That's probably cheaper than making a stack frame. All communications channels within the 'crystal' cost exactly the same.
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue