D
Don Y
Guest
On 7/29/2020 10:31 PM, Ricketty C wrote:
You can see the address of the server WHILE you are connected to it.
You can only diagnose YOUR path.
Presumably, you can ask others to do the same with THEIR paths.
The number of hops isn\'t the issue, in a vacuum. All it tells you is that
there are some number of devices in the path that can introduce latency
and jitter. A *wire* has a fixed latency and no jitter.
The actual devices that YOUR packets travel through are likely not
the same (physical) devices that someone else\'s packets travel through.
E.g., I know that the first hop, here, has ONLY one data source/sink
attached -- THIS PC. Likewise, I know that the second hop (to the
transceiver on the roof) has just one device feeding it (from THIS end).
So, I expect those delays and latencies to be invariant.
The next hop will depend on how many devices are pushing traffic through
the remote access point that I\'m tied to. Likewise, the hop after that
will likely see traffic from all of the access points in town. And,
the point in phoenix will no doubt be fed from many different localities.
I can neither control that traffic nor measure it.
But, because the route is exposed (or exposable) to me, I can make
some deductions on how it MIGHT be affected, over time. I\'m willing
to bet that the path from google back to me has the first n hops seeing
different performance figures than the first n hops from me to them! :>
Because <something> is processing more data (bandwidth or connections).
You should be able to see an increase in the delay between successive
nodes AT the \"problem/bottleneck device\".
Similarly, Joerg should be able to see where *his* problems lie -- or,
those of the folks with which he is communicating. Just saying \"it doesn\'t
work\" or \"it works like shit at certain times of day\" doesn\'t tell anyone
anything.
You can view video at much lower bitrates than that. Our local library
delivers ~400K to each workstation and that\'s very viewable. Esp given
that most video compressors can achieve really high (50x) rates of compression.
Some compressors (e.g., MJPEG) are largely immune to changes in scene
so present a more invariant bandwidth requirement (than others).
Also, video can be designed to tolerate \"dropouts\" much better than audio
(if your image FREEZES, momentarily, it may make the overall presentation a
bit \"jerky\" but likely is still discernible (unless there are significant
events that can be completely elided by the dropout). OTOH, you can\'t
\"freeze\" an audio signal (to bridge a dropout) and hope to retain any
intelligibility.
I can\'t measure the end to end delays. My connection is only to the Zoom
server. Someone else\'s connection is from their source to the server. I
don\'t have an IP address for the Zoom server so I can\'t even check mine.
You can see the address of the server WHILE you are connected to it.
You can only diagnose YOUR path.
Presumably, you can ask others to do the same with THEIR paths.
Your tools don\'t provide any indication of where the problem is, only that
there is a problem between two end points. I already know the problem with
the other guy\'s audio is at his end because there are four or more people in
the conference call and when his audio starts to drop out everyone hears it,
not just me.
Do I not understand what you\'ve said? What tool do you have that will point
to the source of the problem other than that it is in my link or not? I
already know my link is crappy, that\'s why I turn off my video. Nothing I
can learn about details of my link will be of any value unless it in my home
which I know it is not.
I don\'t agree that counting hops is useful. I have the same number of local
hops to reach 8.8.8.8 as the Zoom server and at this time of night the
The number of hops isn\'t the issue, in a vacuum. All it tells you is that
there are some number of devices in the path that can introduce latency
and jitter. A *wire* has a fixed latency and no jitter.
The actual devices that YOUR packets travel through are likely not
the same (physical) devices that someone else\'s packets travel through.
E.g., I know that the first hop, here, has ONLY one data source/sink
attached -- THIS PC. Likewise, I know that the second hop (to the
transceiver on the roof) has just one device feeding it (from THIS end).
So, I expect those delays and latencies to be invariant.
The next hop will depend on how many devices are pushing traffic through
the remote access point that I\'m tied to. Likewise, the hop after that
will likely see traffic from all of the access points in town. And,
the point in phoenix will no doubt be fed from many different localities.
I can neither control that traffic nor measure it.
But, because the route is exposed (or exposable) to me, I can make
some deductions on how it MIGHT be affected, over time. I\'m willing
to bet that the path from google back to me has the first n hops seeing
different performance figures than the first n hops from me to them! :>
latencies are low and consistent. During prime time when everyone is
watching videos the latency gets worse.
Because <something> is processing more data (bandwidth or connections).
You should be able to see an increase in the delay between successive
nodes AT the \"problem/bottleneck device\".
Similarly, Joerg should be able to see where *his* problems lie -- or,
those of the folks with which he is communicating. Just saying \"it doesn\'t
work\" or \"it works like shit at certain times of day\" doesn\'t tell anyone
anything.
I think I mentioned before that on
the holiday weekends when everyone is here at the lake it is a disaster.
The WISP provider said he would be installing a new fiber (I thought his
network connections were wireless, but I guess they go to fiber somewhere)
to a local tower and things will improve. Maybe I can share video on Zoom
then.
Joe talked about 25 Mbps being ok. I have 7 Mbps max and often only see 2
or 3 Mbps.
You can view video at much lower bitrates than that. Our local library
delivers ~400K to each workstation and that\'s very viewable. Esp given
that most video compressors can achieve really high (50x) rates of compression.
Some compressors (e.g., MJPEG) are largely immune to changes in scene
so present a more invariant bandwidth requirement (than others).
Also, video can be designed to tolerate \"dropouts\" much better than audio
(if your image FREEZES, momentarily, it may make the overall presentation a
bit \"jerky\" but likely is still discernible (unless there are significant
events that can be completely elided by the dropout). OTOH, you can\'t
\"freeze\" an audio signal (to bridge a dropout) and hope to retain any
intelligibility.