Unencumbered by any real knowledge, the only thing that comes to mind is
bad connections: disconnect Ethernet plugs, clean contacts, reconnect.

Are there any other explanations - perhaps with solutions that do not
require driving to the site?

Here's a clip from the Ping log: ----------------------------------------------------------------------
Pinging 10.0.0.136 with 32 bytes of data:
2016 08-11 20:04:47.29 Request timed out.
2016 08-11 20:04:51.28 Request timed out.
2016 08-11 20:04:55.28 Request timed out.
2016 08-11 20:04:59.28 Reply from 10.0.0.136: bytes=32 time=4ms TTL=64
2016 08-11 20:04:59.35 Request timed out.
2016 08-11 20:05:03.28 Request timed out.
2016 08-11 20:05:07.30 Request timed out.
2016 08-11 20:05:11.31 Request timed out.
2016 08-11 20:05:15.29 Reply from 10.0.0.136: bytes=32 time<1ms TTL=64
2016 08-11 20:05:15.36 Request timed out.
2016 08-11 20:05:19.28 Request timed out.
2016 08-11 20:05:23.29 Reply from 10.0.0.136: bytes=32 time=2ms TTL=64
2016 08-11 20:05:23.36 Request timed out.
2016 08-11 20:05:27.28 Request timed out.
2016 08-11 20:05:31.28 Reply from 10.0.0.136: bytes=32 time=4ms TTL=64
2016 08-11 20:05:31.36 Reply from 10.0.0.136: bytes=32 time<1ms TTL=64
2016 08-11 20:05:31.40 Request timed out.
2016 08-11 20:05:35.28 Request timed out.
2016 08-11 20:05:39.28 Request timed out.
2016 08-11 20:05:43.29 Request timed out.
2016 08-11 20:05:47.28 Request timed out.
2016 08-11 20:05:51.28 Request timed out.
2016 08-11 20:05:55.28 Request timed out.
2016 08-11 20:05:59.28 Request timed out.
2016 08-11 20:06:03.28 Reply from 10.0.0.136: bytes=32 time=6ms TTL=64
2016 08-11 20:06:03.33 Reply from 10.0.0.136: bytes=32 time=1ms TTL=64
2016 08-11 20:06:03.38 Reply from 10.0.0.136: bytes=32 time=1ms TTL=64
2016 08-11 20:06:03.46 Reply from 10.0.0.136: bytes=32 time<1ms TTL=64
2016 08-11 20:06:03.50 Reply from 10.0.0.136: bytes=32 time=2ms TTL=64
2016 08-11 20:06:03.55 Request timed out.
2016 08-11 20:06:07.29 Reply from 10.0.0.136: bytes=32 time=1ms TTL=64
2016 08-11 20:06:07.33 Request timed out.
2016 08-11 20:06:11.36 Request timed out.
2016 08-11 20:06:15.29 Request timed out.
2016 08-11 20:06:19.28 Request timed out.
2016 08-11 20:06:23.28 Request timed out.
2016 08-11 20:06:27.28 Request timed out.
2016 08-11 20:06:31.28 Reply from 10.0.0.136: bytes=32 time=447ms TTL=64
2016 08-11 20:06:31.79 Reply from 10.0.0.136: bytes=32 time=1ms TTL=64
2016 08-11 20:06:31.86 Reply from 10.0.0.136: bytes=32 time<1ms TTL=64
2016 08-11 20:06:31.96 Reply from 10.0.0.136: bytes=32 time<1ms TTL=64
2016 08-11 20:06:31.99 Request timed out.
2016 08-11 20:06:35.78 Request timed out.
2016 08-11 20:06:39.78 Request timed out.
2016 08-11 20:06:43.78 Reply from 10.0.0.136: bytes=32 time<1ms TTL=64
2016 08-11 20:06:43.82 Reply from 10.0.0.136: bytes=32 time<1ms TTL=64
2016 08-11 20:06:43.86 Reply from 10.0.0.136: bytes=32 time<1ms TTL=64
2016 08-11 20:06:44.65 Request timed out.
2016 08-11 20:06:48.28 Reply from 10.0.0.136: bytes=32 time=1ms TTL=64
2016 08-11 20:06:48.32 Request timed out.
2016 08-11 20:06:52.28 Reply from 10.0.0.136: bytes=32 time<1ms TTL=64
2016 08-11 20:06:52.32 Reply from 10.0.0.136: bytes=32 time<1ms TTL=64
2016 08-11 20:06:52.37 Request timed out.
2016 08-11 20:06:56.28 Reply from 10.0.0.136: bytes=32 time<1ms TTL=64
2016 08-11 20:06:56.32 Request timed out.
2016 08-11 20:07:00.28 Reply from 10.0.0.136: bytes=32 time=9ms TTL=64
2016 08-11 20:07:00.35 Reply from 10.0.0.136: bytes=32 time<1ms TTL=64
2016 08-11 20:07:00.40 Reply from 10.0.0.136: bytes=32 time<1ms TTL=64
2016 08-11 20:07:00.44 Reply from 10.0.0.136: bytes=32 time<1ms TTL=64
2016 08-11 20:07:00.49 Request timed out.
2016 08-11 20:07:04.50 Reply from 10.0.0.136: bytes=32 time<1ms TTL=64
2016 08-11 20:07:04.72 Request timed out.
2016 08-11 20:07:08.28 Request timed out.
2016 08-11 20:07:12.29 Reply from 10.0.0.136: bytes=32 time=3ms TTL=64
2016 08-11 20:07:12.52 Reply from 10.0.0.136: bytes=32 time=2ms TTL=64 ----------------------------------------------------------------------
--
Pete Cresswell
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 11 Aug 2016 20:11:10 -0400, "(PeteCresswell)" <[email protected]d> wrote:

Unencumbered by any real knowledge, the only thing that comes to mind is
bad connections: disconnect Ethernet plugs, clean contacts, reconnect.

In 20+ years of networking, I haven't personally seen a case where an
Ethernet connector had to be cleaned. Your mileage may vary, of course, especially if your connections are exposed to weather. It's worth making
sure that the physical connection is solid, since that's a requirement for a solid electrical connection. One way to do that is to have someone check the 'link' indicator, if there is one. Typically, Ethernet connectors have both Link and Activity indicators, especially on networking gear such as switches and routers. Activity will blink to indicate activity, but Link should be
lit solidly.

Are there any other explanations - perhaps with solutions that do not
require driving to the site?

If any part of the end to end path is wireless, I would focus there. You can also do a traceroute to your intended endpoint to find the various hops
along the way. Try pinging the last hop before your endpoint to see if that
is equally unstable. Keep backing up, hop by hop, until you get solid pings. The link after that (the first one that is unstable) will be suspect, and
any links after that will be unreliable as a result.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Per Char Jackson:

If any part of the end to end path is wireless, I would focus there. You can >also do a traceroute to your intended endpoint to find the various hops
along the way. Try pinging the last hop before your endpoint to see if that >is equally unstable. Keep backing up, hop by hop, until you get solid pings. >The link after that (the first one that is unstable) will be suspect, and
any links after that will be unreliable as a result.

100% hard-wired... and the Tracert seems to show what I expected: a
direct route - since the device (an IP camera) is hung directly on
to the same switch that the server PC is connected to: ==================================================
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

D:\Bat>traceroute 10.0.0.136
'traceroute' is not recognized as an internal or external command,
operable program or batch file.

D:\Bat>tracert 10.0.0.136

Tracing route to 10.0.0.136 over a maximum of 30 hops

1 2 ms 3 ms 3 ms 10.0.0.136

Trace complete.

D:\Bat>
D:\Bat>tracert 10.0.0.136

Tracing route to 10.0.0.136 over a maximum of 30 hops

1 2 ms <1 ms 3 ms 10.0.0.136

Trace complete.

D:\Bat>
===============================================
--
Pete Cresswell
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 13 Aug 2016 15:06:54 -0400, "(PeteCresswell)" <[email protected]d> wrote:

Per Char Jackson:

If any part of the end to end path is wireless, I would focus there. You can >>also do a traceroute to your intended endpoint to find the various hops >>along the way. Try pinging the last hop before your endpoint to see if that >>is equally unstable. Keep backing up, hop by hop, until you get solid pings. >>The link after that (the first one that is unstable) will be suspect, and >>any links after that will be unreliable as a result.

100% hard-wired... and the Tracert seems to show what I expected: a
direct route - since the device (an IP camera) is hung directly on
to the same switch that the server PC is connected to:

Oh, I didn't realize that the two endpoints were directly connected via a switch, although the successful pings do have a consistently low response
time indicating that.

Bottom line then, there are only 3 pieces of hardware involved (PC, switch,
and camera) and two Ethernet cables. Can you test by substitution? Do pings from that PC to another endpoint respond reliably? If so, the PC, its
Ethernet cable, and most likely the switch are all fine. Or, can you ping
that camera from another PC on the LAN? If that works reliably, then the camera, its Ethernet cable, and most likely the switch are all fine. See
what I mean?

With really nothing to go on, my suspicions would be Ethernet cable(s),
camera, switch, in that order, but testing by substitution should help
narrow it down. When I say switch, I think I mean its power supply.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)