"Flexible" redundancy

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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"...

Re: "Flexible" redundancy
On Saturday, October 24, 2020 at 11:33:15 PM UTC-4, Don Y wrote:
Quoted text here. Click to load it

   This reminds me of the 'Automatic Failover' of TV sync generators, in th
e early '70s. Grass Valley Monochrome NTSC system of two Sync Generators an
d 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 exte
rnal source.

Re: "Flexible" redundancy
On 10/25/20 10:55 AM, Michael Terrell wrote:
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: "Flexible" redundancy
On 10/25/2020 8:04 AM, Phil Hobbs wrote:
Quoted text here. Click to load it

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

Re: "Flexible" redundancy
Quoted text here. Click to load it

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?

Re: "Flexible" redundancy
On 10/26/2020 10:34 PM, Cydrome Leader wrote:
Quoted text here. Click to load it

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)"

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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)

Re: "Flexible" redundancy
On 10/26/2020 11:13 PM, Don Y wrote:
Quoted text here. Click to load it

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.

Re: "Flexible" redundancy
On 10/26/20 12:24 AM, Don Y wrote:
Quoted text here. Click to load it





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?


Re: "Flexible" redundancy
On 10/27/2020 7:19 PM, Reinhardt Behm wrote:
Quoted text here. Click to load it


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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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]

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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).

Re: "Flexible" redundancy
On 10/27/2020 11:03 PM, Don Y wrote:
Quoted text here. Click to load it

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.

Re: "Flexible" redundancy
On 10/25/2020 7:55 AM, Michael Terrell wrote:
Quoted text here. Click to load it

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...

Re: "Flexible" redundancy
On Sunday, October 25, 2020 at 12:30:00 PM UTC-4, Don Y wrote:
Quoted text here. Click to load it
y  
Quoted text here. Click to load it
 to  
Quoted text here. Click to load it
an  
Quoted text here. Click to load it
he  
Quoted text here. Click to load it
and  
Quoted text here. Click to load it
d  
Quoted text here. Click to load it
rce  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

They didn't have to be identical, they just had to supply a comparable sign
al. Otherwise, I couldn't have transferred to an external source with a sli
ghtly 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 ho
t swap the  Sync Generator modules, and the cage had two power supplies, ei
ther of which could power the entire system. It was designed to run 24/7 fo
r decades.

In some studios, they used more than one sync system. Individual groups cou
ld continue to function, even if the master system Sync Generators both fai
led. The failover was a separate subsystem, and you could use as many as yo
u wanted, but timing delays would be introduced if you weren't careful in t
he 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 le
ngth had to match to within 1/4"

Re: "Flexible" redundancy
On 10/25/2020 2:14 PM, Michael Terrell wrote:
Quoted text here. Click to load it

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"?

Quoted text here. Click to load it

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?

Re: "Flexible" redundancy
On Monday, October 26, 2020 at 12:25:30 AM UTC-4, Don Y wrote:
Quoted text here. Click to load it
  
Quoted text here. Click to load it
t  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
e  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
y  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
ing  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
ity  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
; if  
Quoted text here. Click to load it
e an  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
th a  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

Back then, equipment was replaced as needed after a studio was built. Unlik
e 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 ne
w IC based unit.

Quoted text here. Click to load it
d hot  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
4/7  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
oth  
Quoted text here. Click to load it
y as  
Quoted text here. Click to load it
l in  
Quoted text here. Click to load it
very  
Quoted text here. Click to load it
 to  
Quoted text here. Click to load it
 if  
Quoted text here. Click to load it
s  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

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 cou
ld leave the current generator, or select the one you just repaired.

Quoted text here. Click to load it
s  
Quoted text here. Click to load it
t  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
tle  
Quoted text here. Click to load it
le  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
gle  
Quoted text here. Click to load it
h  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

I've never seen any, and I used to have catalogs from just about every supp
lier to CATV and Broadcasting. RMS used to make high quality right angle ad
apters, but I think they went out of business. I had a bag of them, but I h
ave 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 week
ends. I had a couple thousand feet of RG6 and RG59 remnants. I was making s
ix', 12' 25' and custom length jumpers. I had some scraps that were too sho
rt, 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.

Re: "Flexible" redundancy
On 10/27/2020 1:12 AM, Michael Terrell wrote:

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.)

Quoted text here. Click to load it


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.

Quoted text here. Click to load it

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?

Quoted text here. Click to load it

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!

Quoted text here. Click to load it

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).

Quoted text here. Click to load it



Re: "Flexible" redundancy
On Tuesday, October 27, 2020 at 3:22:29 PM UTC-4, Don Y wrote:
Quoted text here. Click to load it
  
Quoted text here. Click to load it
be  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
hese  
Quoted text here. Click to load it
nlike  
Quoted text here. Click to load it
ou  
Quoted text here. Click to load it
 new  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
s)  
Quoted text here. Click to load it
igned  
Quoted text here. Click to load it
r  
Quoted text here. Click to load it
Or,  
Quoted text here. Click to load it
as a  
Quoted text here. Click to load it
could  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
s  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
 you  
Quoted text here. Click to load it
it  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
r  
Quoted text here. Click to load it
g  
Quoted text here. Click to load it

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

Quoted text here. Click to load it
 RG6  
Quoted text here. Click to load it
is  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

Remember VCRs? Some people used a splitter to feed a second recorder so the
y 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.


Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

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

Quoted text here. Click to load it

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 n
egligible. It has a tighter bend radius. One trick to doing a complex but n
eat install is to lay it out on cardboard after connecting everything. Poke
 holes in the cardboard to keep everything in position, then use the cardbo
ard 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 ear
ly '70s.

Re: "Flexible" redundancy
On 10/29/2020 5:10 PM, Michael Terrell wrote:
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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).

Quoted text here. Click to load it

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)

Quoted text here. Click to load it

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?

Re: "Flexible" redundancy
On Thursday, October 29, 2020 at 11:25:40 PM UTC-4, Don Y wrote:
Quoted text here. Click to load it
  
Quoted text here. Click to load it
d  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
t  
Quoted text here. Click to load it
e is  
Quoted text here. Click to load it

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

Quoted text here. Click to load it
 they  
Quoted text here. Click to load it
of  
Quoted text here. Click to load it
eet  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
s  
Quoted text here. Click to load it
e  
Quoted text here. Click to load it
e  
Quoted text here. Click to load it
we  
Quoted text here. Click to load it
in  
Quoted text here. Click to load it
d the  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

We had several pieces break, inside the conduit. We were using pulling comp
ound, but there was the old, dried out compound from thee original cable th
at had collected in some spots.
Quoted text here. Click to load it
well  
Quoted text here. Click to load it
mes  
Quoted text here. Click to load it
is  
Quoted text here. Click to load it
s  
Quoted text here. Click to load it
)

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

Quoted text here. Click to load it
 Poke  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
47  
Quoted text here. Click to load it
the  
Quoted text here. Click to load it
ace  
Quoted text here. Click to load it
rips  
Quoted text here. Click to load it
old  
Quoted text here. Click to load it
early  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

Mount it to the ceiling in a pantry?

Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

I would use a piece of Luann plywood, so it hides the hardware.
Quoted text here. Click to load it
  
Quoted text here. Click to load it

Name brands are made with more plasticizer. The softest RG59 uses a layer o
f foil and one braid. My preference was always Belden. The absolute worst w
as made by 'Jeresy Specialty' It was stiff on the spool, and quickly outgas
sed 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 l
ayers of foil, and two layers of braid. The two types of cable use differen
t connectors, as well. I don't know what brand the sell at HD or Lowes thes
e days, but you can buy it by the foot and you can handle it before buying  
.

Re: "Flexible" redundancy
On 10/30/2020 1:45 PM, Michael Terrell wrote:
Quoted text here. Click to load it

OK.  I've typically just tightened them enough to "not be loose" (as they
tend not to see any physical abuse).

Quoted text here. Click to load it

Hah!  Shirley you jest!

Ceilings of the pantry, cupboard, hall closet have all been claimed.

The lowest foot of the cupboard has been commandeered as has the lowest
TWO feet of the pantry.

I've located my distribution amp *above* the ceiling, adjacent to
the front door (this space has to be accessed from outside the house).

Walls in furnace room are covered with bits of kit.

The garage is littered with stuff on walls and affixed to ceiling.
I'll be mounting a track for an "architectural floodlight" in
the garage later this week so I can tweek the position later.
Big.  Heavy.
<https://www.lumenpulse.com/products/1385/lumenbeam-grande-color-changing

[I just love toys!  Especially when they're free!  :> ]

All of this is tastefully done; it doesn't look like a hobbyist's
tinkering.  E.g., custom stainless steel enclosures for any electronics,
molded enclosures for appliances, recessed speakers, etc.

The closets in the bedrooms are available -- but, are off the beaten
track.

Quoted text here. Click to load it

I was going to mount to the wall (the "lowest two feet of the pantry").
There's a bunch of other kit that needs to hide there, as well
(cable modem, DSL modem, PSTN interface, etc.)

The electronics need to breathe as these things draw a fair bit of power
and are in a closed space with no practical ventilation (I may add a low
CFM fan to vent through the door if temperature rise becomes a problem)

I've also considered on the walls *near* the ceiling in the laundry
room.  But, that would be a bit of an eyesore.  I've tried to hide
everything so the house doesn't look like a "lab".

Quoted text here. Click to load it

OK, as long as it's not some "specialty" item, I'll just go with Belden.
I've a spool of Belden RG58U but wrong impedance.

Quoted text here. Click to load it

I'll only need a dozen feet (including waste) so I'm sure I can find what I
need.  And, already have the crimping tool and connectors...

Thanks!


Re: "Flexible" redundancy
On Friday, October 30, 2020 at 6:59:45 PM UTC-4, Don Y wrote:
Quoted text here. Click to load it
 I  
Quoted text here. Click to load it

I would send you some, but what little I have left is 35 years old. Fresh c
able is much softer. If you don't have the little torque wrench, the rule o
f thumb was 1/8 turn, after finger tight for indoors. Outdoors sometimes to
ok a little bit more, and they were often filled with a little silicone gre
ase to keep the treads from corroding. We also used the Raychem self shrink
ing tubing for outside connectors. They came two to a pouch, in a liquid ch
emical. As it evaporated, it shrank by 50%. They were used, rather than ris
k burn marks on a wall where a splitter was installed, and we used them at  
the taps.

Site Timeline