Universal Parallel Bus -- why not?

On Mon, 5 Dec 2016 05:14:44 -0800 (PST), jrwalliker@gmail.com wrote:

>On Saturday, 3 December 2016 10:47:53 UTC, upsid...@downunder.com  wrote:
>
>> One problem with high speed parallel connections is the need to keep
>> the path lengths exactly the same for each connection to be able to
>> direct sample full words. At high speeds, you need to use some self
>> clocking on each wire and after clock skew elimination to build a full
>> word. 
>
>Even if the path lengths are exactly the same there is dispersion to 
>deal with.  The propagation velocity is frequency dependent, so data-
>dependent timing errors creep in.
>
>Long ago I was involved in transmitting digital TV signals around a
>building.  To cut costs the designer tried using twisted pair
>telephone wire with one bit per pair plus a clock pair.  It was
>impossible to get reliable operation at 50m range because of dispersion
>no matter how much tweaking of timing delays was done.
>
>John

This is a well known phenomenon.

While working with (physically) big computers in the 1970's in which
1/2 inch 9 track (8 data bits+(odd)parity was used). The 800 BPI (bits
per inch) drives were quite unreliable. 

The assumption was that  odd parity with 8 data bits would generate  a
clean synch for all tracks. 

Depending on the read head azimuth angle, this was seldom the case.

In reality, you had to manually adust the azimuth angle for each tape
written on a separate drive.

The 1600 BPI tapes were much better due to the chancel specific self
clocking encoding.

jrwalliker@gmail.com wrote:
> On Saturday, 3 December 2016 10:47:53 UTC, upsid...@downunder.com  wrote:
>
>> One problem with high speed parallel connections is the need to keep
>> the path lengths exactly the same for each connection to be able to
>> direct sample full words. At high speeds, you need to use some self
>> clocking on each wire and after clock skew elimination to build a full
>> word.
>
> Even if the path lengths are exactly the same there is dispersion to
> deal with.  The propagation velocity is frequency dependent, so data-
> dependent timing errors creep in.
>
> Long ago I was involved in transmitting digital TV signals around a
> building.  To cut costs the designer tried using twisted pair
> telephone wire with one bit per pair plus a clock pair.  It was
> impossible to get reliable operation at 50m range because of dispersion
> no matter how much tweaking of timing delays was done.
>
> John
   Which gives a good lesson of what not to do and what to look for.
   So a UPB needs a relatively low dispersion data path and a clock rate 
that is limited by frequency dependent issues.
   If speed is of the essense, use of different wavelengths for each 
channel would most likely limit total path length to an "impractical" 
amount (ie design cost not worth t).
   Still, a CPU board using light instead of wires/traces could be 
designed that would "kick ass" for parallel, multi-processing.

On Monday, 5 December 2016 23:01:28 UTC, Robert Baer  wrote:
> jrwalliker@gmail.com wrote:
> > On Saturday, 3 December 2016 10:47:53 UTC, upsid...@downunder.com  wrote:
> >
> >> One problem with high speed parallel connections is the need to keep
> >> the path lengths exactly the same for each connection to be able to
> >> direct sample full words. At high speeds, you need to use some self
> >> clocking on each wire and after clock skew elimination to build a full
> >> word.
> >
> > Even if the path lengths are exactly the same there is dispersion to
> > deal with.  The propagation velocity is frequency dependent, so data-
> > dependent timing errors creep in.
> >
> > Long ago I was involved in transmitting digital TV signals around a
> > building.  To cut costs the designer tried using twisted pair
> > telephone wire with one bit per pair plus a clock pair.  It was
> > impossible to get reliable operation at 50m range because of dispersion
> > no matter how much tweaking of timing delays was done.
> >
> > John
>    Which gives a good lesson of what not to do and what to look for.
>    So a UPB needs a relatively low dispersion data path and a clock rate 
> that is limited by frequency dependent issues.
>    If speed is of the essense, use of different wavelengths for each 
> channel would most likely limit total path length to an "impractical" 
> amount (ie design cost not worth t).
>    Still, a CPU board using light instead of wires/traces could be 
> designed that would "kick ass" for parallel, multi-processing.

All you need do is run your parallel lines as several serial lines in parallel. Low cost is what rules now though.


NT

On Monday, December 5, 2016 at 3:04:25 PM UTC-8, tabb...@gmail.com wrote:
> On Monday, 5 December 2016 23:01:28 UTC, Robert Baer  wrote:

> All you need do is run your parallel lines as several serial lines in parallel. Low cost is what rules now though.

That's what gigabit Ethernet does (1000baseT) with its four pairs.  It qualifies
as low cost after you amortize the (relatively complex) design of the dedicated
ASIC hardware.   The best way to do a fast parallel port nowadays might be
to bond a multiplicity of gigabit wired Ethernet ports (but the switch fabric
requires multiport Ethernet switches to do some nonstandard things to make a
one-to-many node).   

Outside of a server room, does anyone really have a need for such?  There
were four-bytes-at-a-time SCSI parallel ports, but not a lot of use for them.

On Mon, 5 Dec 2016 15:38:26 -0800 (PST), whit3rd <whit3rd@gmail.com>
wrote:

>On Monday, December 5, 2016 at 3:04:25 PM UTC-8, tabb...@gmail.com wrote:
>> On Monday, 5 December 2016 23:01:28 UTC, Robert Baer  wrote:
>
>> All you need do is run your parallel lines as several serial lines in parallel. Low cost is what rules now though.
>
>That's what gigabit Ethernet does (1000baseT) with its four pairs.  It qualifies
>as low cost after you amortize the (relatively complex) design of the dedicated
>ASIC hardware.   The best way to do a fast parallel port nowadays might be
>to bond a multiplicity of gigabit wired Ethernet ports (but the switch fabric
>requires multiport Ethernet switches to do some nonstandard things to make a
>one-to-many node).   
>
>Outside of a server room, does anyone really have a need for such?  There
>were four-bytes-at-a-time SCSI parallel ports, but not a lot of use for them.

Uncompressed video sucks up a lot of bandwidth.

On 2016-12-06 00:01, Robert Baer wrote:
[...]
>    Still, a CPU board using light instead of wires/traces could be
> designed that would "kick ass" for parallel, multi-processing.
>

Why? What advantage do you imagine that might have?

Jeroen Belleman

On 2016-12-05, whit3rd <whit3rd@gmail.com> wrote:
> On Monday, December 5, 2016 at 3:04:25 PM UTC-8, tabb...@gmail.com wrote:
>> On Monday, 5 December 2016 23:01:28 UTC, Robert Baer  wrote:
>
>> All you need do is run your parallel lines as several serial lines in parallel. Low cost is what rules now though.
>
> That's what gigabit Ethernet does (1000baseT) with its four pairs.  It qualifies
> as low cost after you amortize the (relatively complex) design of the dedicated
> ASIC hardware.   The best way to do a fast parallel port nowadays might be
> to bond a multiplicity of gigabit wired Ethernet ports (but the switch fabric
> requires multiport Ethernet switches to do some nonstandard things to make a
> one-to-many node).   

sounde like a poor immitation of 16x PCIe.

> Outside of a server room, does anyone really have a need for such?  There
> were four-bytes-at-a-time SCSI parallel ports, but not a lot of use for them.

every gamer.

-- 
This email has not been checked by half-arsed antivirus software 

On Mon, 05 Dec 2016 15:01:24 -0800, Robert Baer
<robertbaer@localnet.com> wrote:

>jrwalliker@gmail.com wrote:
>> On Saturday, 3 December 2016 10:47:53 UTC, upsid...@downunder.com  wrote:
>>
>>> One problem with high speed parallel connections is the need to keep
>>> the path lengths exactly the same for each connection to be able to
>>> direct sample full words. At high speeds, you need to use some self
>>> clocking on each wire and after clock skew elimination to build a full
>>> word.
>>
>> Even if the path lengths are exactly the same there is dispersion to
>> deal with.  The propagation velocity is frequency dependent, so data-
>> dependent timing errors creep in.
>>
>> Long ago I was involved in transmitting digital TV signals around a
>> building.  To cut costs the designer tried using twisted pair
>> telephone wire with one bit per pair plus a clock pair.  It was
>> impossible to get reliable operation at 50m range because of dispersion
>> no matter how much tweaking of timing delays was done.
>>
>> John
>   Which gives a good lesson of what not to do and what to look for.
>   So a UPB needs a relatively low dispersion data path and a clock rate 
>that is limited by frequency dependent issues.
>   If speed is of the essense, use of different wavelengths for each 
>channel would most likely limit total path length to an "impractical" 
>amount (ie design cost not worth t).
>   Still, a CPU board using light instead of wires/traces could be 
>designed that would "kick ass" for parallel, multi-processing.

SFPs
https://en.wikipedia.org/wiki/Small_form-factor_pluggable_transceiver
are available up to at least 10 GBit/s (SFB+) so you get a decent
throughput with a single fiber.

OTOH, CWDM SFPs are available with different wavelengths (every 20
nm), so you can put 8 lamdas into a single fiber with simple passive
combiners and splitters. Unfortunately the SFP is quite big, if you
want to  put 8 of these into the edge of the PCB.

On Tue, 6 Dec 2016 08:41:40 +0100, Jeroen Belleman
<jeroen@nospam.please> wrote:

>On 2016-12-06 00:01, Robert Baer wrote:
>[...]
>>    Still, a CPU board using light instead of wires/traces could be
>> designed that would "kick ass" for parallel, multi-processing.
>>
>
>Why? What advantage do you imagine that might have?

If you are building something similar to the Connection Machines
Hypercube computer, using CAT6 cabling would quickly consumes most of
the cube module volume.

Using fiber optic cables with multiple fibers and using WDM on each
fiber will have a huge throughput for a specific cable volume. It
might even make possible direct connection between any two nodes in
the cube.

Most massively parallel computers have direct connection to only a few
nearby nodes in each dimension and relying on mesh networking further
away. This greatly increases latency, when latency prone
serializing/deserialisation is applied in each hop.

Getting to any node with a single pair of desers would speed up things
greatly.

On 12/06/2016 05:55 AM, upsidedown@downunder.com wrote:
> On Tue, 6 Dec 2016 08:41:40 +0100, Jeroen Belleman
> <jeroen@nospam.please> wrote:
> 
>> On 2016-12-06 00:01, Robert Baer wrote:
>> [...]
>>>    Still, a CPU board using light instead of wires/traces could be
>>> designed that would "kick ass" for parallel, multi-processing.
>>>
>>
>> Why? What advantage do you imagine that might have?
> 
> If you are building something similar to the Connection Machines
> Hypercube computer, using CAT6 cabling would quickly consumes most of
> the cube module volume.
> 
> Using fiber optic cables with multiple fibers and using WDM on each
> fiber will have a huge throughput for a specific cable volume. It
> might even make possible direct connection between any two nodes in
> the cube.

WDM isn't too helpful in general except for long links, but fibre has
been used inside large computers and data centers for yonks.

> 
> Most massively parallel computers have direct connection to only a few
> nearby nodes in each dimension and relying on mesh networking further
> away. This greatly increases latency, when latency prone
> serializing/deserialisation is applied in each hop.
> 
> Getting to any node with a single pair of desers would speed up things
> greatly.

On-chip optics is the win.  Turns out that you should be able to do
communication faster (~c/4 for silicon photonics vs. ~c/10 for long
lines with repeaters), and at lower power.  I calculated that my
antenna-coupled tunnel junction modulators would come in at about 60
uW/(Gb/s).  (I didn't get them working, unfortunately.)

Cheers

Phil Hobbs

-- 
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510

hobbs at electrooptical dot net
http://electrooptical.net