\"Flexible\" redundancy...

[Don Y]

I use redundancy as a means of increasing availability. I.e.,
the redundant instances are duplicates of their sources.

I\'m preparing a demo for an off-site I\'ll be hosting. I
invited a \"local\" colleague to preview it the other day.

I built a service (\"program\") that runs on the hardware.
Then, configured a \"backup\" service to be present in
case the primary failed, for any reason.

[The typical failure that I am guarding against is a node being
(accidentally) \"unplugged\" or physically destroyed.]

To demonstrate this, I started the service and then
unplugged one of the nodes involved in delivering that service
to show that the service persisted, uninterrupted.

I arranged for an idiot light on the active node(s) to illuminate.
So, the idiot light on the faulted node obviously was extinguished
and a light on the \"backup\" node illuminated.

[This is where things require refining the mental model
associated with the mechanism.]

When I reconnected the original device, the service persisted
AND THE INDICATORS REMAINED UNCHANGED. I.e., the *backup* device
was still providing the service. My colleague had expected
the service to return to the original device (why??).

When I unplugged the backup device, the light moved to yet
*another* device -- which really confounded him! He had
expected the *first* device to resume the role. I explained
that the third device had been nominated as the backup while
the second device was serving as the active device (otherwise,
there would have been NO backup while the original device was
offline!)

[My API lets me nominate a set of devices to provide the
service/backup... I let the workload manager decide which
device is \"best\" as this can vary, over time. So, the goal
is always to nominate the largest set of devices to give
the most flexibility in this assignment]

I, frankly, see nothing wrong with my implementation;
I don\'t see a need to bind a particular service -- and its
backup instance -- to specific devices (though, I could
by deliberately restricting the sets of nominated devices).
And, that any device that CAN provide the backup should
be allowed to assume that role (assuming conditions I\'ve
set at design time can be met).

I\'m thinking that the introduction of a second set of
indicators might make this \"less surprising\"? I.e.,
so the primary AND backup devices can be visually
identified at all times. This would make the choice of
device three as the new backup (when device two takes over)
more obvious and easier to rationalize -- instead of
having it appear, unexpectedly, as the active primary.

I\'ve been looking at redundant HARDWARE systems to see if
there are any clues that I can take away to make this
easier to grok. But, most seem to be simple (dual)
redundant or, possibly, triple redundant. And, the devices
involved are very obvious -- because of packaging, physical
similarities, etc.

I think if folks were more familiar with things like 3DNS
it might be an easier \"sell\"...

 

[Michael Terrell]

On Saturday, October 24, 2020 at 11:33:15 PM UTC-4, Don Y wrote:

I use redundancy as a means of increasing availability. I.e.,
the redundant instances are duplicates of their sources.

I\'m preparing a demo for an off-site I\'ll be hosting. I
invited a \"local\" colleague to preview it the other day.

I built a service (\"program\") that runs on the hardware.
Then, configured a \"backup\" service to be present in
case the primary failed, for any reason.

[The typical failure that I am guarding against is a node being
(accidentally) \"unplugged\" or physically destroyed.]

To demonstrate this, I started the service and then
unplugged one of the nodes involved in delivering that service
to show that the service persisted, uninterrupted.

I arranged for an idiot light on the active node(s) to illuminate.
So, the idiot light on the faulted node obviously was extinguished
and a light on the \"backup\" node illuminated.

[This is where things require refining the mental model
associated with the mechanism.]

When I reconnected the original device, the service persisted
AND THE INDICATORS REMAINED UNCHANGED. I.e., the *backup* device
was still providing the service. My colleague had expected
the service to return to the original device (why??).

When I unplugged the backup device, the light moved to yet
*another* device -- which really confounded him! He had
expected the *first* device to resume the role. I explained
that the third device had been nominated as the backup while
the second device was serving as the active device (otherwise,
there would have been NO backup while the original device was
offline!)

[My API lets me nominate a set of devices to provide the
service/backup... I let the workload manager decide which
device is \"best\" as this can vary, over time. So, the goal
is always to nominate the largest set of devices to give
the most flexibility in this assignment]

I, frankly, see nothing wrong with my implementation;
I don\'t see a need to bind a particular service -- and its
backup instance -- to specific devices (though, I could
by deliberately restricting the sets of nominated devices).
And, that any device that CAN provide the backup should
be allowed to assume that role (assuming conditions I\'ve
set at design time can be met).

I\'m thinking that the introduction of a second set of
indicators might make this \"less surprising\"? I.e.,
so the primary AND backup devices can be visually
identified at all times. This would make the choice of
device three as the new backup (when device two takes over)
more obvious and easier to rationalize -- instead of
having it appear, unexpectedly, as the active primary.

I\'ve been looking at redundant HARDWARE systems to see if
there are any clues that I can take away to make this
easier to grok. But, most seem to be simple (dual)
redundant or, possibly, triple redundant. And, the devices
involved are very obvious -- because of packaging, physical
similarities, etc.

I think if folks were more familiar with things like 3DNS
it might be an easier \"sell\"...

This reminds me of the \'Automatic Failover\' of TV sync generators, in the early \'70s. Grass Valley Monochrome NTSC system of two Sync Generators and the automatic switching. There was no glitch caused by the transfer, and this was done with DTL ICs. It did glitch when fed from an external source that was NTSC Color, but the Genlock circuitry allowed it to match the external source.

 

[Phil Hobbs]

On 10/25/20 10:55 AM, Michael Terrell wrote:

On Saturday, October 24, 2020 at 11:33:15 PM UTC-4, Don Y wrote:
I use redundancy as a means of increasing availability. I.e., the
redundant instances are duplicates of their sources.

I\'m preparing a demo for an off-site I\'ll be hosting. I invited a
\"local\" colleague to preview it the other day.

I built a service (\"program\") that runs on the hardware. Then,
configured a \"backup\" service to be present in case the primary
failed, for any reason.

[The typical failure that I am guarding against is a node being
(accidentally) \"unplugged\" or physically destroyed.]

To demonstrate this, I started the service and then unplugged one
of the nodes involved in delivering that service to show that the
service persisted, uninterrupted.

I arranged for an idiot light on the active node(s) to illuminate.
So, the idiot light on the faulted node obviously was extinguished
and a light on the \"backup\" node illuminated.

[This is where things require refining the mental model associated
with the mechanism.]

When I reconnected the original device, the service persisted AND
THE INDICATORS REMAINED UNCHANGED. I.e., the *backup* device was
still providing the service. My colleague had expected the service
to return to the original device (why??).

When I unplugged the backup device, the light moved to yet
*another* device -- which really confounded him! He had expected
the *first* device to resume the role. I explained that the third
device had been nominated as the backup while the second device was
serving as the active device (otherwise, there would have been NO
backup while the original device was offline!)

[My API lets me nominate a set of devices to provide the
service/backup... I let the workload manager decide which device is
\"best\" as this can vary, over time. So, the goal is always to
nominate the largest set of devices to give the most flexibility in
this assignment]

I, frankly, see nothing wrong with my implementation; I don\'t see a
need to bind a particular service -- and its backup instance -- to
specific devices (though, I could by deliberately restricting the
sets of nominated devices). And, that any device that CAN provide
the backup should be allowed to assume that role (assuming
conditions I\'ve set at design time can be met).

I\'m thinking that the introduction of a second set of indicators
might make this \"less surprising\"? I.e., so the primary AND backup
devices can be visually identified at all times. This would make
the choice of device three as the new backup (when device two takes
over) more obvious and easier to rationalize -- instead of having
it appear, unexpectedly, as the active primary.

I\'ve been looking at redundant HARDWARE systems to see if there are
any clues that I can take away to make this easier to grok. But,
most seem to be simple (dual) redundant or, possibly, triple
redundant. And, the devices involved are very obvious -- because of
packaging, physical similarities, etc.

I think if folks were more familiar with things like 3DNS it might
be an easier \"sell\"...

This reminds me of the \'Automatic Failover\' of TV sync generators, in
the early \'70s. Grass Valley Monochrome NTSC system of two Sync
Generators and the automatic switching. There was no glitch caused by
the transfer, and this was done with DTL ICs. It did glitch when fed
from an external source that was NTSC Color, but the Genlock
circuitry allowed it to match the external source.

Cyclic failover is a good idea--a node that\'s failed once is more likely
to fail again, for instance if there\'s a wind storm in the vicinity.
I\'d far prefer to fail over to a node with a better track record.

Don, try waving around \"Bayesian statistics\" till their eyes glaze over.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

 

[Don Y]

On 10/25/2020 8:04 AM, Phil Hobbs wrote:

I think if folks were more familiar with things like 3DNS it might
be an easier \"sell\"...

This reminds me of the \'Automatic Failover\' of TV sync generators, in
the early \'70s. Grass Valley Monochrome NTSC system of two Sync
Generators and the automatic switching. There was no glitch caused by
the transfer, and this was done with DTL ICs. It did glitch when fed
from an external source that was NTSC Color, but the Genlock
circuitry allowed it to match the external source.

Cyclic failover is a good idea--a node that\'s failed once is more likely to
fail again, for instance if there\'s a wind storm in the vicinity. I\'d far
prefer to fail over to a node with a better track record.

Don, try waving around \"Bayesian statistics\" till their eyes glaze over.

As the \"failures\" that I\'m guarding against are either attacks or carelessness,
(I also use this mechanism as an efficiency hack to bring nodes on-line,
quickly, without waiting for an orderly transfer of services to \"other nodes\")
I figure just keeping track of which nodes \"fail\" gives me a way to redefine
the backup nodes nominated in the future.

[The whole point of being able to specify a list of nodes is to be able to
restrict a \"vulnerable\" node from being selected -- e.g., one that is
not physically protected by its location]

I think the idea of visually indicating the backup node (the indicators are
only used for the demo) AS it is selected for that role will, hopefully,
avoid the \"surprise\" that my first demonstration elicited -- my colleague
would have seen the third device assume the backup role as soon as the first
device went off-line and the second (backup) device assumed primary
responsibility.

I think the indicators -- in addition to being considerably easier to
implement than other alternative \"displays\"! -- are easier to internalize;
just scrolling messages on a display seems too abstracted:
node 1 primary, node 2 backup
node 1 failed, node 2 primary, node 3 backup
node 1 restored
node 2 failed, node 3 primary, node ?? backup

 

[Don Y]

On 10/25/2020 7:55 AM, Michael Terrell wrote:

I\'ve been looking at redundant HARDWARE systems to see if there are any
clues that I can take away to make this easier to grok. But, most seem to
be simple (dual) redundant or, possibly, triple redundant. And, the
devices involved are very obvious -- because of packaging, physical
similarities, etc.

I think if folks were more familiar with things like 3DNS it might be an
easier \"sell\"...

This reminds me of the \'Automatic Failover\' of TV sync generators, in the
early \'70s. Grass Valley Monochrome NTSC system of two Sync Generators and
the automatic switching. There was no glitch caused by the transfer, and
this was done with DTL ICs. It did glitch when fed from an external source
that was NTSC Color, but the Genlock circuitry allowed it to match the
external source.

But, they were likely identical (functionally and physically) devices.
Mine are only identical in that they are potentially capable of
providing the same level of functionality (assuming the backup device
candidates aren\'t presently \"load-ed\" to a level that reduces the
available capacity below the amount needed for the service being
backed up). Instead of hardware deciding on \"who wins\", mine rely
on \"protocols\"... harder to touch-and-feel.

And, with only a pair of devices, there\'s not much flexibility once
a failure is detected -- there\'s ONLY one choice for backup.

I think this sort of thinking underlies my friend\'s confusion/surprise;
if the \"bad\" device comes back on-line, then, surely (?), it should
resume an active role...

 

[Michael Terrell]

On Sunday, October 25, 2020 at 12:30:00 PM UTC-4, Don Y wrote:

On 10/25/2020 7:55 AM, Michael Terrell wrote:
I\'ve been looking at redundant HARDWARE systems to see if there are any
clues that I can take away to make this easier to grok. But, most seem to
be simple (dual) redundant or, possibly, triple redundant. And, the
devices involved are very obvious -- because of packaging, physical
similarities, etc.

I think if folks were more familiar with things like 3DNS it might be an
easier \"sell\"...

This reminds me of the \'Automatic Failover\' of TV sync generators, in the
early \'70s. Grass Valley Monochrome NTSC system of two Sync Generators and
the automatic switching. There was no glitch caused by the transfer, and
this was done with DTL ICs. It did glitch when fed from an external source
that was NTSC Color, but the Genlock circuitry allowed it to match the
external source.
But, they were likely identical (functionally and physically) devices.
Mine are only identical in that they are potentially capable of
providing the same level of functionality (assuming the backup device
candidates aren\'t presently \"load-ed\" to a level that reduces the
available capacity below the amount needed for the service being
backed up). Instead of hardware deciding on \"who wins\", mine rely
on \"protocols\"... harder to touch-and-feel.

And, with only a pair of devices, there\'s not much flexibility once
a failure is detected -- there\'s ONLY one choice for backup.

I think this sort of thinking underlies my friend\'s confusion/surprise;
if the \"bad\" device comes back on-line, then, surely (?), it should
resume an active role...

They didn\'t have to be identical, they just had to supply a comparable signal. Otherwise, I couldn\'t have transferred to an external source with a slightly different standard. Mono used 15,750 Hz and 60Hz. Color was 15,734.34 Hz and 59.94Hz, along with the Blackburst of seven cycles of 3,579,545Hz.

I agree about moving to the next available source. In my case, you could hot swap the Sync Generator modules, and the cage had two power supplies, either of which could power the entire system. It was designed to run 24/7 for decades.

In some studios, they used more than one sync system. Individual groups could continue to function, even if the master system Sync Generators both failed. The failover was a separate subsystem, and you could use as many as you wanted, but timing delays would be introduced if you weren\'t careful in the layout and cabling. I\'m talking about the days when the length of every video source had to match, or you had to adjust the delay in the system to eliminate phase shift in the chroma between sources. It was even harder if you switched RGB rather than Composite video. With RGB, the three cables length had to match to within 1/4\"

 

[Don Y]

On 10/25/2020 2:14 PM, Michael Terrell wrote:

On Sunday, October 25, 2020 at 12:30:00 PM UTC-4, Don Y wrote:
On 10/25/2020 7:55 AM, Michael Terrell wrote:
I\'ve been looking at redundant HARDWARE systems to see if there are
any clues that I can take away to make this easier to grok. But, most
seem to be simple (dual) redundant or, possibly, triple redundant.
And, the devices involved are very obvious -- because of packaging,
physical similarities, etc.

I think if folks were more familiar with things like 3DNS it might be
an easier \"sell\"...

This reminds me of the \'Automatic Failover\' of TV sync generators, in
the early \'70s. Grass Valley Monochrome NTSC system of two Sync
Generators and the automatic switching. There was no glitch caused by
the transfer, and this was done with DTL ICs. It did glitch when fed
from an external source that was NTSC Color, but the Genlock circuitry
allowed it to match the external source.
But, they were likely identical (functionally and physically) devices.
Mine are only identical in that they are potentially capable of providing
the same level of functionality (assuming the backup device candidates
aren\'t presently \"load-ed\" to a level that reduces the available capacity
below the amount needed for the service being backed up). Instead of
hardware deciding on \"who wins\", mine rely on \"protocols\"... harder to
touch-and-feel.

And, with only a pair of devices, there\'s not much flexibility once a
failure is detected -- there\'s ONLY one choice for backup.

I think this sort of thinking underlies my friend\'s confusion/surprise; if
the \"bad\" device comes back on-line, then, surely (?), it should resume an
active role...

They didn\'t have to be identical, they just had to supply a comparable
signal. Otherwise, I couldn\'t have transferred to an external source with a
slightly different standard. Mono used 15,750 Hz and 60Hz. Color was
15,734.34 Hz and 59.94Hz, along with the Blackburst of seven cycles of
3,579,545Hz.

So, were they \"not identical\" deliberately (i.e., implement the same
functionality two different ways so that a fault wouldn\'t necessarily
be replicated in the second device)? Or, was it just a matter of
\"buy a device that performs this particular functionality and can
plug into these gazintas/cumzoutas\"?

I agree about moving to the next available source. In my case, you could hot
swap the Sync Generator modules, and the cage had two power supplies,
either of which could power the entire system. It was designed to run 24/7
for decades.

In some studios, they used more than one sync system. Individual groups
could continue to function, even if the master system Sync Generators both
failed. The failover was a separate subsystem, and you could use as many as
you wanted, but timing delays would be introduced if you weren\'t careful in
the layout and cabling. I\'m talking about the days when the length of every
video source had to match, or you had to adjust the delay in the system to
eliminate phase shift in the chroma between sources. It was even harder if
you switched RGB rather than Composite video. With RGB, the three cables
length had to match to within 1/4\"

How was a faulted/failed subsystem detected/indicated? Was the failover
unattended -- or did it require human intervention? Once \"repaired\"
(replaced, <whatever>), would the previous \"master\" resume that role?
Or, would it then become the backup for the CURRENTLY serving device?

On a side/different subject...

I have 6 RG6Q drops into my equipment closet. These sources from cable
feeds to the house and antennae -- as well as *feeds* to distribution amps
located elsewhere. I need to plumb (wire) these to various devices IN that
closet (CATV/OTA/AM/FM tuners, cable modems, splitters, etc.). E.g.,
a CATV feed would be cabled to two CATV tuners and the cable modem; the
indoor FM antenna cabled to an AM/FM tuner; etc.

These devices are located relatively close together because of lack of
space in the closet. So, coax runs will be short -- no room for long, gentle
arcs to interconnect devices to drops. Instead, it almost wants to resemble
\"point-to-point\" wiring -- nice and tight.

But, the cable won\'t like the sharp bends that will be required to make
it all fit in the small space! I can avoid some of them by using right-angle
connectors/adapters (e.g., I can mate to the wall-mounted connections with
right-angle adapters to route the cable *parallel* to the wall instead of
having it come OUT from the wall and then bend back towards the wall to
meet up with the wall-mounted devices).

What would be nice is some RIGID coax with right-angle fittings that I
could \"fit\" to the space (and shape) available. E.g., imagine fitting
copper pipe together -- you could get nearly any tightly defined shape
you want with the right lengths of straight pipe and ells. Admittedly,
a bit of labor/assembly involved but you\'d only have to do it once.

Is there something like this, available?

 

[server]

On Sun, 25 Oct 2020 14:14:50 -0700 (PDT), Michael Terrell
<terrell.michael.a@gmail.com> wrote:

They didn\'t have to be identical, they just had to supply a comparable signal. Otherwise, I couldn\'t have transferred to an external source with a slightly different standard. Mono used 15,750 Hz and 60Hz. Color was 15,734.34 Hz and 59.94Hz, along with the Blackburst of seven cycles of 3,579,545Hz.

I agree about moving to the next available source. In my case, you could hot swap the Sync Generator modules, and the cage had two power supplies, either of which could power the entire system. It was designed to run 24/7 for decades.

In some studios, they used more than one sync system. Individual groups could continue to function, even if the master system Sync Generators both failed. The failover was a separate subsystem, and you could use as many as you wanted, but timing delays would be introduced if you weren\'t careful in the layout and cabling. I\'m talking about the days when the length of every video source had to match, or you had to adjust the delay in the system to eliminate phase shift in the chroma between sources. It was even harder if you switched RGB rather than Composite video. With RGB, the three cables length had to match to within 1/4\"

Did you get the unit wrong ?

Considering the coax velocity factor, the 1/4\" difference is about 10
mm free space wavelength for 30 GHz (33 ps), clearly a huge overkill
for the few megahertz video signal.

Since the sampling rate for standard definition video systems is
typically below 15 MHz, so equalization to about 10 ns (100 MHz)
should be enough, so a path length difference could be 2 m considering
the coax velocity factor.

Different path lengths and different velocity factors are a problem in
1 GbT+ Ethernets, in which data is transferred in multiple pairs. The
receivers have built in delay compensation for each pair, so that the
symbols can be reconstructed with a single clock. But these
frequencies are much higher than any SD RGB signals.

 

[Cydrome Leader]

Don Y <blockedofcourse@foo.invalid> wrote:

On 10/25/2020 8:04 AM, Phil Hobbs wrote:
I think if folks were more familiar with things like 3DNS it might
be an easier \"sell\"...

This reminds me of the \'Automatic Failover\' of TV sync generators, in
the early \'70s. Grass Valley Monochrome NTSC system of two Sync
Generators and the automatic switching. There was no glitch caused by
the transfer, and this was done with DTL ICs. It did glitch when fed
from an external source that was NTSC Color, but the Genlock
circuitry allowed it to match the external source.

Cyclic failover is a good idea--a node that\'s failed once is more likely to
fail again, for instance if there\'s a wind storm in the vicinity. I\'d far
prefer to fail over to a node with a better track record.

Don, try waving around \"Bayesian statistics\" till their eyes glaze over.

As the \"failures\" that I\'m guarding against are either attacks or carelessness,
(I also use this mechanism as an efficiency hack to bring nodes on-line,
quickly, without waiting for an orderly transfer of services to \"other nodes\")
I figure just keeping track of which nodes \"fail\" gives me a way to redefine
the backup nodes nominated in the future.

[The whole point of being able to specify a list of nodes is to be able to
restrict a \"vulnerable\" node from being selected -- e.g., one that is
not physically protected by its location]

I think the idea of visually indicating the backup node (the indicators are
only used for the demo) AS it is selected for that role will, hopefully,
avoid the \"surprise\" that my first demonstration elicited -- my colleague
would have seen the third device assume the backup role as soon as the first
device went off-line and the second (backup) device assumed primary
responsibility.

I think the indicators -- in addition to being considerably easier to
implement than other alternative \"displays\"! -- are easier to internalize;
just scrolling messages on a display seems too abstracted:
node 1 primary, node 2 backup
node 1 failed, node 2 primary, node 3 backup
node 1 restored
node 2 failed, node 3 primary, node ?? backup

these messages are confusing. Where is node 3 in the top message?

What are the full possible states for each node?
primary, backup, failed and no mention?

 

[Don Y]

On 10/26/2020 10:34 PM, Cydrome Leader wrote:

I think the indicators -- in addition to being considerably easier to
implement than other alternative \"displays\"! -- are easier to internalize;
just scrolling messages on a display seems too abstracted:
node 1 primary, node 2 backup
node 1 failed, node 2 primary, node 3 backup
node 1 restored
node 2 failed, node 3 primary, node ?? backup

these messages are confusing. Where is node 3 in the top message?

Where is node 4? 5? ... 115?

The messages would have been \"event notifications\". E.g.:

\"I have now instantiated the service (we\'re ignoring everything else
that\'s happening in the system, for brevity) on node 1 and elected
node 2 (from the candidates nominated in the request to create the
service) as its hot backup\"

\"Oops! Node 1 has failed -- along with the service that it hosted!
As a result, node 2 is now acting in the role of primary. And, as
that primary needs a backup, I have elected node 3 to be that backup.\"

\"Hey! Good news! Node 1 is back on line (but doesn\'t alter the
primary and backup roles that are currently being filled by 2 & 3)\"

\"Crap! Node 2 has failed! As such, node 3 transitions from being
the backup to being the primary. And, as that new primary needs
a backup, I am electing node ?? (might be 1, might be 47, ...
depends on the initial list of candidates presented when the service
was created)\"

> What are the full possible states for each node?

Not important. Nodes host many services. I was just illustrating an
alternative means by which I could DEMONSTRATE what was happening
in the system instead of relying on idiot lights. My point being
that the text display contains the same information as idiot lights
but in a more abstract, less tangible way.

The above example could have been indicated as:
node 1 green, node 2 blue
node 1 extinguished
node 2 green, node 3 blue
node 1 white (?)
node 2 extinguished, node 3 green, node ?? blue
in which case, you\'d watch the indicator on node 1 change from green
(primary) to \"extinguished\" when the comms link was crashed. At
the same time, you\'d see node 2\'s indicator change from blue to green
as it assumed the primary role -- and, node 3\'s indicator come on
as blue to indicate that it was now in the backup role.

I think this is more intuitive IN A DEMONSTRATION (dog-pony) than all
of that text.

> primary, backup, failed and no mention?

Node 1 might be hosting services A(primary), B, Q(backup) and Z.
Node 2 might be hosting services C, F and R.
Node 3 might be hosting services A(backup) and D.
Node 4 might be hosting services G, H, I, J, K, L and Q(primary)
....

A minute from now, that mix could change -- based on detected failures,
termination of certain services, creation of other services, etc.

As there are many (\"many many\", as Commandant Lassarde would say)
services on each node, using the single indicator on each device
to convey that sort of information IN PRACTICE would be silly
(impossible). OTOH, there would be nothing wrong with *logging*
text messages like the above (further annotated with the name
of the service in question)

 

[Don Y]

On 10/26/2020 11:13 PM, Don Y wrote:

Node 1 might be hosting services A(primary), B, Q(backup) and Z.
Node 2 might be hosting services C, F and R.
Node 3 might be hosting services A(backup) and D.
Node 4 might be hosting services G, H, I, J, K, L and Q(primary)
...

If, for example, node 1 failed in this scenario, you\'d have:

Node 2 might be hosting services C, F and R.
Node 3 might be hosting services A(primary) and D.
Node 4 might be hosting services G, H, I, J, K, L and Q(primary)

noticing that node 3 now acts as A\'s primary, B and Z are
crashed (they weren\'t configured for high availability) and
Q\'s backup has now disappeared -- meaning some node would end
up being selected as Q\'s backup based on the candidates
that were nominated when service Q was instantiated.

 

[Michael Terrell]

On Monday, October 26, 2020 at 1:47:31 AM UTC-4, upsid... wrote:

On Sun, 25 Oct 2020 14:14:50 -0700 (PDT), Michael Terrell wrote:

They didn\'t have to be identical, they just had to supply a comparable signal. Otherwise, I couldn\'t have transferred to an external source with a slightly different standard. Mono used 15,750 Hz and 60Hz. Color was 15,734..34 Hz and 59.94Hz, along with the Blackburst of seven cycles of 3,579,545Hz.

I agree about moving to the next available source. In my case, you could hot swap the Sync Generator modules, and the cage had two power supplies, either of which could power the entire system. It was designed to run 24/7 for decades.

In some studios, they used more than one sync system. Individual groups could continue to function, even if the master system Sync Generators both failed. The failover was a separate subsystem, and you could use as many as you wanted, but timing delays would be introduced if you weren\'t careful in the layout and cabling. I\'m talking about the days when the length of every video source had to match, or you had to adjust the delay in the system to eliminate phase shift in the chroma between sources. It was even harder if you switched RGB rather than Composite video. With RGB, the three cables length had to match to within 1/4\"
Did you get the unit wrong ?

Considering the coax velocity factor, the 1/4\" difference is about 10
mm free space wavelength for 30 GHz (33 ps), clearly a huge overkill
for the few megahertz video signal.

Since the sampling rate for standard definition video systems is
typically below 15 MHz, so equalization to about 10 ns (100 MHz)
should be enough, so a path length difference could be 2 m considering
the coax velocity factor.

Different path lengths and different velocity factors are a problem in
1 GbT+ Ethernets, in which data is transferred in multiple pairs. The
receivers have built in delay compensation for each pair, so that the
symbols can be reconstructed with a single clock. But these
frequencies are much higher than any SD RGB signals.

That was the specification in the manuals.

 

[Michael Terrell]

On Monday, October 26, 2020 at 12:25:30 AM UTC-4, Don Y wrote:

On 10/25/2020 2:14 PM, Michael Terrell wrote:
On Sunday, October 25, 2020 at 12:30:00 PM UTC-4, Don Y wrote:
On 10/25/2020 7:55 AM, Michael Terrell wrote:
I\'ve been looking at redundant HARDWARE systems to see if there are
any clues that I can take away to make this easier to grok. But, most
seem to be simple (dual) redundant or, possibly, triple redundant.
And, the devices involved are very obvious -- because of packaging,
physical similarities, etc.

I think if folks were more familiar with things like 3DNS it might be
an easier \"sell\"...

This reminds me of the \'Automatic Failover\' of TV sync generators, in
the early \'70s. Grass Valley Monochrome NTSC system of two Sync
Generators and the automatic switching. There was no glitch caused by
the transfer, and this was done with DTL ICs. It did glitch when fed
from an external source that was NTSC Color, but the Genlock circuitry
allowed it to match the external source.
But, they were likely identical (functionally and physically) devices.
Mine are only identical in that they are potentially capable of providing
the same level of functionality (assuming the backup device candidates
aren\'t presently \"load-ed\" to a level that reduces the available capacity
below the amount needed for the service being backed up). Instead of
hardware deciding on \"who wins\", mine rely on \"protocols\"... harder to
touch-and-feel.

And, with only a pair of devices, there\'s not much flexibility once a
failure is detected -- there\'s ONLY one choice for backup.

I think this sort of thinking underlies my friend\'s confusion/surprise; if
the \"bad\" device comes back on-line, then, surely (?), it should resume an
active role...

They didn\'t have to be identical, they just had to supply a comparable
signal. Otherwise, I couldn\'t have transferred to an external source with a
slightly different standard. Mono used 15,750 Hz and 60Hz. Color was
15,734.34 Hz and 59.94Hz, along with the Blackburst of seven cycles of
3,579,545Hz.
So, were they \"not identical\" deliberately (i.e., implement the same
functionality two different ways so that a fault wouldn\'t necessarily
be replicated in the second device)? Or, was it just a matter of
\"buy a device that performs this particular functionality and can
plug into these gazintas/cumzoutas\"?

Back then, equipment was replaced as needed after a studio was built. Unlike these days where they junk everything anfter building a new facility. You might be running an early \'50s tube based generateor along with a brand new IC based unit.

I agree about moving to the next available source. In my case, you could hot
swap the Sync Generator modules, and the cage had two power supplies,
either of which could power the entire system. It was designed to run 24/7
for decades.

In some studios, they used more than one sync system. Individual groups
could continue to function, even if the master system Sync Generators both
failed. The failover was a separate subsystem, and you could use as many as
you wanted, but timing delays would be introduced if you weren\'t careful in
the layout and cabling. I\'m talking about the days when the length of every
video source had to match, or you had to adjust the delay in the system to
eliminate phase shift in the chroma between sources. It was even harder if
you switched RGB rather than Composite video. With RGB, the three cables
length had to match to within 1/4\"
How was a faulted/failed subsystem detected/indicated? Was the failover
unattended -- or did it require human intervention? Once \"repaired\"
(replaced, <whatever>), would the previous \"master\" resume that role?
Or, would it then become the backup for the CURRENTLY serving device?

The failover had a pair of indicators to show which was in use. There was a center off, spring loaded toggle switch to manually select a unit. You could leave the current generator, or select the one you just repaired.

On a side/different subject...

I have 6 RG6Q drops into my equipment closet. These sources from cable
feeds to the house and antennae -- as well as *feeds* to distribution amps
located elsewhere. I need to plumb (wire) these to various devices IN that
closet (CATV/OTA/AM/FM tuners, cable modems, splitters, etc.). E.g.,
a CATV feed would be cabled to two CATV tuners and the cable modem; the
indoor FM antenna cabled to an AM/FM tuner; etc.

These devices are located relatively close together because of lack of
space in the closet. So, coax runs will be short -- no room for long, gentle
arcs to interconnect devices to drops. Instead, it almost wants to resemble
\"point-to-point\" wiring -- nice and tight.

But, the cable won\'t like the sharp bends that will be required to make
it all fit in the small space! I can avoid some of them by using right-angle
connectors/adapters (e.g., I can mate to the wall-mounted connections with
right-angle adapters to route the cable *parallel* to the wall instead of
having it come OUT from the wall and then bend back towards the wall to
meet up with the wall-mounted devices).

What would be nice is some RIGID coax with right-angle fittings that I
could \"fit\" to the space (and shape) available. E.g., imagine fitting
copper pipe together -- you could get nearly any tightly defined shape
you want with the right lengths of straight pipe and ells. Admittedly,
a bit of labor/assembly involved but you\'d only have to do it once.

Is there something like this, available?

I\'ve never seen any, and I used to have catalogs from just about every supplier to CATV and Broadcasting. RMS used to make high quality right angle adapters, but I think they went out of business. I had a bag of them, but I have no idea where they are. I used to sell a lot of three and six inch RG6 jumpers with Hex crimped F fittings. I was selling at a flea market on weekends. I had a couple thousand feet of RG6 and RG59 remnants. I was making six\', 12\' 25\' and custom length jumpers. I had some scraps that were too short, so I made a few short jumpers. One guy sked, \"What the helll is this?\" The guy behind him grabbed all of them, and wanted more.

 

[Don Y]

On 10/27/2020 1:12 AM, Michael Terrell wrote:

So, were they \"not identical\" deliberately (i.e., implement the same
functionality two different ways so that a fault wouldn\'t necessarily be
replicated in the second device)? Or, was it just a matter of \"buy a
device that performs this particular functionality and can plug into these
gazintas/cumzoutas\"?

Back then, equipment was replaced as needed after a studio was built. Unlike
these days where they junk everything anfter building a new facility. You
might be running an early \'50s tube based generateor along with a brand new
IC based unit.

OK, so you were implicitly leveraging the fact that there were broadcast
standards that ensured that these devices (different makes/models/vintages)
were FUNCTIONALLY interchangeable -- not that they were intentionally designed
as redundant copies of each other.

How was a faulted/failed subsystem detected/indicated? Was the failover
unattended -- or did it require human intervention? Once \"repaired\"
(replaced, <whatever>), would the previous \"master\" resume that role? Or,
would it then become the backup for the CURRENTLY serving device?

The failover had a pair of indicators to show which was in use. There was a
center off, spring loaded toggle switch to manually select a unit. You could
leave the current generator, or select the one you just repaired.

So, there was some third device that arbitrated between the two candidate
sources? Possibly by examining the outputs of each and \"ruling\" that one
(or the other) was not performing as expected. Then, making a switch to
ensure the functioning device is in play?

(That would work if you can know what is expected of a device at all times
to be able to make that fault determination -- like a power supply, etc.)

On a side/different subject...

What would be nice is some RIGID coax with right-angle fittings that I
could \"fit\" to the space (and shape) available. E.g., imagine fitting
copper pipe together -- you could get nearly any tightly defined shape you
want with the right lengths of straight pipe and ells. Admittedly, a bit
of labor/assembly involved but you\'d only have to do it once.

Is there something like this, available?

I\'ve never seen any, and I used to have catalogs from just about every
supplier to CATV and Broadcasting.

I\'ve seen *specific* examples of this -- but they appear to have been
custom made for particular applications. I.e., not like you could
buy any given size/shape *or* assemble what you need like Lincoln Logs.

RMS used to make high quality right angle
adapters, but I think they went out of business.

I\'ve found right-angle adapters -- but they are male-to-female; useful for
connecting a cable to a bulkhead connector at right angles (instead of
sticking \"straight out\"). Were the adapters you mentioned cable of fitting
cable-to-cable?

I had a bag of them, but I
have no idea where they are. I used to sell a lot of three and six inch RG6
jumpers with Hex crimped F fittings.

What was the expected use for a short STRAIGHT piece of RG6? Bend radius is
such that I\'d imagine it would be hard to use it in any form OTHER than
straight!

I was selling at a flea market on
weekends. I had a couple thousand feet of RG6 and RG59 remnants. I was
making six\', 12\' 25\' and custom length jumpers.

That\'s *feet*, not inches. So, you decided there was a use for the
bits left over?

I rescued a 1000\' spool which is how I ended up with RG6Q. I might have
preferred to use something else for ease of routing (the RG6 feels like
narrow gauge hose!)

Perhaps I can do this \"interconnect wiring\" with RG59? It\'s 75 ohm
as well (58 is 50, IIRC). I should look into that -- both electrically
and mechanically (it may also be too stiff for the space available).

I had some scraps that were
too short, so I made a few short jumpers. One guy sked, \"What the helll is
this?\" The guy behind him grabbed all of them, and wanted more.

 

[Reinhardt Behm]

On 10/26/20 12:24 AM, Don Y wrote:

On 10/25/2020 8:04 AM, Phil Hobbs wrote:
I think if folks were more familiar with things like 3DNS it might
be an easier \"sell\"...

This reminds me of the \'Automatic Failover\' of TV sync generators, in
the early \'70s. Grass Valley Monochrome NTSC system of two Sync
Generators and the automatic switching. There was no glitch caused by
the transfer, and this was done with DTL ICs. It did glitch when fed
from an external source that was NTSC Color, but the Genlock
circuitry allowed it to match the external source.

Cyclic failover is a good idea--a node that\'s failed once is more
likely to fail again, for instance if there\'s a wind storm in the
vicinity. I\'d far prefer to fail over to a node with a better track
record.

Don, try waving around \"Bayesian statistics\" till their eyes glaze
over.

As the \"failures\" that I\'m guarding against are either attacks or
carelessness,
(I also use this mechanism as an efficiency hack to bring nodes on-line,
quickly, without waiting for an orderly transfer of services to \"other
nodes\")
I figure just keeping track of which nodes \"fail\" gives me a way to
redefine
the backup nodes nominated in the future.

[The whole point of being able to specify a list of nodes is to be able to
restrict a \"vulnerable\" node from being selected -- e.g., one that is
not physically protected by its location]

I think the idea of visually indicating the backup node (the indicators are
only used for the demo) AS it is selected for that role will, hopefully,
avoid the \"surprise\" that my first demonstration elicited -- my colleague
would have seen the third device assume the backup role as soon as the
first
device went off-line and the second (backup) device assumed primary
responsibility.

I think the indicators -- in addition to being considerably easier to
implement than other alternative \"displays\"! -- are easier to internalize;
just scrolling messages on a display seems too abstracted:
    node 1 primary, node 2 backup
    node 1 failed, node 2 primary, node 3 backup
    node 1 restored
    node 2 failed, node 3 primary, node ?? backup

I would not make this too complicated. If it\'s for demonstration only,
just two LEDs, \"in service\" and \"backup\" would do. This should clearly
show that you always have one \"in service\" and one as \"backup\". Should
be easy to explain.
From past stories you told, I assume that your nodes provide several
services and one such node could currently be the main node for one
service and backup for others services. So any such display that shows
the status of all services will be complicated and confusing in real life.

Some question I would ask if you would demonstrate this to me:
- How do you synchronize the backup nodes assuming the service needs
also some past data? An assigned backup node could collect this data.
If a new backup node is assigned how does it get synchronized?
- In the case of a switch-over there is only one node until the new
backup is activated. So there is a \"window of vulnerability\".
- Will there be a gap in providing service when switch-over happens?
From failure detection to take-over by the backup. It might not be
critical depending on the application.
- How is the failure detection and switch-over managed? Is there a
central instance who controls this? This could be the single point of
failure, or do your nodes this by themselves?

 

[Don Y]

On 10/27/2020 7:19 PM, Reinhardt Behm wrote:

On 10/26/20 12:24 AM, Don Y wrote:

As the \"failures\" that I\'m guarding against are either attacks or carelessness,
(I also use this mechanism as an efficiency hack to bring nodes on-line,
quickly, without waiting for an orderly transfer of services to \"other nodes\")
I figure just keeping track of which nodes \"fail\" gives me a way to redefine
the backup nodes nominated in the future.

[The whole point of being able to specify a list of nodes is to be able to
restrict a \"vulnerable\" node from being selected -- e.g., one that is
not physically protected by its location]

I think the idea of visually indicating the backup node (the indicators are
only used for the demo) AS it is selected for that role will, hopefully,
avoid the \"surprise\" that my first demonstration elicited -- my colleague
would have seen the third device assume the backup role as soon as the first
device went off-line and the second (backup) device assumed primary
responsibility.

I think the indicators -- in addition to being considerably easier to
implement than other alternative \"displays\"! -- are easier to internalize;
just scrolling messages on a display seems too abstracted:
node 1 primary, node 2 backup
node 1 failed, node 2 primary, node 3 backup
node 1 restored
node 2 failed, node 3 primary, node ?? backup

I would not make this too complicated. If it\'s for demonstration only, just
two LEDs, \"in service\" and \"backup\" would do. This should clearly show that
you always have one \"in service\" and one as \"backup\". Should be easy to explain.

Yes. I only have one indicator (RGB LED) in place on the devices. It is
normally used to indicate the state of the *node*, not any process/service
running on it. (nodes don\'t have any real \"user I/O\" so the indicator has
to be the primary means of interacting directly with a node for status
and diagnostics if the node is unable to communicate with the rest of
the system). I\'m hijacking it for this use. I\'ll have to rely on color
to convey the primary vs. backup information (but it\'s just a dog&pony so
who cares!)

[See my 202010232313 reply to Cydrome Leader -- sorry, I can\'t figure out
how to insert a direct reference to that, here]

The folks involved are savvy enough to understand what\'s happening. The
demo cited in my original post simply caught my colleague off guard. He
had preconceived notions of what was GOING to happen (no doubt based on
thinking about physically redundant devices) so was not expecting
what *actually* happened.

I think there were too many changes folded into one step; he couldn\'t
see the new backup being selected because there was no indication of
that fact -- it was only *implied* once the new backup \"appeared\" as
the new primary!

The second indicator (or, second color, in my case) will, hopefully,
draw attention to that fact earlier so its less of a surprise -- they\'ll
know where to look to find the new primary when that time arrives.

From past stories you told, I assume that your nodes provide several services
and one such node could currently be the main node for one service and backup
for others services. So any such display that shows the status of all services
will be complicated and confusing in real life.

Yes. And some services might not have any backup -- it depends on the
nature of the service as well as its chosen implementation (e.g., a service
that inherently checkpoints can be resumed at any time). See, again,
the above referenced post.

Some question I would ask if you would demonstrate this to me:
- How do you synchronize the backup nodes assuming the service needs also some
past data? An assigned backup node could collect this data. If a new backup
node is assigned how does it get synchronized?

I assume there is always an active instance of the service from which I
can copy the current process state. When the backup is created, I copy
the image from the primary. When the primary fails, the backup is the new
primary and is used as the source of the image for the \"new\" backup.

[So, if you manage to clobber the primary before I can instantiate a new
backup, the service is dead and has to be reloaded]

Most of the services that users will create will be very lightweight.
So, I can create a new copy in a fraction of a second. Some of the
\"system\" services are more involved but they are \"engineered\" instead of
crafted by users.

- In the case of a switch-over there is only one node until the new backup is
activated. So there is a \"window of vulnerability\".

Yes. There\'s no way around this unless I allow multiple \"hot\" backups to
actively coexist. Given the types of failures I envision (outlined in
original post), I expect one backup to be sufficient. A determined
\"attack\" on the primary AND backup would have to know where the service
was running (and being backed up). And, such a determined attack with
that sort of information could similarly defeat any number of concurrent
backups!

[One of the reasons for the \"list of nominated nodes\" is to try to
coerce the backup to be selected from nodes that are physically more
secure than others. E.g., don\'t run an essential service in a node
that is \"exposed\" AND back it up in yet another exposed node!
A list is used as the workload manager needs to see which of those nodes
is best able to provide the resources needed for that service NOW; if a
node is already being heavily utilized, you\'d not want to burden it with
additional load]

- Will there be a gap in providing service when switch-over happens? From
failure detection to take-over by the backup. It might not be critical
depending on the application.

The service decides what sort of slop it can tolerate. The designer of the
service has to have an appreciation for how \"heavy\" the service is (how hard
it is to pick up where the primary left off) as well as how stringent the
constraints for recovery should be. You can\'t squeeze the balloon at both
ends (OTOH, the system doesn\'t force you to fit any *specific* requirements)

And, services that directly manipulate I/O can\'t really be backed up (at least
not the service that is actually DOING that manipulation); I don\'t have
redundant I/O hardware. If a particular I/O device fails, then anything
that relies on that device is also failed.

- How is the failure detection and switch-over managed? Is there a central
instance who controls this? This could be the single point of failure, or do
your nodes this by themselves?

Everything going into and out of a service goes through the OS. So, the
kernels on the associated nodes coordinate this exchange of information to
ensure each instance of the service is \"current\". A kernel failing to
hear from its counterpart in a timely manner (defined by the service in
question) simply assumes the other service has failed and takes over.
Ins and outs are just packets of information over a network. So,
there is no need for physical switching.

[This is much like how network services -- HTTPd, DNS, etc. -- are implemented
in high availability settings. The client (you) doesn\'t really know which
\"CPU\" handled his request for a service. All he knows is that it is handled
properly regardless of which CPU/host actually did the work.]

Otherwise, the \"product\" of the backup service is effectively discarded
(unless needed by other services in backing up a particular service...
language gets clumsy, here, as *everything* is a service)

It\'s like a bank of triple output power supplies being used to feed a bunch
of different devices -- each of which may consume one or more of those
outputs. A device doesn\'t care where it\'s power is sourced -- one supply
may be sourced by PS#1 while the other two are sourced by PS#8.

Similarly, a power supply doesn\'t care where it\'s power is consumed -- as
long as it\'s capacity isn\'t exceeded.

And, a power supply may have *no* load at some point in time (obviously
designed for that possibility).

 

[Don Y]

On 10/27/2020 11:03 PM, Don Y wrote:

- Will there be a gap in providing service when switch-over happens? From
failure detection to take-over by the backup. It might not be critical
depending on the application.

The service decides what sort of slop it can tolerate. The designer of the
service has to have an appreciation for how \"heavy\" the service is (how hard
it is to pick up where the primary left off) as well as how stringent the
constraints for recovery should be. You can\'t squeeze the balloon at both
ends (OTOH, the system doesn\'t force you to fit any *specific* requirements)

And, services that directly manipulate I/O can\'t really be backed up (at least
not the service that is actually DOING that manipulation); I don\'t have
redundant I/O hardware. If a particular I/O device fails, then anything
that relies on that device is also failed.

For example, the demo streams audio to \"networked speakers\" selecting
which speaker(s) to use based on your current location. As you walk
around, some speakers are powered down while others come online.

The audio has to remain in sync even as the speakers are changed. You
don\'t want to hear music coming from the area you are entering that
lags/leads the music coming from the area you are exiting. The
service tweeks the delays in each speaker node so the sound arrives
at your ear appropriately (psychoacoustic phenomena cause this to not
always be *coincident*!)

If a node that actually drives a speaker dies, then there\'s nothing I
can do about it; there\'s no other way to push electrons through that
associated voice coil!

OTOH, if the node that is sourcing the music dies, a backup can take
over its role. As long as the backup comes up before the output buffer
on the speaker node(s) empties, there is no audible indication that
there has been a device failure.

 

[Michael Terrell]

On Tuesday, October 27, 2020 at 3:22:29 PM UTC-4, Don Y wrote:

On 10/27/2020 1:12 AM, Michael Terrell wrote:

So, were they \"not identical\" deliberately (i.e., implement the same
functionality two different ways so that a fault wouldn\'t necessarily be
replicated in the second device)? Or, was it just a matter of \"buy a
device that performs this particular functionality and can plug into these
gazintas/cumzoutas\"?

Back then, equipment was replaced as needed after a studio was built. Unlike
these days where they junk everything anfter building a new facility. You
might be running an early \'50s tube based generateor along with a brand new
IC based unit.
OK, so you were implicitly leveraging the fact that there were broadcast
standards that ensured that these devices (different makes/models/vintages)
were FUNCTIONALLY interchangeable -- not that they were intentionally designed
as redundant copies of each other.
How was a faulted/failed subsystem detected/indicated? Was the failover
unattended -- or did it require human intervention? Once \"repaired\"
(replaced, <whatever>), would the previous \"master\" resume that role? Or,
would it then become the backup for the CURRENTLY serving device?

The failover had a pair of indicators to show which was in use. There was a
center off, spring loaded toggle switch to manually select a unit. You could
leave the current generator, or select the one you just repaired.
So, there was some third device that arbitrated between the two candidate
sources? Possibly by examining the outputs of each and \"ruling\" that one
(or the other) was not performing as expected. Then, making a switch to
ensure the functioning device is in play?

(That would work if you can know what is expected of a device at all times
to be able to make that fault determination -- like a power supply, etc.)

On a side/different subject...
What would be nice is some RIGID coax with right-angle fittings that I
could \"fit\" to the space (and shape) available. E.g., imagine fitting
copper pipe together -- you could get nearly any tightly defined shape you
want with the right lengths of straight pipe and ells. Admittedly, a bit
of labor/assembly involved but you\'d only have to do it once.

Is there something like this, available?

I\'ve never seen any, and I used to have catalogs from just about every
supplier to CATV and Broadcasting.
I\'ve seen *specific* examples of this -- but they appear to have been
custom made for particular applications. I.e., not like you could
buy any given size/shape *or* assemble what you need like Lincoln Logs.
RMS used to make high quality right angle
adapters, but I think they went out of business.
I\'ve found right-angle adapters -- but they are male-to-female; useful for
connecting a cable to a bulkhead connector at right angles (instead of
sticking \"straight out\"). Were the adapters you mentioned cable of fitting
cable-to-cable?

No, I\'ve never seen a cable to cable version.

I had a bag of them, but I
have no idea where they are. I used to sell a lot of three and six inch RG6
jumpers with Hex crimped F fittings.
What was the expected use for a short STRAIGHT piece of RG6? Bend radius is
such that I\'d imagine it would be hard to use it in any form OTHER than
straight!

Remember VCRs? Some people used a splitter to feed a second recorder so they could keep watching TV. A six inch jumper kept the splitter up and out of sight. the 18 and 36 inch kept the VCR\'s cables hidden, as well.

I was selling at a flea market on
weekends. I had a couple thousand feet of RG6 and RG59 remnants. I was
making six\', 12\' 25\' and custom length jumpers.
That\'s *feet*, not inches. So, you decided there was a use for the
bits left over?

I rescued a 1000\' spool which is how I ended up with RG6Q. I might have
preferred to use something else for ease of routing (the RG6 feels like
narrow gauge hose!)

Try running it in 1/2\" EMT! A lazy civilian at Ft. Rucker decided that we needed to replace all the RG59 in the shop with RG6. It was almost all in conduit, inside concrete block walls I\'m sure that some of them exceeded the 360 degree rule.

Perhaps I can do this \"interconnect wiring\" with RG59? It\'s 75 ohm
as well (58 is 50, IIRC). I should look into that -- both electrically
and mechanically (it may also be too stiff for the space available).

You can buy some fairly soft RG59, but it isn\'t quad shield. It also comes in black, white and beige. For short runs the increased insertion loss is negligible. It has a tighter bend radius. One trick to doing a complex but neat install is to lay it out on cardboard after connecting everything. Poke holes in the cardboard to keep everything in position, then use the cardboard as a template. There are cable clams made to hold the coax in place. I recently bought two types:
https://www.ebay.com/itm/262782187047
https://www.ebay.com/itm/264036572918

I preferred doing it on 1/2\" plywood. Wire it all up, then screw it to the wall. That way if you make major changes, you build a new one, and replace the old without worry about too many holes in the wall. Some furring strips down the two sides let you hide a lot of cable behind the plywood. Jerrold used to make wall mounted cabinets for this, but they were $300 in the early \'70s.

 

[Don Y]

On 10/29/2020 5:10 PM, Michael Terrell wrote:

On Tuesday, October 27, 2020 at 3:22:29 PM UTC-4, Don Y wrote:
On 10/27/2020 1:12 AM, Michael Terrell wrote:

I\'ve found right-angle adapters -- but they are male-to-female; useful
for connecting a cable to a bulkhead connector at right angles (instead
of sticking \"straight out\"). Were the adapters you mentioned cable of
fitting cable-to-cable?

No, I\'ve never seen a cable to cable version.

I could hack together such a beast -- M-F 90 feeding a F-F. But, that just
seems like a boatload of connections to worry about loosening as the cable is
flexed, potential impedance bumps, etc.

I had a bag of them, but I have no idea where they are. I used to sell a
lot of three and six inch RG6 jumpers with Hex crimped F fittings.
What was the expected use for a short STRAIGHT piece of RG6? Bend radius
is such that I\'d imagine it would be hard to use it in any form OTHER
than straight!

Remember VCRs? Some people used a splitter to feed a second recorder so they
could keep watching TV. A six inch jumper kept the splitter up and out of
sight. the 18 and 36 inch kept the VCR\'s cables hidden, as well.

Oh, OK. I\'d have thought a bit longer but I see the point.

I was selling at a flea market on weekends. I had a couple thousand feet
of RG6 and RG59 remnants. I was making six\', 12\' 25\' and custom length
jumpers.
That\'s *feet*, not inches. So, you decided there was a use for the bits
left over?

I rescued a 1000\' spool which is how I ended up with RG6Q. I might have
preferred to use something else for ease of routing (the RG6 feels like
narrow gauge hose!)

Try running it in 1/2\" EMT! A lazy civilian at Ft. Rucker decided that we
needed to replace all the RG59 in the shop with RG6. It was almost all in
conduit, inside concrete block walls I\'m sure that some of them exceeded the
360 degree rule.

I\'d almost have prefered that, given I was trying to snake cable through
places that didn\'t really have clearances for them (no attics, here).

Perhaps I can do this \"interconnect wiring\" with RG59? It\'s 75 ohm as well
(58 is 50, IIRC). I should look into that -- both electrically and
mechanically (it may also be too stiff for the space available).

You can buy some fairly soft RG59, but it isn\'t quad shield. It also comes
in black, white and beige. For short runs the increased insertion loss is
negligible.

Is insertion loss the only thing I\'d have to worry about? Foot long pieces
would be inconsequential, in that case. (the other RG6 runs are 50-100 ft)

It has a tighter bend radius. One trick to doing a complex but
neat install is to lay it out on cardboard after connecting everything. Poke
holes in the cardboard to keep everything in position, then use the
cardboard as a template. There are cable clams made to hold the coax in
place. I recently bought two types: https://www.ebay.com/itm/262782187047
https://www.ebay.com/itm/264036572918

I preferred doing it on 1/2\" plywood. Wire it all up, then screw it to the
wall. That way if you make major changes, you build a new one, and replace
the old without worry about too many holes in the wall. Some furring strips
down the two sides let you hide a lot of cable behind the plywood. Jerrold
used to make wall mounted cabinets for this, but they were $300 in the early
\'70s.

I\'m severely constrained on space and volume. And, \"appearance\" lest my
other half give me The Eye... Hence the need for a really tight placement
and routing of the components involved. I have two other beta sites that
are commercial so I can be more luxurious in those installations (here,
I\'m trying to shoehorn things into pantrys, walls, etc. to keep them
out of sight)

If the cable is reasonably flexible, I could route/laser-cut channels in
some lexan block and lay the cables in those, fasten a sheet of lexan on
top and its a nice impervious block. Bolt the block directly to the wall
and just worry about the connections on each end being accessible (with
a tiny bit of flex to act as service loop)

Thanks! I\'ll start looking for cable. Any keywords I should use in a
search? Or, do I need to actually play touch-feely to determine amount of
flex?

 

[Michael Terrell]

On Thursday, October 29, 2020 at 11:25:40 PM UTC-4, Don Y wrote:

On 10/29/2020 5:10 PM, Michael Terrell wrote:
On Tuesday, October 27, 2020 at 3:22:29 PM UTC-4, Don Y wrote:
On 10/27/2020 1:12 AM, Michael Terrell wrote:

I\'ve found right-angle adapters -- but they are male-to-female; useful
for connecting a cable to a bulkhead connector at right angles (instead
of sticking \"straight out\"). Were the adapters you mentioned cable of
fitting cable-to-cable?

No, I\'ve never seen a cable to cable version.

I could hack together such a beast -- M-F 90 feeding a F-F. But, that just
seems like a boatload of connections to worry about loosening as the cable is
flexed, potential impedance bumps, etc.

Use a wrench to tighten them. They won\'t come loose. I don\'t remember the torque spec for F connectors, but there were small \'click type\' torque wrenches made for this task.

Remember VCRs? Some people used a splitter to feed a second recorder so they
could keep watching TV. A six inch jumper kept the splitter up and out of
sight. the 18 and 36 inch kept the VCR\'s cables hidden, as well.

Oh, OK. I\'d have thought a bit longer but I see the point.

I was selling at a flea market on weekends. I had a couple thousand feet
of RG6 and RG59 remnants. I was making 6\', 12\' 25\' and custom length
jumpers.
That\'s *feet*, not inches. So, you decided there was a use for the bits
left over?

I rescued a 1000\' spool which is how I ended up with RG6Q. I might have
preferred to use something else for ease of routing (the RG6 feels like
narrow gauge hose!)

Try running it in 1/2\" EMT! A lazy civilian at Ft. Rucker decided that we
needed to replace all the RG59 in the shop with RG6. It was almost all in
conduit, inside concrete block walls I\'m sure that some of them exceeded the
360 degree rule.

I\'d almost have prefered that, given I was trying to snake cable through
places that didn\'t really have clearances for them (no attics, here).

We had several pieces break, inside the conduit. We were using pulling compound, but there was the old, dried out compound from thee original cable that had collected in some spots.

Perhaps I can do this \"interconnect wiring\" with RG59? It\'s 75 ohm as well
(58 is 50, IIRC). I should look into that -- both electrically and
mechanically (it may also be too stiff for the space available).

You can buy some fairly soft RG59, but it isn\'t quad shield. It also comes
in black, white and beige. For short runs the increased insertion loss is
negligible.

Is insertion loss the only thing I\'d have to worry about? Foot long pieces
would be inconsequential, in that case. (the other RG6 runs are 50-100 ft)

Good quality CATV grade coax is swept out past 1GHz. They stared sweeping every spool in the mid \'80s. We used Belden and Times.

It has a tighter bend radius. One trick to doing a complex but
neat install is to lay it out on cardboard after connecting everything. Poke
holes in the cardboard to keep everything in position, then use the
cardboard as a template. There are cable clams made to hold the coax in
place. I recently bought two types: https://www.ebay.com/itm/262782187047
https://www.ebay.com/itm/264036572918

I preferred doing it on 1/2\" plywood. Wire it all up, then screw it to the
wall. That way if you make major changes, you build a new one, and replace
the old without worry about too many holes in the wall. Some furring strips
down the two sides let you hide a lot of cable behind the plywood. Jerrold
used to make wall mounted cabinets for this, but they were $300 in the early
\'70s.

I\'m severely constrained on space and volume. And, \"appearance\" lest my
other half give me The Eye... Hence the need for a really tight placement
and routing of the components involved. I have two other beta sites that
are commercial so I can be more luxurious in those installations (here,
I\'m trying to shoehorn things into pantries, walls, etc. to keep them
out of sight)

Mount it to the ceiling in a pantry?

If the cable is reasonably flexible, I could route/laser-cut channels in
some lexan block and lay the cables in those, fasten a sheet of Lexan on
top and its a nice impervious block. Bolt the block directly to the wall
and just worry about the connections on each end being accessible (with
a tiny bit of flex to act as service loop)

I would use a piece of Luann plywood, so it hides the hardware.

Thanks! I\'ll start looking for cable. Any keywords I should use in a
search? Or, do I need to actually play touch-feely to determine amount of
flex?

Name brands are made with more plasticizer. The softest RG59 uses a layer of foil and one braid. My preference was always Belden. The absolute worst was made by \'Jeresy Specialty\' It was stiff on the spool, and quickly outgassed the plasticizer to the point that the jacket would crack if you bent it.. Radio Shack wasn\'t much better. Some looked like less than 50% braid.
The most common these days is \'Quad Shield\', and it is stiff. That is two layers of foil, and two layers of braid. The two types of cable use different connectors, as well. I don\'t know what brand the sell at HD or Lowes these days, but you can buy it by the foot and you can handle it before buying ..