The clock pulse
There are three parts of the clock signal that you need to be aware of:
Data is transmitted on the falling edge of the mark. Therefore, within a certain period, you ideally want the mark as short as possible and the space as long as possible. The faster your clock goes, the faster you can transfer data across the network. However this is mitigated by three factors:
Response timeThe duration required for each type of machine to recognise the clock is shown below, along with experimental times taken from my network (as it was in 1999).
A tiny caveat here is the MDFS. My MDFS was quite happy serving using a 0.5µs MARK in a 2µs PERIOD. When I came to use the "FAST" terminal to talk directly to the MDFS firmware, it failed on anything faster than a 1µs MARK in a 4µs PERIOD... A considerable difference!
Calculating the best clock speedIt is not possible to exactly calculate the best duration of the MARK. In essence, what you need to do is set the MARK to the fastest that permits all stations to recognise it.
Given that the data transfer takes place in the SPACE, we can calculate the SPACE as follows:
2 × d S = ----- v × cWhere:
d = distance of the longest side of the network (in metres)For example, a 600m network with the clock 200m from one end and 400m from the other.
2 × 400 S = --------------- = 5.33333333E-6 (rounded to 6µs) 0.5 × 300000000Therefore, your SPACE is 6µs. As the network is long, try your MARK at 1µs, which gives you a PERIOD of 7µs - an overall frequency of 143kHz.
Put it like this, you may be wondering why we have such a long SPACE value when we are talking about the speed of light. The problem is, in cabling, the signals travel it what is affectively 200 metres for every microsecond. Logically, the further you are from the clock box, the later you will receive the clock signal. It gets even better - for not only will the furthest station receive the clock signal the latest, it will put its own data on the line the latest, and - not to forget - that transmission will have the same lag in being 'propagated' across the network.
The minimum MARKOne thing that should be bourne in mind when selecting the MARK timing is the ability of the ADLC to recognise it. According to the datasheet, the 68B54, as used in Econet interfaces, responds as follows:
Taking this as a guide, it would be logical to figure that the clock high should be no less than 280ns and the clock low should be no less than 280ns for correct operation. Together these add up to 0.56µs, so running the clock MARK at 0.5µs is pushing the hardware.
In reality, for small networks, you may find that half a microsecond works perfectly well. It did for me. If your machines have problems, and you are using an SJ clock box, you can step up to 0.75µs which should be more than adequate.
The minimum PERIODFor those who are interested, there is a gobbledegook formula to work out the maximum data rate that you can push through the ADLC. Here it is:
In essence, as the ADLC is not blessed with a big FIFO buffer, the data rate of what we can push through the Econet is based purely upon the responsiveness of the hardware in total. The ADLC can more than cope. The importance is how quickly the firmware can respond to the interrupt, and how quickly it can deal with received data. This is why 6502 machines need a clock in the order of 5µs per bit, while the ARM machines can run a tad better than 2µs per bit.
Siting the clock boxIf you consider the final paragraphs above, we can figure that a way to reduce the problem of propagation delays is to minimise this potential. What this means is that if the clock is at one and of the network (say, alongside a server) and the station at the furthest end of the network is talking to the server; we must take into account the total time for the signal to travel the network wire plus the return time.
On the other hand, if we locate the clock box in the middle of the network, then we can cut this propagation delay in half, as the clock pulse will be radiating out from the centre. It will reach the extremities faster than if the signal had to travel from one side to the other.
These simple diagrams show this in practice. It may appear that the one on the right is running about twice as quickly. In all cases, the red ball moves by its own width each frame, with an 8cs delay between frames. Feel free to check this in a GIF editor; and when you have, believe that putting the clock in the middle of the network is a very good idea!
Actual implementationIf the maths does your head in, the best thing to do is to set the above recommended clock speed, and then increase it in small steps until you the network becomes unstable; then slow it down a step.
You should, on average, be able to shave at least a µs off of the recommended speeds, except for 6502 based equipment such as BBC micros and FileStores.
The MDFS cannot quite keep up with RISC OS machines, but it isn't far behind - and you will find your network is quite comfortable operating a tiny bit slower in order to allow the MDFS to be used. Certainly, you will benefit more from the advanced features that the MDFS offers, than from the extra ½µs...