Clock speed

EEA index Clocks Clock speed Acorn2 clock SJ clock Other clocks Intro FileStore MDFS Others Clocks Bridges Interfaces Misc h/w Testing Misc info

The clock pulse There are three parts of the clock signal that you need to be aware of: MARK - this is when the clock signal is high (on). SPACE - this is when the clock signal is low (off). PERIOD - this is the speed of the clock, which is MARK + SPACE. 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: Longer networks require a slower clock speed to prevent spurious signals and data collision in the cable. Poorer quality cable requires a slower clock speed. The best cable is dual twisted pair with shielding. Some people, on the other hand, use 6-core (unshielded) telephone cable! The minimum time required for your stations to recognise the clock.   Response time The 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). Computer Quoted Achieved Comments BBC micro / Master 4µs 4µs (250kHz) SJ recommend 5.25µs FileStore 4µs - Only likes its own clock?!? SJ MDFS 3µs 2µs (500kHz) Not when using FAST SJ Econet Bridge 3µs 2µs (500kHz) RISC OS computer 2µs 1½µs (~660kHz) 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 speed It 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 × c Where: d = distance of the longest side of the network (in metres) v = velocity factor - assume 0.5 for most cables c = the speed of light - 300,000,000 (3×108) 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 × 300000000 Therefore, 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. Therefore we can determine that the relative delay between the emission of the clock pulse and the reception of its related data increases by one microsecond for every hundred metres of cable.   The minimum MARK One 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 PERIOD For 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 box If 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! Clock at one end   Clock in the middle   Actual implementation If 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...